Managing Product Development

I’ve posted last month’s Pragmatic Manager email newsletter, Making Waterfall (a Serial Lifecycle) Work For You, Part 2. I’m working on #3, which should be out this week.

My most recent Stickyminds column is up: Are Your Pants on Fire, or Do You Suffer from Split Focus?. There’s also a podcast on that page. You can leave comments there or here.

In For a more productive team, put the pressure on (within reason), Chris Hoover recommends a little pressure to help the procrastinators un-procrastinate, and help people get their work done on time.

I only sort-of agree. Everyone has their own amount of pressure, and what’s good for you is not good for me. But working in timeboxes allows people to choose how much work to get done in a fixed amount of time. If you keep the timeboxes small enough (1 or 2 weeks), the timebox keeps everyone focused and keeps the gentle pressure on.

Smaller timeboxes help people estimate better, which makes their commitments believable–to them and to the rest of the project team. Few people encounter Student Syndrome when working in short timeboxes.

If you’re a project manager, don’t put any pressure on from the outside, as you putting pressure on the team. Get the team to agree on a short timebox, and let their own pressure help them focus and finish tasks.

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 had the pleasure of speaking with two different colleagues today, both with the same dilemma. They are near the end of their projects. They don’t quite have enough time for one round of final testing–but if they’re lucky and the stars align, and they don’t find too many problems, they can still (maybe) test what they need to test before the desired release date.

But no, the stars don’t align. First week into testing, they find a nuisance of a defect. It only occurs once–in installation, and they can work around this with release notes–but they’re under pressure to make the change. They each asked me what I would do.

After asking a few questions to make sure the problem only occurs when installing, and they can make big red stickers to explain to the customers what to do, I agreed with the PMs: don’t make the change.

The risk is just too high. The reason the projects don’t quite have enough time for testing is that they’ve encountered trouble all the way through the projects. The builds take too long. The developers didn’t integrate testing as they developed. They implemented by architecture, and couldn’t manage the changes in requirements, so the architecture doesn’t quite fit what the customers want–but they shoehorned the features in anyway. The project team hasn’t met one deadline yet.

If you’re in this position with your project team, ask yourself and the team this question: What did you see or hear that leads you to believe this would work?

If the someone has data, “Oh, we fixed the build and we can tell in 10 minutes if the build is any good,” maybe you can agree with the decision to make the change.

But if all you hear is gut feelings, say no. Murphy is one of your team members. Finish this project. Hold a retrospective. Work differently on the next one. But don’t make that one small change. It won’t be small. It probably won’t work, and you won’t know until the customers receive the product. The risk is too great.

Labels: project management, risk

I just finished updating all my email newsletter (Pragmatic Manager) pages. I hadn’t announced my most recent newsletter, Making Waterfall (a Serial Lifecycle) Work For You, Part 1 (Vol 4, #1). I’ve reorganized the pages, so go here to read all the previous articles.

Labels: email newsletter, project management

Kevin says in his comment:

Business analysis is how you figure out what done means. Project management is how you figure out how to get to done.

I disagree. Business analysis is the elicitation and definition of what everyone else wants to have in the product. Project management is understanding what’s driving the project, and leading the team to fit as many of those “what everyone wants in the project”, with the desired quality in the time frame. Business analysts don’t get to define “done.” They don’t have enough context. (Yes, there are some business analysts who can do this, especially if their PMs don’t. I bet Kevin is one of these multi-talented folks.) The PM and the project team define “done” and how they will get there, not the BAs.

Labels: project management

Via Raven’s Think you know what a project is?, there’s a pointer to What is a Project? Think Again!. Garry, the author likes David Allen’s definition of a project:

A project is any outcome you