How to “Go Faster” in SAFe
“We need to deliver faster!” How many times have you heard this phrase uttered in status meetings, planning events, and program retrospectives? It typically comes from enterprise leaders who adopted SAFe with the expectation of increased delivery. I understand the desire and the urgency behind the request, leaders want to maximize their return on investment and stay ahead of their competitors. It just makes good business sense. However, how should the program handle this request? While I’m a true believer in going slow to go fast, this message doesn’t always resonate with key stakeholders. So where do you focus your efforts? What should your action plan be and how should you communicate the plan?
I use a simplified analogy which views large development programs as a car engine. The development teams are the physical components of the engine, they need to work together, firing pistons at the right time to keep the engine running. Building, tuning, and optimizing the physical engine is hard work and takes time. If you try to increase the RPMs too quickly (scale too fast), you can end up burning out the engine and having to start over. If you try and operate the engine at 100% capacity without any breaks (innovation/planning) or performing any maintenance (tech debt) then you’ll experience wear, become less efficient, and eventually destroy the engine.
If the development teams are the physical engine of the program, then the product management team would be the fuel needed to make an engine run. Their backlog is the gas tank, and if the gas runs out, then there aren’t any requirements to fuel the teams. Think about the gas you put in your car, oil isn’t taken straight from the ground and sold at a gas station, it has to be refined into gas so your engine runs efficiently. A similar process takes place within your backlog to fuel the development teams. If your backlog isn’t refined, energy is wasted by development teams having to clarify requirements with the product team. Put simply, by focusing on the quality of your backlog refinement, you will increase the efficiency of the teams. This efficiency can usually be realized quickly, the same way that using higher quality gasoline will increase your engine’s efficiency immediately.
Focusing on the engine of a SAFe program is important and will pay off in the long run, but it’s not the place to look for quick increases in speed. Putting too much pressure on delivery, increasing the number of teams too quickly, and reducing innovation and planning will often have the opposite effect on your program’s speed, and may end in catastrophic results. On the other hand, focusing on the quality of your program backlog can give programs a faster return on investment and allow for the building and tuning of the development effort. If you are wondering where to start, below are three questions to ask the product management team to help focus your efforts.
Do we have an MVP for the Feature?
“We need to deliver faster!” How many times have you heard this phrase uttered in status meetings, planning events, and program retrospectives? It typically comes from enterprise leaders who adopted SAFe with the expectation of increased delivery. I understand the desire and the urgency behind the request, leaders want to maximize their return on investment and stay ahead of their competitors. It just makes good business sense. However, how should the program handle this request? While I’m a true believer in going slow to go fast, this message doesn’t always resonate with key stakeholders. So where do you focus your efforts? What should your action plan be and how should you communicate the plan?
I use a simplified analogy which views large development programs as a car engine. The development teams are the physical components of the engine, they need to work together, firing pistons at the right time to keep the engine running. Building, tuning, and optimizing the physical engine is hard work and takes time. If you try to increase the RPMs too quickly (scale too fast), you can end up burning out the engine and having to start over. If you try and operate the engine at 100% capacity without any breaks (innovation/planning) or performing any maintenance (tech debt) then you’ll experience wear, become less efficient, and eventually destroy the engine.
If the development teams are the physical engine of the program, then the product management team would be the fuel needed to make an engine run. Their backlog is the gas tank, and if the gas runs out, then there aren’t any requirements to fuel the teams. Think about the gas you put in your car, oil isn’t taken straight from the ground and sold at a gas station, it has to be refined into gas so your engine runs efficiently. A similar process takes place within your backlog to fuel the development teams. If your backlog isn’t refined, energy is wasted by development teams having to clarify requirements with the product team. Put simply, by focusing on the quality of your backlog refinement, you will increase the efficiency of the teams. This efficiency can usually be realized quickly, the same way that using higher quality gasoline will increase your engine’s efficiency immediately.
Focusing on the engine of a SAFe program is important and will pay off in the long run, but it’s not the place to look for quick increases in speed. Putting too much pressure on delivery, increasing the number of teams too quickly, and reducing innovation and planning will often have the opposite effect on your program’s speed, and may end in catastrophic results. On the other hand, focusing on the quality of your program backlog can give programs a faster return on investment and allow for the building and tuning of the development effort. If you are wondering where to start, below are three questions to ask the product management team to help focus your efforts.
Do we have an MVP for the Feature?
- The best way to “go faster” is to develop less for the same user value. Do the research to make sure your program isn’t gold platting solutions. Does the program have a clear priority?
- Teams spend their time task switching and putting out fires when everything is a high priority. Creating a clear backlog priority reduces this waste and allows for increased throughput.
- Having design, high-level architecture, and clear acceptance criteria figured out before development will save precious time spent running down answers.