VRT NU — Visualizing a scaled-agile team’s valuestream
Context
VRT NU is the video streaming service of VRT, the Flemish Public Broadcaster (based in Belgium).
The importance of this product (in this digital age) has been steadily growing, and has recently gone in overdrive as VRT management re-enforeced it to be an important strategical pillar in the overall future plans for the company, with an ambitious roadmap and extra resources to match this ambition.
This means that in the last half year, we refocused a lot of our people working on smaller touchpoints to join our efforts on the VRT NU platform. Together with some extra additions the result was one big VRT NU team. In half a year we went from about 15 to around 50 people working on the same platform.
The original team was organized as one cross-functional team using Scrum to deliver. As the team got bigger, we switched to ‘sub-teams’ using a scaled approach inspired heavilly on LeSS (Large-Scale Scrum) but tailored to our needs and context.
In broad lines, we created a PO-team, a Design team & 5 Feature teams, each with a specific touchpoint preference (web, app, redactional systems) and stimulated Communities of Practice and Chapters to boost inter-sub-team coöperation.
The results so far have been amazing. Since we already had a quite mature Agile culture with lots of trust and ownership, the transition to working in a more scaled way went quite easily and felt natural given the expansion of the team. We had no spike in turnover and no significant sudden drops in our ability to deliver (which has subsequently grown tremendously).
“Visualize work” — Transparency challenges
The planning process was quite simple, PO’s presented the roadmap and representatives of each team used this as input to propose a ‘team goal’ for next sprint and a tentative goal for the sprint after that (in discussion/cooperation with the PO’s and each other). This resulted in goals for every team, aligned with the roadmap & with ownership/buyin from the teams.
But of course there is no ‘perfect’, in retrospectives we felt that every team was firing on all cilinders, but the overall valuestream was not very transparent. This lead to recurring remarks like ‘who should I talk to about …?’, ‘what (different things) are we currently working on?’, ‘is this something we are still working on?’, …
It became clear that a more structured way of visualizing our ‘whole-team’ efforts was needed. And not only because ‘transparency’ is a key scrum value. So, from the next Overall-Retrospective, a taskforce was born to come up with a more fitting solution.
The proposal/current experiment
1. The board — structuring the visualization
The goal was to come up with a better cross-team visualisation of the work we were doing. A tried and tested approach is to map out the valuestream using columns and swimlanes (very popular in Kanban). This lead to the following board:
We opted for a board that has 3 large parts. The first (red) part is about discovery and refinement. This part basically has 3 steps; Design (in the broad meaning of the word, not just UI), Refine (discuss with the dev-teams and stakeholders to make sure it’s ready) and Ready (at which point it is divided up amongs the different touchpoints, resulting in the need for multiple ‘Ready’ columns, but virtual whiteboard space is cheap :) ).
The second (blue) part is about building it into the product, this is basically a run of the mill Scrum board layout with a Todo-Doing-Done layout. It’s important to note that each team has a more detailed ‘Sprint’ board where the story lines (and other work-to-be-done) are visualised in a more detailed way.
The last (green) part is about measuring and learning what the effects of the effort was. We want to answer the question ‘(how much) did this effort get us closer to our goals’.
The granularity — story maps & story lines
Another big question regarding this visualisation was the granularity of the items to visualize. ‘User Stories’ are a useful level, but we felt that the story level granularity would result in (1) too many tickets on the board making it cluttered and less valuable as a tool for keeping an overview and (2) a big risk of reverting to ‘shopping list planning’; that’s what I call when the idea of a ‘sprint goal’ for the team gets lost and teams just end up planning a (non related/meaningless) list of stories without any overarching theme or ‘goal’.
Since our PO’s and design team rely heavily on the Story Mapping approach, we decided that main items represented on the board should be the ‘Story Maps’ (dubbed Discovery Maps) and the ‘Story Lines’. Story Line are a logical horizontal slice of the Discovery Map.
Usually a ‘Story Line’ is called a ‘release’ or ‘increment’ in the Story Mapping methodology (see figure), but we chose to rename this concept as both are loaded terms in our context.
You can look at a Story Line as a set of related stories that together strenghten a specific User Journey through the product. As such, they make quite nice ‘sprint goals’ for teams.
The items — storyline cards
To improve transparency and collaboration, it helps to have additional information regarding the things we are working on. Ideally, as an outsider, you want to look at the board & know which items are being worked on and who are Single Point of Contacts (SPOC’s) to talk to for additional information or discussion.
As a team member, you want to know where you can find additional information about the story line and if it should be done by a specific date.
Trying to cater to these needs, we came to the following layout for a card (representing a story line):
Lifecycle of a story line — how it works
The resulting board looks like this:
Since we are using the LeSS framework to some extent, the lifecycle of a story line ‘starts’ at planning. At planning, a representative of each team joins the PO’s to discuss the upcoming (2 week) sprint. Story lines are pulled into the sprint by the team representatives (moving cards from the red ‘Discovery’ to the blue ‘Implementation’ part of the valuestream). Since we established a WiP-limit (Work-in-Progress limit) on the ‘Discovery Ready’ columns, this frees up slots/spaces in these columns.
Those free slots trigger the questions: what should we Discovery/refine next to fill those ‘Ready’ slots? And who (which people or teams) should/need to be involved in making that happen?
By answering those questions, PO’s, Design Team & feature teams know what discovery work is expected to happen in the following sprint. This work will result in (new) story lines for future planning meetings.
After selection into a sprint for implementation, the story lines are implemented and measured for effectiveness. These learnings also feed back into the selection process for upcoming story lines or may even trigger the need for whole new Discovery Story Maps if important goals turn out to have been reached!
Is this working? First feedback
After one planning meeting using this format, the initial (spontaneous) responses in the retrospectives were very positive. Designers felt that this approach gave a much better view of what was being worked & what should be worked on next while the other teams clearly liked the better view of which Story Lines were ‘ready’ to be picked up. Hopefully this sentiment will remain and get stronger while we gain experience with this new tool.
But as always, this is not the end of the road but the start of an improvement process, learning as we go along. Lots of tweaks to this visualisation are (of course) possible and I’m looking forward to further experimentation together with the rest of the VRT NU team!
Reflections while writing this post
Writing this post was hard! It lightly touches a lot of very interesting and broad tools/techniques/frameworks such as ‘LeSS’, ‘Scrum’, ‘Story Mapping’, ‘Kanban’, ‘User Stories’,’Cross fountional teams’, ‘Team topologies’,…
I forced myself not to go in too much detail since that would risk turning this post into a book, but instead resorted to some links for further reading. But if readers are interested in how we at VRT NU approach some of these topics, or you have other questions regarding this post, feel free to reach out!
And of course I’m also interested as to how other practitioners have solved similar problems, please let me know about similar (or wildly different) approaches to solving similar challenges!
Eager to join us and to make the best Flemish streaming platform even better, check our joblisting.
