There’s been some talk recently about TDD being dead.
DHH’s post, “TDD is dead. Long live testing.”, brings up some good points about problems I’ve seen with developers trying to adopt to Agile practices.
However, there are larger problems I’ve seen that have completely killed attempts at implementing Agile development.
Management pushed Agile on the development team
In one place, with a non-Agile IT team in one division, they merged that team with their “main” IT team, which followed Agile practices – while still keeping them in a separate building.
This was handed down as a command, with little discussion with the development team.
As a reasonable person might guess, you have a team that’s suddenly worried about their job, and you’ve basically told them they’ve been doing everything wrong, and the main team (in the main office) is so much better.
They were supposed to go from “typical” development practices, to unit-tested (with a high degree of code coverage) code that was being continuously integrated and passing all tests.
What really happened was that most people did everything they could to avoid changing – including, for many people, quitting.
Management didn’t care
Many Agile practices revolve around improving code quality – automated unit tests, continuous integration, etc.
To paraphrase an old saying, “You get what you measure and monitor.”
The problem for another company was that management didn’t monitor anything concerning development. They never even looked at the build server status.
So, not too surprisingly, the builds started to break, and stay broken. Since the senior management didn’t care, the development managers didn’t care. And since the development managers didn’t care, the developers didn’t care.
If a company doesn’t even keep their builds from breaking, there’s no hope for maintaining passing automated unit tests.
Since actions speak louder than words, management needs to be actively involved in the process of changing to Agile development. If they don’t pay attention to what is happening, it’s obvious that they don’t care. That will kill the attempt to change.
Management picks and chooses the practices they like
One company I worked at decided to start doing Agile development, instead of the waterfallish way they were previously managing projects.
We gave points to user stories, ranked them by priority, put them up on a Kanban board, and had weekly sprints. However, senior management still had an unchangeable list of required features, and a single delivery date about nine months after the project started.
We gave our weekly demos to a “user representative” – a full-time member of the IT staff.
But there was no feedback from real users, who were actually using the web app. No users tried the app until it was too late to change it.
Not too surprisingly, when we finally released it, there were few subscribers.
In fact, we hadn’t yet written the code to handle subscription expirations and renewals. There were so few subscribers that it was decided it wasn’t worth the time and money to write that code. It was cheaper to let the few users continue using the app for free, than to add in that code.
One of the huge advantages of Agile is frequent deployments – getting the product in front of the users as soon as possible.
With frequent deployments to your users, you get real feedback.
With this high-quality feedback, you can add the features your users really want, resulting in an application that truly fits their needs. Without it, you can spend a year guessing what your users need, one or two million dollars on development, and deliver a product that no one wants.
How can you avoid killing an Agile implementation?
Realize that this is a significant change to people’s mindsets. Most people don’t like change, and you’re about to tell everyone on the development team that they’ve been doing things “bad” for their entire previous career. Spend time with them to get buy-in. You may need to move slowly, implementing one new practice at a time.
Realize that most of the practices in Agile are based around some basic principles. If your company’s management doesn’t care about these principles, then your development team won’t either. It’s just like the companies with noble mission statements that all the employees laugh at – since it’s obvious management doesn’t consider “employees their greatest asset”, even though they repeat that line at every employee meeting.
Realize that a common thread behind most Agile practices is “faster feedback”. If you take out one of the feedback loops, you may kill many of the advantages you could have achieved. You don’t stay physically healthy by only exercising one part of your body. And you can’t improve how your web applications impact your business if you don’t apply some Agile practices outside of the IT department.
Leave a Comment