Agile Program Management at iflix - Physical and virtual boards and how we run our scrum of scrums.

Early program management at iflix

At iflix, our tech teams are spread across Asia, Europe, Africa and Australia. At the time I joined, a lot of change had/was happening (and it still does). The organisation is in the early stages of adopting agile and teams are evolving rapidly.

Visual tools for agile program management

Managing programs of work for software companies is hard, even if you're using agile to manage your work, it must be really effing hard, why, because... PMO's. Organisations would not willingly put PMO's and their corresponding bureaucracies in place by choice would they? Are there other ways to organise multiple agile teams, multiple locations and multiple delivery goals without a PMO?  

We took the following agile manifesto line as a guiding principle when designing our approach to program management at iflix: “Individuals and interactions over processes and tools”. Whilst I wanted to create tools to represent WIP and highlight issues/dependencies, We wanted to ensure program management was a by-product of the team members getting together and talking. Here’s the story of our agile program management process.

In the early days tracking the program level of work was initially down to a number of high level program goals written on cards and stuck on a window, as well as tools like Jira and a lot of powerpoint decks.

As for me, I’m a huge fan of using physical spaces and boards to visualise WIP, whether individual sprint teams, or even, the program level across multiple teams. I liked having the goals on visible on walls and windows at least,  This however, gave no indication of who was doing what, dependencies, why’s? Whens and whatevers. The process to map this stuff was also restricted to senior managers with limited input from the teams.

So, We spent a few days getting to understand the different teams. Knowing what information is important to the group was critical and we workshopped some board ideas. We went through a number of iterations (as you should) of the Program boards. One of the major changes we did was to directly involve team members in their particular schedules of work.

Early board design. Cards colour coded of course.

People (not resources!)

Highlighting the relationships between work in progress and organisational goals was also important. When there is a lot of stuff underway, knowing what impacts what is complicated. So, we used coloured cards, stickers pieces of string to tie grouped items together. At a glance you could get an idea of the relationships and dependencies between teams.

We added little icons of the ‘people’ in the team.We wanted to avoid people using the term ‘resources’ when talking about people in teams. It’s not just the fact that it is dehumanising (which it is) it’s also dangerous. When we start talking about team members as resources, they get stuck in the mindset that each person is exactly alike, can produce the same work etc etc. Reinforcing that we’re all individuals by simple tools like these ‘card/icons’ reminds us to consider the individual skills and personalities when planning.

Title: Agile program board.

The image above shows a detail of the current board. Global events/dates at the top of the board such as App releases and regional launch events. These have implications across all teams so get prominence. The full board contains twice as many teams so the complexity scales up rapidly.

Teams have a swinlane each, with the swimlane holding epics the team are working on (nothing too micro). We also group teams via relationships (similar themes, overlapping dependancies) and highlight group / team goals on a collective swimlane that tops the group.

The 'monkey of time' is a magnetic monkey with a red ribbon tied to it. The ribbon is the date, running down the board. Here, we group work together with similar coloured cards (or in this case magnetic re-usable cards, fancy!). We use a whole pile of visual tools here to convey otherwise complex information, colours, magnets, stickers.

The mechanics of this agile program management session

Quite simple really. We meet once a week most people in the one room but a significant number of others joining online. We’ve got an electronic version - below (a google doc) for those online which we keep up to date.

Then we run from the top down. What releases are coming up? Are we all ready for them, any ‘must haves’ for that release in danger? As EPIC’s and MILESTONES are signed off, we stamp the cards and clap! (on the google doc we colour these bright Green).

Each team calls out whether they are green, orange or red. With the following guide to what that means:

*RED*: Act - How can we help, must have decision at meeting -e.g. Work has slipped and that will impact something such as a country launch or another teams delivery goals

*ORANGE*: Act or Accept - Change to schedule - New work or work slipped - Others need to know - decision in meeting whether Green or Red

*GREEN*: No additional action required, team on track, no change to plan

If a team is green, we give a quick summary and move to the next one. If a team is Orange or Red, we decide there and then what to do to help. We also re-iterate that we shouldn't wait for this meeting to flag if you’re in trouble of missing goals.

A nominated ‘ring-leader’ or scrum master takes a note of the main achievements, issues or promise of a future conversation that get raised and puts these into our slack channel, along with an updated photo of the board. We @tag people with actions arising out of the meeting in the slack channel.

The focus here is on sharing information and support. If you start to introduce ‘punishments’ for slippages in schedule and you break the trust necessary to ensure honesty. We end up back in the old ‘Watermelon project’ cycle - Green on the outside, Red in the middle. Teams insisting they are green for as long as possible to avoid repercussions, hoping they can somehow turn it around before crashing.

One of the criticisms of this board is that there is no consequence of shifting dates of delivery. In the stand up, a card will shift to the right. The reality is, most likely, this was already happening, we just had no visibility if it. Getting work in progress up and visible and having a stand up/accountability session allowed us to see the shifts happen and make a plan on what to do.


We have also noticed, over the course of the life of this board, teams focussing on doing 'less' and delivering 'more' so the transparency has had an impact. Teams are more open when things are going wrong and we look for ways to assist each other.

What the meeting is for:
Accountability
Highlighting problems and working out what to do collaboratively
Shared understanding of the program of work underway
A place to ask for help or offer it
A chance to uncover dependencies
Revealing those 'missed conversations'

What it isn't for:
This is not the first time you should be finding out about problems with delivery
Pointing fingers at people
Covering up problems
Blame shifting

Resources (things not people!):

Some people have asked if they can play around with our electronic document for their own teams. More than happy to share, so I’ve created a template that you’re welcome to copy and use. Remember, I really love physical boards so I’d default to something like that first. The simpler the better.

https://docs.google.com/spreadsheets/d/1sToQjsiGbJZYrRXHfBg1-9z4MQWLHkJJQXr3NYr7Lqw/edit?usp=sharing