Agile methods and business transformation

During 20+ years of consulting on large business transformation projects, often with technology content, I formed some strong views on how to make them successful. Some simple principles about how to get people to work together with a common vision and with common expectations. Harness the power of teams who have been given the tools and opportunity to achieve something great and then just get it done.

But we all know that big projects always come in late and over budget, right? Well, in the last two years I have experienced a sure way of reversing this. My change management principles have found a new expression, a new structure and a new level of effectiveness through Agile.

Agile methods have been around for a while. The "Agile Manifesto", created in 2001, was a milestone in the evolution of a better way of approaching change. The trouble is that agile methods (and there are many) are too often aimed at Information Technology development and are not readily applied to business transformation. The language used in most agile methods leads the reader into a technology funnel that is difficult to back out of. The adaptation of agile methods into a non-technical world has been my goal over the last two years and has been tested in delivering a successful business transformation programme. (I would note that most transformation work in the digital age involves IT but the challenge is to be business led / IT enabled rather than IT led).

The agile method that has been the platform for my new perspective is the Scaled Agile Framework (SAFe). Yes, it suffers from the technology context bias mentioned above ... BUT seeks to consider a larger, "scaled", programme environment where other aspects can be factored in. SAFe is not the only agile method out there, but for large change programmes I have found there is a lot to recommend in it. So, how do I now describe my top principle for transformational change?

Don't commit to a scope, commit to a business intent

This is a difficult one. Executives don't like to sign off funds without a guarantee of deliverables. The trouble is, there are no guarantees. Even if a supplier has signed a contract, there will always be assumptions and unknowns that will make any guarantee worthless. Traditional "waterfall" methods of defining requirements and then designing, building and implementing changes reinforce this myth of guarantee until the 11th hour when the delivery is late or not fit for purpose and the only option is to extend time and money (or stop!).

An alternative approach is to fix time and money and let scope progress, following a clear strategic intent. Whoa, I hear you cry - nobody in their right mind would commit millions without knowing what will be delivered! Well, consider this:

• Traditional approaches rarely deliver what was "guaranteed" within time and budget, and if and when it is delivered it is not what is really needed. Large documents can never articulate the future requirements adequately and customers need to understand change through smaller value delivery steps. So wouldn't it be better if ...
• The intent (or outcome) is clear, the approach ensures teams are high performing, deliverables are prioritised and then delivered incrementally so all of the important things that can be delivered will be delivered. Value delivery will have been maximised as "learning by doing" will have adjusted the direction along the way. And by definition, anything not delivered is of least value.

So, forget guarantees, focus on setting up a high performing team environment and deliver prioritised pieces of value incrementally towards a clear intent. (I could have used the "vision" word here as in Kotter's seminal 8 Step Change Model but I find that "intent" helps to make things more practical). The uncertainty inherent in any transformational change makes up-front specification difficult (or impossible) and a learning journey of incremental value delivery is a far better way. The learning, modifying and re-prioritisation that happens through these delivery increments results in a better business solution being delivered.

This article describes the fundamental paradigm shift away from trying to define a fixed scope but success relies on leadership and delivery teams adopting agile principles and ways of working. Defining what this means in practice and embedding it within the teams is the next challenge. More on this in a later article ...