September 1, 2008 by mattgrommes

This is the first in a series of posts on what I've learned about how we're doing (and not doing, as I've learned) Scrum on a big project at my work. Going to the Agile2008 conference and reading Mike Cohn's Agile Estimating and Planning have really helped me understand how we got into the predicament we're now in, with a late project and diminished team credibility with our upper management. Hopefully our story will help other teams on their road to becoming Agile.

We were brought Scrum by the vendor of the new billing system we were integrating. They use it internally and taught us about the practices. Immediately, it was a hit. We all liked the iterations, taking on tasks, demos, etc. Except the day-long planning meetings (we were doing 4 week iterations and have ~10 people on the team so that's a lot of estimating and assigning) we liked the whole process. I had complaints very early about the seeming lack of involvement from upper management but we dismissed it at the time, thinking they would come on board later. I gave a presentation at one of the demos about Scrum, having been told that some of our senior management team would be there but they weren't. The project seemed like it was going along fine though, so we just kept going.

The first big non-Scrum thing we did was we had an enforced deadline given to us by senior management based on a planning spreadsheet the vendor did. At the beginning, we thought we could meet that deadline so we didn't think about it. Bad idea. Since the vendor had brought Scrum to us, and had people in our office working with us, we figured we were doing everything right. The other huge non-Scrum thing we didn't know about, however, was the practice of looking at our velocity and reexamining the end-point of the project. That, of course, is a big deal and now we're paying the price. We just kept adding stuff into the project and iterating, without knowing that we should be taking much harder looks at the backlog and the amount of work remaining.

If we had known about using velocity to estimate the amount of work remaining, we would have known how in trouble we were. Our velocity was very consistent month to month but we never used that knowledge for anything. The result is that our deadline came and we had to get an extension but it was another arbitrary number, not based on our velocity or the amount of real work remaining. That deadline also came and went, and we're about to get another extension. The difference with this last extension is that now I know what we should have been doing all along and I'll make my voice heard.

Now, I can't blame the slippage of deadlines on any one thing, which makes looking back much harder. We had to deal with literally the worst software vendor I've ever heard of, let alone worked with (not the vendor we bought the product from, they're great luckily). The less said about them, the better for my blood pressure. But they did contribute to the slips immensely (and still are, so at least they're consistent). Another thing is that it turns out converting 15 years worth of financial data from an old system to a modern one is really, really, difficult. So that took longer than expected. And we had to implement a large piece of functionality on our own that the vendor should have done most of. That sucked up probably 6 full months of our most experienced programmer's time when the vendor told us it would be 2 weeks of work.

But taking that into account, almost certainly would have still taken until now to finish if we had known about the full Scrum processes we weren't doing. The difference is that our management would have known where we were the whole time and we could have taken a different tack in prioritizing features. (One problem I've had is finding help on implementing Agile in integration / upgrade projects. Most of the literature is on new development, which I'm planning a post on for later.) Part of the whole point of Agile is making sure people aren't surprised and we've now surprised our management more than once. And I can't say it's all their fault for not coming to the demo either since we didn't have the data we needed to be showing them. We also didn't start taking things off the backlog for inclusion in the first release until very recently. Partly because in an upgrade of a billing system there doesn't seem to be much that can be left out until you really start looking. Since we didn't think we had to, we weren't as brutal about taking things out as we clearly should have been.

I'm calling this part of the story Doing 80% because the problem was we were doing 80% of Scrum. We were doing iterations, estimating hours, assigning tasks, and demos so we thought we were doing just fine. If we had been skipping those fundamentals, we would have known something was wrong. The danger is that since we were doing 80% and we were new to Agile, we thought everything was fine. Now I see that if we had been doing that other 20% of planning and estimating and reexamining the backlog it would have helped tremendously. Now for our next projects I know what we need to be doing so hopefully things will go a lot smoother. Now we have our own knowledge and won't be reliant on the vendor to tell us if we're doing things correctly.

Further posts in this series will revisit some of these points to flesh out my thoughts; including the importance of upper management buy-in, Agile on integration/upgrade projects, and others.

More on my first agile project later. Thanks for reading.

My First Agile Project Series
Part 1: Doing 80%
Part 2: Inception & Planning
Part 3: Viral Videos and Bad Jokes in Scrum Demos
Part 4: How to lose credibility and jeopardize your project with lack of management buy-in
Part 5: Our Top 5 Agile Mistakes
Part 6: The First End Of Our Project

Permalink