In other blogs, I looked at what some of the advantages are of using an Agile process, and in particular Scrum. However, is it enough to just do something agile, or do you need a be agile?
But first, have you ever learnt another language? Maybe you did at school, and it was most likely a little basic grammar, a load of vocabulary and not a lot else. You ended up thinking of a sentence in English and translating each word in turn. Imagine you’re in Paris (France, not Texas!), and it’s raining heavily. At home you might say “it’s raining cats and dogs”, so you comment to a passer-by: “il pleut des chats et des chiens!” They look at you in amazement, and probably no small amount of panic as they seek cover from the multitude of four-legged creatures falling from the sky! Simply taking your French dictionary and swapping an English word to the French equivalent does not work: to truly speak French you need to understand their mindset, how they think, what idioms they use (“il fait un temps de chien!”) and so on. Learning the French dictionary doesn’t make you a French speaker; you need to understand the French psyche as well.
It’s the same when implementing Agile. It’s very tempting to think that if your company’s development team has adopted a Scrum-like process, the company is Agile. After all, Scrum gives you quicker releases of product increments, higher productivity, lower costs, greater ability to make changes, higher quality and so on.But Scrum is not Agile. Well, all right, it is agile, but it is not Agile. It is a step in the right direction, but simply using Scrum does not make one Agile; there is much more to being Agile than just using Scrum.
Traditional (by which I mean pre- or non-Agile) Product Owners are generally focussed on three things: new features, when they can have them, and how they will cost – the Project Manager’s infamous Triangle of Death. They have a list of requirements, and (understandably) are unhappy when the delivery is late or over budget. They are not prepared to change the scope: the requirements are set and they want them all, whenever and whatever the cost. In contrast,
Agile Product Owners don’t think in the same way. They too are focussed on scope, time and cost, but are prepared to compromise if things don’t go to plan. Their new features are listed in priority order, and if time or money run short they miss out on the least important things. And this is the key difference: the Agile Product Owner knows when to stop; their focus is more on time (and to some extent cost) than on demanding that everything they wanted at the start is delivered.
And there’s also this strange new person called a Scrum Master. What’s that? Just a fancy new name for a Project Manager? No, absolutely not! And this is where many organisations go wrong: they simply don’t understand what a Scrum Master’s role is. They think of them in the same way as a Project Manager, and expect them to do that role: allocate work to team members, identify and manage risks, monitor and control costs are just a few examples. In reality, of course, a Scrum Master is responsible for none of these things.
And it’s not just the new roles that get misunderstood: the new ways of thinking suffers from this too. For example, the Agile Manifesto says the Agilists value “responding to change” more than “following a plan.” This does not mean that plans are bad and should be outlawed. It simply means that if the situation changes, the plan can (and should!) change too. And by working in two-week Sprints, it can change fairly quickly. However, some people choose to interpret this as justification for telling people to stop one thing and start another at the drop of a hat, because finishing a Sprint is “following a plan” (albeit a short one). And the result is chaos; no one has any idea what’s being done nor when it will be ready.
Much has been written elsewhere on the difference between ‘agile adoption’ and ‘agile transformation’; the difference between doing agile and being agile. it’s not enough to simply know the terminology and some processes; you also need to understand the change in the way work is approached. It’s whole different way of thinking. Just as learning a French dictionary doesn’t make you a French speaker, running a sprint cycle doesn’t make you Agile.
The conclusion is that it’s not enough for an organisation to implement Scrum for it to be able to legitimately call itself Agile; it’s more than just a change for the development team – the mindset of the whole business needs to change too.
