Visualise an agile programme
The approach I am advocating is suited to when you want to look at a single agile programme. It allows the programme to be managed in an agile way, whilst providing the teams and stakeholders a single reference point that visualises both priorities and progress.
The board should be in a position that is permanently highly visible, with space around for people to conduct periodic reviews.
The layout of the Board
Display the programme vision
So that everyone associated with the programme understands the programme vision, it is essential it is kept visible. If the vision is just mentioned at the kick off and then only exists on wiki pages or in documents sitting in a shared folder, it will not be used so put the vision up on the board as a constant reminder of the purpose of the programme.
Display the objectives
Put up a swim lane for each of the programme objectives. The work is going to be organised by objective, not by team, and so will need a swim lane dedicated to each objective. I like to ‘bookend’ the swim lane by having a card, with the objective written clearly, at each end of the swim lane. This will be useful later when the objectives have been completed.
Order the objectives
Put your objectives in order, taking into consideration both urgency and importance. If you are struggling to do this then don’t just press on with the programme. Spend a day or so to review with stakeholders and decide the order. Ultimately it is the person in the Programme Director role who should have the final say on this, but this should be done after a healthy dialogue with those who have an interest. Periodic review is essential to agile processes and the objectives could be reordered as part of a review.
On the board, order the objectives from top to bottom with the primary objective at the top of the board.
Set your review period
Having a clear review period for the programme is useful because:
- it allows the teams to forecast up to this period;
- it manages the stakeholders’ expectations in terms of what may be achievable in the given timescale;
- it presents an opportunity to review the objectives, including their order, and for the programme to respond to any external changes such as market conditions or overall business goals.
Populating the board
The next stage is to start populating the board. The level of detail I am advocating for this is high level stories. As is common practice, I have used the term ‘Epic’ to indicate a high level story that will be sliced into smaller stories as the team approach doing the work. I suggest using one card per epic per team.
Indicate which team will be doing the work
When writing the cards indicate which team will be doing the work. I have used different colour cards for this, but you could put labels or icons on the cards.
Clearly indicating the team helps members of that team identify their contribution to the overall programme.
Put the team epics against the objectives to which they relate
Rather than having a section for each team, put the epics on the board in the swim lane for the objective to which they relate.
Forecast based on order of the objectives
Starting with the top objective, the team forecasts how many of the relevant epics they can complete within the time period, putting them in the ‘current’ column and leaving the remainder in the ‘future’ column. They then move down the board adding in the epics they forecast they will be able to complete that are associated with the other objectives, taking into account the epics higher on the board in the ‘current’ column. The team will eventually get to the point they feel that they will not be able to complete any more epics within the time period.
On the above example board, team 2 cannot include epics 4 and 5 in the current time period as they are already looking to complete their epics 1, 2 and 3 in that period.
Indicate which objectives will not be progressed
Once all teams have completed this process, there are likely to be some objectives that cannot be started. Make this visual by moving the objective card over to the end of the current period so that all of the epic cards are in the ‘future’ column.
Reviewing the programme board
As stated above, periodic reviews of the programme and programme board are essential, so the programme can respond to new information that comes in. Doing this at regular intervals gives this process structure. However, there may be occasions when the circumstances have changed significantly and waiting for the next planned review is not desirable.
The following activities should be done during each review.
Remind the attendees of the programme vision
Making sure the attendees who are reviewing the programme board understand the programme vision. It may well help the discussions as the work should all build toward this vision. If the vision has been fulfilled, it may be time to close the programme, even if not all objectives have been met.
Move all of the completed epics into ‘Done’
Add a ‘Done’ column to the left-hand side of the board. I realise it is a little unconventional to have it on the left, but in my view, it works better this way with this kind of board. A card should only be moved into ‘done’ when all work associated with that card is complete.
Confirm objectives and the order of the objectives
As with any agile process, the team or teams delivering it learn as they go. There could also be external factors that have changed. Sticking rigidly to the objectives that were set and ordered at the beginning of the programme regardless of this new information does not seem like the right thing to do. We must be prepared to reconsider the objectives and/or the order of the objectives to ensure they are still relevant to the programme vision.
Identify any additional epics that are required
As teams progress, additional work may become evident that is necessary to achieve the objectives. These are added to the board as additional cards. It is also possible some epics that were previously written on one card, can be divided into multiple smaller epics and have their own cards.
Populate the ‘Current’ column
Teams should now populate the ‘Current’ column based on their forecast for the next period. This takes into account what was delivered in the previous period and any new cards that have been added. As before, teams should work their way down the board.
Indicated objectives that are expected to complete
If any of the objectives have no epics in the ‘Future’ column, and no further work for that objective is anticipated, then move the objective card on the right of the board to the beginning of the ‘Future’ column to indicate that the objective is forecast to complete at, or before, the end of the current period.
Indicated objectives that have been achieved
If an objective has been achieved, then this can be shown by moving the objective card from the right of the board to the beginning of the ‘Current’ column. This indicates there is no further work necessary to complete this objective.
Things to avoid
When adopting this approach to visualise an agile programme it may be easy to introduce some command-and-control behaviours so here are a few things to look out for.
This is not a Gantt Chart or a roadmap
Don’t turn this into a Gantt Chart by adding in dependency arrows or into a roadmap by forecasting beyond the current period. Each product should have its own roadmap where the future epics may appear. This should be visible to those interested and it is unnecessary, and potentially an administrative overhead, to look to replicate that roadmap on the programme board.
This does not replace the need for team level events (Sprint Planning, etc.)
The team should continue to follow their own processes. The programme may or may not be the only source of work for the teams but even if it is, the team should still hold all of their events.
This does not overrule the Product Owner
There could be many reasons why there is a different point of view between the Product Owner and the programme leadership. Hopefully, this can be resolved through constructive dialogue but, until this happens, the team involved must use the sequence provided by their Product Owner and not by any other stakeholder.
Summary
- I am advocating this approach as a way to visualise a single agile programme.
- A clear programme vision and ordered programme objectives are required in order to create a programme board in this way.
- The board should be in a position that is permanently highly visible.
- Periodic reviews around the board will help stakeholders understand progress but also give the programme a structure when it can respond to new information or changing conditions.
- This visualisation does not replace team processes but is a light touch addition designed to complement individual team roadmaps and events.
