Scrum part 1: Why I like Scrum!

Dear reader,

For me Scrum has three things that makes it very good for execution of software projects:

1. It is a simple process
2. It uses a methodology that gives clear results and
3. It introduces soft parameters that drive efficiency

What’s good about the simple process in Scrum:

• If you can learn it by hart and do not have to peak in a process chart the chance of succeeding is much greater.


• If the process is simple top management, product management, sales and the rest of the company will understand what engineering is doing and hence it is much easier to get an overall buy-in from the rest of the company.

What’s good about the methodology in Scrum:

• You spend minimal time investigating requirements that might not be part of the product in the end.


• The daily Scrum meetings give you instant feedback on your development status. Or as Addison-Wesley put it in the The Mythical Man-Month (1975): Question: How does a large software project get to be one year late? Answer: One day at a time! This was written in 1975 and is unfortunately still true.


• The burn down graph/s give anyone in the company 100% transparency on the project status if you have a good project portal available in your ALM tool (application Life cycle management tool) or team collaboration platform (more on ALM tools in a later post).


• You have a very clear distinction between the one who orders the products and sets priorities and who delivers.


• When the sprint is running you have a very low risk for requirements creep i.e. the sprint is closed. And if anyone want new requirements they have to put them into the product backlog, and then they are always measured against the most important stuff that is in the product backlog, and when you do it, it is often very clear that the new requirements has a lower priority.


• In the end you often get a better products since you reevaluate the product after every sprint and you plan for the flexibility and change (change is not something evil that you feel when you are doing waterfall projects).


• Sprint Retrospective gives you part of the learning organization for “free” (for more information see my blog post from Saturday, 6 March 2010: The development process part 3!)

What’s good about the soft parameters in Scrum:

• The team is isolated during the sprint (i.e. efficient and easy to understand for the rest of the company)


• The daily Scrum meetings gives the team a nice peer pressure to deliver results every day. Who would like to come every day and tell there friends I did not do what I promised?


• Delivering in short iterations give a much greater satisfaction than working with something for maybe 1 year without seeing the results.


• When you are having the sprint planning meeting you get a buy in from the team to deliver what you agree on (do not forget to use planning poker if you want full impact of this soft parameter). This address many of the issues addressed in the book “The Five Dysfunctions of a Team” by Patrick Lencioni. Patrick Lencioni book explores the fundamental causes of organizational politics and team failure. In later post I will explain how I use this book and what it has give me and how you can use it to increase efficiency and trust etc.

Okay that was a long list and not the complet list! But as you can see it is absolutely attractive to start using some agile development :- ) for your project execution.

In part 2 of Scrum I will give you best practices and how to use Scrum in the most effective way in your development (imo) and write more about why you should use planning poker..

Thank you for reading and please give some feedback?

Anders