Project Manager, Iteration Manager: Who's who?

Does your team have a project manager? Probably. An iteration manager? Maybe. More likely not. Do you need one? What's the difference?

Google for "project manager vs. iteration manager" or similar phrases and you will get lots of job search links and about half a dozen fairly good articles and posts that attempt to answer these questions. (A selected few are at the end of this post.)

Probably the one that does it best is the original description from 2000 by Cara Taber and Martin Fowler: Planning and Running an XP Iteration ( http://bit.ly/YnnASZ )

In the section on team structure, they give a real-world example that makes the inward-facing, outward-facing nature of the two roles pretty clear. Their description shows that making these roles effective for the team is not so much about how you characterize tasks but how you enagage personalities for situations. That has certainly been my experience. Across all my projects, going back to the 1990s, projects with teams larger than five ran best when two or more people split up the PM and IM roles.

The PM role primarily looks outward and deals with leadership from participating teams and the overall parent company organization. The IM role looks inward and tracks the pulse of the team, resolving small issues and escalating big ones, and keeping the metrics clean.

You can compare it to film-making. The PM is the Producer and the IM is the Director. Sometimes a Producer can direct their own film or a director will self-produce their work but the results are generally better with a team.

The Producer is responsible for backing and selling the project vision, plus all of the arranging of people, places, supplies, contracts, etc. necessary to bring cast, crew, and location(s) together. The Director is responsible for conveying the creative vision to the cast and crew and enabling them to perform the actions that become the film. (You can make the same type of analogy with sport team owners and coaches, or the difference between conducting an orchestra vs. the executive duties of a music director.)

The Software Project Manager, like the Producer, is the big-picture, big-structure, studio-boss facing, investor-facing money person.

The Iteration Manager, like the Director, is the on-scene, every day, fine-tuning, people-relating, situation-improvising person.

If the software project is large or complex enough, the IM role can be full-time. More likely it is not. Sometimes the PM and IM role is combined in one person but more often the IM role is played by a BA, QA or Dev Lead, or a combination of people in those roles.

The reason why that happens, it seems to me, comes down to personality type – there are Manager types and Maker types ( http://bit.ly/WZOYHc ). Project Managers obviously tend toward the Manager type. BAs, QAs and Dev Leads tend toward the Maker type. For whatever reason, IMs (at least all the ones I’ve met) also tend toward the Maker type.

Perhaps there is a flow-state awareness that happens to Maker-types that makes them better attuned to the day-to-day rhythm of the team. Whatever it is, it seems different from what drives Manager types and all teams need some of each.

A few more links

Venkatesh Krishnamurthy, The Differences between a Project Manager and a ScrumMaster. http://bit.ly/14NuFAe

Darian Rashid, Transforming a Traditional Manager into an Agile Manager. http://bit.ly/Y5H7Z7

Rene Maslen, What is an Iteration Manager and why do we need one? http://bit.ly/WZu634

Petra Skapa, Iteration Management: Unclogging your development process. http://bit.ly/YdmWe1

A Checklist for Effective User Stories

Even though the classic Agile position is that a story is just an starting point for a conversation and thus should only be a sentence or sketch, this only works well for certain kinds of teams and projects - within big corporations, you usually need to do more to document the story for stakeholder review and to retain knowledge within the team. But you don't need to do too much more.

Having a good story pattern or checklist makes it much easier to get the essentials captured without going overboard on documentation. Here are the eight checkpoints I run through when I prepare a story:

1.	The story.	As a (role), I want (to do or have something ) so that (I get this benefit). In addition to this statement, you can add one or two short paragraphs giving any necessary background explanation of the problem and goal.
2.	What is in scope.	A list or statement of what everyone agrees will exist when this one story is done. Note, this is a list of what to do, not how to do it.
3.	What is out-of-scope.	Give a general statement or list of specific of exclusions. These are the things everyone agrees go beyond the current goal.  E.g., this story will not calculate depreciation using LIFO method; ability to add comments will be handled in a separate story, etc.
4.	Assumptions.	List any assumptions made about existing functionality or data access.
5.	Open questions and issues.	List any questions still to be resolved and update them as the answers become available.
6.	Design artifacts.	Don't go overboard but do include at least one relevant sketch, screenshot, flowchart, design diagram, mapping table, etc.
7.	Dependencies and related stories.	What else should developers, testers and reviewers know to put this new story in context? What others stories must be complete before this one can go forward?
8.	Acceptance tests.	Given (the system's starting state), When (this action occurs), Then (the system delivers this result). Acceptance tests are the BA/product owner's contract with the developer how they the product owner/BA will test the story. A BA/product owner cannot fairly reject a story if their test was not included in the acceptance criteria.

1, 2, and 8 are necessary. You can't have a story without them. 7 is also almost always necessary if you're doing anything that has a strong UI component, but sometimes it's OK to add or update this after development starts or after the story is completed. In this way the illustration acts as a guide for tech writers and the support team.

The other checklist items are optional but it's a good idea that any record of the story indicate when an item is not applicable, e.g., No open questions, no dependencies.

Remember to keep it short. If you are telling the background story, that can be one or two short paragraphs but no more than three or four sentences each. If you are listing out points, (e.g., a list of assumptions) no item in the list should run more than one or two sentences (think one-liners).

If you are writing more than that, you may have bitten off a story that is too big or you don’t know enough about the situation to isolate the central objectives. Stop what you are doing, check in with your teammates and SMEs and try again when you have a better handle on the situation.

PS: Later Developments - This is a discussion on LinkedIn about how to write user stories in which I take a troublemaker role: How to Write Good Stories.