I hated Agile once. Some days I still do.
What do you call a project with two-week development increments and then a release of a potentially done product? If you said Agile (or Scrum), you are missing some of the most important parts of Agile.
- Where is the emergent leadership?
- Where is the collaborative work effort?
- Where is the self-organizing team?
- Are we maximizing the value of the work not done?
- Why aren’t we discussing our potential issues and figuring out how to make things better?
- Why is the Scrum Master leading the daily stand-up?
- Why aren’t we adapting?
- Why do the developers have no input into the work they are doing to complete this increment?
My fist Agile project was a project where they focused more on the processes that are often associated with Agile rather than the things that can potentially make Agile better. If you have never experienced that, it can make for a miserable working day.
I don’t think my first experience with Agile was a unique situation. In fact, I think it is entirely too common. I have heard people talk about how much they hate Agile and how it doesn’t work. It won’t work when you only focus on iterative development and meeting arbitrary deadlines set by someone who is not doing the development work (or never even met the developers, which has happened to me before).
Agile conducted in a way that focuses solely on the processes only has the effect of turning the software development process into a factory; and not even a good factory. Imagine a factory that didn’t care about the quality of what they put into their product, just as long as it looked good enough on the surface for the people who are using it.
No one really cares what the code looks like, you just need to push it out fast and it only needs to work today. You need to push it out faster than you are doing it. Faster than it can be done and still keep it high-quality code. But no one sees the code so no one cares.
The code always needs to work today, just get it to work today. Worry about tomorrow when tomorrow comes. On the surface that sounds like progressive elaboration, but it isn’t. With progressive elaboration, you would use today to help you plan for tomorrow and then adapt.
Technical Debt? Not an issue we need to deal with right now as long as it works. You are likely making spaghetti with that code 6 months into the project and no one cares as long as it works. Now someone you have never met has promised huge changes to the application and that someone gets to go home on time while you work overtime to deliver on those changes. But it’s okay, the company made you a salaried employee so it won’t get too expensive for them.
Most of the developers want to try and create quality code; they also want to go home to see their families. So you give them a push to keep going faster in order to adhere to these arbitrary iteration lengths and deadlines and as much as they possibly can they will try to make sure they can go home on time and code quality will suffer for it. I don’t blame them, no one wants to spend their entire lives inside of a software factory creating a product they know to be subpar.
Focusing too much on the wrong things is not very agile. I can’t blame anyone who has experienced an Agile environment like that for hating Agile. I hated it too, and when I see it again, I still hate it. It isn’t a well thought out implementation of Agile. It isn’t Agile at all.
Images from pexels.com