We were talking with a customer a few weeks back and was asking them why they kept changing the specification and data of their survey. Their reply? "We are using an agile development process". Unfortunately, although they thought they were being honest, it was very clear.

That isn't agile.

Agility in its most general sense is "delivering value quickly", which usually means delivering value in small packages. Small because that is easy to specify, agree, implement, test, deploy and revert/fix if there are any issues.

In other words, agility is about seeing work in a different way. Let's imagine you wanted to build a passport application system, a tax system or an ObamaCare health insurance system. The traditional view, dictated by history and a hardware-dependent system, is like this:

  • We need a lot of hardware for this, therefore we need to know almost exactly what the entire scope is so that we can design, plan, order and install all of this hardware ready for the software testing stage.
  • Coding is complicated, slow and difficult so we would rather know exactly what we need up-front to avoid us having to rewrite things, especially if it has an impact on other parts of the system.
  • So we make an effort and spend an enormous amount of money analysing and specifying the system at extreme detail upfront before anything is designed or implemented. Some systems can take 5+ years or more just to design!

So what is the problem with the traditional model?

  • Most systems are now designed to run on relatively standard hardware and suppliers can supply this at relatively short-notice. 
  • Many public or private clouds are available which offer flexible hosting options with usually no notice required to utilise them.
  • Coding is much easier now with many more libraries and high-level languages. Coding patterns and principles are more entrenched now, there are many more developers available. The days of super-fragile code should be over in most cases and we should be confident to make changes/refactor code.
  • Not only is detailed design expensive, it is extremely error prone - how do you check that someone didn't mis-type an important detail?, it is very time-consuming which is not only expensive but by the time the specifications are ready, they are either out-of-date or they specify something that is now obsolete,whether the software or hardware.
  • It does not make allowance for the realistic (arguably unavoidable) changes to the design and specification. There are hundreds of reasons why a government, military contractor or even corporate business might need to change what they originally needed. Regulations, Politics, an upstream-change in the supply-chain, suppliers are no longer in-business etc.
  • The time-frames involved coupled with the higher turnover of staff in newer businesses means you are more likely to be lacking expertise (or the original authors) of a specification that might have a bug in it.
  • Longer delivery timescales means that either the supplier is exposed to costs they are incurring before payments or the buyer is making payments before they have anything that is actually useful. 

People can react against the time they know it takes to completely specify a system up-front and decide that agile will fix this problem but without understanding agile properly, they treat it like an ad-hoc process, which is even worse than the traditional "waterfall" method since it will most likely create a much less reliable or consistent application and may or may not take less time than waterfall.

So how does Agile development make this better? Instead of seeing something like a passport system as one large application that gets done in big stages, we slice the functionality into different levels of detail. Initially, not only can we design and implement a very high-level function, we can possible implement a large number of separate supporting systems before the front-end is fully designed. Instead of building things out wide, we build individual functions deeply.

How does this help?

  • We don't need to know the hardware up-front, we can instead run it on smaller/simpler systems during development, ideally with scalability built-in, which can be scaled when released to production.
  • We can get very quick buy-in and sign-off from the customer. A few weeks in and they might have a basic application with a login and a number of menus. Seeing it "in the flesh" allows people to provide early feedback with the types of things that developers always wonder "Why didn't they already think about that?" when we all know that most stakeholders are not technical enough to understand what a written document will look like when implemented into an application.
  • Changes are small and therefore less previous. If we do a basic high-level function and the buyer decides that red is too bright for long-term use and wants blue, we have not invested too much time and emotion to change it.
  • As the system is built-out, the buyer can be part of the discussion of priorities. Many things that sound like essential features can easily be dropped if the project is taking too long or the buyer realised that those features perhaps won't be used very much. In that case, the buyer gets to change the scope without it having affected too many people.
  • Payments are much easier to make against individual features rather than large blocks of time which the buyer might contest.
  • The timescale for a feature from design through to implementation and test is much shorter so it is easier to manage the availability of the experts if there are questions/rework on a feature.
  • Adding new features is more easily possible also, since the buyer will have an appreciation of how other features fit in with the overall system. If they have developed, e.g. a Google "connector", that might realise that they also want a Facebook connector and adding this is usually much easier as a separate feature since the dependencies are easier to reason.
  • The agile process can lead to a useful system delivered much sooner than the traditional "sign off" of the entire application. Individual features are signed-off, which will involve far fewer people and much less time than attempting to sign off everything and potentially not having a final payment until every single last feature is completed acceptably.

So agile has discipline, it is just different discipline than waterfall. In most cases, it will bring advantages, even if the system only makes sense when completed in its entirety. Agile is not ad-hoc and requires buy-in much earlier than other systems. If you just make decisions off the hoof, you get the worst of both worlds.

That is not agile.