Bas Vodde has published a good article about making goal oriented action plans for agile projects. It is a nice piece of the puzzle on how to do effective retrospectives. It also nicely ties into the “Learning Circle” Reflection/Learning/Planning/Action steps.
Joe Little has created a yahoo! group called agile-ann. It will be used for all types of announcements for agile events, conferences, meet-ups, courses, seminars, calls for papers, etc. etc. It will probably become fairly high volume with all the agile stuff that goes on! I strongly encourage everyone reading this site to sign up for the list.
What happens when you are iterating away, your team is totally groking agile, delivering great results every couple of weeks, and then unexpectedly, suddenly and firmly everyone is stuck!? An obstacle has come along that forces a full stop. A barrier has been placed in the path. What do you do?
Continue reading Stuck? Try Extreme Obstacle Removal!
Lisa Crispin has written an excellent article about defect tracking in agile environments. The article is a couple of months old now, but if you haven’t read it yet, you definitely should! I particularly like the perspective that Mary Poppendieck offers in the article…
Continue reading Agile and Lean Defect Tracking
The fall schedule is up for Agile/Scrum training. For Canadian training, prices are currently discounted and will be raised on Sept. 15th. For Beijing, the course date is tentative based on pre-registrations up to Oct. 15th. Pre-registrants for the Beijing course will get the pre-registration price of 8000 RMB and after Oct. 15th, the price will go up to 10000 RMB.
Ah, tools…
For agile training and consulting, I always recommend starting with the standard physical tools of note cards on a wall plus a whiteboard and digital camera. However, I am still interested in what tools people have used when they have found that note cards are not sufficient. Here is a list of the tools that I am aware of, as well as a link to a survey…
Continue reading Agile Management Tools
Okay, I’m only here for one day, and the first part of the day was me giving a workshop and then the next part was a presentation on Ruby and Selenium which was interesting (but unfortunately nothing to write home about) and then…
Mary Poppendieck spoke. Here are my notes.
Continue reading Agile 2007 Conference Notes – Mary Poppendieck on Leadership
I’m pleased to see that Agile 2008 conference is in Toronto! I’ll be there the whole time… The web site doesn’t have any information yet except the hotel.
What happens when you delay adopting agile? Well, one large client I have worked with has found out…
Continue reading A Cautionary Tale – Delaying Agile Adoption
I just read a recent article on PMHut called “Schedule Questions: Pair Programming and the PNR Curve“. There is much in this article that is important for agile project management… and much that should be avoided at all costs!
Estimating Projects
The bulk of the article is an explanation of the PNR curve (Putnam Norden Rayleigh curve). The explanation is sufficient and can be checked against other web articles about software estimation. The basic idea of the PNR curve is to find an ideal number of people with which to staff a project based on an estimate of overall project size (e.g. 72 man-months).
Take a moment to go read Fantasy Estimation (the comments here provide good additional material).
It should be clear now that any initial sizing estimate based on units such as man-months is ridiculous. So what is our alternative? What about an agile approach to estimation and planning?
Agile Estimation
Well, at a minimum, in an agile approach to estimation, we need to resolve some of the problems identified in “Fantasy Estimation”. So, we:
The great thing about an agile approach is that it allows all these things to be done and to be done well. Scrum has a specific set of “Drag Factors” that can be used to weight the team’s estimates. And using a team’s past estimates vs. “actuals” is possible on an iteration by iteration basis… and this is possible because every iteration the team is doing the “same thing”: delivering an increment of valuable results (working software, edited video, organizational change, whatever is contributing to the project goals).
The other thing that agile methods allow is to make a distinction between estimation for planning and estimation for commitment.
So. It’s cool to learn about the PNR Staffing curve and the thinking behind it. It’s a little scary to see it being applied in an agile context when we have tools that are much better.
Pairing and Estimation
At the end of the PMHut article, the author, Mike asks a question:
What about pair programming? When using pairs on a team we could either:
- Continue as is, use the model to determine optimal team size and then encourage pairing to increase efficiency.
- Treat a pair as one hyper-effective person, so count pairs not individuals and increase team sizes accordingly.
This second option seems counter intuitive to agile, we strive for small teams to reduce communication channels, so I’m not convinced by this idea. I would be very interested to hear people’s thoughts on agile staffing curves. So, lots more questions than answers in this post, please let me know if you have any research or thoughts on the matter.
I wrote in response:
Mike, I feel like the options you present in your question at the end actually miss the true point of pairing which has to do with communication. I have never seen pairing done in such a way that two people always work together as a pair. Rather, pairing is promiscuous: people switch pairs frequently throughout a day, iteration or project. This switching has two communication effects: 1) the human interaction and gradual diffusion of information as people switch pairs 2) helping everyone understand all parts of the work as a result of frequently working on many different things. From an estimation standpoint, I expect that neither of your two options is quite right. Rather, the third option is to continue as is with existing estimation and then encourage pairing to increase communication. Increased communication shows up in a number of different ways, not just efficiency: risk mitigation, accelerated individual and team learning etc.
I would like to expand on this just a little. To me, pair programming or pair work of any kind has always been able to provide a number of benefits to projects. Problem avoidance is one benefit (lower defect rates, better code quality through constant inspection, spotting each other). Better communication is another benefit. Increasing the Truck Factor is yet another benefit.
None of these benefits have any direct bearing on estimating a project at the start, particularly since most projects sacrifice quality for schedule. From an agile perspective, since planning estimation is not commitment, it actually doesn’t even really matter! Get a conservative estimate for you project using whatever method you like, then start working and get a commitment velocity and see what the team can really do.
