Managing Product Development

John Cook wrote a blog post, Scaling the number of projects, that starts addressing the issue of why it’s everyone’s job to manage their own project portfolios. Here’s an example of the problem he’s noticed:

It sounds easy to manage independent projects: if the projects are for different clients and they have different developers, just let each one go their own way. But there are two problems. One is a single developer maintaining an accumulation of his or her own projects, and the other is the ability (or more important, the inability) of peers to maintain each other’s projects.

I’ve seen this in IT organizations, where one or two developers work on a “small” product, which, of course needs “maintenance” (more features, some problems fixed, more documentation, whatever). Since that developer wrote it originally, somehow that project is supposed to stay with the developer forever. (That’s a bad idea.)

I’ve seen this in product organizations, where even if it’s a larger team, once you’ve put your hands on the serial driver, or the engine to drive the application, or the version control system, or any other piece of a product or infrastructure, you couldn’t get rid of it no matter what you do.

Developers (and testers and writers) need to let go of old work. Their managers need to stop assigning everything that smells like that old thing to those specific developers, and add in the new requests to the entire project portfolio.

The interesting question is: Why does this happen? Why are people stuck with these old projects and legacy work (not in a negative legacy way, just that they’ve always been assigned to it and it looks like they always will be)?

Because the work is invisible. No one realizes all the little pieces of work. You’ve got to make that visible, and I like to make it visible in a portfolio.

One way to do that is to start collecting all the work you’re supposed to do. (I’ll address a product’s backlog at some other time). Here’s a template to start you off. I like to put this table on a whiteboard or a flip chart. If you must, use a spreadsheet, but please, not the first time. You will be moving stickies around.

Here’s how you collect all the work. Make a yellow sticky of all the work you are supposed to do. If you are working on a project for several weeks, make a sticky for that project for each week. Put all the stickies in the appropriate week, above the unstaffed work line. Just get them all in.

Now, be honest with yourself and put the work you can’t do in a given week into the unstaffed work row. Now you have something to discuss with your manager or your customers. (I’ll talk you through how to do this in my next podcast, which is already recorded, but not posted.)

If you receive a lot of little requests for products you can’t get rid of, you can create a product backlog for each product, or a product backlog for your time. (You either fix the requests by product, or fix your time and allow your customers to negotiate among themselves for what you do first. Sorry this is rough, but I haven’t written enough about this before to be articulate yet without gesturing with my hands.)

The key is for everyone to know what they are working on for a short while, and what their personal backlog is. That’s why I only ever plan for 4 weeks at a time. If you’re working in shorter timeboxes, plan for the shorter iteration. But using the portfolio like this allows you to do some rolling wave planning for your work as a whole, especially when you have lots of pieces of work to do.

I’ve published a podcast: How Many Emergency Projects Do You Have? Enjoy!

I received two questions this week about how well does agile allow you to do traceability matrix. Very well is the short answer. Here’s why.

If you commit to implementing features (not chunks of architecture)  based on user stories in an iteration, you know what you’re planning before the iteration starts. Because you’re working in a timeboxed iteration, and the testing is incorporated into the iteration, there’s no (ok, very little) time lag between the time you know what a requirement is supposed to be, and the time the requirement is implemented and tested. Now it’s a simple matter of paperwork (ok, maybe not trivial) to match the requirement with the code and the test. If you do test-driven development, and start with user-facing tests, it’s even easier.

The shorter your timebox, the easier traceability is. That’s because you have fewer features and fewer tests to manage.

Some of my clients keep their index cards and organize the traceability that way, with notes about where the tests are. They lock the index cards (post-iteration) in a fireproof safe. Other folks use a spreadsheet for the organizing. They use a source control system to manage the changes to the file.

Remember, the requirement is to trace the requirements through the code and tests and to be able to show you did that. The fewer artifacts, the better.

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.