More stuff on Scrum

Here is another post on Scrum from Mike Cohn.

--Boehm's spiral model is risk-driven. To start each pass through the spiral
you determine the riskiest thing and do activities to resolve that risk
(normally code that part of the system). Scrum, on the other hand, is
customer-value driven. To start each sprint, the product owner selects her
highest priority work. This is a very key distinction because spiral model
leads to work on risky items that may not be needed. It also puts the
development team in a mode of avoiding risk instead of a mode of delivering
customer value. This doesn't say we ignore risk in Scrum and often risky
stories get prioritized quite highly but risk is not the only or the driving
factor.

--Spiral model is iterative but doesn't stress having the same length of
iteration each time. Scrum wants the same sprint length every sprint. This
creates a very nice rhythm to the project--every 30 days the team knows it
will deliver.

--Spiral projects may or may not produce working code each time through the
spiral. During the initial go-rounds it is entirely likely they won't
produce code, or at least won't produce code that lives in the final
product. Scrum teams will.

--The spiral model is really a shortened waterfall if you uncoil it. There
are distinct phases. They may overlap slightly but they are not
highly/totally concurrent as with Scrum.

I hope that helps,

--Mike Cohn
Author of User Stories Applied for Agile Software Development
www.mountaingoatsoftware.com

What is Scrum?

What is Scrum?
The first question that you’ll probably want answered is: is Scrum an acronym for something? You would not be alone in thinking this; most other project management processes and techniques are acronyms. Scrum however is just a name, it’s not an acronym. Similarly, it has very little to do with rugby either, although there is a "daily meeting" that might be compared to a traditional rugby scrum.
Scrum borrows from the "agile" world through its promotion of iterative and incremental practices. It has a simple implementation that is designed to increase productivity and reduce the time it takes to benefit from a software/product development. Importantly, it embraces adaptive and empirical systems development.
That last paragraph introduced two of Scrum’s key facets: adaptive and empirical. The majority of project management methods and techniques are very prescriptive; they tie us down to a fixed sequence of events and offer little in the way of flexibility. Similarly, newer, less mature methods often claim to be a panacea, yet they lack any definitive proof or track history. Fortunately, Scrum is mature; it has a track record going back as far as 1995 and earlier. Similarly, it is scaleable: Scrum can be used on projects of any size. Whilst I will not be discussing it in this article, "Scrum teams" allow Scrum to be used to manage enterprise-level projects.
Scrum also promotes and lends itself to managing eXtreme Programming (XP) based projects. XP uses "customer on site" as a means of ensuring that the development team’s questions are answered but also to ensure that what the development team is producing what the customer actually wants.

End Of an Era

Well,  my time at Flicker has just about come to an end. We are in the final processes of making the big switch.  This is my final project I am involved in.  But, even though it is sad I have a very exciting announcement.  You may know that I have been interested in agile software development, some of which I started here.  You may have heard me talk about Scrum!  Well I am about to embark upon a new career as a Scrum Master.  What is a Scrum Master you ask? Well a Scrum Master is the person that keeps the scrum team working efficiently.  You still don't know what I am talking about?  Well, I will fill you in later once I have a little more time to explain to you what it all means.  I think you will find it all very exciting. Until then, take it easy.