Agile transformation is necessary for organizations to thrive in today’s markets and into the future. Your transformation strategy will need to address your specific needs. By first establishing where you are in your agility across a wide range of roles, workflow processes, product performance, understanding of your market and customers, and much more, you will be in a better position to answer the question, “Why does my organization need to transform to be more Agile?”
Every transformation is different, but a typical roadmap for transformation will have several common features:
Analysis of where the organization is today – technologically, culturally, in the market, etc.
Discovery of where the organization would like to be at some point in the future
An area of the business where they can pilot a mini-transformation, from which to gain learning
A vision to guide the transformation
Governance as guard rails for the initiation
A communication strategy for those affected directly as well as indirect effects the rest of the organization may see
A change management strategy for working with and supporting the individuals and teams who will be living and working within the parameters of the pilot
A high-level plan for what training, coaching, and consulting will be provided to these individuals and teams to make the intended initiative results stick
Waterfall to Agile Transformation:
If Agile is the new way of working, we can think of the old way of working as “traditional”. You will also see and hear the word “waterfall” a lot. Not long ago, waterfall was an innovation, the first iteration of a consistent process for developing software.
The name “waterfall” is based on the thinking behind visualizations of value delivery like this one.
Early on, Scrum allowed teams to do the impossible: release value to end users within one sprint, with the typical sprint being two weeks. Even if that were inflated to four weeks or eight, delivering anything of value to an end user in anything short of six months to a year was just not possible.
Agile thinking is the difference. The traditional assumption is that a finished product would be delivered at the end of the whole process. But in Scrum – which is not synonymous with Agile but simply one approach to it – an increment of customer value would be delivered at the end of the sprint. It’s up to the team, working with the product owner, to decide what increment would be delivered. It could be a login screen for what will eventually be a website. The hard work is not in the delivery itself, but in figuring out how to break big work into small batches.
Waterfall thinking is the opposite: you design everything up front, including all of the controls in the iron triangle, and execute the plan without making any changes. We see the result of this strategy everywhere: The project goes out of scope, over budget, or takes too long. No one uses the features, because no one bothered to ask which features to make. Predictability and flexibility of the product is nil. And, up until people got tired of it, this was just the way software was developed. Many organizations still use this delivery method today.