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.

Thoughts on Moving Beyond Scrum

Moving Beyond Scrum, a posting by Todd Charron on Infoq.com has been making the rounds of our team lead discussion groups. Here's my take on what the writer says and the comments he received:

I’m with the voices that say that Agile is a philosophy and set of principals; not a practice. When we live those principals, we choose and adapt practices to best fit the current situation. Thus, each project team may do things a little differently from the others and one project team may change what it does over the life of its project.

The key drivers of being Agile are focus on business value, delivering working code as frequently as possible while maintaining a sustainable pace, and constant improvement in process and outputs by regularly iterating (review/change) over the results.

Practices that facilitate being Agile are close communication among business representatives and the development team (where UX is part of the development team and not handled as an over-the-wall service); pairing – programming, designing, user researching, testing; test driven development and continuous integration; user research; rigorous ETA projecting and prioritizing based on business value and team velocity.

Attitudes that facilitate being Agile are tolerance for ambiguity and unknowns; flexibility to compromise; interest in hearing and trying new ideas; satisfaction in teamwork (getting things done) over heroics (getting credit for being right).

Shu – Ha – Ri describes three stages of learning -- beginning to learn fixed patterns, experimenting with changes to the patterns, intuitive actions transcending patterns.  This is what much of the article’s discussion was about and describes why the article and its commenters feel there is a problem. There are too many people and organizations who are only in the Shu phase (I read about Agile, I got a Scrum certificate, we always do it like this) and not so many people and organizations at the Ri stage.

SCRUM, whatever its original intention, has become a defined set of practices. Ri people that I know have always referred to Scrum as a project management method and not about how software development happens. Scrum in itself is not magically agile.  Ditto Lean and Kanban.

Entropy, gravity, and human nature combine to emphasize or depend on predictable patterns and relationships. Difficult things fall apart faster, bodies at rest tend to stay at rest, following directions is easier than making a trail or reading a map. Agile works when you bring together a collection of people who prefer to go against these patterns. Therefore, the first challenge is to collect the right people.

Collecting the right people becomes difficult in large, established organizations unless the organization’s culture already rewards innovators and explorers.

Starting small with selective teams and projects is generally the best way to introduce change but such change is never sustained if it depends on outside coaches and consultants or if the higher leadership in the organization does not support and exemplify the change through its own behavior. In other words, long-lasting change needs to start simultaneously at both ends and work its way into the middle.

Things that can be done to foster a JIT delivery culture:

·         Evangelizing – reading & discussion group(s); brown bag sessions (internal & external presenters); publicizing internal examples; agile game sessions.

·         Hiring

·         Project staffing – all intentionally “agile” projects should have sufficient staffing at the Ha level and a Ri member or coach.

·         Co-location – UX, QA, Dev, Business sit together and have mixed meetings beyond IPMs  to discover and negotiate project requirements and design (google "Divergent and Convergent thinking" to learn more).

·         Shadowing

·         Regular process and structure to identify negative patterns, think of solutions, and conduct real-world tests (retrospectives make this happen at the project team level, what’s the equivalent at levels above that? Are the right people participating? Is the right information surfacing? )

·         Demonstrative leadership – actions and words are aligned.

How big is a 1?

Nothing sinks a project faster than a poor estimate, or rather, an estimate that sets the wrong expectation. Part of the problem with setting expectations is finding the right words to paint an idea of the development  effort.

It usually starts to go wrong when somebody tells a prospective client that the team estimates work in story points and 1 point “is about a day”. Wrong!  And too late.

 

The client will never lose the impression that a point is really just another word for “a developer day” and they will always be suspicious why it’s taking weeks to do what apparently was rated as a few days work.

A point is not always a day. I’m on teams right now that are only getting 1 or 2 points done per week. I was on a project where it took 3 weeks to complete a one point story.  I’ve also been on a project where the stories were so small, we stopped using points completely and did 3 – 5 stories a day.

So how big is a 1 or rather, what should a 1 represent?

All we want is some way to express time and effort relative to everything else that’s on the table.  

A 1 seems like an easy way to say that of all the things there are to do, each story in this pile will likely take about the same effort and time to do and they are all smaller than any other story on the table (or in the list).  From there, 2, 3, and 5 are useful to express increasingly larger scales of work, with anything above 5 or 8 signaling something big enough to require decomposition. 

But although it is convenient to use numbers to express relative positions on a sizing scale; using numbers tempts people to apply the same numbers without adjustment to generally quite unrelated timing scales.

Eliminating the numbers and using other mental images may be better for illuminating story sizing and starting a discussion around the development effort that might be involved. Let’s try some different scales:

     Cherry, apple, cantaloupe, watermelon, holiday fruit basket.

     Skateboard, bicycle, Vespa scooter, Ford Escort, 18-wheeler moving van.

     Pebble, rock, boulder, Corinthian column, Stonehenge.

     Stick horse, pony, racehorse, the Budweiser wagon, a circus carousel.

The next time you are sizing stories (and yes, call it sizing not estimating), it could be interesting to forget about numbers and try using some flashcards with pictures of objects instead. Your team might end up saying, “This week we finished three little ponies." Or, "The last time we did a beer wagon, it took a week and a half."  

Lifecycle of a project: What's wrong with this picture?

This weekend, I attended a Design Hack session for CivicLab, a new effort in Chicago inspired by Milwaukee's Bucketworks.org; an institution that fosters member-driven civic and creative projects and activities.

There were several discussion groups taking up various themes. Since it seemed well correlated to what I do at work, I joined one about the lifecycle of activist projects and campaigns. Quite a few other software geeks took part, too.

The facilitator kicked things off by putting the following illustration on the board. Take a look, do you see anything wrong with this picture?

I quickly killed my good will with the facilitator by pointing out that Inception was a noun and Execute a verb. You don't execute at the end of a process, you execute all the way through a process. Someone else jumped in and observed that a lot of preparation has to happen before you can do an Inception. Another person wondered where Feasibility studies fit. And so on.

In the end it was a good discussion, enough for two or more blog posts but what I've been pondering all day is what kind of diagram would have said it better?  This is what I came up with:

Execution happens throughout a process. Throughout a process, research and investigation are happening to detect problems and opportunities. At any time, ideas may pop up, or you may set aside specific brainstorming sessions. Ideas, and problems and opportunities have to be prioritized. Problems and solutions have to be validated and evaluated - are they real problems? Will the solutions work? Will people adopt the solution as designed? Is it cost effective? Prototypes at varying levels of fidelity are in order throughout the process.

Feeding into all of this is an understanding of the context; the bigger environment of the problem and the people you want to assist: politics, money, geography, values, culture, etc.  Understanding the context and where you are in the process determines what tools will be useful in the execution of any phase.  

We Don't Estimate Hours!

Now that I'm at Pathfinder, many new clients are coming in through the UX door and they are not familiar with Agile. I often have to explain how estimating and story points work.

If you search the Internet, there are tons of links about Agile estimating and story points so it seems redundant to add another but I really wanted to blog about this, if only to organize my favorite references.

So here are four links that cover just about everything on the subject (plus they'll send you to other places anyway). And if you don't have the patience to comb through these references, I've added my basic explanation to customers at the end.

1.I know Anand Vishwanath from a long time ago.  I value his overview for the thorough job it does of covering all the angles: http://bit.ly/MdH1tS

2. I love Dan North's post because it correctly, and effectively, shoots down that compulsive estimation marathon most companies want to indulge in: http://bit.ly/J9DvxF

3. Jay Fields is another former Thoughtworker who sums up the how-tos concisely: http://bit.ly/LbKy9Q

4. Mike Cohn is the ultimate writer in this area and this link leads to a chapter from his book on Agile estimation and planning, "Chapter 6: Techniques for Estimating": http://bit.ly/K6pvqQ

What I tell customers: We estimate expected effort, not hours. My teams count effort in points -- one is small, two is something more than small, three is something more than a one and a two, five is a large effort and going above five indicates the story is stated too broadly or contains enough unknowns to be manageable within an iteration.

Effort is either a measure of complexity (figuring out the unknown) or time spent on something that is naturally slow and tedious or a combination. Effort doesn't translate directly into hours but a team can use effort to figure out approximately how much can get done per iteration. It takes a team several iterations (2-5) to get a handle on their velocity (stories points completed per iteration) but you can use yesterday's weather to get a starting range for estimating a project.

Yesterday's weather comes from looking at what a similar team (size, experience) accomplished in a similar situation (familiarity with technology and domain). You only need one previous project to get this information. Use the averages - mean, mode, median - to figure out a likely range of outcomes and prioritize stories accordingly. Add 1-4 iterations for ramp-up (because both sides have to get up to speed) and 2-4 weeks for wrap-up (bugs, testing, and the unforeseen). Review and adjust the plan as you complete each iteration.

9 x 2 Things Agile Project Managers Do

I don't generally think of myself as a project manager, or agile project manager, although others have referred to me as that. "Project Enabler" is more how I see what I do. But recent events (Groupon acquires Obtiva), have caused me to start talking about the role and talking, of course, leads to thinking.

List-making is one technique for examining thoughts. I made a fairly long list of everything a project manager might have to do in the course of an assignment. I ran through that list a couple of times and got it down to 18 items that sum up what I think project management is all about.

The first 9 things are more concrete; easier to accomplish by following a book or template or checklist than the second 9. I've called the first set the "hard skills" 9. The second 9 activities are squishier; more dependent on experience and a gut-sense about people and situations; obviously, I've labelled them the "soft skills."

The "hard skills" 9

1. Prepare and present status reports. Chair demonstrations and planning sessions.
2. Create or identify effective visualizations of status and objectives. Know how and when to use them.
3. Convene estimation sessions and document results. Transform estimates into feasible budgets and plans.
4. Track velocity and maintain current projections of the project's likely progress.
5. Schedule meetings and milestone events (UAT, releases, etc.). Insure that necessary staffing, equipment and information are in place.
6. On-board new team members.
7. Evaluate people.
8. Coach people.
9. Treat your team to fun and games.

The "soft skills" 9

1. Set goals and vision for the team. Channel constructive feedback to your team.
2. Monitor development progress & facilitate blockages. Know when your team doesn't know or have something it needs; help the team fill the gap.
3. Convene team discussions on issues & get decisions agreed; help the team resolve conflicts.
4. Nurture stakeholder confidence in the team.
5. Proactively meet with clients to discuss their issues, goals and concerns.
6. Deliver bad news and present possible solutions to clients & leaders. Help the client understand and control scope.
7. Make tough decisions when everything is stalled. Prioritize work or requirements if needed (proxy product owner).
8. Defend your team from abusive stakeholders and leaders. Maintain productive operational patterns and sustainable pace.
9. Be a caretaker of the application's integrity & quality.