The Cult of Agile
The Cult of Agile
By Damon Swayn
The original version of this post was much different. I wanted to talk about my feelings towards the cargo cult of those who sell us the Agile Manifesto and talk about software architecture while it seems, at least to me, they probably haven’t written a line of code in many years.
However, after writing a first draft, I feel the need to revise what I think is the real cargo cult in the current age of software development. I did a lot of research, reflected on my experiences, and even talked to a few people.
Agile is a great idea in theory, given that software is a field where estimation is near impossible. The problem with Agile today is that enterprises saw it as a solution to turning software into a profit center instead of a cost center. As much as I’d like to remove myself from thinking in terms of business (I’m an engineer, not an accountant), I want to concede that it does make sense.
The reason why this has been bad is because an enterprise is based on years of practices around charting and estimating and other such things that we pay project managers for, which allows businesses to do cost-benefit analysis and other such things. Agile makes these things difficult, and therefore today’s version of Agile is bastardized to reflect what an enterprise thinks it needs.
Let’s lay out how I feel Agile should be practiced in an enterprise setting:
- Pointy-Haired Boss comes up with a project
- Meetings are held with developers to nut out specs, stories, etc.
- Sprint meeting is held to decide what is to be done in upcoming sprint
- Sprint is locked down, and it is iterated to the client that during the sprint things cannot change
- Developers code for duration of sprint
- While project is not complete, goto 3
The problems I have personally experienced with modern Agile reflect issues with two things I think are important in this process; a lack of QA/testing during the sprint, and clients who see customer collaboration and responding to change as meaning that they can change the specifications and the requirements at any time.
Admittedly, the first problem is solved on the developer’s end. Having continuous integration and nightly builds means that every day there should be a new build to be tested. While developers should be aiming to have their sprint as bug-free as possible, sometimes it is not possible to finish the sprint and fix all the bugs in a given sprint – this is what sprint meetings are for, as they allow for the client to be notified of existing bugs and for bug fixing to be scheduled in as a part of the project.
The second problem is one of communication. Clients need to understand that if things are to be done on schedule, you can’t keep adding more targets to hit along the way. Explaining to clients that while yes, Agile is designed for changing requirements, the reason we have sprint meetings is exactly to evaluate regularly the priorities and needs of the project – and to schedule such changes into the development process.
A good Agile developer/project manager needs to recognize these shortcomings not just for the sake of the project, but also for the sake of the sanity of his developers.
Damon Swayn is a Web Developer at Ivy Street. You can read more from Damon on his blog.
Hi Damon,
I have to admit, I enjoyed reading your post, enough even to produce some thoughts on it.
Firstly, I think the heading of your post should have been “The Enterprise Bastardization of Agile” or something similar, because that’s what you’re describing, as you identified correctly yourself. The “cult of Agile” exists too, as a cultural stream where everything agile is good and everything not-agile is bad.
Secondly, you seem to equate Scrum with Agile, an all too common mistake. You probably aren’t but it comes across that way in the article.
Personally, I feel that if you take collaboration to its natural conclusion, IT and business cannot remain separate. Enterprises should be divided in customer-focused value networks and enterprise development teams integrated into to the very business for which they create software. I believe this would reduce problems with silo thinking, customer-supplier behaviour, demands for up-front specifications and estimates fall away naturally.
Of course, this is sensitive stuff in an enterprise, since it would move a large part of IT into other departments and with the other half being replaced with cloud services that is a tough call for any exec to make. But what if you could make small, engaged, agile mini-companies out of each enterprise department? Just a thought.