I know that the title sounds like it contradicts itself, but let me make myself clear. There are 2 kinds of software organizations in the world today… one who don’t know/do Agile (and don’t really care as long as the cash registers ring) … the others who have heard of this new messiah called Agile and think that it is the answer to all their problems. This blog post concerns the second category who fanatically follow the ‘Agile Way’.
Any concept in practice has 2 parts to it …
a) Principles (why am I doing something)
b) Practices (how I enforce my principles)
What I think is happening with most new agile adopters is that the principles/intent is lost or ignored and what persists are the practices. Let me give an analogy with religion as an example. Most religions came into being so that people of a region lead meaningful and fruitful lives. The difficult part was to make people understand the rationale behind the practices but the easier part was to force the people to follow the practices blindly. A few people might really understand the principles behind the practices, but most people blindly practise rituals without knowing why. Agile today is the cool new religion in the software world. It is the messiah which promises that if you are on it’s side, you are on the right side. But as with religion, it’s message is getting lost. It is a commodity today with the range of different flavours, practices, buzzwords and certifications. The common software development team member is confused what to choose. Ultimately, it something that the management decides and off goes the team in the crusade to deliver outstanding and working software.
The developers read blogs and absorb buzzwords. The general message being that you should write tests. Developers start writing unit tests, integration tests, database tests, acceptance tests, smoke tests, acceptance tests and a variety of other words suffixed with tests. Then they spin off a continuous integration environment, which runs all these tests on every commit. All is well in Agile land, but as time passes by bugs seem to increase and the build seems to take an eternity. But features keep on coming, so tests keep on getting added. As the code base grows bigger, the tests become more and more brittle. There comes a stage where it takes time more time to fix a build than to develop a story. A broken build triggers a chain reaction of more broken builds and the developer is an indentured build fixer who fixes builds more than he develops new features.
The project manager has different problems. It is uncool to estimate in hours or man days. Estimating in points in the new way to go. Like a budget, a manager is given x points for a deliverable (it is funny that most people have a mental formula to convert the points into days and money). I am sure most project managers don’t question the reason behind relative sizing or the concept itself. When the team productivity goes down to due various issues, most project managers/team members still don’t question the practices and the reasons behind them (Why has this test broken the build ten times in 2 days… how do we fix it for good … or do we need it ?).
I have seen places where a practice/tool takes hours and hours to run and breaks the build for an invalid reason (99 percent of the time), it is still honoured to be ‘Agile’ and followed religiously. I have seen unit tests which instantiate an object and check if its instantiated (are you testing the programming language?). I have seen stake holders fight for a couple of ‘points’ or just one point for days (They could have gotten it done in a day). The reason I see is that the principles are forgotten and the practices and glamour persist. By the way, the first line of the Agile Manifesto says : Individuals and interactions over processes and tools.