The word Agile has become so associated with software development methodologies that it’s hard to remember that a lot of its roots started in Kanban and Lean manufacturing. These roots should be a reminder to us that Agile at its core is not only a methodology but a way of thinking about how you approach getting work done. And that an Agile philosophy can be applied to any branch of business and built into a company’s ethos.
A great deal of the buzz of late around Agile and Lean has been the focus on the need to create something of value to the customer. And rightly so. After years of engineering teams locking themselves away in a product silo, it was important to find ways to better enabling engineering teams to understand customer requirements. As well as to gain improvements fast tracking priority requirements and getting quick validation that the value desired is actually realized on delivery.
For this post, I’d like to step back a moment. Instead of looking at the why’s and how’s of the methodology, I would like to instead consider one of the key benefits that Agile brings to both us as product creators and to our customers. What you might think of as the “Value” with a capital “V” of Agile. This is that it brings down the cost of change.
Years ago, I was introduced to an interesting analogy that compared the approach to change at the large corporate client I was working with as trying to turn an ocean liner. An analogy which also brings to mind the image of the Titanic failing at this type of maneuver at a drastic point in its brief history. I was working for a small software company at the time and implementing a solution at such a giant. I was frustrated with the slow processes and bureaucracy involved in getting done what we wanted to achieve. In contrast, the customer team liked working with us because of our sailboat-like ability to tack as a response to continuously clarified requirements.
Anyway, I digress. The point is that a non-agile approach to change is also much like turning that ocean liner. The larger the individual need to change and the more entrenched the status quo, the longer and harder it is to invoke change. And more importantly from a business perspective, the more expensive it is to make that change. All too often, needed business transformations are often killed at concept and business case stage.
At the same time, I have also been fortunate to have worked with some pioneering executives who have been able to mobilize and drive change when it’s been needed. Doing it quickly and at the right time. Which has taught me that even those big companies can be agile when the need to be is identified and key sponsorship is put behind it.
This brings us full circle back to how I believe a business can remain agile regardless of its size. It’s to find ways to incorporate the discover-deliver-validate cycle that is part of the agile methodology into the way it plans and implements change in the company. Whether this is the formal strategy portfolio process of a larger company. Or the less formal, continuous business improvement cycle of a smaller company, individual department, or team.
Discovery
With the “discover” cycle being that quick identification for the need for change (the pain point).
An organization that is agile will hold regular quick reviews of business goals based on business criteria. And if necessary, will launch a discovery project when a deeper situation analysis is required to detail what is required in the change.
Having a way to measure the impact and priority of a required change will mean that you chose the things that need to get done based on what will have the greatest return. Improvement projects will be identified before they turn into big hairy unmanageable beasts. And objections to change can be challenged using the business criteria set out.
Delivery
One of the key components for delivery of a continuous improvement project is the commitment or sponsorship of management to get behind the required actions to implement change.
I’m highlighting this here because I believe that most project teams know how to deliver. A higher level discussion on why delivery fails often points back to the lack of support of an executive sponsor to follow through.
There will always be competing needs for resources and fires. If the change project has been identified as important in discover, then commitment needs to be put behind it in the delivery phase.
Validation
Validate being able to put in the necessary checkpoints and processes to measure the effectiveness of the change. This should be done not as a post-mortem outcome, but at different points in the process.
Measurement should be against the business criteria that was identified in discovery and mandated in delivery. It needs to also be understood that an acceptable outcome of validation may be to reverse or abandon the change project when necessary.
Finally,
Having agile built into the DNA of how a company organizes its work or runs its projects means that this continuous improvement loop will result in smaller chunked changes of lower cost and higher impact. Feedback from validation goes back into discover, as the need to make further changes arise out of the completed change.
