The implementation and integration part of SAFe is very solid and represents real value-added work. Here are some areas for potential improvement.
Focusing on managing Work-in-Process with a focus on finishing
Work-in-Process (WIP) is not just the work you are working on. It is anything that has been started and not yet completed. This means once you have started work on a Minimum Business Increment (MBI), epic, feature or story, it is WIP until it is released.
Managing WIP is a recurring process. Once you have sequenced your work in the proper order, you can allocate your capacity to the items that are truly most important. Do not start projects that adversely affect more important ones merely to “utilize” your people.
Managing WIP is essential. You are not trying to achieve the “one-piece flow” that Lean-Manufacturing emphasizes; rather, you are trying to avoid working on too many things at one time.
Here are some symptoms for WIP that is out of control.
Certainly, if a team is trying to work on two things at the same time when they could be focusing on finishing just one, the delivery of both will be delayed. But what is less obvious is what happens when working on one project and then another and then coming back to the first. This is called interleaving work. These delays in workflow and feedback induces yet more additional work. This is why a one-week interruption delays what people are working on by more than a week. The week spent on the interrupting work causes additional work to be done because the effort interrupted cannot just be picked up again without a cost.
Common root causes for too much WIP
Besides the obvious “starting too many things” these also are common root causes:
WIP Limits and a focus on finishing
We don’t recommend using WIP Limits at the beginning of a transformation. They are not really needed and may complicate things. In the early part of the value stream, WIP can be managed just by having teams pull work only when they are ready.
It is often more effective to create a focus on finishing at various levels.
Too many Kanban implementations don’t focus enough on collaboration and cross-functional teams. In this case they sometimes overcompensate by having WIP limits in place.
Focus on finishing stories in the sprint and on delivery value in the Program Increment
A common challenge in Scrum is having a burn-down graph that looks like a hockey stick at the end of the sprint. That is, few stories are completed until near the end of the sprint. At the Program Increment level, the same thing can happen where business value is not realized until the end. Your goal is always to avoid “hockey stick” delivery graphs.
It is important to focus on completing MBIs throughout the Program Increment. The reason is that many features will not realize value by themselves but will require other features to do so. Trains can get quite a few features done but have nothing to release.
Without a focus on MBIs it is possible, even likely, that features from different MBIs will get interleaved with each other and although we may complete our Program Increment have nothing releasable. In the same way that Work-in-Process (WIP) is managed in Scrum by focusing on completing stories, Program Increments need to focus on completing MBIs.
This shift results in an Agile planning and delivery process. Planning events usually focus on getting a release done by the end of the Program Increment (PI). But the focus should be on creating releasable value as quickly as possible – even if you don’t release until the end of the PI. This helps ensure you will have something of value at the end of the PI if things don’t work exactly according to plan.
Managing large and small MBIs
There is a common dilemma of having big projects interleaved with little ones. The question is how do you handle this? Weighted Shortest Job First (WSJF) helps with this by encouraging small increments to be delivered. From the point of view of WIP, it is better to start and finish items instead of running several at a time. But how do you manage small projects with big projects? We can learn a lot from this insightful anecdote:
I heard this story years ago at a Stephen Covey time management seminar where he described a segment of one of his classes.
Mr. Covey tells how he held up a big, open-mouthed jar. On the table were lots of rocks. He started picking up the rocks and carefully placed them in the jar until no more would fit. He then asked the attendees, “Who thinks the jar is full?”
Most people raised their hands. He then reached under the table and pulled out a box of small rocks. He started placing these rocks into the jar until no more of them would fit. Again, he asked the attendees, “Who thinks the jar is full?”
Only a few people raised their hands this time. He then reached under the table again and pulled out a bag containing sand and poured the sand into the jar until no more would fit. Then he asked the attendees, “Who thinks the jar is full, now?”
No one raised their hands, obviously thinking another trick lay in store. He then reached under the table and pulled out a pitcher of water and filled the jar with water until it could take no more. He then asked, “Can anyone tell me the lesson of this?”
One attendee responded that no matter how much you’re doing you can always do more? Covey chuckled and said, “No. It’s that you must put the big things in your life first. The smaller things will find a way in on their own. But if you don’t put in the big things first, they won’t fit in later.”
This story provides a useful insight for development. The cost-of-delay of a big increment is accounted for in WSJF, but the impact of delays to big and small stories is not. You might infer that big increments should not be interrupted. But that is not practical in the real world. If you slice up big increments into chunks that can be validated, you can interrupt them in an intelligent manner as needed by smaller pieces. Of course, it would be good to avoid this completely but that is not always possible.
Improving the team process
A combination of Scrum and Kanban is something to be considered. To best see how to do this, read the online book Lean-Agile at the Team: A Lean Approach to Scrum and Kanban (Book in work)
Using a flow model
All teams must work at the same cadence. But individual teams can use a flow model if they prefer. It’s even possible that the entire train works in this fashion.
Managing Shared Services
Shared services almost always need to be run with a Kanban system. The two main reasons for this are first, that much of their work will be determined after planning. The second is that shared services often have several specialists who cannot commit to particular teams.
Options for Innovation and Planning Iterations
At small to mid-scale the innovation and planning iteration is likely not needed. Innovation should be able to be done at these scales through the Program Increment. And the planning event should not take two full days. Note, however, that if you do the planning event in less than two eight-hour days, it is still advised that you split it over two days with each day being half a day or less.
Using consistent objectives to enable self-organization of teams across an enterprise
The context for teamwork often varies from team to team. As a result, the practices they need to use must be allowed to vary to fit the context. You want to allow this. One way to do this is to define consistent objectives for teams and allow them to define practices to meet those objectives.
Consistent objectives help teams to work together
Consistent objectives make it easier for teams to work together for these reasons.
Consistent objectives makes for a better on-boarding process
Since all teams would be implementing the same intentions, albeit in their own way, an on-boarding process would be designed to take advantage of the intentions of what a team needs to do. This would be consistent for all teams. This would also set the standard for any new teams, in that what they had to do is preset but they are allowed to do it however they want to.
Consistent objectives enables people to transfer between teams more easily
Each team would only need to make new individuals aware of how they are doing things different. Making workflows explicit on all teams, regardless of the practices they use, makes it easier for people moving to a new team to discover the new team’s workflow.
Consistent objectives ensures management has the visibility they need
Whatever it is that management truly needs to see will be one of the requirements that all teams need to manifest, albeit they can implement how they want to.
Consistent objectives promotes learning between teams
Teams are trying to accomplish the same things but are doing it in different ways. When a new way is discovered, or a team decides the intention of an existing approach is wrong, they can convey this to other teams so that the entire community of teams learn from this. Because teams are focused on the same intentions, there is more ground for common conversations and learning. This also helps avoid each team thinking they are so different from other teams that they cannot learn from other teams or cannot share what they learned with other teams.