Probably one of the most common mistakes in Software Development is to allow Estimates to become Commitments. I am sure you know the following scenario all too well. The development team is called into a meeting room and asked the following question. We (the management team) have had a look at the estimates, and your tasks on average are taking longer. The insinuation is that the development team is, stupid or perhaps lazy. Worse still, an individual is called in because the stats show their work is “Behind Schedule” as judged by the estimates. The problem is none of this though, the problem is believing that estimates are anything other than an educated guess.
Tag Archives: scrum
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.
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.
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
6 Tips for Good Scrum
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?















