There is no one right way to have teams coordinate with each other. Some key factors to consider are:
- how dependent are the teams with each other?
- what is the business planning cadence that drives the development group?
- is a set increment in a time-box for the program (SAFe’s program increment is one example) or a flow model with cadence across the program better?
- how long should the time-box/cadence of delivery be?
Coordinating teams must be driven by value realization. This means that we must use slice the items that come into our product backlogs into vertical slices that can pulled by the teams together. Here are two case studies that show how to do that:
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 by focusing on finishing
- Improving the team process
- Using a flow model with cadence in addition to the Program Increment iterations
- Managing shared services
- Options for the innovation and planning iteration
- Using consistent objectives to enable self-organization of teams across an enterprise
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.
- People must wait on other people.
- People are being continuously interrupted by other people.
- There are delays in feedback.
- There is a high multi-tasking cost.
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:
- running mini-waterfalls in a sprint
- having stories (at the team) or epics (at the program) that are too big
- when something gets completed, people (at the team) or teams (at the program) opening something new instead of helping others finish their work
- having developers and testers not collaborating
- having development teams and shared services not collaborating
- not using ATDD (I am not referring to automation of the tests but given-when-then is much better than “as a user …” when you get to buildable stories.
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.
When done with a task, try to finish another task in the same story.
When done with a story, try to finish another story within the same feature.
When done with a feature, try to finish a feature within the same MBI. This focus quickens the rate of feedback, both increasing quality and efficiency.
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.
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
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.
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.
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.
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.
- Business Alignment. Business needs drive everything in any organization, and therefore teams align their work to a common vision from the business side. Because all the Product Owners or equivalent backlog owners of all the teams are using MBIs to guide them, it is easier to achieve alignment when conflicts arise.
- Local prioritization within Business prioritization. Teams use a consistent approach to determine what’s important for them to work on and do so within the context of the business priorities.
- Velocity. Teams measure velocity in a similar way so that it can be used for cross-team forecasting, planning, and coordination.
- Collaboration. Teams work together to plan, create, and integrate. By creating a bigger picture view, teams focus on MBIs, not just their own individual backlog items in isolation. This creates a bigger team-of-teams mindset.
- Systems Thinking. Teams understand that local optimization is not as important as sustainable global optimization, and they set sustainable global optimization as the goal for any local optimizations. Therefore, local optimizations must be made within the context of the bigger picture and must be sustainable for global optimizations to be sustainable.
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.