If you Google “Agile Methodology” you’ll get just short of three million results. There’s clearly a lot of it about.
Well, actually, there’s a lot LESS than first impressions would have you believe – and there are a lot of people who think Agile is something that it simply isn’t.
And that’s the problem. Lots of organisations claim to be ‘doing agile’ when, in reality, very few are. Many are doing something they consider to be agile software development, but which could not be further from the truth.
This blog post covers some of the points raised in our recent YouTube video “Are you really being agile?” (which you can watch here) – and is the first in a series of blogs covering common misconceptions about Agile.
We regularly hear people saying that agile doesn’t work – or it’s not appropriate for a particular situation – when in fact it’s just not being used effectively.
And that could mean missing out on the many benefits that a truly agile project can bring.
Before we look at the misconceptions – a recap
First – a small trip back to the drawing board, and a look at the biggest differences between agile and ‘traditional’ methods of software development (waterfall seems to be the most commonly quoted).
The three key elements of a project are:
In the ‘traditional’ model, it is the scope and resources which tend to be fixed.
Any change in the project which increases the scope means it’ll take more time. Quite understandable then, that change is feared in this scenario, as it will add delay.
In the Agile model, however, we have exactly the same parameters, but it is the TIME and resources that are now fixed.
Scope is, therefore, the variable – and it makes provision for the fact that change is EXPECTED. This methodology, therefore, allows for change – and in fact, encourages change.
Misconception 1: Agile automatically works for everyone
So – back to the plot. How does this relate to misconceptions made by organisations claiming to ‘do agile’?
The first issue, surrounds ‘people’ – and by this we mean the entire team of stakeholders involved in the agile process. We know that the time is fixed – as are the resources.
So, when feedback leads to new features being introduced, it is inevitable that lower priority items will no longer fit into the timescale, and will go onto a wish-list for a future release. Everyone involved has to accept this – and unless there is buy-in for this concept, it could be viewed as a negative. And this regularly happens, as users who are familiar with the traditional approach, expect the new features AND the old, and are unwilling to let anything drop out of scope. If one gives into this pressure, the project is no longer agile.
We combat this by always holding detailed upfront sessions with users to make sure they are familiar with the benefits of agile – especially the fact that it allows a predictable timely delivery based on prioritisation of features.
Misconception 2: It takes all sorts
It’s vital that the correct personalities are involved in an agile project. This includes not just the techies, but also the non-IT stakeholders. For agile projects to be really effective, they need to be staffed with individuals who want to prove something, and who thrive on the challenge of working to produce the best possible result to well defined timescales.
It’s simply not for everybody.
Next time: Misconceptions 3 and 4
In the follow-up to this blog post, we look at scrums, sprints an excuses. Following that, we’ll go on to discuss failures to manage user demonstrations, and ways to get quality feedback. We’ll examine problems with prioritisation and failure to build testing into the process.
In the meantime, if you’d like more information about any aspect of Agile, please contact Jumar.