Share via

Why Did I Go Agile? Part Three: Scrum

  • Article

In my other posts in this series, I shared why I was open to trying agile ideas, and I discussed how and why I adopted TDD (Part One: An Open Mind and Part Two: TDD).  At the end of the project cycle that sold me on TDD, I was approached by one of the PMs in MSN (Mitch Lacey) to work on another project, but a project where we would be allowed to do a lot of things differently. 

The software the project was to deliver was a back-end system, integral to the business.  We would be replacing an existing system with one that was built on a different technology platform.  This system had to have high availability (99.999%), be modular and pluggable to handle future business needs without a recompile and re-deployment, and handle a high number of transactions per second.

Mitch gave me a book to read, Agile Project Management with Scrum by Ken Schwaber.  I read the book, and was intrigued by some of the ideas.  The idea of no overtime really grabbed my attention.  So did the idea of being able to estimate my own work, and not have features handed to me with arbitrary fixed-in-concrete estimates on the amount of effort attached.  Mitch and I chatted quite a bit about pulling a team of folks willing to try Scrum together, and getting management to buy off on the idea.

Management liked the idea and had a few requests for the team.  First, we had to try Scrum and a few other agile techniques (which I will cover in later installments in this series).  Second, we had to report back to management and the rest of the organization on how well things worked, things that we learned, and challenges we ran into.  Finally, we had to deliver some software. 

So, we started this project with 5 folks on the team: Mitch as Product Owner, two developers (myself and one other), and two testers.  None of us had previously worked together on anything, so there was no existing team dynamic.  We also had a ScumMaster/coach who was not part of the team, but assisted.  Our first few sprints were ugly.  By ugly, I mean really bad, painful, and we did not accomplish a lot.  However, we were changing how we thought about software development.   For example, for our first 30 day sprint, we spent about 12 hours doing the planning meetings, during which we argued a bunch.  At the end of the sprint, we had accomplished about half of what we wanted to do.  Our second sprint, planning was better and only lasted about 8 hours.  However, the sprint was terminated when there was an big re-organization of the group and we lost a few team members.  By our fifth sprint, we were doing better and delivering on about 85% of what we wanted to, but the planning meetings were louder.  Over time, our estimation skills improved, our ability to decompose stories into tasks improved, and our team started to gel.  Eventually, we were able to effectively plan our sprints (we did eventually change to two week sprints), deliver 90% + of the stories, and we identified a whole lot of areas, internal processes, etc that caused friction.

While we did not completely get away from overtime, we did get a lot better about it (except for about a month where the team signed up for overtime to deliver a v1 by a specific date, rather than bring in a few unwilling team members that management wanted to give us and would probably have slowed us down).  We became a lot more predictable in our delivery.  There were times that management asked our team to completely change course as business needs changed, and we did so with no problems.  This surprised management a lot. 

In the end, things worked out well for everyone involved.  The project shipped in stages, replacing features of the old system one at a time.  Management called the project a success.  To quote one of the members of the management team, "[The team] replaced our most core system, the heart of our service, with no downtime, no drama, and with no customer impact and on time."  That is a success.  One of the testers also had comments about the project, "This is the highest quality code I have ever seen in [our team]." You can't get any better than that.

Watch for my next installment where I discuss why I tried Pair Programming.

Comments