I iterate, therefore I am.

Iteration meetings are just that – project meetings that occur at the same day/time/place with the entire project team. I believe the core purpose of an iteration meeting is to demonstrate working software. As I’ve branched out into other types of non-IT projects, I believe the primary value is still in demonstrating work that has been completed and verifying the priority of the work for the upcoming iteration.

With most of my projects being 1-4 months in duration, one week iterations have worked well to keep momentum and ensure we are on track. I have led projects that ran on two-week iterative cycles, and those projects did not meet success criteria – over budget, missed deadlines, and unmet requirements. By consistently time-boxing the work done, I am able to create visible milestones that easily track to our requirements or other success criteria.

My iteration meetings generally have four parts to them. My clients receive an agenda the day before that outline these items:
• Housekeeping
Some people are nervous about it, so I get it out of the way first thing! Budgets.

I review the actual budget utilized up to that week against the estimated budget. Depending on the project, we can also provide other KPI such as budget burn for specific roles or tasks. Housekeeping is also for any discussions about scope, contracts, change orders or amendments – the “legal” aspect of the project.

In most cases we are only reviewing budget status, and it is a great motivator to the team when they see how their actual hours are comparing to their estimated hours. If there are special circumstances that must be discussed or negotiated, I invite only the relevant team members – usually myself and the account manager, and of course my client. This creates an intimate collaborative dynamic and uses everyone’s time wisely.

• Requirements
Any questions from the client, architect, designer, writer, or other team members can be directly addressed to the product owner (client). Team involvement at this level may seem like project overhead to some, but the results are fewer re-works and higher satisfaction with the work done.

Throughout the week I track ongoing requirements gathering and analysis, and add these items to the agenda as touch points. It helps to keep these business requirements in view – especially because as we demonstrate the solution that meets those requirements, the requirements are likely to be refined and slightly changed.

• Demonstration
While I use a task-tracking tool for general project management needs, I do not like to bore my clients by sitting through a granular review of each and every technical task – unless they ask for it! Generally it is not a good use of their time. Over the last few years, I’ve found the tempo of the meeting is improved if I recap the work done by mapping it to larger functionality ‘chunks’ and demoing to the client the feature as a whole instead of each smaller task that went into it.

Also, I am adamant about this – if it is a software project, code coverage for unit tests must be shown each week!

Demonstrating is basically the delivery of finished work components – whether it is copy, photo galleries from a shoot, or a working screen in a new software application. By this transparency, the product owner has no doubt of the progress – or lack of it.

• Planning
Because this meeting segment can be quite technical, I generally close the formal iteration meeting and wrap up with my client before we begin planning, which generally takes 20-30 minutes. (The first three segments are easily covered in an hour if the project manager prepares a thorough agenda.)

After showing the work of the previous week, we keep forward momentum by carefully planning and committing to the work for the upcoming iteration. Any new tasks (or user stories) that are discovered during the iteration are added to the project backlog. Tasks with the highest business value, or mapping to what the product owner has assigned a high priority, are added to the queue for the new iteration. We re-estimate the ideal hours for the iteration’s tasks, and as individuals, we commit to delivering those items.

Some additional benefits of having iterative project meetings that follow this basic format:
• These meetings create what is called “tight communication-feedback loops”; we can respond faster and with less process overhead.
• Stakeholder alignment is created by including the client as a working team member. The project team organizes around the client’s priorities, and the client has frequent visibility into the work being done.
• The team is constantly focused on doing the work with the highest value.
• Team politics and dysfunction are reduced.

Iteration meetings are easily “tweaked” and adjusted to suit any team or project. The important thing is to be observant, learn what works to keep information flowing in all directions and to keep everyone feeling comfortable with what’s been done and what’s on deck. Be creative, be brief, and most of all, have fun!