Agile is chaotic. Agile is suitable for everything. Agile won’t require you to change much outside the development team. Agile automatically makes things better.
None of the above are true, but all of them are either said, implied, or acted-as-though-true somewhere. As with any hype cycle (and in IT we get them all the time) it is important to focus back on what is going on, where the issues are and how to get the best outcomes.
Agile has in some ways been a pretty elite domain. Experienced agile participants have been working through the rapid evolution of an exciting way of doing things that can be totally transformative.
It could be argued that the true test of agile is not whether elite teams fully empowered can make it work, but whether it can deliver in the worlds of more constrained resources. As it comes out of the hothouse and is being applied to organisations ‘down the road’ it will be a testing time. The reputation of agile is at stake, and if it is as good as the hype suggests even in part then that reputation is important.
Myth 1: Agile is chaotic
One thing that can either prevent agile getting beyond senior management, or doom a project to failure, is a lack of understanding of the rigour of agile. Agile methods require disciplined attention to planning and change control, and won’t succeed without it. Because it is incremental and iterative by design, the planning and change control is simple (which is a good thing) rather than simplistic (which isn’t).
Anyone who has worked on a mediocre waterfall-style project is fully aware that from the outside a project can look calm with a clear status board while on the inside it is chaos. Agile projects can, to the uninitiated, look like chaos.
Closer inspection should reveal a tight process and controls, well-defined roles that a) people stick to and b) mean what they say (e.g. if product owner means product scapegoat you’ve got problems right up front). Agile projects should be rigorous, but based on very simple principles and approaches rather than a complex well-documented nightmare.
Myth 2: Agile is suitable for everything
This is a live debate. Avoiding the front line of this debate, it is fair to say that some types of environments clearly benefit from agile methods, and others already work well with traditional delivery methods.
Where user experience is paramount, where you’re implementing based on concepts and people interactions, effectively where requirements are either evolving or vague, agile methods can work extremely well. That didn’t do it quite right? Iterate! Typically on infrastructure projects where the technology details are paramount and simple, where the requirements are clear and deterministic (must meet XYZ protocol and connect to ABC) it is not clear that agile methods offer the same level of advantage. This is, as mentioned, open to a lot of debate.
Irrespective, the first taste of agile for an organisation should ideally be where the advantage is clear, significant and obvious to the whole organisation once delivered. Agile is not a pill to take that will make everything ok.
Myth 3: Agile won’t require you to change much outside the development team
If you hear the phrase ‘Our IT team are going agile’ then that probably means ‘Our IT team are going into business for themselves’ or ‘We are about to do significant corporate self-harm’. Perhaps that is a matter of context, but the point is that agile teams must involve the relevant people.
If it is a project for the marketing team, then the marketing team are part of the agile team; if they are the passive recipients of the output then either the project will go very badly, it isn’t really a project for the marketing team, or the people who think they are the marketing team aren’t. Or all of the above.
Because agile methods require very close collaboration with their customers and stakeholders, they are inherently multidisciplinary. Decisions are taken within the team or it isn’t an agile project. Therefore adoption of these methods needs to extend to the limits of what the project involves; it is incredibly important that all the relevant bits of the organisation are aware of the way agile projects work, the terminology and the crunch-points. Yes, that does mean that your finance and marketing team may need to understand what ‘scrum’ and ‘sprint’ mean or they won’t be able to interact successfully with it.
Myth 4: Agile automatically makes things better
Agile is very exciting and can be fantastic, but it is not magic pixie dust. Summing up all the other myths, you can do it poorly without rigour, you can apply it to the wrong things and you can fail to understand how the whole organisation needs to adapt. It will not work unless leaders and managers understand how to delegate to, support and hold to account an agile team.
It will not work unless the right skills, capabilities and responsible owners are directly involved. It will not work unless the necessary expectations, terminology and culture extends far beyond the IT team. It will not work unless people understand why Agile works the way it does.
This is a challenge to IT leaders and those in organisations who can see the benefits of agile and want to push them in; you need to do the hard job of getting buy-in or you’ll blow it. This is a challenge to leaders to make sure they create an environment where agile teams can succeed not only in their mission statement but in their day-to-day decisions and how they support teams as they learn and overcome barriers.
It is a challenge to anyone working in an environment going agile to re-invent yourselves as collaborators, into people who are open and confident about small failures to avoid bigger ones. It is a challenge to everyone to take seriously the agile manifesto and the specific methodologies such as scrum and kanban and do agile properly and rigorously to a great outcome.
So to sum up, agile can make some things a lot better if you do it right. So do it right.
