Transversal Agile Scaling

Deezer is an audio company. Our goal is to fill your life with sound. Pretty ambitious, right? If we want to achieve it — to quote Carl Anderson — “it’s about processing work in a way that balances the company’s competing needs and requirements in order to deliver the best final value to the customer.” In other words, understanding and adaption are key elements to moving forward towards a relevant and top-notch experience. The main question is: how do we get to it?

Alignment.

We’ve been working to provide an in-depth vision of Deezer’s strategy to every individual in the company. The big plus is that everyone is now contributing towards it. The purpose is to get all teams on board around a shared vision. It’s obviously easier to engage with motivated co-workers than to coerce skeptical ones.

An inclusive way of working

A master plan

It all starts with the top management taking part in strategic planning. Executives come up with initiatives, i.e. the master plan to achieve their corporate mission. Nothing’s set in stone and this plan may change to meet the evolving market demand. This allows us to prepare each quarter and share our plans for Deezer to the whole team.

We use a simple matrix to make quick decisions about what we should focus on:

The team evaluates each initiative weighing implementation and development constraints against its impact and added value. The impact/effort analysis allows arbitration: multiple options are prioritized thanks to rational reasons.

However, remember things can change and we may have to adapt. Even if we’re planning three months ahead, we’re constantly challenging the matrix to do the right thing at the right time.

Team level

Teams self-manage and self-organize to deliver. It’s all about collegial work. Product owners provide input matching both the product vision and roadmaps while developers help estimate stories, identify spikes, dependencies and any missing story. Eventually these initiatives are sliced into versions with defined release dates. This part of the work is done as early as possible to make everyone’s workflow smoother. At Deezer we want to start building each product in a tangible manner.

In « Making sense of MVP » Henri Kniberg elaborates on what should be a truly iterative and incremental development in opposition to a « Big Bang Delivery », meaning this…

© Henri Kniberg

instead of…

© Henri Kniberg

Here the aim is to focus on users’ expectations and needs. It’s a try and learn approach: test something smaller than expected, gather feedback, then improve your product until you achieve a cool result. Remember there are three stages of maturity to every product:

Testable: grab it and play with it knowing there’s still a lot of room for improvement.

Usable: the service offered is satisfying and really matches your needs, you can consider using it daily.

Lovable: awesome, it’s a game changer.

A goal oriented roadmap

We mix the MVP approach with the Go Product Roadmap of Roman Pitchler. It provides a straightforward way of visualizing each increment with key details such as goals, scopes and expectations or KPIs. It has the advantage of being a meaningful and easy-to-read medium for anyone.

We talked about vision, product definition and execution. But how do we get there?

Quarter Planning

In 2017 we wanted to empower teams and remind them that building Deezer’s products and features concerns everyone. That’s why we booked a day and a half to gather everyone — developers, product teams, designers, executives, QA analysts — and threw a quarter planning, aka PI Planning in SAFe. The event allowed us to create a link between the three main levels of planning (we do not consider the Value Stream here) in SAFe:

  • Portfolio, embodied by strategic intents and vision,
  • Program, the vision is sliced into projects,
  • Teams, they are self-organizing (Scrum, XP, Kanban…) and have a clean and prioritized backlog.

We’re in this together’ — Nine Inch Nails

As mentioned before, alignment was the #1 objective of our quarter planning. We talked about vision, product and features, teams and management.

It is important to hold such an event to catalyze team work, align and create movement before the quarter actually starts.

The white paper Hubert Smits wrote, « Five levels of Agile », helps us understand what are the inputs and outputs to tackle a quarter planning in the best possible way.

Inputs

  • Product vision is where we want to be in the future in terms of features and as differentiators, in an elevator pitch way in order to keep it simple (and not too detailed if we need to adapt to a market change later for instance).
  • GO Product Roadmap exposes a deeper vision with product managers & owners identifying requirements, drawing a first timeline and prioritizing features according to their complexity.

Outputs

  • Release plan: now that we know in which direction we’re heading, it’s time to define each feature release, i.e. scope and release date. We mitigate potential risks and dependencies that may block the teams concerned.
  • Sprint plan: the product owner sets the highest priorities in terms of stories while the development team asks any questions they may have. The two main outputs consist of defining a sprint goal and building a clear sprint backlog. The goal is to drive away any possible ambiguity.
  • Daily commitment and self-organization are key. Enhanced cooperation and communication within teams, notably through daily meetings, are necessary to reach the objectives set in sprint plannings.

Bringing it together

One last thing: it really is a no brainer to share, build products and get everyone’s curiosity, feedback and involvement.

Now that you had an overview of the way we build things at portfolio, program and team level, we’ll conclude by highlighting that communication and coordination are catalysts of a great workflow. We have not reached perfection yet but we want everyone to work with a lean approach.

There’s always room for improvement, the main pitfall is to be stuck and remain passive.

We’re all learning, why don’t we share best practices?