Two week sprints; twelve month releases

"We do two week sprints here," said Daniel. "Each fortnight we pick the items from the backlog that we're going to do, and we do them. At the end of the fortnight, we demo it to Michael, and do a retrospective. The project has been going for about 8 months."

"Who is Michael?" I asked.

Daniel pointed, and said: "His title is business analyst, but we made him the product owner. He writes the specs."

"Great!" I exclaimed. "And who are the end users? When do they see the product?"

"They are on the other side of the building; they're too busy to look at the product right now, but going by Harry's Gantt chart they'll start using the product in about 4 months."

I was naive then, but to me this seemed like a great example of an Agile project. Two week sprints, a well maintained backlog, reviews and retrospectives. Automated builds running every checkin, and plenty of unit tests. The team had been humming along for 8 months now. Every build produced an MSI ready to be used. Someone had even spent days just tweaking the size of the icons used in the MSI. In four months a real user was going to use that MSI to install the software. We were ready!

If you've been around for a while, you'll recognize that this project eventually became a death march. Once real users actually saw the application, everything changed. The system performed terribly. A lot of the assumptions that had been made about how the software was meant to work were flat out wrong. The numbers came out wrong. The forms took way too long to fill in. "You should have just built it in Excel" said the users. In fact the users who ended up using the system weren't even the people we had in mind. Working long hours and weekends, we eventually delivered something of value 6 months later, not too long after the auditors arrived from HQ to find out what on earth was going on.

What was missing from this "Agile" project was one thing: feedback. Not just any feedback, but valuable feedback from people that mattered. Delivering software successfully, like anything in life, is all about tightening the feedback loops. The sooner you learn what you are doing wrong, the sooner you can do it better.

The two week sprint and demos to a BA gave us some feedback, but it was no where near as valuable as the feedback real users gave. Software that isn't in the hands of real users is inventory, and the longer it sits on the shelf, the smellier it's going to get.

With the benefit of hindsight, I would have done this project differently. We should have focused on delivering one small part of the product early, something that would be useful to a real user, and convinced them to use it. Then those two week sprints would have delivered software to someone who mattered.

That experience is why I love hearing stories like this about Octopus Deploy:

We are saving about 1.5 days man days a week, not to mention that we are no longer zombies the day after the deployment. It used to be impossible to do more than one a week. Now I can easily push code with OctopusDeploy to QA and then do some rudimentary checks and then promote to Production as well as our fail over environment.

If releasing software to real users is hard, people avoid it, which means the feedback loop is reduced. By making deployments consistent and easier, people are more likely to do it. That gets working software to end users faster, which makes a real difference in the quality of the feedback. That's good for everyone.