Scrum Agile Development: Uncommon Sense
Scrum is an agile development method based on some of the key principles of lean manufacturing, pioneered by Toyota.
Advanced Development Methodologies, Inc is the home of Scrum. On their web site, I recently noticed their strapline: 'It's about Common Sense'.
When you think about it, it is.
In fact, it's so ludicrously simple, it's almost funny.
Think about it.
Think about the basic framework, only without the jargon:
- Make a list of the things you need to do (Product Backlog)
-
- Get someone (Product Owner) to decide what's most important and put the list in priority order
- Set a fixed deadline in the foreseeable future (Sprint)
-
- Estimate how much you'll be able to complete by the deadline (Sprint Planning/Sprint Backlog)
-
- Work through the list in priority order, completing each thing before moving on to the next
-
- Check your list every day to see how you're doing (Daily Scrum)
-
- Even if you haven't completed everything on the list, release the software when the time is up, in order to realise some benefits
-
- Review how it went to see if there's anything you would do differently in future (Sprint Review)
-
- Repeat (iterate)
So if it's so simple - if it's such Common Sense - why do so many software development teams tend not to work this way?
Why instead do so many development teams tend to work on long projects. Seeking to understand and define the entire scope up-front. Seeking to resist change. Seeking to develop everything before getting it tested. Seeking to complete *everything* before releasing *anything*.
Perhaps the makers of Scrum should have tagged it 'Uncommon Sense'.
Personally I think that would be closer to the truth.
See also:
10 Key Principles of Agile Development
18 June 2007 19:51
That's a great summary. I think the tendency to try to think of things up front has to do with fear of risk. There is a perceived reduction in risk if you assess things up front. However, in practice, it tends to be a waste of time. I do think the RUP idea of identifying and maintaining a list of the highest project risks is a not a bad idea - but it has to be handled in a way that doesn't involve ridiculous amounts of time spent on meetings and artifacts that don't have intrinsic value.
20 June 2007 08:29
Indeed a great summary of Scrum, even better than any of their highly regarded evangelists could have come up with :).
I also believe Vladimir is correct when he says that thinking things up front and resisting change tend to give development teams a feeling of comfort and low risk.
My personal opinion regarding software development methodologies is that you should use whatever suits your team and project best, even if it means combining more of the commonly known methodologies like Agile, RUP or Waterfall or doing something entirely new if that helps things along. I also wrote a short post on my blog regarding this so, if you like you can check it out: http://hypersynapse.blogspot.com/search/label/software%20methodology.
20 June 2007 14:03
My take on Why not?: There's nowhere to hide.
You have to accept that many bad ideas and poor workers are hidden within software products: Misanthropic people, burnouts, requirements that don't make sense, pet projects, sideline items demanded by management, but of no value.
With Scrum, it's so startlingly obvious what's valuable and what's not, that there's nowhere for a bad manager/project manager/architect/developer to hide, and that scares some people to death, enough that they bring down any sort of 'Agile' methodology as too radical or "cowboy".
I'm not implying that other methodologies are bad. This is just my experience with how Agile has been received where I've worked.
20 June 2007 21:35
I agree.
see my other post "Agile Development: No place for snipers!"
http://kw-agiledevelopment.blogspot.com/2007/04/agile-principle-10-no-place-for-snipers.html
Kelly.
29 June 2007 02:19
I've posted a blog entry refering this one at the following url
http://vladimirlevin.blogspot.com/2007/06/software-development-vs-engineering.html
3 August 2007 08:23
Reality is more complex than Scrum lets you believe.