In the dynamic realm of product development organizations, an ongoing debate between “predictable” and “agile” approaches unfolds, with perspectives often divided on the very definition of these terms.
At the mere mention of ‘predictability,’ some immediately argue that it contradicts the principles of agility and that the uninhibited ability to adjust the plans is critical. On the other hand, some leaders expect deliveries to be predictable no matter what and consider Agility as a nice-to-have rather than an org-level mindset. However, is the scenario truly as stark as black and white? Is it a matter of one or the other?
My perspective is that it’s contingent on several factors: the current business reality, the nature of the product, and the timeframes under consideration. Therefore the balance between predictability and agility is dynamic and varies across scenarios.
Short-term planning
In my opinion, teams should be predictable in the short term. If you follow Scrum you should be able to deliver on what you promised when the sprint was planned. Exceptions are acceptable (such as discovering unforeseen technical difficulties, team disruptions due to illness, or urgent, complex support requests), but persistent failure to meet commitments or regularly achieving less than 70% of sprint plans indicates a potential flaw in your process or setup. Similarly, if you follow Kanban you should be aiming for a stable lead time and cycle time to allow for reasonably-accurate forecasting about when backlog items are to be delivered. Again, exceptions are okay, but cycle time exhibiting high variability is rather a sign of a bad process or team-related problems rather than an indication of great agility.
Longer-term forecasting
While I find most people agree that with the above it becomes way more debatable when it comes to longer-term planning. Here, in my opinion, it depends more on your offering and the type of clients you serve.
B2C SaaS world
If you work on a B2C SaaS solution that is used by thousands (or millions) of users then you probably don’t need to present (and stick to) a publicly available roadmap of things you want to build. Moreover, with thousands of users you probably run experiments (like A/B testing, piloting new features to a small subset of users to gather their feedback, etc.) and you have good telemetry in place to decide what to do next. You can constantly adapt your plans to what users really like or want.
Of course, there are things that you want to build regardless (because you bet on conquering a new market or you need to redesign the architecture to allow the product to handle more users), but these internal endeavors are fully in your hands and you can shift priorities if need be. A good example is the recent burst of AI which forced many organizations to shift their priorities and work on AI-based features (because it’s either a good addition to the product or only because it’s sexy and therefore deemed a must-have – but that’s a topic for another post…).
Enterprise-level clients
Unfortunately, it’s not that easy if you have a customizable software solution that you sell to enterprise-level clients (also, usually technology partners are involved in doing the customizations, configuration, etc.). In situations like this, a publicly available roadmap is often necessary, and adhering to the outlined timelines is crucial. While occasional adjustments are acceptable, consistent failure to meet deadlines can significantly impact sales and your Annual Recurring Revenue (ARR).
This means that longer-term predictability of your delivery machine is important and you must somehow optimize for that. Some degree of unpredictability is okay and therefore aiming for 75% levels sounds about right. One comment on that, though – it’s usually acceptable to be more unpredictable when innovating products or features, while stability and predictability are expected in well-established parts of the product (in terms of business needs or technological challenges).
While this may seem counter to agile principles, it’s challenging to argue against the business reality at play. On a positive note, your ability to communicate the roadmap intelligently becomes an asset, allowing for a somewhat cautious approach.
First of all, you can be a bit conservative in your forecasting – without going to extremes, though, as lengthy delays are generally unacceptable to clients.
Secondly, the roadmap often focuses on higher-level promises allowing for agile adjustments in the exact scope to be delivered. Again, a balance must be struck because the clients won’t be happy if instead of full-blown features they only get early prototypes with a limited functionality that nobody can use or that require tons of effort (read: money) from implementation partners to adjust.
Last but not least, in most cases it’s expected that you deliver on your commitments for the next 1-2 quarters, but it’s also acceptable to shift things around when it comes to plans that are farther into the future. This is also not against an agile mindset as it opens room for changes based on what you learn on the way or what happens to the market in between.
Also, any big shifts in business environment (think i.e. about Covid) or unforeseen inventions in the IT world (let’s take the AI burst mentioned earlier as an example) are acceptable reasons for shifting priorities and timelines within the roadmap – assuming you earned the trust by being predictable earlier and that you’re capable of openly communicating the reasoning behind the changes you’re doing.
Conclusion
I hope this post has illuminated the importance of predictability in certain scenarios and how adopting a rigid, ‘either-or’ mindset can be counterproductive for organizations and stakeholders. The key lies in understanding the context and striking a balance between predictability and agility.
