Contact

Program Board - Setup

In a recent training course that my colleague and co-trainer Keith DeMendonca was running he was asked about documentation on how the Program Board within SAFe works, after a brief search the answer turned out to be that there’s very little information on what it’s for, how to set it up and how it is utilized both in PI Planning and beyond. Even the Scaled Agile material itself just shows a picture of the Program Board with a couple of lines of description of what it is; but no more detail than that. The training material has a few slides scattered between the various courses but is similarly scarce.

Keith and I talk about the program board extensively in the trainings that we do together, so it’s not as if there isn’t a body of knowledge and experience out there about how to utilize the Program Board, it’s just that nobody appears to have written it down. These articles aim to rectify that and provide a permanent record for future reference.

In this first article we'll look at how to set up the Program Board, subsequent articles will look at how it should be used during PI Planning and PI Execution

What Is It, Why Do We Need It?

The purpose of PI Planning is to generate alignment within a team of agile teams as to what they can accomplish over the next 10 or 12 weeks. Honouring SAFe Principle #9 : Decentralise Decision Making, whilst the business might provide the direction, The Intent to quote David Marquet, the teams are tasked with putting together a plan that accomplishes as much of The Intent as possible, whilst balancing their own needs of keeping themselves and the solutions they own healthy.

A Centralised Tool for Coordinating Decentralisation

Henrik Knieberg

As part of the process of PI Planning the Program Board is built to provide a visual representation of anticipated value delivery, the collaborations to make that happen and how the value and collaborations align with any key milestones.

The power of visualisation is that if you can see it you can manage it, if you can’t see it you can’t manage it. The visualisation allows everyone on the train to see bottlenecks, structural issues with teams, challenges within the plan for the Program Increment and then everyone can start to manage the issues and challenges to minimise them as much as possible.

The collaborations that have been identified as part of the planning process can be tracked during execution to ensure that the teams are interacting and the Program board can be annotated to indicate both progress and changes to the plan.

Collaboration not Dependency

Scaled Agile refer to all interactions between teams as dependencies; but words have meaning:

Dependency: Adjective

  1. relying on someone or something else for aid, support, etc.
  2. conditioned or determined by something else; contingent: Our trip is dependent on the weather.
  3. subordinate; subject: a dependent territory.

Dependency implies helplessness, but that’s not true within an Agile Release Train, we collaborate with our fellow teams to get things done so that the Agile Release Train itself is successful. We talk to each other, we help each other. We’re only dependent on external parties where we have much less influence and ability to interact.

Collaboration: Noun

  1. The act of working together with other people or organizations to create or achieve something:

This article will use Collaborations to describe internal interactions, Dependencies are reserved for external interactions.



It’s a Gantt Chart, That’s not Agile!

Yes it is a form of Gantt Chart, but a Gantt Chart is neither Agile nor not-Agile, it’s just a tool to visualise sequences and interactions over time. It is how the people utilise the tool that makes them Agile or not-Agile. If the tool is used to impose a sequence upon a set of people then they are unlikely to display Agile behaviours. If the tool is used by a set of people to visualise their own interactions then it can help them to display Agile behaviours at scale.

Plans are worthless, but planning is everything

Dwight D Eisenhower

The act of building the Program Board is as important, if not more important, than the Program Board itself. The act of the engineering staff collaboratively building the board to visualise the interactions amongst themselves means that they themselves understand what those interactions are. It is the collaboration that creates alignment amongst the teams as to what they can achieve.

The process also allows the teams to see the bigger picture, rather than get lost in the minutiae of stories. Mike Cohn has also observed this phenomenon and suggested a quarterly planning activity to set the goals for a team for the mid-term; he suggests a 13week quarter, SAFe would use a 10-12 week Program Increment. Don’t expect a perfect set of stories from a PI Planning event, planning just needs to produce enough detail to ensure that the objectives that the teams are setting for themselves are SMART and that the necessary interactions between the teams have been identified.

The visualisation should not be seen as an attempt to fix a plan, but utilised as a living document so that when the plan changes the set of people can assess the impact and adjust accordingly. It is merely one record, amongst many, of the results of the negotiations between teams that happens during PI Planning.

Setup

All program boards follow a similar structure. There will be minor differences in the information that the group wants to convey and visualise but usually, rows are for teams, columns are for timeboxes.

Program Board

Figure 1: Program Board

Horizontal Rows

The horizontal rows represent people, either teams or individuals, that collaborate together. Some program boards utilise an explicit row for displaying milestones.

There is no implied precedence in the ordering of the rows on the program board, however it typically runs Milestones, Teams, Shared Services, Individual Contributors, Other parts of the organisation and External Collaborators.

The row headers usually show the team name and key contacts within the team.

  • Timebox Description: Acting as the column header, the name of the timebox and the start and end date of the timebox. Other calendar information could also be displayed here, e.g. public holidays.
  • Milestones: Any key dates or deadlines that the Agile Release Train needs to plan towards or around are made visible. We tend to rotate the Post-Its (or their virtual equivalent) by 45° to create a diamond so that they are can be differentiated from the work items that are aligned to the grid of the program board.

    Sometimes this is merged with the Timebox Descriptions mentioned above that are acting as the column headers; the decision to merge or don’t merge is purely upon the volume of information that needs to be conveyed, if there’s only a few milestones then it should be possible to merge it into the timebox descriptions, if there are a lot then they might warrant a row in their own right.

    Whilst there might be hundreds of potential milestones that could be visualised pick the ones that will affect the teams’ plans. The organisation might be aiming for a specific release date but if the organisation has an antiquated 2 week release process then the real date that the teams need to plan towards is 2 weeks before the actual release.
  • Teams: Each team on the Agile Release train has it’s own row. The row headers contain at a minimum the team name, but often the key contacts of PO and SM are also listed. For distributed and dispersed planning events it’s useful to provide details of the breakout room the team is using, or the video conferencing channel that they are on.
  • Shared Services: Shared Services are just another form of team. If the shared service belongs to this train and is across the teams on the train then they would plan like any other team. If the shared service is external to the train, then representatives of the shared service should be present to understand what help the train needs from them and to represent what they can do for the teams on the train. The advice given below in Other Trains / Parts of The Organisations applies to external Shared Services.
  • Individual Contributors: Individuals within, or attached, to the train that may need to visualise and plan their interactions with others within the team. It is not uncommon for the System Architect, or similar technical expertise roles, to have a number of ad-hoc interactions with teams as part of helping them understand technical concerns, these need to be negotiated and visualised just as much as the team to team collaborations.

    Sometimes it’s worthwhile Individual Contributors building their own plan and forming their own objectives so that they can explain what they are doing to the rest of the Agile Release Train using the same format and presentation as the rest of the teams. They probably don’t need multiple giant sheets of flipchart paper to formulate their plan, it’s usually sufficient to have a single sheet subdivided into sprints and a second sheet for objectives and risks.
  • Other Trains / parts of the organisation: If the train is part of a solution train, or even if it just knows that it will have a lot of interaction with other specific train(s) within the organisation then those trains can be given their own rows. All the trains that need to interact should be planning in parallel so that they can interact in real-time with each other, this will be across phone lines or video links rather than planning together in one super-giant room. The row is used to map out the interactions with the other train, tickets for what they are delivering to this train and tickets to represent what this train is contributing for work flowing out from this train.
  • External Collaborations: There is usually a row towards the bottom for external collaborations, it can be used to map out interactive with either people or teams that are external to this Agile Release Train and haven’t been represented elsewhere on the board. Whilst it’s external to this train in could still be internal to the organisation or it could be true external collaborations.

Vertical Columns

The vertical columns represent the time-boxes that form or influence the plan. Time traditionally runs left to right; on the left hand side of the Program Board are the time-boxes closest to the planning event, the further right on the board the further away the time-boxes are getting.

The column headers usually show the time-box name and it’s start and end dates.

  • Team Names: The left hand column acts as the row header and provides the team name and any other useful information about the team such as key contacts, location where they will be planning, etc… Usually a “half width column” is enough to convey the information required.
  • Plannable iterations: These get a “full width column” since the expectation is that they will be filled with the tickets representing value delivery and interactions that contribute to value delivery and so require a sizeable amount of space.
  • IP Iteration, Next PI: The Innovation and Planning iteration and Next PI columns usually get a “half width column”; we’re not expecting any work to be planned into these two time-boxes so they don’t need a large amount of real-estate. They are present so that we have space to indicate any key milestones that occur during these timeboxes.

    A major release is scheduled to occur in the first iteration of the Next PI. When is all the work for that release going to occur? In the Next PI? No, in this PI. Because the Next PI column is present we can stick a milestone in it so that we know it’s coming up and then connect the relevant work planned in this PI to that milestone to visualise it.
  • Being Planned: When working in a virtual environment we’ve found it useful to have an extra column right next to the team names that gives the teams a space to place the feature that they are currently working on.

    Program Board

    Figure 2: "Being Planned" Column

    In the physical environment the team would carry the Feature ticket taken from the Program Backlog back to their table, in the virtual world there is no physical place to take it to so we need a virtual place instead, the Being Planned column.

    Having the column makes it quick to see what each team is working on. If they’ve taken more than one Feature then it’s very visible; we would alwyas advise teams to plan one feature before moving to the next, i.e. work in a serial fashion, but there may be instances where it makes sense to grab two features and plan them together because they overlap or interact.

Tickets

Tickets represent value delivery, or collaborations contributing to value delivery.

In the physical environment these tickets are typically self-adhesive Post-It® notes, in the virtual environment they are the electronic equivalent.

Colour Coding

The exact colour coding you choose is entirely up to you, what’s most important is that everyone knows the colour coding and utilises it consistently. Using different colours for visualisation allows patterns to be seen which can inform the decision making process.

  • Historic colour scheme

    Historic Colour Scheme

    Figure 3: Historic Colour Scheme

    Blue represents value delivery, i.e. Features, Red represents the collaborations needed for value delivery to occur.

    Although this loosely ties in with colour scheme prevalent throughout the framework, where Blue represents customer requests and Red represents internal requests, it’s worth noting that Red tickets are not necessarily Enabler Features or Stories. If the collaboration is supporting a Business Feature then the stories to realise the collaboration are likely to be Business stories as well. If the collaboration is supporting an Enabler Feature then the stories to realise the collaboration are likely to be Enabler stories as well.
  • Colour coding by Epic

    Colour Coding By Epic

    Figure 4: Colour Coding By Epic

    Another colour coding scheme that we have utilised before is colour coding the Features according to which Epic they derive from; each Epic had it’s own unique colour with Red being reserved for representing the collaborations as described in the Historic colour scheme above. For an Epic owner it makes it very easy for them to see where their Features are within the plan, they just have to look for the tickets in their Epic’s colour. The colour Red is reserved for representing the collaborations.

    Colour Coding By Epic Example

    Figure 5: Colour Coding By Epic Example

String

The string is used to link tickets together. Most electronic whiteboarding tools provide some form of connector to link their electronic tickets together.

  • Ensure that the string is a different and distinct colour from the background of the program board and the post-its. If the string is the same colour, e.g. white string on white flip chart paper then when it’s photographed to record the outputs of PI planning the colours blend together and it’s hard to discern the links.
  • Additional sticky tape or tack may be necessary to secure the ends of the of the string. The stick on the back of a Post-It® is strong enough to hold itself but is not strong enough to support string.

Conclusion

In this post we've covered why Program Boards are useful and how, if used right, they can be a tool that encourages agile behaviours and decentralisation.

The next post will explore how the Program Board is used during a PI Planning Event.




or

More Great Agile Content from Ivar Jacobson International:






Subject: 

Contact Us