Not everything needs agile
I have been involved in agile software engineering projects almost exclusively for the past 9 years or so. I have witnessed and have set up all kinds of different flavors of agility. And I am still a big fan of the agile approach and what it stands for.
So to say that not every product development process needs an agile approach might sound weird coming from me. Yet, aside from agile or lean startup processes being fashionable not many people seem to ask themselves the question: do we really need this?
The advantages of agility are pretty clear when you’re building something new. Say you’re building a new online store or a game the best way forward would be to start small and go live as soon as you can to get feedback from the market. Subsequently you adjust to what your customers say about your service and expand on the functionality as you go and as is needed.
What’s the use?
But what if you’re working on a legacy application? Does it really make sense to go all agile on it? Say, a large (in-house) CRM or ERP, or campaign software or a government service. In many cases these are tools that are heavily used by many people and change is hard. Not only for the users of those systems but definitely also for the developers building and maintaining the code. Even for a complete overhaul of such a system it’s usually no option to start small. You would start feature-complete. So why would you do that in an agile way? You can use agile tools and processes, but if you’re not releasing regularly and in small increments why bother?
Also on a smaller level: many features of a product rarely ever change. Especially if they are part of a bigger suite or service. In many companies the teams working on the newer components will push for a more agile approach. Of course. They need it. But do the other teams working on sustaining what already exist have to follow suit?
Moreover, think of the human opportunity cost. If there is no clear advantage for switching to agile development the mindset of developers working on those products will not naturally shift. It will feel (and it often does) as yet another imposed process that needs to be followed. Meaning: trainings, certifications, role definitions… but to what end? You’ll pull people out of their comfort zones, but will not be able to empower them with the spirit of agility. In the end, in these kinds of projects, and there are plenty of those, the requirements are set up front and months of work can be nicely planned ahead. So why not do waterfall? It sure beats waterscrumfall or any other watered down version of an agile process. (And I don’t even want to touch on the topic of scaled up “agile” frameworks)
Agility is the promise to the development team to have a great impact on what they are delivering. Timing-wise but also requirement-wise. It comes with great power and great responsibility. In reality many people don’t want that. They prefer a 9-to-5 job over the excitement of an agile team. And for them that’s fine. In fact in companies that implement agile processes from the top down you will often find a lot of the developers leaving the company.
If you’re up for it, go agile! It’s exciting, it’s customer-centric, it’s cost effective and your team will learn a lot! But: you need developers and other team members that truly believe in the agile way of working. For me, having dealt with both “real” and “fake” agile teams, that does not mean writing stories in JIRA and having daily stand ups, it means understanding the agile manifesto and working according to its spirit and not its supposed rules.
At the end of the day if you force agility on people that (often for good reason) don’t see the need you’ll just create unhappy coworkers. And unhappy workers quit your company.
Or worse: they stay. And because they are forced to work in a way that bothers them so much you get a really negative vibe going on against agility. Agile is getting the blame for everything that goes wrong.
Don’t force it
As a strong believer in agile software developments and having seen its great benefits that is the thing that worries me most: a negative attitude towards agile development that builds from inside. If it becomes strong enough and tensions rise high enough it will come to a point that management starts thinking: “this agile thing is clearly not working”. So, don’t force agile for the sake of agile or the projects that really need that approach will suffer in the end and you will kill innovation in your company. And it will be killed off by the very process that you set up to boost it: agile software development.