Managing Product Development

Deb Hartmann interviewed me (video and audio!) at Agile 2007. We mostly talked about schedule games from Manage It. (We briefly discussed Behind Closed Doors: Secrets of Great Management and Hiring the Best Knowedge Workers, Techies & Nerds.)

For those of you who’ve met me and are wondering, “Where are Johanna’s glasses?” They’re in my lap. They were reflecting too much, so I took them off. Luckily I could see well enough to have a conversation with Deb.

David Daly interviewed me, PM Interviews: Johanna Rothman by email. I answered in American spelling and he translated into UK/English spelling

PM Boulevard just published How Often Should You Review the Project Portfolio?. You have to be a member to see whole article (membership is free). You can’t leave comments there, so please leave them here.

Clarke Ching interviewed me by email. Here’s the link to the first question: Q1. There are a total of 7 questions.

In one of the comments, for When is a Scrum Master (or a PM) Not?, Craig Brown said

Process, process, process.

What about people? At the end of the day the process is just one of several enabers (alongside culture, technology and tools, etc.)

Won’t an experienced and talented team just deliver regardless of the process? ANd doesn’t that indicate that the process is relatively unimportant?

Well, yes, if you have “experienced and talented” people, they will manage to deliver just about regardless of the process. My experiences over the last couple of months lead me to believe these folks don’t have the experience. They may well have the talent, but not the experience, or the self esteem to do what they know they need to do.

One of the reasons the XP folks are so adamant about their practices is because the practices create a system (a process, if you will) that helps people accomplish the work. We Tried Baseball and It Didn’t Work is a humorous take on what happens if you say you’re playing baseball, but don’t follow the process. Same thing with XP, Scrum, or cleanroom or anything else you choose to do. If you don’t follow the process, it doesn’t help. You can call it anything you want, but calling it Scrum (or something else) doesn’t make it so.

So what do you do with an inexperienced team? (Let’s assume they are talented.) I still think someone needs to help with the process, so the team gains experience and succeeds. Without the willingness of someone to stand up and say, “No, that’s not the way this is supposed to work. And, here’s why…” the team cannot be successful.

I’ve met process police, and no, I don’t want to work with them. But a little process does go a long way when organizing or managing a project. If I want to use timeboxes because otherwise people fall prey to Student Syndrome, I should have that option. It’s quite reasonable to want an iteration backlog before an iteration starts, so the team can estimate it and commit to it. It’s not reasonable for a person who’s not developing or estimating to lengthen the timeboxes and reject retrospectives because he doesn’t think it will help the team. The people who reject the agreed-upon process are not helping the team, even though they think they are.

Leaders, no matter what they are called, are the people who guide the team through it’s designated process. They are especially necessary when the team is inexperienced, whether that’s general inexperience or inexperience with a particular project organization.

I’ve been busy the last few weeks (as you can tell by the paucity of posts :-). I’ve been working with project managers, Scrum Masters, and technical leads who have been thrust into the role of Scrum Master.

Here are some examples of the problems these nice folks have had:

• “When I want to use timeboxes to focus the attention of the project team on the project, my boss won’t let me.” — a Project Manager
• “Our Product Owner can’t decide on a backlog before the sprint starts. How can we possibly commit to anything?” — a Scrum Master
• “Our Product Owner thinks that reviewing the backlog and have a demo and retrospective every 4 weeks is too frequent, so our sprints are now 8 weeks.” — technical lead working as a Scrum Master

None of these folks are really acting as a project manager, whether that PM is called a PM or a Scrum Master. The PM’s role is to steer the project to “done,” and that means choosing and following through on the actions required to get to done. A PM makes the choices and acts on them–or the PM is not effective. A Scrum Master is supposed to protect the process. Anyone working as a Scrum Master who’s not protecting the process is not effective in that role.

Think about your recent actions. Are they helping the project, irrespective of the project’s organization? If not, you’re not effective as a PM.

Effective PMs control their project’s process. Do that, and you’ll be an effective PM or Scrum Master, or whatever your organization calls you. Don’t control the project’s process and the project and organization will control you.

PM Boulevard has my 5Qs on Agile, and Manage It! review. (They like it!) You might need to log in to see all the content.

Bob Payne interviewed me in this podcast at Agile 2007. We mostly talked about project management, some specifics from Manage It!, and also talked about hiring for an agile team.

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