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.

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:

Process

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

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.

Practices

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?