Managing Product Development

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.

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

Want to save time on your next project? Improve working relationships? Understand what contributed to your success–or what didn’t? You’ll need a retrospective to do these things, and if you want a great retrospective, you’ll buy a copy of Agile Retrospectives: Making Good Teams Great by Esther Derby and Diana Larsen.

A retrospective provides feedback to the entire project team and helps them see how to proceed based on their immediate past experience. Esther and Diana have written a readable actionable book that explains how to plan, conduct and use the results of retrospectives. They include a full explanation of the 5-step process for a retrospective:

Set the Stage

Gather Data

Generate Insights

Decide What to do

Close the Retrospective

They included 30 activities with instructions on how to use those activities (and which stage(s) in which to use them). Even if you’ve never facilitated a retrospective before, you could use this book to learn how.

I particularly like the quick reference matrix and the moebius-strip-like picture of how the retrospective fits into an iterative lifecycle.

Everything in this book is applicable to any project. Even if you’re using a stage-gate lifecycle, you could benefit from having a retrospective at any management review milestone. The ideas in this book are applicable.

Esther and Diana explain how to timebox a retrospective so the team uses the time most effectively. Too many of my clients use questionnaires to perform “post-mortems.” Ugh. To those of you who are suffering through those questionnaires: put down your pens, and conduct a time-boxed retrospective. You’ll learn a lot more and have fun doing it.

You don’t have to be a part of an agile team to use the ideas in this book. If you’re willing to understand what’s happening (or what has happened) on your project, and you’d like to improve things as you proceed, you can use this book. And what project manager or team wouldn’t want that?

You can buy the book at Pragmatic Bookshelf or at Amazon.

In the immortal words of Dilbert/Scott Adams, “Agile programming doesn’t just mean doing more work with fewer people.” See today’s cartoon.

I’m at the 13ICSQ conference this week. One person (at least) was confused about agile processes:

Conference attendee: “Agile processes are a license to hack!!!!!!!”

JR: “No. Every agile team I’ve seen is highly disciplined. No hacking there. I’m sure there are people who say they’re performing agile development, and they’re just hacking, but truly agile teams are highly disciplined.”

Conference attendee: “Oh yeah? Well how come the project manager doesn’t control the team’s work?”

Aha! Because the team drives the project instead of the project manager having the illusion of driving the project, this person was confused. To make things worse, this person thought it was the testers’ job to point out how wrong the developers were, not to provide information about the product under test.

Agile techniques are disciplines the developers, testers, and customers impose on themselves. The project manager facilitates discussions, removes obstacles, and checks on resources and velocity. The project manager doesn’t have to control the team because the team controls itself. The test manager doesn’t rub the developers’ noses in their bad code because the incidence of bad code is lower and the developers discover the bad code first.

I don’t think I was able to change this person’s mind. But we did have a conversation that attracted other people’s attention. I think I made some progress with them.

Fred Brooks, in his classic, “The Mythical Man-Month,” talks about a chief programmer team (chief programmer, and programmers of lesser hierarchy until you get to the peon). The chief programmer team works when one person can keep all the details about the product in their head. If you use several hierarchical teams of chief programmers, each one keeps their part in their head and the chief-chief programmer keeps the whole thing.

Except that on large projects, that’s asking for people to forget important things and make mistakes. We then call these mistakes defects (or bugs or problems).

But what if we didn’t have to keep the whole product in just one head? What if more than one person could see the whole product, and learn pieces of the product intimately? That’s what agile development is all about.

If you want the best of everyone, not just the chief programmer, consider some of the agile practices: