This is my second posting and I want to talk about how we’ve implemented SCRUM at Nearsoft.

When we started, we used traditional waterfall development.  To build complex, sophisticated products we prepared huge, MS Project plans.  MS Project is fine for what it does, but I really never liked it.

Maintaining these documents is a nightmare.  The process is very error prone and as the plan got more “accurate,” it also got harder to understand.

At one point I read an eBook called “SCRUM and XP from the Trenches,” by Henrik Kniberg.  (BTW, this is a “must read” if you are interested in learning the SCRUM methodology).

I knew right away that this was a better way of building software.  I started applying what I just learned and moved all the information from MS Project document to a very simple MS Excel workbook.

This document contained the defined product features in two-week sprints.  To complete this exercise, and completely get rid of MS Project, we needed to calculate the amount of hours that the team would be able to invest on each two-week sprint.  From that we could easily estimate what features could be completed in that time.  Features that could not be done in Sprint 1 were moved to Sprint 2 and so on.  In the end, we figured that we would need nine Sprints to complete the first version of the application and go live.

That was just the beginning of it, the plan.  It was only one small step, but we were on our way.  Over time we added other practices to our cycle:

  • Daily meetings to review progress and find roadblocks early.
  • A whiteboard to visually keep track of the progress of the sprint.
  • The Product Backlog to keep track of features and estimates.
  • Retrospective meetings, for lessons learned.
  • Metrics, to quantify our efforts and delivery deviations.
  • Sprint planning meetings to review requirements, make estimates and define future sprints.

As we gained experience with this methodology, we spread the practices to other client teams. Today, we use it as our default software development life cycle.

Did We Get Better Results Using SCRUM?

Yes, we did.  Absolutely. Here are a few reasons:

  • The daily meetings helped us improve team communication.
  • Progress is highly visible. You know when you are either behind or ahead the schedule.
  • Every delivery is an opportunity to receive feedback—the sooner you realize you are headed the wrong way, the better.
  • Each iteration allows the team to quickly learn from previous iterations, while everything is still fresh in our minds.
  • Team members like it, and product owners love it.
  • The product owner becomes an integral member of the team, he/she is aware of everything that’s happening in the project and can support the rest of the team when needed.
  • At the end of each sprint, the team celebrates its success or even its failure—this keeps team morale high.

If you don’t find this convincing enough, then try this:  there is no “Project Manager” to babysit the team.  Instead, everybody in the team behaves as an adult, the scrum master, the developers, the product owner.  So, how’s that?  As an ex-Project Manager, I much rather work in this type of environment.

Next Steps

A successful implementation of SCRUM is only one piece of the puzzle of modern software development practices, including daily builds, unit testing, continuous code reviews, test-driven development, automated testing, etc.

But that is another story (and several future posts).