Managing Product Development

I was shopping today, taking advantage of the summer sales. One of my favorite retailers offers petite sizes online, but almost nothing in the store. I go to the store to try the clothes on and then decide what to order online.

I had a number of blice (blouses to those of you who are not aware of alternative plurals to order, and the nice salesperson who was trying to type my information into the form got frustrated, “I keep putting the wrong data in the wrong boxes.”

“It’s not your fault,” I explained. “The developers should have sat with someone in a store to see what it’s like to input the data when you’re interrupted and holding onto clothes, and all the things that happen when you’re on the floor and not in a back room.” She then explained that the form was the same whether you were online or in the store. But the problem is the data available online is different from the data available in the store.

I don’t know if the developers were lazy, or pressured, or if it just didn’t occur to them to test the system with a real user. But a salesperson should never have to apologize to me about the lack of user interface keeping me at the store longer than it should have. It wasn’t her fault.

User experience design and implementation is difficult. But why make it more difficult by not getting feedback from the users? I’ll never understand.

I was speaking with a potential client about their approach to knowledge management. They think they need a senior person to organize a top-down appoach, and build a custom tool, so they know what knowledge they want to manage and have a place to put it.

I don’t think that’s going to work. That approach requires they know what kinds of knowledge they need to store and who will need access to it, and when. They don’t know any of that now.

Here’s what I know about knowledge management:

• You can’t create an electronic system until you understand what you’re trying to manage. That’s because the kind of information changes over time, not just the content.
• The Dreyfus model of knowledge acquisition infers that electronic systems are fine for novices, advanced beginners, and maybe the competents. But the people who really make a difference in the organization are the proficient and expert folks. Those people cannot easily put their knowledge into an electronic system, nor can the other people acquire their knowledge that way. Knowledge has to be transferred one-on-one, within a team, inside groups, between groups, and company-wide as the very last step.
• If you put people in competition with each other *in any way*, they will have dis-incentives to share their knowledge.

Given all of that, it’s not clear to me a top-down approach to knowledge management can work at all. What I do see as necessary is to have the managers (or some person):

• See the pockets of knowledge
• Plan some adaptive, people-based, timeboxed systems of knowledge management
• Measure where the knowledge management systems are headed
• And steer the people to do better

To me, agile approaches would work well. You could try something for a short timebox and see if it’s working. If so, keep doing it until it doesn’t work or needs another storage mechanism. Now you’ve got some experience to know what you need.

Starting with a tool is backwards, if you really want the experts who have substantial intuition to impart their knowledge.

Jurgen interviewed me via email, 5 Easy Questions for Johanna Rothman. The questions were not easy!

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!