Let me tell you about three projects that I've worked on recently.
Project A was a waterfall project for a Fortune 500 equipment manufacturer. We had a department of around 150 developers and QA people. We ran a full year behind schedule at one point, and had to spend three months just fixing bugs to stop churning. Late in the project, the team wound up working lots of overtime, which burned everyone out. Eventually, the whole product line was canceled, which torpedoed a billion-dollar initiative for the company.
Project B was an XP project developing an n-tier workflow and billing system with a custom desktop client. We had a team of 15 developers and two or three support people, working in three agile project rooms. The system was of roughly the same size and complexity as project A. In a typical 3-4 month release, we accomplished more than project A did in the four month release that ran to 16 months.
Project C was an xP@Scrum project doing SaaS with a modern rapid development framework and a RIA front end. It was a "green field" project, staffed with a team of five experienced agilists, including several veterans of project B. We avoided some of the agile adoption pitfalls that project B ran into, stayed on top of our technical debt, had effective tests (at full coverage) from the start, and generally got off to a good start and stayed there. We estimated our work by using the same number of "story points" that it would have taken us on project B... but at one point per pair day, not per pair week.
Doing some quick back-of-the-envelope math, project B was at least 40 times as productive as project A, and possibly more because B actually delivered reliably, and A didn't. Project C was five times as productive as project B, and therefore 200 times or more as productive as project A.
Which project would you rather fund?
Showing posts with label process. Show all posts
Showing posts with label process. Show all posts
30 July, 2008
16 October, 2007
Two kinds of velocity
A couple of iterations ago, our product owner made the comment that he was unhappy with the progress that we were making. As we had exceeded our velocity target on the previous iteration, I challenged him on this. He referred me back to our original tentative plan that came out of our planning effort at the start of the project; we were clearly nowhere near that point.
In the course of the ensuing discussion, it became obvious that we're really using velocity to measure two entirely different things:
We decided to start tracking two velocity numbers by dividing our story cards into two categories: system features and everything else. We have a blue star stamp that we use to identify the system features, and we keep track of our velocity both overall and in "blue star stories." We've been tracking the fraction of our total effort that goes into completing those stories, and managed to raise it from around 60% into the upper 80s.
The obvious danger is that useful technical work will be thrown out along the way, but we've been reasonably good about not doing that.
In the course of the ensuing discussion, it became obvious that we're really using velocity to measure two entirely different things:
- the rate at which the team was completing useful work (and by extension, the rate at which we could plan future work), and
- the rate at which we were making progress toward getting the system we're building into production.
We decided to start tracking two velocity numbers by dividing our story cards into two categories: system features and everything else. We have a blue star stamp that we use to identify the system features, and we keep track of our velocity both overall and in "blue star stories." We've been tracking the fraction of our total effort that goes into completing those stories, and managed to raise it from around 60% into the upper 80s.
The obvious danger is that useful technical work will be thrown out along the way, but we've been reasonably good about not doing that.
19 August, 2007
Recording daily stand-up
One of the things we've done on our project that has really helped is to record our daily stand-up meetings with a digital voice recorder and post the recordings to our team Wiki.
Our old CTO was big on written status reports, and asked everyone on my team to spend fifteen minutes every day writing status reports into their news space on our Confluence server. It inevitably takes half an hour to write a "fifteen minute" status report, which adds up to two and a half hours per week per person... or 6% of our capacity.
The next day, right before stand-up, I noticed a USB voice recorder on our product manager's desk. I decided to try making that the "talking stick" for our stand-up instead of the stuffed animal that we had been using. By passing the recorder as a talking stick, we got a good quality recording of each speaker's voice, and the fact that it was a USB digital recorder made it trivial to get the recordings off at the end of the meeting and post them to my daily reports in Confluence.
The recordings have been a huge hit. Our old CTO loved them (though they failed to fend off the written reporting requirement), and they quickly spread to the rest of upper management. Since we finish our stand-up meetings in ten minutes, they're short enough to fit into a busy executive schedule, and because they're recordings, they're asynchronous, and can be listened to between meetings or while doing other tasks. Our CEO is now a regular listener, among others... and other groups that hadn't been standing up are now doing so, having trained themselves by listening to our model. Also, because we can offer the recordings to all interested parties, there's less pressure for "chickens" to be physically present in the meeting, although that's less of a concern for us because we're located in a different city from the rest of the company. (Naturally, the recordings have helped to bridge that distance.)
A couple of weeks ago, I needed to work from home for half a day to take some lengthy phone meetings without disturbing our team, and I had the opportunity to actually use the recording to catch up with what the team was doing. It really worked, and in fact, I picked up some important status information from it that I was able to use in my phone conference with our investors. Having the recordings also gives us a lot of valuable institutional memory, for no additional cost beyond having morning stand-up, which we were going to have done anyway.
Memo to myself: investigate how much it would cost to have a transcription service transcribe our stand-ups... or better yet, look into speech-to-text options.
Coda: We're still doing regular Confluence reports, but they've morphed from a status reporting function (which is now fulfilled by recording stand-up) to a record of technical details to be communicated to other team members. We've kept them, because they've become valuable.
Our old CTO was big on written status reports, and asked everyone on my team to spend fifteen minutes every day writing status reports into their news space on our Confluence server. It inevitably takes half an hour to write a "fifteen minute" status report, which adds up to two and a half hours per week per person... or 6% of our capacity.
The next day, right before stand-up, I noticed a USB voice recorder on our product manager's desk. I decided to try making that the "talking stick" for our stand-up instead of the stuffed animal that we had been using. By passing the recorder as a talking stick, we got a good quality recording of each speaker's voice, and the fact that it was a USB digital recorder made it trivial to get the recordings off at the end of the meeting and post them to my daily reports in Confluence.
The recordings have been a huge hit. Our old CTO loved them (though they failed to fend off the written reporting requirement), and they quickly spread to the rest of upper management. Since we finish our stand-up meetings in ten minutes, they're short enough to fit into a busy executive schedule, and because they're recordings, they're asynchronous, and can be listened to between meetings or while doing other tasks. Our CEO is now a regular listener, among others... and other groups that hadn't been standing up are now doing so, having trained themselves by listening to our model. Also, because we can offer the recordings to all interested parties, there's less pressure for "chickens" to be physically present in the meeting, although that's less of a concern for us because we're located in a different city from the rest of the company. (Naturally, the recordings have helped to bridge that distance.)
A couple of weeks ago, I needed to work from home for half a day to take some lengthy phone meetings without disturbing our team, and I had the opportunity to actually use the recording to catch up with what the team was doing. It really worked, and in fact, I picked up some important status information from it that I was able to use in my phone conference with our investors. Having the recordings also gives us a lot of valuable institutional memory, for no additional cost beyond having morning stand-up, which we were going to have done anyway.
Memo to myself: investigate how much it would cost to have a transcription service transcribe our stand-ups... or better yet, look into speech-to-text options.
Coda: We're still doing regular Confluence reports, but they've morphed from a status reporting function (which is now fulfilled by recording stand-up) to a record of technical details to be communicated to other team members. We've kept them, because they've become valuable.
Subscribe to:
Posts (Atom)
