Using scrum of scrums for Portfolio Management

In departments where there are several teams working to a single portfolio or programme of work, it is possible to create an Agile org structure which maintains focus, communication and transparency while managing dependencies and risks.

Using scrum to manage the portfolio

For an enterprise-scale department or a small firm that manages a wide range of products, the best way for them to be properly tracked is by establishing a portfolio. Although the term "Portfolio Management" can often smack of old-school, traditional "Waterfall" project governance, it is absolutely possible to eschew portfolio management in the traditional way, and instead to adopt Agile portfolio management using scrum.

Begin by developing a scrum backlog which covers all of the product workstreams and operates in a portfolio scrum team, similar to the normal scrum team, but with a Portfolio Owner (akin to Product Owner) and a Portfolio Master (akin to Scrum Master) to ensure scrum is used to manage the portfolio backlog, following all the standard scrum rituals but on a programme level.

There are a number of benefits to this setup. Once a Product Vision is established which encompasses the entire programme of work, an org structure like this is a way of ensuring focus on that vision and that the right products are being prioritised across the entire portfolio. Having a sprint retrospective for the portfolio team means that progress of each sprint is reviewed across teams, allowing you to assess how the teams are doing, and ensure priorities and customer commitments are being met. Once a velocity for the entire portfolio can be established, it becomes possible to estimate deliveries across multiple teams and flex resources between teams in accordance with demand.

Each scrum team has a Product Owner and a Project Manager and/or Scrum Master. Each scrum team holds its own scrum activities, and then reports to the Portfolio scrum-of-scrums to join the dots between the workstreams.


In addition to participation in the portfolio scrum team, the PMs should be responsible for:

- Short, medium and long term plans for the entire programme of work
- Resource allocation of scrum teams
- Working with Product Managers to funnel projects and work items to teams
- Ensuring projects are vertically sliced in a way that resource can be assigned/withdrawn in an agile manner

Stakeholder focus

Drawing it all together means you can have unified reporting, metrics and demos for presentation to senior stakeholders and you'll be able to consult one place to get info on all products in the portfolio rather than chasing individuals in different teams or across multiple locations.

Team organisation

This approach allows a large pool of resource to be structured into small, fluid (but colocated) scrum teams working in a scrum-of-scrums environment across the entire portfolio of the department's projects.

Colocation is a strong success factor in this kind of setup. If you are joining remote teams into the portfolio, they should be colocated rather than splitting teams with members in different locations.

Teams in a portfolio scrum-of-scrums should have:

- Combined monthly sprint demos where every team in the program presents
- Quarterly release plans defined for each team, as well as the department as a whole
- Shared sprint cycles across teams

A structure like this allows for mobility between teams as well as career progression for individuals, as several individuals can take on Scrum Master roles and teams can become more cross-functional and be exposed to a variety of products within the portfolio.

Working with scrum teams in different locations

Working in a distributed way is becoming more common. This can be a particular challenge for scrum teams. Here are some ideas of how to run distributed scrum teams, assuming that they are co-located, rather than having members of the same scrum team split across locations (a very different challenge!).

Have a Project Kick Off

Have a project kick off with everyone in the one location. Run through everything pertinent to the project and get everyone to present something, including information on themselves.
A good project kickoff can make all the difference, because people will tend to work more smoothly together once they can put a name with a face. Rather than just an exchange of information, use the kickoff as a way to bring the teams together socially and have a bit of fun.

• Book a group lunch
• Invite the group to the pub
• Have introductions - ask everyone to give an interesting fact about themselves

Don't underestimate the extra time needed 

Extra time will be needed for:

• Ongoing careful comms to plan and to prevent misunderstandings
• Travel
• Questions and queries (which will take longer to ask and answer)
• Video conferencing.

Use chat/IRC or messaging

Tools like IRC or Skype can be used to create team "rooms" to act as a virtual home for a distributed team. Each team member can use whatever chat client suits them and they can also use it from home. Encourage everyone to be logged into chat or messaging all day. If you use multiple channels for your project, ensure that everyone feels welcome to join into any of them and that logs are freely available.

Hold a daily Scrum of Scrums 

Have a daily Scrum of Scrums between the leads on each project.

If you hold this in chat/IRC:

• Use a separate channel from the main project's channel
• Remind others that "chickens" are welcome and what the log location is
• Make sure that it starts on time
• Encourage the attendees to have the text ready beforehand to cut and paste so that others aren't hanging around whilst people type
• To keep things moving it's a good idea for everyone to state when they have finished and/or choose the next person to give an update.

Get good at Video Conferencing

If you have access to a corporate video conference system, make use of it to hold end of sprint demos and ad hoc chats between the distributed teams. If not, you can use Skype, though the quality isn't as good for demos. Google hangouts is preferable to Skype for scrum of scrums, because it can handle multiple attendees (more than 2 participants).

Agree Travel Budgets

If you can get to and from the other locations in a day, try to budget for at least:

• Initial project kick off trip to one location, including overnight stays if needed
• One person's trip from each team to each other location per sprint (more if you can afford it)
• Trips at the start of the project whilst teams ramp up
• Trips for new joiners to get to know the other teams
• End of project celebration

Improve communication

Clear reports, clear and useful pre-sprint planning and up-to-date-ness of issue trackers will help.
Agree the comms that you will have between teams, everything from ad-hoc queries, through in-team reports and updates to stakeholder reports.

Document everything - no, seriously, write it down!

Make use of a team wiki and ticket tracking system to ensure that the remote teams have a single area to share information. It's better to over-document than under-document, even if you're an Agile team (being Agile doesn't mean having no documentation!). One of the most frequent frustrations that a remote team has is that they miss out on the "hallway" conversations that happen in the other office. So, whenever the team discusses something, make sure that someone writes it down in the wiki.
Examples of useful things to document:

• A checklist of activities that occur during the sprint, so that both teams are always in sync
• A record of dependencies on other teams so that everyone knows the gaps in responsibility for tasks
• Listings of communications methods so that the teams know their options for getting questions answered
• Working agreements clearly stated for the teams, which help to align the practices of geographically separated groups
• Areas on the wiki, such as a scratchpad where remote teams can record their thoughts, concerns and questions -- then have them answered

Use common working practices

If two or more teams in remote locations are working on the same project, try and merge working practices as much as possible so that there's a common language and frame of reference between the two groups.

• Use a single ticket tracking instance for the teams
• Follow the same sprint cadence:
  • Use the same sprint numbering for both teams
  • Hold sprint demos over video conference
  • Share both teams' sprint goals and priorities at the start of each sprint
  • Hold sprint retrospectives and planning sessions at the same time
• Use the project as an opportunity to learn from the other team and improve the way both teams work

(Thanks to Anna Charemza for collaboration on these tips)