Scrum part 2: How I practically use Scrum!

Dear reader,

I am not religious when it comes to use a methodology; hence always being pragmatic is key for me. Today I am going to write about how I would like Scrum to be executed in a project and what practical things you should think about.

First of all, as I have been writing about in the 3 product development posts, Scrum is part of the execution part of the project. What I mean with that is that you have to find a good point between when you exit the waterfall process and moves into the agile development that Scrum is. For me this happens when you reach the point in the requirement analysis phase where you know enough of what you need to implement on a high level and where top management has enough data to make a business decision on starting spending money (i.e. putting more resources on the project). This stage is for me often after a small team with the product owner, lead developer, chief or system architect and system designer, usability experts etc has done a top level pre-study with estimations (at this stage a +/- 25% accuracy is very good). Now you have your stack ranked product backlog (based on maybe focal point analysis) and you also have all your work included (not just the coding).

With ALL work I mean not just coding: All testing: Unit testing, integration, regression, user stories, more requierment analysis, documentation, bug fixing, platform testing 32/64 bit, platform set-up time, virtual development environments, installation programs, packaging, training etc.... The ALL work part is what is often missed when a product owner or a manager asks a developer how long time it takes to develop function X. This is often the 3 times factor many people use to get the right time estimated. Any way if you done this right the +/- 25% accuracy is not too bad and that can often be handled within the Scrum execution process (if you don’t have a backlog that only consist of show stoppers of course).

Now you have started the execution process, you have assigned the resources and the Scrum Master/s are ready to go. First you need to divide the work from the top of the product backlog to the Scrum team/s and you have to find all dependencies between the teams. I like to have a project manager running the top level dependencies between teams making sure nothing falls between chairs and an integration team that can integrate the deliveries.

In each team it is great to use planning poker for sprint planning session. Why? Many developers are not the most extrovert persons and will not share their great wisdom if not forced by a poker game :-). Also if everyone is involved you will get commitment (again the great book “The Five Dysfunctions of a Team” by Patrick Lencioni).
Then the execution of the sprint is straight forward and the daily meetings should always be used with great focus but I am not 100% religious around the pigs, chickens and or the 15 min it is okay if it is 20-25 min as well if it is produtive.

A very good support in the execution is a good ALM tool. You can use Microsoft Team Foundation Server (TFS) as the ALM tool with the task board add-in with virtual post-it notes (for more on this look at this site: http://www.scrumforteamsystem.com/en/default.aspx ). Also use Skype for Scrum meetings when we have several locations involved. I recommend to use more or less everything in TFS like sources control, testing tools, data collection, reporting, daily builds and project tracking (with project portals for burn down graphs etc). Since TFS 2008 does not have very good support for agile development I recommend the use of the Conchango template for TFS (hopefully the TFS 2010 release will improve, it seems to be a lot of nice things in the next release for this and for test support).

Okay that was a lot for one post! There is a lot more and I will see if I can write more on the execution topic, but now I am of for a two weeks’ vacation and will not write any posts for some time.

Have a great day!
Anders