After my presentation at the Nashville PMI IT Local Interest Group last night, several project managers stayed to talk about estimating and project forecasting with Scrum. One was skeptical about being able to reliably tell management where they would be 6 months or 1 year down the road. Another was in an experienced XP shop that only planned for the current iteration and was having trouble meeting long term goals. The coincided with a thread on the Lean/Agile Yahoo group about estimation and planning that includes contributions from many experienced Agile leaders.
One of the posts had a link to an older presentation by Mike Cohn at Google on estimating that is a fantastic introduction to how to estimate and forecast in an Agile project. Here is the PDF version and the YouTube part 1 and 2 are below. He has many of the examples I have seen and used in my presentations based on studies done at Simula Research Laboratories in Norway. It is good to have this research for the skeptics you will eventually encounter. I really like the "Zoo Points" exercise and plan to add it to my training. Mike (and others) have many more great presentations at the Mountain Goat Software site.
This is a great intro to estimating User Stories (i.e. Product Backlog Items) and performing release planning to have an idea of where your project might be far into the future.
- My company Compuware
- My blog (which you are on now of course!)
- Conchango Scrum template for Team System
- Ken Schwaber's book on Scrum
- Scrum and XP From the Trenches by Henrik Kniberg
- Certified Scrum Master training
- Microsoft's eScrum TFS template
- TFS Light Weight Scrum template on Codeplex
- devLink Technical Conference
- People we mention: Ken Schwaber, Jeff Sutherland
It's a short quiz totally from the team perspective. Once completed, they present you with a great report to show you your strengths and weaknesses. They match areas to practices than can help you improve your score. I ran through this several times thinking back about different projects and clients to get an idea of where I personally have been and grown my practices. They also have an option to track you results over time.
I'd love to take the Nokia Test and create a web application like this. If anyone has some free time to loan me, I'll do just that!.
Many detractors of the Scrum framework claim it to be too thin and does not include the prescribed Agile engineering practices like XP. Scrum is actually supposed to be a very light weight framework for a company to adopt into the development process. It is minimalistic on purpose.
As far as the engineering practices, one does not have to search too hard to find all the primary originators of Scrum stating that it is a management wrapper for XP. The Control Chaos website has a good summary of the xp@scrum approach here. During my Scrum Master training, Jeff Sutherland himself featured the graphic below prominently in his first few slides and stressed how the engineering practices of XP were essential to getting more productivity out of any Scrum implementation. Ken Schwaber has also co-authored an article about combining Scrum and XP.
All of this information has been around for quite awhile and is fairly prominent, so I find it astounding that so many still see these approaches and not compatible. Jeff also told us in our training of the infamous email he received from Kent Beck in 1995 asking for more information about Scrum so he could incorporate it into his approach:
"Is there a good place to get reprints of the SCRUM paper from HBR? I've written
patterns for something very similar and I want to make sure I steal as many
ideas as possible."
In general, Scrum leans more towards a management process that supports Agile development processes like the ones prescribed in XP. I personally believe that you cannot be very successful with Scrum without implementing things such as Continuous Integration, Unit Testing (TDD), Coding Standards, Small Iterations, Sustainable Pace, etc.
I also think Scrum is a bit more acceptable to the masses (which some people also site as a detractor) that a pure implementation of just XP. It is called extreme programming for a reason!
Hopefully this combined approach will be what people implement rather than just adopting the Scrum mechanics and continuing to develop with their same, non-agile methods. This would most likely lead to failure and that usually gives people the impression that the reason for the failure was Scrum.
Posts
