Mean in green
I'm Kevin. I live in Salem, Mass with my wife and little boy and I build software.

Empirical development and Scrum

Thursday Oct 16, 2008

Recently, I've been reading a book about Scrum methodology for software development. The book is titled Agile Software Development with Scrum, by Ken Schwaber and Mike Beedle. It's interesting to me because it really defines and encapsulates a lot of my theories in a way I have not been able to articulate on my own. It helps to define a process to create unique, unrepeatable results. I think it demonstrates a great way to build custom-tailored solutions for your clients.

Click through to

The basic gist is that you use an empirical process control model for software and systems development - experimenting, learning and adjusting throughout a project - instead of using a defined process control model. If a project lasts six months or a year, there is a very good chance that the requirements and even the fundamental technologies will change during development. An agile method allows for periodic adjustments during the development cycle.

It provides and exercises control through frequent inspection and adaptation for processes that are imperfectly defined and generate unpredictable and unrepeatable outputs. (Schwaber 2002, p. 25)

There is a good analogy in the book comparing development to navigating a ship using stars as reference points at night. The ship will inevitably drift off course due to environmental, instrumental and mechanical factors, but it can always recalibrate at night. So, the course of the ship is a zig-zag that is constantly adjusting towards the destination.

Scrum is controlled in a similar manner, through daily meetings - appropriately named Scrums - and using thirty-day development iterations where management can get involved and adjust the course of the team. There are a lot more details about the management style and Scrum practices, but I'll let you read the book for those specifics :)

Over the course of my career I have found that it is best to keep a clear definition of project goals, but not get caught up in defining each step of the process. Software, systems and design are not repeatable processes and should not be looked at as such. A repeatable process will give you a cookie-cutter product that most likely will not be a good fit for every client. If you truly focus on the unique needs of a client, you have to create a unique solution for that client. It is by definition an unrepeatable process.

This book was given to me by my new colleague Chuck D'Antonio, who is the Senior Director of Professional Services at Acquia. I'm beginning to get very excited to work more with the new team and I'm positive that I have a lot to learn. It's going to be fun to analyze our processes and develop methodology of our own. For now, Scrum seems to be an awesome starting point, and I would highly recommend the book to anyone involved in project management - software or otherwise. It is written at a high enough level that you don't need to fully understand the software terminology. There is still a lot of good knowledge to be gleaned.

I have a few more books on Agile and Scrum, so as I get through them I'll try to write some more reviews. Fascinating stuff!

  • Schwaber, K (2002) "Agile Software Development with Scrum", Prentice Hall.