Dancing to the tune of the Scrum Demo

As you achieve more experience with the scrum process, you come to realise that there is very little if anything you can afford to leave out. If your conducting scrum and considering leaving out a practice, its worth considering what is to be gained and lost.  So continuing with the scrum and agile theme this year I plan review some of the scrum practices highlighting the benefits and some of the errors that are made.  The first of these focuses on the Sprint Review and within that in particular the Software Demo.

Craig Larman in Agile & Iterative Development, A managers guide describes it thus:

Sprint Review: At the end of each iteration, there is a review meeting. (maximum of four hours) hosted by the Scrum Master.  The team, Product Owner, and other stakeholders attend. There is a demo of the product.  Goals include informing stakeholders of the system functions, design, strengths, weaknesses, effort of the team, and future trouble spots.

Feedback and brainstorming on future directions is encouraged, but no commitments are made during the meeting.  Later at the next Sprint Planning meeting, stakeholders and the team make commitments.

“Power Point” presentations are forbidden.  Preparation emphasis is on showing the product.

Continue reading

Digg This
Reddit This
Stumble Now!
Buzz This
Vote on DZone
Share on Facebook
Bookmark this on Delicious
Kick It on DotNetKicks.com
Shout it
Share on LinkedIn
Bookmark this on Technorati
Post on Twitter
Google Buzz (aka. Google Reader)

Of Groundswell and Product Owners

I have just finished reading Groundswell by Josh Bernoff of Forrester Research.  The book has been around for awhile but its concepts are worth understanding.  Its a great book about how Social Technologies have changed the way companies relate to their customers.  Not only that but how companies can benefit from Social Technologies within their own organisation.  Its a good read, get hold of a copy.  The book is rich with Internet law, marketing tips, research and good practice.  It gave me some ideas on how Groundswell could be used to provide a product owner with some powerful tooling.

Groundswell shows a way to tool up your Product Owner?

One of the most important scrum principles is to assign a Product Owner.

Vietnam, man takes a call in the temple.

Tool me up, Temple, Ho Chi Minh City, Vietnam: Martin Harris

This person should have a very good understanding of the business.  At first glance is seems like a good idea for that person to be an active part of the business.  For a single dealer platform it looks like a good idea to recruit someone who actively deals or for a legal application a senior member of the law staff.  The problem with this is a dealer is likely to be too busy looking after money, and the Lawyer is in and out of court.  Active members of the business have better things to do, so we have to look elsewhere for our product owners.
read on for the tooled up idea

Digg This
Reddit This
Stumble Now!
Buzz This
Vote on DZone
Share on Facebook
Bookmark this on Delicious
Kick It on DotNetKicks.com
Shout it
Share on LinkedIn
Bookmark this on Technorati
Post on Twitter
Google Buzz (aka. Google Reader)

6 Tips for Good Scrum

Pushing the cart, Matheran, India: Martin Harris

Pushing the cart, Matheran, India: Martin Harris

I went along to the London Scrum User Group yesterday evening.  For a change it was a quiet night.  Christmas is around the corner so we had less attendees.  Nigel Baker of AgileBear kicked off and suggested putting together 15 tips for good scrum.  After some discussion, we came up with 6 good ones, and in true Agile style, we decided that if you did these 6 well, you would be in front of the pack.  So we stopped there and got on with eating the snacks and drinking the beer.  The night was sponsored by Rally Software, cheers for the food guys.  So here is what the group came up with, look at your team and ask yourself if your doing these, if not, perhaps its time for a scrum experiment?

Continue reading

Digg This
Reddit This
Stumble Now!
Buzz This
Vote on DZone
Share on Facebook
Bookmark this on Delicious
Kick It on DotNetKicks.com
Shout it
Share on LinkedIn
Bookmark this on Technorati
Post on Twitter
Google Buzz (aka. Google Reader)

Pair Programming – My perspective.

Pair of farmers working the rice, Ubud, Bali, Indonesia: Martin Harris

Pair of farmers working the rice, Ubud, Bali, Indonesia: Martin Harris

I have done quite a bit of XP and Agile.  One of XP’ engineering practices is pair coding, At first I just did not understand pair coding.  My initial introduction was within a self directed team practicing Scrum and Agile.  I have come to realise that without self-directed teams, you don’t have scrum. You can scrum without pair coding but without these, you have thrown away two very effective techniques.  What is left just turns into inefficient micro management.  For some reason, these two techniques get resisted hardest.  Yet they are the key and the dynamo behind the success.

My definition of Pair Programming: A technique to increase development throughput by maximizing review coverage, reduction in faults leading to increased software quality and less effort in downstream processes such as manual testing and product maintenance.
Continue reading

Digg This
Reddit This
Stumble Now!
Buzz This
Vote on DZone
Share on Facebook
Bookmark this on Delicious
Kick It on DotNetKicks.com
Shout it
Share on LinkedIn
Bookmark this on Technorati
Post on Twitter
Google Buzz (aka. Google Reader)