Susan, a new-to-the-company program manager, could not understand why Product A was so late. The teams used a well-known agile approach. They weren't working on anything else except for production support. Yet, even though the teams worked hard, not one team could meet any of their deadlines. The teams were unhappy with their progress. They were barely able to release a feature every month.
Susan's management originally wanted to release the product last quarter. But with all the delays, it looked as if they might delay another quarter or two. Her management claimed, “Heads are going to roll!”
She did some investigation and realized the teams were not cross-functional, but component teams. They were organized as in the image on the left, which is from Project Lifecycles: How to Reduce Risks, Release Successful Products, and Increase Agility.
While Susan wasn't fond of component teams, she'd accepted them in her previous companies. However, this organization had more problems:
- Each component team was in a different part of the world. The testers lived in India and the UI team was in Spain. The middleware and backend teams were in New York and Atlanta. Each team worked alone. And because the UI and testers had fewer than four hours of overlap with the rest of the program, the program had built-in delays. As a result, they had to wait for all the teams to finish before they knew any feature worked.
- There was no program-wide checkin policy, so each team waited until they thought they were done before they checked their code or tests in.
- Whenever they had a production support issue, everyone multitasked: they stopped what they were doing on the feature and changed to production support. Inevitably, each component team required assistance from other component teams.
Susan decided there was a useful term for this: A mess.
She needed to help the teams focus so they could deliver better and faster. She started with cycle time and visualizing their feedback loops.
Tip 1: Measure the Cycle Time and See the Feedback Loops
While Susan shared everyone's frustration, she decided she needed some data to clarify what was happening. Since there were four component teams, she asked each team to measure their cycle time in two ways:
- Map their value stream to both measure cycle time and so everyone could see all the various handoffs and delays. (See Measure Cycle Time, Not Velocity to see how.)
- Create a feedback map, as in Unearthing Your Project's Delays.
With two visualizations, each component team could see their realities.
That's when all the teams realized that separating code review and testing from the coding “step” created multitasking and increased their delays. Susan asked the teams if they would collaborate and integrate code review into their normal work. (See See and Resolve Team Dependencies, Part 1: Inside the Team.)
The teams needed to practice, because moving from cooperation to collaboration changed how they work. But that was just the first step. Next up was her request to re-evaluate their check-in policy.
Tip 2: Check In and Build Daily
Because the cycle time was so long, teams tended to check their code and tests in about once every week or two. When teams wait that long, they have to reconcile everyone else's changes before they can build. That's when Susan asked everyone to check everything in on the Main trunk every day.
After the virtual uproar subsided, Susan explained that the more often everyone checked their work in, the faster they could reconcile their changes. Finally, the teams agreed to check their code in at least once every day at noon, whatever their local time was. That policy allowed everyone to build the product at least every day.
Susan continued to explain that since they were component teams, monitoring each team's cycle time wasn't enough. They had to collaborate as a program to reduce the cycle time for each completed feature. The teams needed to practice, but after a month or so, they were able to reduce their cycle time from roughly three plus weeks to under a week.
Because the teams developed smaller chunks of value, they had fewer interruptions. That helped decrease the number of production support issues. But they still needed to address the large backlog of those customer-facing problems. That's when Susan asked the teams to keep their code and tests clean.
Tip 3: Keep the Code and Tests Clean
Because the cycle time was so long and everyone had interruptions, too many people forgot to finish their code and tests. As a result, the teams unintentionally shipped incomplete product. That caused production support issues.
Now, Susan asked the teams to consider a two-pronged approach:
- Always verify that the code and tests were as clean as possible before releasing.
- When in doubt, fix a production support issue first, before finishing a feature. (This is not a universal truth, but worked for these early months when Susan supported the teams in reducing their cycle time.)
These ideas helped the teams stop multitasking and create less accidental complication for the code and tests.
Now, the teams could focus on finishing Product A. While Susan was not yet done, everyone realized how to deliver better products faster.
Principles Behind These Ideas
All teams can right-size their work, so they have a more reliable level of throughput. And all teams can check in and build at least daily. Finally, make sure your team keeps the code and tests clean, especially if they also have to manage interruptions.
If you're a manager, you can use these ideas, too. Keep your decisions small and collaborate with others. That will allow you to make decisions that will stick for enough time. What if those decisions are wrong? Because you didn't spend so much time deciding, you can recognize that and choose again. What if you experience an interruption? Decide enough for now and then return to this decision.
For teams and managers, make sure you have enough hours of overlap to collaborate with the people you need. Susan is working with her management to recreate these teams as cross-functional teams in each location, instead of functional teams separated by distance and time.
That's how you can focus to deliver better products faster.
This newsletter touches on topics in Project Lifecycles: How to Reduce Risks, Release Successful Products, and Increase Agility, From Chaos to Successful Distributed Agile Teams, the Modern Management Made Easy books, and Create Your Successful Agile Project as well as Agile And Lean Program Management.
Learn with Johanna
Want to write nonfiction better and faster? Put yourself on the list for the Q2 writing workshop. I'll open registration shortly.
If you are considering public speaking, please see the self-study workshop for Write a Conference Proposal the Conference Wants and Accepts. Enroll and take it any time you want. If you want my feedback, you can add that at the end of the workshop.
I write fiction, also. If you like thrillers or other suspenseful writing, see the Thrill Ride Magazine Kickstarter. I have a story in one of the issues. Back the Kickstarter now and get ready for great reading. I write short stories because I can finish a story in a few hours and then continue with my other writing. You can do the same for your reading!
New to the Pragmatic Manager?
Are you new to the Pragmatic Manager newsletter? See previous issues.
Also, see these newsletters on my YouTube channel. I post the videos a few days after I send these emails.
Here are links you might find helpful:
- My Books. (BTW, if you enjoyed one of my books and still need to leave a review, please do. Reviews help other readers find books.Thanks.)
- All my Workshops (public, private, and self-study).
- My various consulting offerings
- Managing Product Development Blog.
- Create an Adaptable Life
- Johanna's Fiction
Johanna
© 2024 Johanna Rothman
Pragmatic Manager: Vol 21, #2, ISSN: 2164-1196
P.S. I had an opportunity to give a talk about this newsletter. See the Virtual Agile video. The link to the slide deck is there also.