Managing Product Development

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 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.

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.

One of the problems I see in projects is that there is not a sufficient definition of done. For agile teams, it’s not clear what done means for a timebox. For non-agile projects, the team may not agree on what done means for a milestone or for a release.

For an agile team, do you know what done means for your timebox? Is all the code tested? By whom? Is it all checked in? Does it build without problems? Can you demo the product? Can you release the product? I much prefer product that is developed, fully tested by developers, system tested by the testers, and could be released–what I call release-able. But that might not fit for your project. If the product is only demo-able, make sure everyone knows that you still have technical debt and will need another timebox for testing and fixing.

For every team, develop release criteria. That way you’ll know what done means for the project as a whole.

For a team using any lifecycle other than agile, make sure you have interim milestones and criteria for those milestones, so the team has early feedback about the project’s progress. And, measure your progress towards your release criteria.

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.