This is a guest post by Johanna Rothman
Many teams claim to use Scrum, often in two-week iterations. When should they think about a cadence or a flow approach to their work?
Carolina, an experienced agile test manager, started a new role, facilitating nine testers based in Lisbon. The testers worked on a total of four projects. Three of those projects were humming along. One seemed to be in trouble.
The project in trouble was the Europe Shopping Cart. That team had a counterpart in the US, the US Shopping Cart team.
Both teams were dispersed. The US Shopping Cart team was dispersed all over the US, in every single time zone. The testers were on the coasts: one tester was in New York (UTC -5) and one in San Francisco (UTC -8). That team was able to demo at least once a week.
The Europe Shopping Cart team was a different story. When that team had started, there were two testers in Lisbon (UTC +1), and two developers in Kiev (UTC +3). Then, that team needed more people. Management had decreed that they would hire two more developers in Ho Chi Minh (UTC +7).
That team was barely able to finish anything inside of a sprint. Their demos were a disaster. At least half the time, the work that was supposed to be done crashed when the Product Owner tried it.
Carolina discovered several problems:
- The team couldn’t agree on when a day started or ended. That meant they never finished what they thought they could in a given iteration.
- The team couldn’t agree what to do with the standups or when to have them. Were the standups for handing off work or recommitting to work?
- The team didn’t have enough time during a “team day” to plan together or refine new stories together. They couldn’t learn together or explain the issues to each other.
Carolina thought they weren’t a team at all. No one was happy. Everyone was frustrated—with their work and with each other.
Carolina knew their approach wasn’t working for them. She decided not to request they change any of their processes yet.
She’d ask the team if it was okay if they started to use a Kanban board to visualize their flow. She would volunteer to measure their cycle time. And, if she was lucky, she’d see if the team would agree on WIP (Work in Progress) limits.
Can Your Team Exploit the Timebox of an Iteration?
Collocated teams who work within 30 meters of each other can exploit iterations as a timebox. The team members can easily talk with each other. Everyone’s days look relatively similar, or the team can create working agreements to have core hours. The team can define the times for its various daily and weekly activities.
Distributed teams with enough hours of overlap can also use iterations. The US Shopping Cart team had four hours of overlap. That team can use iterations because everyone can agree on the same relative days. The team has enough hours of overlap that they can agree on the times for their daily and weekly activities.
The iteration provides a container for the various kinds of teamwork, including planning, demos, and retrospectives. When iterations work, the team can plan for the next couple of weeks, finish work, and reflect to improve.
However, the Europe Shopping Cart team, with their insufficient hours of overlap, have trouble defining what a team day is. When does it start? When does it end?
If you can’t tell when a team’s day starts or ends, iterations won’t work. The team has a lot of WIP at all times, never mind for a given day or the iteration.
Because the Europe Shopping Cart team had too few hours to discuss and refine the stories, they didn’t learn together. When they used a Kanban board, they realized the work bounced from developer to test and back to developers.
The big problem was the team wasn’t collaborating and learning together. Their insufficient hours of overlap prevented them from working as a team.
If you also have this challenge, you have at least two alternatives instead of iterations for your team’s work: using a cadence instead of a timebox and using flow.
Cadence Creates a Rhythm for Your Work
One distributed team I know separated their retrospective from their iterations. They conduct a retrospective every Thursday at noon Eastern, each week. It’s a cadence because they don’t stop work as a team then. Instead, they take a break from other work to focus on their inspect-and-adapt time.
Noon Eastern works for them. The people in the UK (UTC +1) are still available because it’s only 5 in the afternoon their time. The people in North Carolina (UTC -5) sometimes eat lunch during their meeting because it’s that time of day. The people in San Francisco (UTC -7) are available because it’s 9 in the morning their time.
The team agreed that they would all flex their start and end times to create that one hour of overlap.
They managed the content of their retrospectives. They normally limited their discussions to what occurred since the previous Thursday.
But, sometimes, they conduct experiments that last three or four weeks. As a team, they decide which Thursday they will address which of their experiments.
The weekly cadence helps them remember what they actually did the previous week. And, that cadence helps them start and end small experiments.
This team also separated their demos from almost everything. Because they don’t have enough hours of overlap, the Product Owner, based in North Carolina, works with the various people to make sure she understands how the stories actually work as the team members finish their work.
The PO demos each story to interested parties in real-time and creates videos of the stories for other people to see and review at their leisure.
The team doesn’t use iterations, because some of their work takes more time than their weekly cadence. But they have a drumbeat, a rhythm for their work.
Flow Might Encourage Smaller Stories
Another team with insufficient hours of overlap decided to move totally to a flow approach to their work. They have a Product Owner in New York (UTC -4) who creates stories as well as she can. The stories then move to testers in Bangalore (UTC +5.5). They create automated tests that they expect to fail. If they have questions about the acceptance criteria, they ask.
The story then moves to developers in Paris (UTC +1) and Berlin (UTC +2). They develop according to the tests and acceptance criteria. They use their group chat to ask questions as they proceed.
When the team is done, the story returns to the Product Owner for verification.
The team thought they were taking a long time to finish work. They were. Their typical cycle ranged from three to four days when they first started to measure it. (Cycle time is the time from when someone on the team takes the card off the Ready column until the team marks the card as done.)
After a few weeks of seeing where the work was and measuring the cycle time, the PO learned how to create smaller stories. The team learned how to work in smaller chunks. They were able to reduce their average cycle time to about two days.
That cycle time allows them to demo something to other people a couple of times a week. That’s enough of a project rhythm for feedback.
Select Your Project Rhythm
Iterations don’t work for every team. Especially if they have too few hours of overlap for the team members to collaborate. You can decouple the “normal” iteration events from the start or end of the iteration or day.
After Carolina measured the cycle time and learned a few more things about the Europe Shopping Cart team, she helped the team experiment with various Kanban boards. The team learned to see their WIP and cycle time. They defined a workflow with a weekly demo on Tuesdays and a weekly retrospective on Thursdays. The team is now finishing work more steadily.
In addition, she worked with her management to create whole feature teams in Vietnam, so one team didn’t have to try to work with so few hours of overlap.
When teams build and maintain a rhythm, they know what to expect. Consider how your team can build its project rhythm.
Johanna Rothman, known as the “Pragmatic Manager,” provides frank advice for your tough problems. She helps leaders and teams see problems and resolve risks and manage their product development. Johanna is the author of fourteen books and hundreds of articles. Find the <em>Pragmatic Manager</em>, a monthly email newsletter, and her blogs at <a href=”https://www.jrothman.com/” target=”_blank” rel=”noopener”>jrothman.com</a> and <a href=”https://createadaptablelife.com/” target=”_blank” rel=”noopener”>createadaptablelife.com</a>.
