Agile makes sense. In a demanding business scene Agile aims to deliver and deploy faster and follow a cycle of further drops to enhance the customer experience. Yet in big organisations it is either unpopular among the technical cast or fails quite often.
Let us break it down to three main headings:
The first two are pretty self-explanatory items really.
Agile is more than a principle or methodology it’s a style, with a core of a belief and dressing of a philosophy. One just cannot do agile for a convenient task and follow a different style for the rest. You need to apply the philosophy to the entire domain. It’s a paradigm shift. An agile train of thought has to be applied right from scoping the project through to its deployment. The business sponsor or the writer of the mandate has to understand what agile is and how it works. Agility of course comes with a price and the price here is that the typical lifecycle of deployment is short. The scope will have to be decided accordingly – so that it can be packaged in smaller drops. The benefits of such agile cycles have been broadly discussed everywhere; it reduces the risk of wasting a lot of money for nothing for long – and that alone should be the most compelling one for the sponsor. However this is not an easy task; with years of waterfall practice it is easy to see why people struggle to think in agile way. Probably an example can help explain.
Waterfall thinking: We are a bank. We need a new current account. Our scope includes launching the account, training the customer facing staff with new account opening process, and offering all types of banking features including mobile and online banking for the account when it’s launched.
Agile thinking: We are a bank. We need a new current account. To achieve that, we need a new account opening function and train staff in the process, integrate it with current Standing Order, Direct Debit and other payments engine, launch its online portal, develop its mobile content and mobile banking platform or integrate with existing one.
We will like to point out that both have exact same scope of launching a new current account product for a bank. However with agile approach, all its features won’t be available on day one. The challenge here is on the analysts and SMEs to ensure that the basic features that an account must have to be ready for launch are included in the first drop, and subsequent features are added as future drops. It is indeed possible for different organisations to have different take on what constitutes to be the most basic features for the account type, for example, a bank that only offers portal or digital banking will need the mobile/digital aspect as a requirement for drop one whereas a more traditional bank will probably keep it for second or third drop. However by the same token, a bank offering only online products and services is expected to already have a robust online channel thereby making it easier to integrate the new product with it.
So that covers the first two headings for us – smaller drops to scope leading successfully to smaller drops to deploy.
The fundamental reason of all failures for agile is an organisation’s lack of appetite to change the traditional governance protocols which is heavily embedded into its culture and how it operates its business. Let’s look at an example.
In our example bank, the project lifecycle necessarily has three distinct steps – all mandated – namely:
This is all fine for agile too, however in the said bank, one can only move to Develop stage when Define is signed off and subsequently Deploy when Development is completed and signed off. Deployment is heavily change controlled meaning that for every deployment one needs a change record and undergoes a rigorous and painful change management process which in itself takes weeks to prepare for and pass through the gruel of change boards. As agile process will consider several drops, multiply this process by the number of drops and one can quickly see it won’t work.
Is there a solution? One will argue that an organisation should be open to both waterfall and agile ways of working because for some projects agile may not really be the answer. How does the governance protocol can support both?
First thing to understand here is that there is no direct conflict between waterfall and agile except for the size of the delivery. Agile too follows scoping, designing, developing and deploying lifecycles albeit at a much faster pace. The good news for organisations therefore is that they don’t have to drastically change their protocols for agile. They can keep the core protocols intact and just alter them to a “light mode” for projects that are marked agile. It needs the recognition that some deliverables, e.g., application design, will undergo changes every sprint, so the final version will not be released for sign off until the final sprint is over. It also needs a lighter change control, or allow a change record to stay open for a longer window. It can allow self-certification by a delivery manager on some of the compliance elements.
All of this of course adds certain risks to the protocols and change governance, there will be competing forces from external policies such as Sarbanes Oxley, so it is fair to comment that the agile way of doing things needs cognisance from all quarters, internal and external, and one can only hope that the agile way of working will evolve for the better in coming months and years so agile won’t have to fail for no fault of it.