Seems everybody and their dog are “doing agile” and they all seem to be complaining about how agile isn’t helping them, in fact for a lot of them it seems to be hindering them.
I’ve wondered about this for a while and it wasn’t until reading Dan North’s recent post “How to train your agile” that it struck me.
I’ve been writing software for just under 20 years and when I started the way projects were managed were completely different from how a lot of people manage them now…
When I was young it was all fields around here
At the end of the 90’s delivery of software was frequently measured in years, projects often cancelled before completion and of those projects that were delivered they frequently had stability issues requiring lots of rework.
This way of working was fundamentally broken and so people set out to find a better way to work.
When they started using agile, delivering in months not years and focusing on ensuring the software worked you can see how radical the change was and this lead to a real change in how software was delivered, it gave businesses:
- Faster development
- Better quality software
- Working software delivered to production
All the things you still hear today associated with agile, what organisation wouldn’t want all of those things compared to what they had?
Whatever grandpa, that’s not how we do it nowadays
The expectation today is working software delivered in weeks not months or years, an “agile” process isn’t really adding anything here, it’s the norm, it certainly isn’t going to make it any faster, even though people might keep saying it will.
Unfortunately not all environments are the same and in some “agile” is a dirty word synonymous with pointless meetings and having to work in a hamster wheel of sprints which never deliver what they were supposed to, where each sprint can become a
Where people are working in this way they don’t see any benefits, all they see is a broken process that they’re forced to follow because the management believe it will mean faster development, better quality, etc. If all you’ve known is this type of environment then you would most likely think agile should die in a fire and for a lot of devs that have joined our community in the last 6-8 years this is their only experience of agile.
At the other end of the scale there are people working in an environment that makes original agile look antiquated, continuous deployment multiple times a day, focused on adding value for the business, trunk based development with feature toggling, etc. These types of environment frequently, but not always, have a DevOps culture looking beyond development to see how the organisation as a whole effects what they do, and the organisation looks for ways to improve, systems thinking.
Where does this leave us?
When you take a look back at the environment that spawned agile its easy to see where the claims around faster, better quality, etc came from, at the time it was a completely different way to work. To be fair if you are still delivering multi-month/year projects using waterfall then those original claims are still likely to be true today.
For anybody in environments that look backwards to most agile practices – well done! keep up the good work! Only thing I will say is stay vigilant as it can be all too easy to slip back into bad practices.
If you are working in an “agile” environment, that is anything but agile, you may be able to change what you are doing by using the retrospectives to start conversations around the areas you believe aren’t helping and look at what you can do to change the situation, focusing on the principles rather than the practices (outcome not output, working software, etc) to attempt to improve your situation.
There is almost always ways to improve how you are working and that should be baked into any process you follow, what is frequently missing is the will to change or even try to change.
I firmly believe agile can help you but it does require you to participate so make sure you join in and look for ways to improve how you work, regardless of its “agile” or not.