- Thinking about Adoption & Improvement
- Early Days: Team & Management Changes
- Early Days: Breaking Barriers & Habits
- Early Days: Gatherings
- Coaching & Community
- Continuous Improvement
- Conclusion
- Recommended Readings
This chapter is from the book
This chapter is from the book
This chapter is from the book
Early Days: Breaking Barriers & Habits
Try...Break the walls—team areas with whiteboards
ScrumMasters remove barriers for teams. At Valtech India, when we saw the cube farm on the left, we arranged to gut the interior of the building, and create team areas with plenty of whiteboards.
before
)
after
)
Try...Two-week iterations to break waterfall habits
Although Scrum allows iterations of up to four weeks, this is seldom advised or practiced. The Scrum Guide suggests:
- Tip: When a Team begins Scrum, two-week Sprints allow it to learn without wallowing in uncertainty. [Schwaber09a]
When we started coaching large-scale groups in Scrum, we assumed that four-week iterations would be useful to gradually "lower the waters in the lake." What we discovered, however, was that four weeks is just long enough to maintain old habits: sequential life cycle practices, the existing single-function teams, and handoff between groups. Consequently, there was no strong force for out-ofthe-box thinking or transformation to a profoundly different organizational design with concurrent engineering, continuous integration, feature teams, and so on.
But, two-week iterations—with the goal of getting items really done according to done—do not readily allow for old habits. Things have got to change—dramatically.
A similar suggestion, for other good reasons, is found in the first book on scaling agile development:
- Although you may have heard otherwise, the larger the team is, the more important short cycles are. The reason is simple—if a large team takes a completely wrong course from the entirety of its three-month development cycle, the cost of correcting the course will be enormous. And even if the team took the correct course, it wouldn't benefit from the frequent feedback that is possible with short development cycles. [Eckstein04]
Try...One flip chart for tasks of one Product Backlog item
Figure 11.2 shows a common-style Sprint Backlog, with one row of task cards for each Product Backlog item, and three columns: to do, underway (meaning, WIP), and complete (meaning, done).
)
Figure 11.2 Sprint Backlog—rows for each item, columns for to do, underway (meaning, WIP), and complete.
In the early days of a big-group adoption, a coach will notice—by looking at this display and in the behavior of the team—two symptoms of old habits:
- Many tasks cards at the same time are in the underway column—there is high WIP.
- Key point—task cards for multiple backlog items are in the WIP column because people are thinking "I only do my special tasks."
For example, "I am an interaction designer. I have finished my interaction design tasks for item-1. Therefore, no more tasks for me in item-1, so I will start on my interaction design tasks for item-2."
Team members have primary specialities, and will do tasks in those areas, but when those are finished, the idea is for team members to take on other tasks of the current item in progress, in less familiar areas—perhaps in an area of secondary speciality. This both reduces WIP and increases multi-area learning.
A visual management technique to encourage this is illustrated in Figure 11.3. Now, the Sprint Backlog is spread across a set of flip chart posters. Each Product Backlog item has task cards on a separate poster—and each poster has the three common columns: to do, WIP, done. Now—key point—the team displays only one or two posters on the wall at a time;9 the other posters (items) are out of sight. Then, the whole team focuses on getting one item at a time done, increasing learning and reducing WIP.
)
Figure 11.3 one flip chart for each item