Managing Product Development

I reported on my progress cleaning up my office previously . I hadn’t let it get that bad since that round of organizing, but I did ask for help from Daughter #2 in May, to buy some bins and drawers to continue my never-ending attempts to stay organized.

The past 8 months, I’ve traveled about half time and finished a book. Either of those events means my surface organization goes downhill, but my office was not a disaster. (Mark disagrees with my assessment. Wednesday, Daughter #2 and I attacked the part of my office I had not yet organized: my desk and a bookshelf of supplies I use frequently. (The bins and drawers for the travel and workshop material was working quite well. I’d updated and refined that over the last few months.)

I only had three bags of recycling. Once we bought some bins, I could organize the pens, stickies, and pads I use, so now everything has a place.

There is no way I could have done a BDUF to really know what I needed or how to organize. I had to evolve my organization, based on how I work. I was willing to change some of my workflow, but not all.

When you’re developing a system in which people work, such as an office, or a kitchen, or–gasp–a software system, make sure you build in feedback-from-the-customer time. I had to live with my office to see what was working and what wasn’t. So will your customers. The result will be worth it.

Labels: agile, BDUF, implement by feature

I’ve taught several workshops where people wanted to learn how to start adopting some agile approaches. They knew about timeboxing, but didn’t quite see how to make it work. The part they were missing was having working valuable product at the end of each timebox.

I explain that to the participants, and they nod sagely. Then I ask them to do a simulation. Practicing in a workshop is a safe place to practice. If they don’t do something quite right it’s still ok. Normally this part proceeds well. Some folks have a little trouble, but most people start changing how they work by the third iteration.

At a recent workshop, things didn’t go so well. One group took five iterations to complete the first part of the project when I’d expected three iterations (when designing the simulation). But take a look at a chart of their first project’s velocity.

They couldn’t predict what they could finish–or not–in an iteration. One of the reasons they had so much trouble is that they did not implement by feature. They attempted to build the architecture first. But as soon as they started attempting features, the architecture didn’t quite work. Instead of throwing away a not-quite-right architecture at the end of iteration 2, they decided to stick with it, because of all the time they’d invested.

They had a different experience in the second project. In their first iteration, they decided to do an architectural prototype, but not deliver anything. Ok, I could live with that. They had a working architecture, and if they’d put things together, they could have been halfway done with the project. They chose to leave the first iteration as a prototype.

In planning for the second iteration, they told me (senior management), they were going to work on the prototype more. I asked what they would have to show me. It wasn’t going to be product, so I told them that was unacceptable. They didn’t plan much for that iteration, but delivered plenty. Same thing with the next two iterations.

They never did have a predictable velocity, because they were caught in the trap of pre-planned architecture instead of seeing the architecture evolve as the product grew. I asked them if this ever happened in their organizations. Predictably, it did.

This may be the most difficult idea to help people see–that they make more progress implementing the most valuable features one at a time, and letting the architecture evolve. Big Design Up Front (BDUF) slows down the project. You can’t predict what the architecture needs to be.

Labels: architecture, BDUF, implement by feature, timebox