Trading control for great products – the Telia TV team example

Adapting to accelerating change

In a world where the speed of change seems to accelerate almost exponentially, it is only natural that an organization’s way of working must be constantly challenged and improved – especially in the highly competitive media business.

This text, which was inspired by winning an award (we will return to that), is the outcome of a joint effort between Michael Göthe, Agile Coach at Crisp, and Jens Abrahamsson, Agile Coach at Telia Company’s TV & Media Backend department. In it, we describe parts of the always-ongoing journey towards a more lean and agile way of working at the Telia TV team.

As always when looking back at a complex change process it is not possible to copy what we did but our intention is to share useful learnings, practices, and tools that can inspire you on your change journey, in your context.

Reminiscing Ye Olden Days

Let us look at the situation and our main impediments just a few years ago.

A project-centric and inflexible way of working

We had teams and worked in sprints. We occasionally had retrospectives. But the demos were few. Actually, there might easily have been months between the demos. For simple reasons:

• There was no need for continuous feedback within the projects since these were already hand shaken (probably by some random project manager) as far as scope and time schedule were concerned.
• We were usually too stressed out over catching up with the plans in the project manager’s nice-looking Gantt charts to have the time and energy to set up a demo.

Sprints out of sync

It had been decided best and most efficient that the sprints in TV team’s two main development sites (Stockholm and Gothenburg) were out of sync. This meant that a major part of the Product Owner’s work became to re-synchronize the efforts in the two departments. Nor was there any clear ownership of continuously integrating the whole product. This created a lot of waste, in most of its forms. For example, the backlog of unsolved bugs kept growing week to week.

Development teams insulated from users

Another major issue was that the development teams lacked a “clear line of sight” to the users. Market requirements were broken down to specs and handed off to the development teams who often translated this into technical changes. This, in turn, made progress very difficult to visualize. Business people and developers could not understand each other as they spoke different languages.

Water-scrum-fall

Huge projects with unintelligible requirement specifications and inflexible delivery time schedules were pushed hard onto the development teams. After the project had been hurried through the teams and reached the customers, it was hard to act on the feedback from customers, since the project was now closed, and next one already started.

Change begins

In 2014, it was decided that in order to remain competitive, the TV team would have to start on its agile journey for real. Michael Göthe and Mattias Skarin from Crisp were chosen to guide us.

The project-centric paradigm that was at the core of how Telia does it business had to be challenged! We needed to shift from an inflexible project-centric way of working into a product-centric one where a deliverable is not a huge project but rather something that brings value to the customers. It was decided that instead of having to go through the hassle of starting up a new project for every product increment, there should be ONE project “to rule them all”, acting as a host for product iterations of different sizes and flavors. This meant that we could dynamically change content in the backlog and adapt to changing priorities and still be able to work within the overall company framework.

This change was started before Crisp came onboard. Now, let us go through the main changes that Crisp brought to us!

Creating a working discovery flow:

It used to be that product decisions were taken in isolation, one at a time, by each stakeholder without a holistic view. This caused sub-optimal tradeoffs and very long lead times. To speed up the flow and to increase the level of innovation in product discovery, several activities, roles, teams, and tools were introduced.

First, it was needed to create some clear responsibilities and effectiveness for the innovation process. Discovery teams were created for the different product areas. These teams were cross-functional including Product Management, Product Owners, Usability Experts, Developers, Testers, and Architects. Other roles were also participating depending on need such as operations, HW or social media responsible. This enabled everyone to get a common understanding of the market and user needs as well as the underlying assumptions for the first time. This enabled alignment of expectations, assumptions, and priorities. Below is a cross-functional PO team in a Discovery Workshop exploring new product ideas.

Once the overall idea of a new product feature has taken shape, a Story Map is created to visualize how the different users can interact with the new feature and in which order it will make most sense building it. This work is also done in a broad cross-functional workshop. Uncertainties in the underlying assumptions are identified and prioritized to be validated as soon and A new product idea is typically staged in several possible releases. Primarily a very basic prototype or a “Proof Of Concept” in order to validate the riskiest assumptions. Those assumptions can be technical, market or user risks. Next step is to define a “Minimal Viable Product” (MVP) that can be tested with real customers. After that, there are typically several stages of enhanced functionality identified that we call “WOW features” with the intention to “WOW” the users. The story maps then input to the Product Backlog refinement sessions where the PO team and development team collaborate on the highest priority items to be prepared for the upcoming sprints.

Once the discovery work was up and running for each product areas it was time to improve the cross collaboration and alignment across all Telia TV Team initiatives. To achieve that we introduced a quarterly overall planning session that we called it the Common Planning Workshop since it covered all initiatives within and representatives from all areas were invited we. The purpose was to create a transparent visualized picture of everything that was going on within the Telia TV Team.

The outcome is alignment around a common understanding of the overall priorities. It also helps to make a forecast of the top prioritized features to be released in upcoming quarters and their contribution to the overall business goals.

But what if the capacity of the organization doesn´t meet the demands? Adapting the capacity of an organization is a slow process. So, it is important these decisions are not tied to specific features to be able to keep up the adaptability. However, having an outlook on future demands on capacity and adjust the recruitment and other strategic choices is key. For this purpose, we introduced a quarterly Business Strategy meeting.

In addition, to clarify the discovery work setup, we also set-up teams and some roles in general. Previously there was almost no explicit roles or structure. That caused a lot of frustration and misunderstandings. Further, it is very difficult to do any systematic improvements if there are no clear agreements on what is expected of teams and individuals. Also, the decision-making becomes ad hoc and often things need to be escalated when it is not clear which decisions are taken where and when. With this, we had an explicit starting position or continuous improvement work going ahead.

Real Scrum

Another area was boosting the Scrum teams. Most teams had many of the Scrum practices but none of the team had them all or understood the purpose behind each ceremony. That meant teams were only getting marginal benefits from their Scrum teams.  The teams were doing several of the Scrum practices but were not being true agile teams. Here we did some coaching to set-up the foundations for the teams and for the team members to start to understand the underlying agile mind-set.

Agile mind-set and culture

One thing we noticed in the beginning was that there was a climate of being very cautious and even some secrecy. Information was not shared among everyone. Especially low communication between the different sites. Some people had worked together for 6 years but never met physically. For agile to be successful there must be a climate of openness and trust. We want to fail fast to maximize learning. This means people dare to be open when things didn´t go as planned, people need be able to ask for help or speaking up when they don´t know. All information needs to be accessible and transparent.

By introducing the common planning workshops, more traveling, openly starting to share all information and making roles and responsibilities more explicit the climate started to change for the better. One of the goals with the agile change was for Telia TV Team to become a more attractive place to work. After one year, we did an evaluation that indicates an improved work satisfaction. 75% responded Better or Much better to the question: if the Telia TV team is an Attractive place to work? We also got the following comments: “we have better transparency and are not afraid anymore to challenge each other”, “people are no longer afraid to give feedback” and “people have more fun today.”

A culture of experimentation!

After Crisp had left the TV team, we have continued to do experiments, with the overall goal to remove the biggest impediments.

Synchronizing the sprints

Two years ago, the scrum masters and product owners at both sites agreed that it was finally time to synchronize the sprints. Collaboration has improved considerably and building teams with members on both sites is much easier.

Trading Scrum Master for Agile Coach

Because of all the change and experimentation that is going on, we decided that it is better if this is a full-time role. We came to the conclusion that if you are part developer/tester and part scrum master, you either do a sub-par job as a “normal” team member or you spend insufficient energy on the scrum master role. In practice, you usually end up in the latter situation.

Experimenting with team size

Up until a year ago, we were organized in teams of six to eight people. However, we gradually began to see that the bigger the team, the more work in progress. We also saw that a small team of dedicated developers can commit to delivering on time by fully focusing on the task at hand. Therefore, we began experimenting with smaller teams of three to four people, which we named “micro teams”.

The number of deployments in production has greatly increased since. There are many reasons for this, and the micro-team setup is one of them. The main elevator pitch for smaller teams was a shorter time to market through less work in progress and more focus, but we see other advantages as well:

• A smaller team can focus fully on a single task. This minimizes wastes such as work in progress and task switching. (A big team often ends up working with “this and that”.)
• With a small team, it is much easier to enforce MVP thinking on the Product Owner; since the team is small, it is much more obvious that the project resources are finite.
• Team communication is much easier and more lightweight compared to the situation with a normal-size team. You may not even need a daily scrum.
• Lunch plans, grooming sessions, retrospectives and other get-togethers become much easier to organize.

Removing team insulation through embracing maintenance

One of Crisp’s suggestions was to implement a Lifecycle Management development team, aka LCM, a team responsible for solving bugs affecting the production environment. Previously this was handled by a group of different individuals with little transparency to the rest of the organization. We have tried to implement this concept in a few incarnations – both within a normal-size team that worked with general “product efficiency” and as a really small team that focused on bug fixing.

Neither approach was fully satisfactory; The big LCM team was good at starting tasks but not as good at finishing. The bug-fixing two-person team started off in a promising fashion, but two people just are not enough to accommodate all required competencies.

We abolished the concept on an LCM team since it creates unnecessary waste: In order for the LCM team to be able to solve issues in the originating team’s code, a lot of handovers has to be done. This approach also insulates the originating team from the harsh realities of a 24/7 high-end television service, which in turn impacts negatively on quality; if a team is responsible for the entire lifecycle of the code it creates, it will care much more about the quality of the code, about how it is monitored in production, and about how it is deployed.

Tinker Tailor Architect Business Analyst

Before the improvement initiative started, a development team was – more or less – only involved in creating the code. In other words, there was a lot of handover waste within the value stream.

Today, we try to involve the teams as early in the value stream as possible. The team members are the domain experts, so who is better suited for creating exceptional value? We are also much more involved in the deployment, handing over to another silo in order to deploy the product makes no sense.

Learnings

• Synchronizing the sprints of all teams greatly facilitates collaboration.
• In the first implementation of the micro teams, the teams had to share testers. Testing became something you did in the end, instead of letting the QA people coach quality all through the process. Also, it prevented team building.
• Don’t overload the micro team! This is a risk with any team, but a micro team becomes overloaded much faster!
• Don’t look at maintenance as a disturbance you would rather outsource.
• Remember that the team is involved in much more than coding! Initially, the team velocity will decrease.
• Ensure effective cross-functional discovery work including perspectives from all stakeholders.

Lo and behold – an award!

In March 2017, the TV Team received the “Purple Award Customer” for, among other things, “new ways of working, enabling faster product development on the customers’ terms”. This summarizes what we have been working towards since the start of the improvement project in 2014. This acknowledgment from top management has filled the team with lots of energy and enthusiasm for the journey ahead!

The times, they are a-changin’

So, what do we see in the crystal bowl? This is what we are expecting, and hoping, to see realized over the next year:

• True continuous delivery for all new applications.
• True DevOps.
• The journey towards self-organizing teams continues.