Blog

When "Must Go Agile" Is Just a Face of Deeper Issues?21 Feb 2017

Agile can be controversial - it has its clear enthusiasts and vivid mockers. What does not help the situation are groups of people who use a call to become Agile, as a cover-up for a number of other organizational problems.
This can fuel a discouragement towards Agile methods and can depreciate them in the long run, by making it seem as though these methods are only a cover up for ill-operating teams and an excuse for them when it comes to reasons why they're not doing so well.
How to spot these occasions? When is a team's stated need of Agile likely to be only a smokescreen for a larger issue?

First off, there are causes stemming from people's lack of knowledge of what Agile is and is not.
Example 1: Agile means getting results without having to do as much as normally. - This is a big and faulty short-cut of what the methods offer. Users of Agile, in any of its forms, still do need to work hard, the difference is in how they go about planning and reviewing work: concentration on short-term milestones, frequent reviews of requirements vs. execution.
Example 2: Agile will just let us code and never document a thing again! - While the amount of documentation is advised to be limited to the necessities only, it doesn't mean cutting it out completely. Therefore, if this is your team's reasoning for wanting to use Agile, perhaps consider putting a limit on what and to what extend needs to be documented?
Example 3: - Agile will help us see the next step required to keep moving - Well, Agile may do so, but it will not be based on the fact that you've implemented it, but on the work that someone has gone and put into planning and management. Nothing ever gets done of its own accord. If your team says Agile will help them know the plan, what they mean is they aren't best looped in to the scheme of the project as it is - that rarely helps anyone, but solutions may vary from one team to another.

Then, there are the cases when teams don't really know the reasons behind wanting a change, but shouting out the need of Agile seems like a good idea. Very often, all this means are various overlapping problems with the current system used, making the team tired and desperate for a change - any change.
And since Scrum, Kanban, Scrumban and different variations of Lean methods are often presented as a silver bullet for all modern companies - it's easy to see why teams lean towards this when a change is needed.

Following this trail of thought, teams and individuals often make the assumption, that starting an Agile program or remodelling the processes to an Agile one is done by a single switch, after which the difference is present. Meanwhile this process is - most of the time - long, often difficult for the whole organization and potentially challenging for some of the team members.
Once there is the realisation that people are dissatisfied with how things are done, the right thing to do is deciding what will be best, not assuming it is indeed Agile that the team have made an informed decision to require.
It may well be Agile that is the answer (and we recommend it!), but the change has to be suited to you to a tee and planned ahead, as it will take time to complete.

Another common reason for organizations to turn towards Agile is the customer demand to do so. It's understandable, when you consider that Agile does allow for more often product delivery and invites the stakeholder to take active part in the process of decision making and gives them some oversight throughout the process.
But Agile's frequent deliveries do not equal wrapping-up more products in a time that's needed to deliver one product in a traditional way. It only means a change in how things are done - after each iteration a working version, a prototype is available for customer review - it's not a complete thing.
Quite often this is where the stakeholders get confused and on that basis can be mistaken in thinking that working Agile equals doing more for the same price. It means doing probably just as much, but in a way that's better tailored to the client's need - via more feedback loops.

To sum up, while there is an indisputable value in Agile, let's not be fooled into thinking it solves all issues, however deep and however misunderstood. Most of all, it's worth asking more questions when teams are signalling problems.
There will be times, when teams are just inefficient and it's making everyone tired, or when processes simply don't work any more. Not all of these Agile calls are substantiated - let's try not to assume that a spontaneous need of Agile just gets randomly manifested by teams, everywhere, all at once.
Some of these cases just need a good realignment of goals vs. methods. It may well be that Agile will give the correct answer, but it rather shouldn't be an assumed answer to all problems.