Probably one of the most common mistakes in Software Development is to allow Estimates to become Commitments. This article looks at story point estimation in scrum, and how velocity is a better tool for monitoring progress through to delivery. If your interested in the arguments that can be presented to the business for velocity metrics over estimation for setting delivery dates, read on.
Feb
8
2010
8
2010
Jan
18
2010
18
2010
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.
Jan
14
2010
14
2010
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.
Dec
8
2009
8
2009
6 Tips for Good Scrum
I went along to the London Scrum User Group Monday evening. We decided to put together 15 tips for scrum that every team should try. Its was an optimistically large number of tips given that the meeting is held in a pub. Even so, we did produce 6 very good tips. Read on to see what we came up with.
Nov
30
2009
30
2009
Pair Programming – My perspective.
I have done quite a bit of XP and Agile. Not as much as I would like to be honest but enough to have a personal opinion about it. At first I just did not get 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 maximising review coverage, reduction in faults leading to increased software quality and less effort in downstream processes such as manual testing and product maintenance. See the full article for my reasoning.