Martin Fowler has recently posted a note on Flaccid Scrum. Related posts such as Jim Shore’s The Decline and Fall of Agile have made similar points. Lots of discussion has ensued. The fundamental observation can be put this way:
There are a lot of Scrum teams out there who are not performing well.
Elizabeth Hendrickson hosted a web chat yesterday, attended by her imaginary brother Chet, Corey Haines, J.B.Rainsberger, and yours truly. After about a year of getting the microphones and webcams to work, we settled down to talk about pair programming. I won’t telegraph the results of that, so that if/when Elizabeth posts the thing you can enjoy every minute of it. However, I have had some additional thoughts on pairing that I’ll put down here.
James Brett runs scrummaster.com.au. He is starting a new series called “5 Questions”, where he asks leading lights in the industry five questions about Scrum and their relationship with it. Apparently he was unable to get any leading lights to respond in a timely fashion, so as his first article in the series, he had to settle for me.
Check it out here.
I’ll be attending the Scrum Gathering in Orlando this March, as will Chet. We’ll be speaking, and generally milling around with the rest of the folks. Read More…»
Agile software development, with one exception mentioned below, is iterative. An iteration consists of a short time-box, from one month down to one week. The length of the iteration, averaged over random teams I hear about, seems to be coming down from one month (the original Scrum standard) toward one week, the XP cycle which I currently recommend. I’d guess the current mode is about two weeks.
But I digress. The essential element of Agile, the sine qua non, the necessary condition, the prerequisite, the thing you must do or be laughed out of town on a rail is:
The team must deliver running, tested, integrated software, “done-done”, as the Scrum people like to say, at the end of every iteration.
There is no way out of this. You can’t deliver software every other iteration. You can’t deliver mostly-done software and fix it next iteration. Don’t even bother to twist on the hook. You have to deliver software.
If you’re looking down here to be cut a break, you have come to the wrong place. The single exception to delivering done-done software every iteration is to deliver it more frequently than that. Some top teams are now operating in a sort of “kanban” mode where they deliver features essentially continuously, typically every few days.
Real, running, integrated, testing, done-done software. Every iteration, or else all the time. When you set out to do that, you’ll surely run into some difficulties as you learn what it takes to do this. You’ll surely discover that the meaning of “done” is further than you think. Of course done includes the manual. Of course it includes user training. Of course it includes whatever impossible thing you’re thinking of.
Your team is probably falling short of perfection on getting all this done every iteration. (If not, get in touch: I’d like to observe and see how you’re doing it). What you’re supposed to do when you inevitably find room for improvement is what Scrum calls “Inspect and Adapt”. As Kent Beck put it: “Find your biggest problem and solve it the XP way, then repeat.”
If you need a little help, there are lots of people who can coach you. I might even be one of those myself.
Now start shipping that software!