Re-Read Saturday, Project to Product, Week 7, Chapter 6: Tracking Disruption

This week, the PC version of the Kindle software I use seems to have lost its copy of Project to Product — I have gotten reasonably adept at reading on all of my devices therefore got the re-reading done. While not the end of the world, it makes this week’s chapter on disruption and the role of technical debt in some of the stories shared by Kersten even more poignant. In the chapter the author tells four stories of disruption — they are interesting in their own right. Still, if we look for a common thread I would suggest the communication needed to manage the balance between flow items (features, defects, risks, and debts). The right balance requires knowledge of external contexts such as changes in business dynamics and market risks and internal context, such as the amount of work required to support a product and the level of technical debt accumulated. Getting the balance right is a strategic portfolio decision that requires a broad range of parties at the table.

I have had a hard time wrapping my head around this chapter in the past. In previous readings, I have felt that the points the author makes are more of a summary of this part of the book. Two conversations this week changed my perspective. The first was with a colleague about the portfolio of work a team is working on. The team serves a specific business function, covering all of their systems needs, all of this within a larger organization. The team is chronically stretched to the brink and has a backlog that is scary in size (as you would expect they have been impacted by the great resignation). The work they are doing is focused on two flow items: defects (a lot of defects) and enhancements (or features to use Kersten’s nomenclature). Zero time is spent on technical debt or worrying about risks to their part of the business. My colleague had indicated that the business was expressing displeasure at how slow the team was in delivering new enhancements and features. The team was very stressed by the amount of time they were spending fixing problems. No one was willing to invest in rooting out root causes and reducing technical debt. Both of us see a train wreck on the horizon. Engineering the right conversations to help all parties come to grips with the impact of choices they have made and then to help them make better decisions is the solution and the punchline to this chapter. Even at a team level, the balance of the portfolio of work has to be understood.

The discussion was with my wife after I completed the reading. The crux of the conversation was based on her experience as an owner of a software development firm and later as a program manager for a city that was acquiring customized software. How you perceive the balance of flow items in your portfolio is very dependent on your role and business context. The pressure to ship and generate revenue calls for a different balance (at least over specific periods of time) than a software acquisition in a risk-averse environment. Understanding that reasonable people might have different perspectives of the balance of flow items in the portfolio suggests the need for transparency and conversation about how organizations are investing in their product portfolio. The portfolio of work a team or organization chooses to work on is just that, a choice. Having a diverse group of perspectives at the table is important to avoid robbing Peter to pay Paul.

Simply put, this chapter is about the tradeoffs that all teams and organizations make and the impact of those decisions. Understanding the portfolio of work in terms of flow items is a step in the right direction.

Remember to buy a copy of Project to Product https://amzn.to/2WzvPac (Amazon Affiliate Link) and read or re-read along.