Managing Product Development

It’s winter here in Massachusetts, and we’ve had lots of snow, ice, rain, snow, ice, snow, ice, rain. All that freezing and melting plays havoc with the roads. We have lots of potholes, and the local and state governments are busy doing emergency repairs all over the place. (For those of you who don’t know how potholes are made, first the water seeps in through the cracks in the roads. When the temperature drops and the water under the road freezes, the cracks get bigger. Loop until the road surface breaks apart and creates a hole. When the holes are deeper than a few inches and longer than a few inches, it’s time for emergency repairs. We have some foot-long and foot-deep potholes right now. Yuck.)

Potholes are a fact of life in the northern climates when you have cycles of freeze and thaw. But I’ve been talking to some folks whose defects are like potholes. “We only have time for emergency fixes.” “We have time to fix and fix the same darn thing over again, but we don’t have time to do it right.” That’s when your defects are like potholes.

Potholes slow down traffic, because the cars need to drive slowly through them, or around them. Defects, especially big ones, slow down other development or fixes. So, what do you do?

If you have a ton of defects, I would choose a one-week timebox, and work on fixing them. For me, fixing means developing a fix along with a unit test (or two or three), getting some peer review, and then checking it in so the developer can do some around-the-area testing before system test. I don’t care if the developers write the unit test first, I just care that they write some unit tests. Although, if you’ve got defects, you’ve got the makings of a bunch of great unit tests. I would not allow any development in this timebox, just fixing and checking the fixes in a variety of ways.

After making some progress and getting the defect counts lower, decide if you want another one-week timebox. Is it more valuable to finish (fix defects) than write new stuff and have old stuff unfinished? I don’t know, but you do for your project.

For the rest of the project, I would make sure people are working by feature, developing and fixing and checking a whole feature in totality before moving on to the next one.

If you’ve got a bazillion defects, they are like potholes–they prevent you from moving smoothly onto the next piece in your project. Fix them! No emergency repairs either–real fixes.

Last week, when I was at the Much Ado about Agile 2 conference in Vancouver, I had a conversation with Dan Rawsthorne. He said he wants to make sure his teams have demo-able software, not necessarily release-able.

Interesting. So what would have to be true for an agile team to have “just” demo-able software, not release-able?

• If the entire team is large (think Scrum of Scrums) and the product has big features. Each smaller team can do their user stories, but they may not be able to totally integrate each user story with each other until enough user stories are done.
• If there’s a hardware component and it’s not done yet.
• I keep trying to think of a third reason, and I’m stuck I bet you can help.

Even if at the end of an iteration, the product is “only” demo-able, that still means the team has integrated among themselves.

Thanks, Dan, for the jiggle.

Thierry poses a question I’ve heard in several of my PM workshops this week and last week: When should the team do the architectural work?

Thierry’s concerned if his team continues to implement by feature, how can the team do the architectural work? If they take an iteration or two to deal with architecture, they stop churning out features. And, Thierry has an additional problem–his new module could be a stand-alone feature. But he has some other alternatives:

• Implement three features and see where the architecture is going. If the team implements three relatively independent features, it may be clearer where the architecture is evolving. Once you see the evolution, maybe you can spend a short timebox (couple of days?) to define the architecture big picture, and let it continue to evolve within the framework the team has defined.
• If trying some features doesn’t work, prototyping several architectures might. When you prototype, you don’t have to have releasable software; you just need enough to evaluate the architecture. If you prototype, maybe you don’t have to take the whole team to do so, and they can still be making progress.
• Develop tests for the architecture. Get enough of the team in one room, have someone facilitate the discussion, and generate the questions/assessments/tests you’ll need to use to know whether an architecture will work.
• Timebox the architecture development. Spend a day or two (I would definitely not spend more than a week) developing an architecture on paper, and then start implementing some features so I could see if I got it right.

I’m sure there are more options and I can’t think of them now.

If you do take time to do some architectural work, make sure it’s as little design up front, so you can test the architecture by implementing more features. Any time you do incremental development, you do run the risk of not realizing the architecture is sufficient until later in the project. But that risk is mitigated by having significant parts of the product already working.

Labels: architecture, incremental development