Encouraging convergence: Our project management working agreements

As I described in my previous post, the project managers in my division want to be deliberate about how we run and deliver projects. We decided to develop set of “working agreements” (or manifesto!) calling out best practices we have experienced (such as retrospective meetings) and the aspirational aims we have (such as delivering frequently) with a view to embedding these in all projects in our division and encouraging consistency.

A team's taskboard reflects their processes and practices, but how much of this stuff should be common across other projects and teams at the same company?

A team’s taskboard reflects their processes and practices, but how much of this stuff should be common across other projects and teams at the same company?

If you want to learn more about why we did this, see Encouraging convergence: Putting a framework around agile team autonomy.

Here are our project management working agreements:


We will use the Scrum framework for projects.
We agreed to have:

  • One or two week “sprints”
  • Daily stand-ups
  • User stories to capture work 
  • A shared sprint review/demo
  • Frequent, regular retrospective meetings

We’ll share sprint cadence.
This means sprints on each project will be 1 or 2 weeks long and start & end on the same day across all Opportunities projects.

Each project team will be able to adapt their process and practices within this framework to suit their circumstance.
For instance, projects may have a differing level of certainty which may affect planning practices.

Purpose and goals

We will give our teams a clear purpose and good goals.
Where “good” means:

  • We will give our teams clear goals that they can directly influence.
  • We will give our teams goals that help them decide what to do and what not to do.
  • We will know if we have met the goals we set.
  • We will know if we are on target to meet the goals we set.

Teams will deliberately identify what they want to achieve in each sprint and release.

Roadmaps and themes

We will have a project roadmap for the next six months.
This should be a rolling 6 month window.
The immediate contents of the roadmap will be well-understood and certain.
The contents of the roadmap 3-6 months may be more uncertain and represent our ‘best guess’.

Project roadmaps will be broken into discrete, timeboxed themes.
These themes will be timeboxed according to the investment Opportunities is willing to make for the value.
These themes will help teams decide what to do and what not to do.

Themes will be broken down into small, independently valuable user stories.
This will be done before development begins on a theme (probably just-in-time).
The generation of themes and user stories will be owned by a product manager but, if necessary, facilitated by the project managers.

Delivery and planning

We will encourage our teams to release frequently (ideally, at least once a sprint).
We believe this is best practice and motivational.

We will adopt a deliberate, release cadence (for example, releasing every Wednesday).
We believe this is best practice; it builds predictability, keeps us honest and unlocks the release train approach.

We will use the release train technique to plan the delivery of each theme of work on the roadmap.
We use the “train” metaphor to communicate a few key concepts:

  • The train departs the station and arrives at the next destination on a reliable schedule (fixed cadence; standard velocity, predictable releases)
  • It delivers its cargo to customers (release)
  • If a team wants its “cargo” (code, documentation, etc.) to go, it has to put it there on time. The train will not come to them nor wait to get their content.

We believe using the release train will:

  • Engage the team in planning
  • Visualise the plan to deliver the current theme of work
  • Make the effects of scope changes and delays clear
  • Help us make better decisions around what we work on and what we don’t work on

We know when we expect to finish the current story and theme.
We accept that this may change as we learn more.

Continuous Improvement

Each project will have a mechanism to ‘Inspect and adapt’ each sprint.
We favour Retrospective meetings and believe running these every sprint is best practice.

We will share improvements and adaptations taken on each project with other project managers.
This can be achieved by a write-up of a Retrospective.

We will adopt good practices in other teams if there is a clear advantage or improvement to be had.
This should be reflected in this document.

We will regularly facilitate Retrospective meetings for other project managers.
This is so that project managers can participate in the meetings for their own projects.


Meetings will have clear goals.

Meetings will be attended by the ‘right’ people.

All regular meetings will have an agenda that is shared with the attendees.


We will record decisions that have been taken over the course of the project.
We believe this will help us with consistency across the lifetime of the project and ensure all team members are aware of decisions taken in their absence.
We believe this will help new team members can be brought up-to-speed quickly.

We will encourage our teams to identify the relative priority of the tasks required complete a user story.
We believe asking teams to differentiating between ‘must have’, ‘should have’ and ‘could have’ helps us make sound decisions.

We will encourage team members to take time each sprint for personal development.
We favour doing this by using ‘gold cards’ to represent personal development tasks on team taskboards.

Cross-project Cooperation

We want the teams in the division to feel part of a larger development team.
This is so that:

  • Team members know who they can talk to in another team about a given problem
  • We are not blinkered by ‘team goals’
  • We avoid social barriers between teams
  • We are more easily able to move people between teams if a need or development opportunity arises

We want the teams to know what each other are doing and what they plan to do.
This is so that:

  • We know when work in one team will affect another team
  • We know when teams should work together to solve a problem
  • We spot opportunities to share skills and experience across projects
  • We are more easily able to move people between teams if a need or development opportunity arises

I’d be interested to hear what people think of these. Do you think they are useful, over zealous, anti-agile or just common sense?

Visualizing team work: Physical Taskboards vs Virtual Taskboards

I’m a project manager, so unsurprisingly I can find myself in animated conversations with other project managers regarding how best to manage the work that our team members are doing. We all have our favourite techniques and methods, but the process generally starts with making the work each member of the team is planning to do, is doing, or has done, visible to the whole team. From there, the team can start to tackle important questions together, such as “are we doing the right work?”, “where we are struggling?” and “are we on-track?”

For the purposes of this post, I’m going to call these work visualizations “taskboards” but they are known by many names. For instance, at Red Gate they are called whiteboards, even though our teams use a combination of boards, walls and windows to host information. My team’s whiteboard is actually an opaque glass wall, but it works just fine!

Our 'physical' taskboard

Our ‘physical’ taskboard

In addition to visualizing the work the team is doing and their progress towards their current goals, taskboards also:

  • Map out the process of turning feature ideas into valuable functionality delivered to our users
  • Encourage team members to focus on team goals
  • Highlight dysfunction, bottlenecks and issues
  • Provide context for the current tasks underway
  • Give perspective on the relative priority of work
  • Encourage the completion of work and reduction of work in progress
  • Illustrate project health to stakeholders

There can be something strangely motivational about the completion of a task causing a tangible change. The ritual of moving a task from the ‘in progress’ column into the ‘done’ column emphasises that you have achieved something.

However, while project managers tend to agree on why it’s important to visualise work, the question of how to do this does not always reach such a clear consensus. In fact, there seems to be a dichotomy between people who favour physical taskboards, filled with tangible post-it notes and index cards, and those that prefer project management software tools, brimming with time-saving functionality and features.

When I tell people that my team exclusively uses a physical taskboard to visualise their work rather than a virtual tool, I’m quite sure some of them consider me to be some kind of Luddite. They proudly, and occasionally smugly, announce that everything pertaining to their project lives inside a computer! This, they assure me, is more collaborative, saves them time and is hassle-free (apart from when it’s down for maintenance).

However, it’s not a fear of technological change that causes me to continue sticking stationary to walls. It’s because I believe physical taskboards best meet my two most important requirements of a team work visualisation:

  1. It radiates information from a central, obvious place
  2. Everyone in the team uses it

The information should be clearly presented and in your face. It should be big and constant, so you aren’t able to ignore it. You shouldn’t be able to lock it away or hide it. All team members should use it, and use it in the same way. It should be trusted as the single, definite representation of the work going into the project. For me, a physical taskboard does this best.

There are many good software tools that can provide a virtual taskboard. I’ve used VersionOne and LeanKit successfully in the past. Personally, I’d only ever use one exclusively if my team was not co-located. In fact, when I worked with a geographically distributed team, I maintained a physical taskboard situated where the few co-located members of the team had their daily meetings.  That was because I wanted an information radiator. Admittedly, I could have done this with a very large monitor that permanently showed the virtual taskboard, but it was cheaper, quicker and easier to tailor a physical wall with index cards.

As a central heating radiator emits heat to passers-by, a taskboard should broadcast project status to everyone who passes it. Often virtual taskboards live in browsers on individual team member’s machines. These browsers can be closed or hidden. They are more like information cabinets. Everyone knows that the project information is in there, but they need to choose to open it up to discover what it says. If you suspect something sinister lives in that cabinet, then you are probably quite unlikely to open it regularly.

Maybe we shouldn’t really be trying to find a one-size-fits-all resolution to the physical vs virtual taskboard debate. Both approaches can work really well depending on the behaviour and location of your team. The more important discussion is whether your team work visualization is an information radiator or an information cabinet.