Agile transformations in large enterprises

Agile transformations in large enterprises

To conduct an agile transformation within big companies remains challenging. In fact, not every part of the business has the need to act in an agile mode. It definitely makes sense in companies producing digital services, such as mobile apps, TV services or anything else that can be consumed digitally. In production companies (automotive or industrial) there are limits, since you cannot manufacture the shell of a car in agile release trains (technical and legal feasibility). It might be different for an infotainment system, especially if you think of over-the-air updates in recurring release cycles to have your car up to date even after 5 years of usage.

For telecommunication services providers, there is no doubt that the IT department can adopt agile methodologies. The network side is usually the one struggling the most with the adoption, because network functions have not been virtualized in the past. Of course, they would benefit from less silos with a DevOps approach when those functions become software. However, with NFV/SDN there are many more changes besides the virtualization part: The organization (reporting lines), roles and responsibilities.

Changing a culture is tough, especially if the organization has a lot of conservative managers who tend to think in hierarchical structures, rather than focusing on where the customer value is flowing. The discussion ends up in politics and around who is in charge of what with the result of drawing an org chart that has agile teams. This will not lead to increase customer value, but rather puts the focus on internal matters. Inevitably, the product and its value proposition is not fulfilling the needs of the customer anymore. The organization will make itself obsolete.

Now, the Scaled Agile Framework (SAFe) and Spotify with their own model of tribes give us reason to believe that even traditional companies will eventually change towards a value-driven organization structure. It’s actually pretty funny to obeserve when C-levels and managers express how much they want to have the Spotify model or some sort of agile transformation. You cannot simply copy their model to your organization. Spotify had different challenges back then: They were exponentially growing, trying to figure out their business model and they only had one digital value proposition. I highly doubt that Telcos face similar challenges.

Another important difference is that Spotify didn’t have any legacy in terms of infrastructure and resources. They built a digital product from scratch.

If you have not checked out Spotify’s original two videos on how they manage agile teams, check it out on their website. It is worth watching, because it shows how a born-on-the-cloud company manages the above described challenges and how they focus solely on customer value creation.

However, Telcos can adopt similar ideas and concepts that Spotify utilized. There are a few Telcos which already adopted the SAFe framework and many trying to move away from hierarchy models.

However, leadership and management will be even more important in the future, because they are are responsible for communicating a vision and the customer problems to solve. They are the factors to move agile teams and inspire them to work as a entrepreneur.

Agile teams in their self-organizing manner find solutions to those problems. If the organization is just relabeling their business units, they are not seizing the advantages of agility: no cross-functional teams are created and silos are still in place.

When starting the transformation, the goal should be to improve time to market, increase release cycles and deliver more value solely for customer. But how to start such a transformation?

It depends. There are several approaches depending on your companies current state as well as the willingness to change.

(1) Evolution: I recently found a very interesting framework called “The OS CANVAS”. Basically it captures the current state by putting the stakeholder’s pains into 9 fields and subsequently add a desired future state. Prioritize based on the feedback you get during a 1-day workshop and start focusing on quick wins. Check the author’s book on how to reinvent your organization based on this assessment. If you are not eager to try new things, I propose using SAFe for an evolutionary approach.

(2) Greenfield: This approach may be fitting for you if you want to found a new legal entity, not for the sake of agile, but if you plan to build a new digital solution. This pilot company can serve as an incubator and blueprint later on for the main organization. Since this is the case for just a few companies, I will focus on adopting SAFe in an evolutionary approach.

Adopting SAFe

SAFe recommends to start small by adopting what they call “Essential SAFe” that comprises the (agile) team layer and the program layer. This addresses a team of 80 to 125 people, usually around 1 product or platform. At this layer the notion of an agile release train (ART) is used to describe the value flow towards a product increment. Think of it like a train that collects Sprints from every agile team in order to deliver value for the customer every 6 to 12 weeks. Spotify uses this for product increments as well, sometimes they even release features that are visible to only a small group of customers to apply A/B testing methods. To a group “A” of customers the feature is shown in a different way compared to the group “B” of customers. They then collect customer feedback and adjust accordingly.

SAFe uses the illustration of an architectural runway on which new features arrive to be integrated. One of the main objectives is to increase reliability of value delivery of the release train. This can be realized by having a small team including a system architect that builds this runway. The runway produces working code. Enablers build the runway and Features consume it.

To put into more practical words: A new system release might be developed and will land on the runway, which needs to ensure a safe landing (e.g having a shared database in place that fits the new release or a code skeleton) and is just enough.

Enablers are the activities to extend the runway, they are technical initiatives, such as building the appropriate testing and development environment at infrastructure level.

The Agile Release Train is cross-functional as well as it creates a virtual program with the following roles included: Commercial oriented stakeholder, product management, architecture, program management, hardware, software, deployment and testing. All sit together to plan the product increments, where management sets the vision and the teams create the plans.

Once you defined your release train, the cross functional teams have a plan on the timing schedule (release cycles), you can move towards the portfolio layer.

For further reads on agile transformations, you might check out the books I read when dealing with customers who started their agile transformation journey.

Books to read on applying Agile

  1. Rethinking Agile (EnglishGerman)
  2. Applying The Scaled Agile Framework (EnglishGerman)

Leave a Reply