Managing Product Development

At a prospective client, a senior manager asked me, “In agile, when does the spec freeze?” I said it either didn’t, or did at the end of any iteration in which people wrote a spec. He had a puzzled look on his face, so I explained that if you discuss how to design or what done means for a feature with the people who are asking for the feature and with the other people who will be implementing it, you might not need a spec at all. If you do need a spec, then it will go into the backlog for a given iteration, and it’s as done as it will be by the end of that iteration.

He still looked confused. I asked him, “When does the spec freeze now?” He smiled, and pointed to his “Design freeze” gate on his process picture. “I bet you a coffee that you can ask any developer here and that they cannot point to one spec that didn’t change after that or any spec that was right at the end of the project.” He took the bet.

Over the next two days, he asked every developer he encountered. Some of them laughed at the question. “The specs are never right. They freeze, but they should change.” One project manager said, “I can’t remember a project where we actually froze a spec for more than a day or two.”

The manager was chagrined. “How will people know what they have to do?” I replied, “They talk to each other. Sometimes loudly. Sometimes they disagree violently. Sometimes they don’t understand what the product owner wants, and the product owner has to walk them through the request a bunch of times, refining what done means as they walk through the request. But they will do what the product owner wants. But you don’t ever have a spec that’s out of date. You may not have a spec. You should have a bunch of tests that tell you how the feature is supposed to work. Would you rather have working software or a spec?”

My colleague wants working software. He’s just quite suspicious about how he’s going to get it. He’s never seen design by verbal contract; he’s only seen design by written contract. He’s concerned.

The reason he’s considering agile is that he doesn’t get software that works the way he wants. He thought he had specs, and now he realizes he doesn’t have them either. We’ll see how my simulation convinces the technical staff of how they can build and test in small chunks, so that they do get working software.

Tweet This Post

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

Tweet This Post

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

Tweet This Post