SAFe is…well…safe

Traditionally, Iterations in a SAFe Program Increment are dedicated to delivering on User Stories and Features.  The ideal team is stable and has good, broken down work that allows for consistent delivery Iteration after Iteration.  The last thing any Scrum Master wants to see is a Velocity chart that looks more like a seismograph.

When teams get to consistent User Story delivery, the hope is that they can deliver Features consistently over the course of a PI. When talking about nailing the basics, one of the first things mentioned is meeting commitments on a regular basis.

In order to set up teams for consistent delivery, a conservative culture often develops in SAFe environments (and I’m not the only one to observe this).  SAFe encourage User Stories and Features that are well-defined, well-understood, and have minimal uncertainty.  Teams make sure their User Stories and Features are as refined as possible before committing to them in a PI or Iteration.

Conservative Culture Doesn’t Promote Innovation – and SAFe Knows This

This conservative Culture isn’t necessarily a bad thing.  Remember, it’s stemming from the lofty goal of consistent delivery.  However, it’s important to recognize that this Culture is not conducive to innovation.

The flip-side of encouraging consistent delivery is that risk taking is inherently discouraged. Anything inherently risky or uncertain is encouraged to be better refined.  This gives us predictable delivery, but how innovative can our delivery be if we’re not taking any risks?

SAFe explicitly recognizes that innovation may not really be possible during normal delivery Iteration by saying “finding time for free association and innovation in the midst of delivery deadlines can be difficult.” And they put their money where their mouth is by building in time in the PI to dedicate to innovation.

If We Really Want Innovative I/P Iterations, We Need to Deliberately Shift Culture

After 10+ weeks of conservative, consistent delivery, what are the odds that people will naturally shift into a mindset of innovation for 2 weeks?  As Agile leaders, we need to be deliberate to shift our Culture during the Innovation Iteration; otherwise, there’s a serious risk that the conservative Culture of the normal delivery cycle will bleed into the Innovation sprint.

How Can We Shift to Promote an Innovative Culture for Just One Iteration?

Hackathon

Hackathons are a common way of leveraging the Innovation Iteration to encourage novel thinking in a fun environment.  I recommend any hackathons leverage the SAFe encouragement for them to be free-form – allowing team members to work on whatever they want with whomever they want.  This is a clear shift in Culture from the hyper-organized environment during delivery sprints.

Make Time to Celebrate Failures in the Hackathon

There’s evidence that embracing failures helps encourage innovation.  If failure is actively discouraged, what incentive is there to stick out with an innovative idea if you’re likely to get hammered back down?

Take time to reflect what is being celebrated in your ART’s hackathon.  I worked with a client who celebrated the most successfully executed Hackathon deliverables, which was a great idea and added to the fun of the hackathon.  But what incentive is there to risk a truly innovative idea if only the successes are celebrated?

I encouraged the client to not just celebrate the successes, but also the failures.  We want to encourage Hackathon teams to dream big and try to build something that may not pan out.  We even implemented a “shoot for the moon” award – based on the phrase “shoot for the moon, even if you miss, you’ll land among the stars” – as a way of celebrating a Hackathon team that dreamed big, but didn’t quite hit their mark.  What a way to truly shift culture for your Hackathon Iteration by actively rewarding failed ideas. Could you imagine something like that in a traditional SAFe PI?