Agile does not work but agile does

In his article ‘Agile Does Not Work’ Oleg Vishnepolsky makes several observations based on his experiences with Agile development (note the big ‘A’, it’s my emphasis, not his). Specifically, he cites issues with quality, predictability, poor strategic alignment, monolithic architecture due to poor design, complex and costing infrastructure and challenges managing stakeholders.

A response frequently heard to such accusations is that “If Agile is not working for you then you are not doing it right”. This response is the last defence of an Agile consultant or coach that has nothing left to offer. Sadly, In many cases this is all many coaches have to offer in the first place.

Oleg is quite correct when he talks about the lack of understanding of the principles underpinning agile development and the hordes of consultants trying to make a quick buck packaging principles and techniques as dogma and selling them wholesale. How can he not be when anyone could be proclaimed a Scrum MASTER after attending a trivial 2-day training course?

Sadly. what Oleg is describing will ring true for many teams that have attempted to go Agile. I have heard the same criticisms from many teams and the conclusion is always the same: We tried Agile and it did not work for us.

When teams go Agile and it fails they are left in a difficult situation. The populist view is that Waterfall = Bad and Agile = Good. To say otherwise would be heresy and result in hordes of Agilistas storming your team area with pitchforks and sticky notes! But, if Agile failed for you then what? Most teams end up where Oleg seems to have landed – “Common Sense Development” or just “Built it till it works”.

The tragedy here is that the (agile) baby has been thrown out with the (Agile) bathwater. Whilst there may still be value for the team in agile principles and techniques the team are now totally switched off to the notion and are left to fend for themselves. They now have to re-discover many of the lessons that have already been learned in the broader agile community.

Ultimately they will learn that “Common Sense development” is actually just agile development.

If your team is struggling with the issues listed above or if your experience of applying agile is more of religious, dogmatic exercise heavily reliant on faith and light on results then you have more than likely been sold Agile with a big A. Agile is the dogmatic, fast food, saccharin flavour of agile concocted by the consultants and peddled to the masses. It does not work and will add little value. As Oleg will attest.

So where to from here?

Let’s start by sticking a large pin that overinflated A and get Agile back to plan old agile. Let’s stop doing things because someone told us that if we don’t we are not Agile. Rather let’s start doing things because they add value, because they make sense and because they help the team move faster.

Look at what you are doing in the name of ‘being Agile’ and ask yourself and your team the following questions:

• Do we know why we are doing this and the value it should add?
• Is what we are doing adding the expected value?
• If we stopped doing this would anyone notice or care?
• Did we learn something from this activity that changed what we originally planned to do or thought?

If you answered NO to more than a couple of these, you should really re-evaluate whether you need it. Start by looking at why you are doing something and the value you expect to extract. Agile will fill your days with arcane rituals that add little value. Use common sense here – do more of the things that add value and less of things that don’t.

There are some specific pitfalls that result in the issues that Oleg identified I’ll address each of these in an upcoming post.