My previous post asserted that predictability at the business or organizational level is having teams that consistently deliver solutions that enable desired business outcomes. These organizations and business are predictable in the large. Predictable organizations have the ability to change course even as the ecosystem they are a part of changes. Ergo, my second assertion:
Your company values adaptability over predictability
This is not to suggest that predictability is not important. In fact, it is quite the opposite. In the ever-changing business landscape that now confronts us, organizations are required to adapt in order to survive. In order to be predictable, organizations must be able to adapt.
(I will concede that it is possible that your business cares about predictability more than it cares about anything else. I just don’t interact with a lot of those organizations these days.)
Organizations that possess a high degree of adaptability have the capacity to change course in a largely frictionless manner. They have the characteristic of responding to changes in the ecosystem and changing direction as needed, effectively and efficiently.
An organization can only adapt as quickly as its component parts can adapt. More specifically, a product organization’s ability to adapt is a function of their individual product development teams ability to adapt.
Agile places tremendous value on teams being able to adapt as change emerges. In fact the Agile Manifesto states that we value:
Responding to change over following a plan
and backs that up with following the principle of:
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage value number
Many Agile practices enable teams be in position to respond to change in a productive manner. Here are a couple of them (in case you’re not familiar with Agile practices):
- Focusing on the “what” over the “how”
- Working in small increments of value (days not weeks or months worth of work)
- Short delivery cycles; weeks over months
- Stakeholder feedback on a regular cadence
- Pair-programming/test-driven development
- Continuously running automated test suites that validate product suite
- Feature teams developing features
- (I’m sure you can add more to this list)
- Etc etc etc
Teams that leverage all these practices (and more) are in a position to respond to change very effectively. I find however that many organizations that claim to “be Agile” are only partially committed to a few of these practices and then wonder why it’s so difficult for them to change direction. Coincidentally, these organizations seem to also believe that Agile is about delivering software faster. (If that’s you, it’s possible that you’ve been misled). To top it off, these organizations often respond to their inability to adapt by instituting heavy processes and protocols that are focused on ensuring that they won’t have to adapt!
Here is a thought exercise for you: If at this very moment, your team was asked to stop working on a particular initiative and release it into production so that your customer could start using it and the team could start working on a different mission, would your team be able to do it? How many days, weeks or months would it take for your team to be able to release a product increment at this very moment? Would you be able to release anything at all?
If an organization desires to be predictable in the large, its teams need to be able to effectively adapt in the small. When teams holistically adopt Agile-based approaches to software development, they place themselves in a position where they can respond to change in a predictable way. Could your organization and teams benefit from this ability?
But wait, we’re not done yet. There is the little matter of predictability in the small. My next post will be about that. Stay tuned!