Managing Product Development

I write a roughly monthly email newsletter, the Pragmatic Manager. I (finally) posted Refocusing: Emerging from the Split Focus Schedule Game. Yes, I’m working on the July issue now. Enjoy!

I have a Stickyminds column up, Does Exploratory Testing Have A Place On Agile Teams? The column arose out of an email conversation I had with Jon Bach. Please leave comments there.

Dwayne’s comment on my post, Architecting from the Features, made me realize I hadn’t provided an example of how I’d changed the book. Head slap on me! One of my rules of writing, which I use when I’m revising because I rarely remember as I’m writing the first draft, is to explain what I’m writing with an example. Examples can be a “for instance”, a story, an anecdotes–anything that connects my writing to the reader. Some people like stories first. Some like the idea first. But both of those kinds of readers will stay with your writing if they know you’ll get to the other part sometime soon.

So here’s the before an after table of contents for the project portfolio management book. I fully expect the chapter titles and contents to change.

I’ve got the notions of the reader’s span of control in “Making Great Portfolio Decisions” rather than in separate chapters, which is making it easier for me to write that and the other chapters.

Dwayne, thanks for asking for an example.

I’m writing the portfolio management book, and I just finished a whole big re-architecture. I’m so excited.

I realize most people aren’t that excited about a rearchitecture :-), especially not of a book in progress. But I am, because I took my own advice.

When I started writing the book, I had several partly done chapter-things. They were not particularly well-written, nor were they coherent and several pieces were tightly coupled. But they were enough for the Prags to see what I was thinking. Luckily, that was enough for a contract.

I’ve been writing off and on since I got the contract, and have been getting stuck. I realized last week it was time to print the book and start cutting pieces of it to reorganize.

I finally started making the book (yes, I write in markup language, check my writing into Subversion, and use make to make the book), and seeing it on paper helped me see where my features were.

I have some user stories:

• “As a first level manager or technical lead, I want to see how to make a portfolio.”
• “As a middle manager, I want to see how to make a portfolio and make decisions about it.”
• “As a senior manager, I want to review the portfolio, and make decisions about it based on data.”

But being your own product owner is not such a good idea. Because I thought the roles were driving the book, I had separated a bunch of the writing by role first, and then what the roles did. But it turns out, that for this book, right now, the portfolio activities are what needs to drive the book. Maybe that’s obvious to you. But it wasn’t for me.

I realize the current book’s architecture may not last. But I can see how to write more of it. And, I’ve been refactoring to clean up my writing. I think of the refactoring as where I put things to make the book clearer, and editing as how I change the words to make the ideas clearer.

I wrote several features–actually parts of several features because I got stuck. Now I’ve rearchitected and the writing is flowing. I’m probably not done rearchitecting, but that’s ok. I have a place to head towards now. Onward!

On the long weekends, Mark and I make a concerted effort to clean up the house. That means I have to address all my little piles: go through them, recycle what I can, throw out what can’t be recycled, file others, figure out what to do with the rest. While Mark was helping me bring some of my paper and books downstairs, he nudged me about finishing the living room. “I know you don’t like clutter,” he said. “Yes, but I know where everything is. Besides, you have clutter, too.” “But I don’t like your clutter,” he responded. I started to say, “Yeah, but my clutter is different” at which point we both cracked up.

My clutter is comfortable for me, otherwise I would have dealt with it already.  You could call my clutter technical debt, and you’d be right. I don’t mind paying it off on long weekends. Otherwise, I would do something about it more often. But the reason my clutter is different is because it fits with my mental model of the world.  I’m sure when Mark reads this, he’ll try to change my mental models. He’s unlikely to be successful.

These same kinds of discussions occur at work, but we tend to laugh at them less. (Maybe we should.) The next time you find yourself perturbed by someone else’s perspective, consider this question: What would have to be true for the other person to be happy (or content or satisfied) with the situation?  Partly, my clutter helps me see all the things I do, which is helpful. More clutter does not make it more helpful — there’s a point at which even I think there’s too much clutter. But seeing clutter doesn’t help Mark, and since we share a house, I need to flex a bit. I’ll continue cleaning up now.

I’ve been wanting to start podcasting for a while. Now, I finally seem to have enough tools that I can do it! Thanks to Clarke’s suggestion, I’m using libsyn, and I do believe iTunes is syndicating the podcast also. So, here is the link to my first podcast: Timeboxes Help Multisite Teams on libsyn.

I have successfully syndicated The Pragmatic Manager on iTunes. I don’t know how to give you a URL that will get you there directly. Thanks to Rick, here is the iTunes URL.

I also added the mp3 file to the libsyn page. Now I know for my next podcast:

• Make files in mp3 and m4a.
• Publish links to both those files and iTunes url

I don’t know if there’s more, but I bet there will be…

I’ve been working with several clients on their transitions to agile–or at least, more agile approaches to their projects. In each case, the managers decided to move towards agile because the technical staff were in their words, “naive” about the project goals. To be fair, none of the projects had a vision or release criteria, so it’s not surprising the technical folks didn’t understand the project goals.

But waterfall, with it’s emphases on understanding up front,  helps create that naivete. If you could understand requirements or design up front, then the project is just a SMOP (Simple Matter of Programming). And the testing is just a SMOT, and the writing is just a SMO (Testing and Writing). With a SMOP attitude, everyone assumes the predictive schedules are correct, creating a sense of naivete for the entire project–not just the technical staff. The managers are naive about what the milestones really mean, and everyone’s naive about the entire schedule.

But there’s an even more insidious  assumption in waterfall: that the time to finish the project doesn’t matter. This attitude arises even more if a senior manager or program manager or project manager says something like, “Quality is Job 1.” At some point, this project has to end and the product has to ship. Maybe not next month, maybe not even next year, maybe the year after. But at some point in time, the product will ship, regardless of the technical staff’s perception of quality. And that’s where waterfall lets down the entire project team.

I haven’t worked on a project or consulted with a company where they had endless time to get to release for at least 20 years. (I can only remember one project where we were not under time pressure back in the early 80’s. But maybe I can’t remember much Granted, I tend to work on or with projects in commercial organizations, so if you’re working on a government project, maybe you have more flexibility in time.

But a waterfall project organization, where you have milestones such as “requirements complete” or “feature freeze” or “feature complete” provide a disservice to the entire project and management team. We know the requirements are not complete. We know the features will change. Saying they are complete or frozen won’t change reality. But those complete or frozen milestones provide a sense of inevitability about the eventual ending of the project, and infer that since we’re “meeting” (ha!) the project milestones, that we will continue to. That’s the naive part. (See There is No Such Thing as Percent Complete and Showing Project Progress (NOT percent complete) for why.)

Waterfall is fine for a few weeks (4 or fewer), and a few people (4 or fewer) and where you’re sure the requirements are not going to change. Absolutely, positively sure. No surprises. But if you have a larger project or a longer project or you have a suspicion things might change, you want to work differently. I recommend you read my recent Cutter IT article, What Lifecycle? Selecting the Right Model for Your Project to see ways to organize your projects so they make more sense.

Naivete can be charming in people. But it makes for badly organized and executed projects and programs. Waterfall reinforces naivete. Any other lifecycle allows you to take a more empirical approach, rather than a more predictive approach. The agile lifecycles are all about empiricism, so they banish naivete–at least, about schedule–completely. Choose any other lifecycle, and you can take a mature, not a naive, approach to your projects.

I recently spoke with a project manager. He was concerned about the product managers handing off the requirements to the development staff.

He was right to be concerned. Handoffs don’t work.  The more people think they are done with “their” part, the less likely you are to receive/finish a great product. That’s because no one can tell what they really want until they see it.

The more often the requirements-generators see the product as it’s being built, the easier it is to modify the product. The more the developers see the testers test the product, the easier it is for them to incorporate that feedback into their development.

A successful product requires everyone to participate fully throughout the whole project.  That means you can forget about people coming off this project to start the next one. That’s because the people who are supposed to come off the project need to continue their work until everyone is done.

Handoffs don’t work. Collaboration does. Keep everyone on the project until it’s really done-done-done.

I’ve finally finished my first podcast, and don’t know where to host it. Any recommendations from you folks?

I’m pleased to announce that Esther, Jerry, and I will be co-teaching another PSL in Sweden in January of 2009. (You don’t have to be Swedish to participate!) Magnus has announced it, PSL Sweden 09! If you’re thinking about PSL, please join us.