I’ve found predictability to be more important than high productivity
Every product manager wants to be the bearer of good news, sharing details of on-time product releases packed with high value features. Too often, however, product managers bear news of yet another late release or the feature that had to be scoped out. When customers, partners, and internal constituents lose confidence in a development organization’s ability to consistently deliver promised functionality, the inevitable outcome is micromanagement and second-guessing of the product organization. With over a decade of product management experience, using both waterfall and agile methodologies, I’ve found predictability to be more important than high productivity. Knowing that what gets prioritized and accepted into a development cycle gets released into production on time, every time.
Predictability means dependent organizations.
Internal and external—can plan with confidence (and without feeling the need to backseat drive the product organization). Business executives will choose slightly less functionality in exchange for higher predictability almost every time. Like many product development organizations, my current organization struggled in the past with releasing the committed scope of functionality on schedule. Over the past few years, however, we’ve released on time and in-scope 90+ percent of the time.
How did we calculate the 90 percent success metric?
We looked back at actual release dates vs. planned release dates, and also looked at cases where a feature accepted into a sprint (using Scrum as our development approach) wasn’t production ready. Exceptions existed in less than 10 percent of cases—a dramatic improvement from our level of predictability when we were following three to six month waterfall development cycles.
The switch to agile development (Scrum specifically) was a major factor in achieving this high level of predictability. Under the hood of Scrum, however, it has been our refinement of development cycle times that has had the most impact. We started with very tight cycles—two weeks—but found we were consistently late. We bumped up to three weeks per sprint but still found it difficult to achieve predictability. Development cycles that are too short don’t leave sufficient time for QA and refinement. We ultimately settled on a standardized four-week cycle, with one week in between sprints for planning, enabling nine to ten major releases per calendar year. (Note that four-week cycles are working weeks, not calendar weeks, allowing holidays to be taken into account on a sprint-by-sprint basis.)
One Week and Four Week Sprint Why did a standardized, four-week sprint cycle have such an impact?
Both “standardized” and “four week” are important. By standardizing on a cycle, our product management, engineering, and QA teams have found a rhythm—a natural feel for what can be accomplished in a four-week cycle. Four weeks has proven effective because it is long enough for significant progress on features, but short enough to be estimated accurately. Four weeks is also short enough from a business perspective that the risk of mid-sprint executive overrides (changes in priorities) is minimized. We’ve been able to avoid this problem altogether. The most significant challenge with three to six month waterfall cycles is estimating the work—like many companies, we simply couldn’t achieve sufficient accuracy in estimation over such a long cycle, resulting in low predictability.
I noted above that predictability is more important than high productivity.
The hidden gem here is that predictability, in our experience, drives higher productivity because as the product teams deliver consistently, confidence in the ability to delivery grows—and the teams are prepared to take on more each sprint cycle. By focusing first on predictability we have ultimately achieved higher productivity.
What product manager would argue with that outcome?