Three Stages of Agile Transformation Roadmap

Many companies do not design a clear roadmap for agile transformation and take one step at a time. That can easily lead to an unclear direction and lack of motivation on the way forward because people may think that they have already been agile and the transformation is over. With clear roadmaps, it is obvious which stage we are currently in, and don’t be satisfied with the transformation results that have been achieved because the mission is incomplete, and we still need to move to the next stage.

What is an Agile Transformation Roadmap?

For small startups with only a few teams, perhaps there is no need to design any organizational transformation roadmap. But for medium and large-scale enterprises, due to many teams and complex organizational structures, all teams can’t walk in unison.

Therefore, in addition to these three steps, a general directional route is needed to pull the whole enterprise forward. The transformation strategy introduced in this article is suitable for such enterprises. Generally speaking, the agile transformations that companies go through follow this route.

Stage 1: Small Team Agile

Agile Team Size

Team-level agile refers to agile transformations in small teams of 5-9 people. Most companies that want to try an agile transformation generally start by selecting one or a few sections to pilot. Each team delivers the product independently and does not necessarily need to be connected to each other. Once the pilot is effective, the organization will often continue to expand the scope of the agile transformation and encourage more teams to join the agile camp.

Team-level agile practices are generally the following:

• TDD (Test Driven Development: Test Driven Development)
• Scrum or Kanban method
• Continuous Integration
• Emergent architecture design
• Domain Driven Development
• BDD (Behavior Driven Development: Behavior Driven Development)
• Automated Testing
• Pair Programming

If a single agile team can release a product independently, they may further experiment with engineering practices such as:

• Automated Operations and Maintenance
• Microservices
• Continuous delivery pipelines

However, for large projects delivered collaboratively by multiple teams, even if each team works on agile practices, you may not see significant benefits and results for the entire project. Because large projects are concerned with the efficiency and quality of delivery of the whole release and product, teams need to work together to deliver the entire product.

At the same time, every team in the process of trying agile is bound to encounter some project processes, management, and collaboration styles that conflict with agile and constitute shackles for the team’s efficiency, which is outside the scope of what the team can change.

Agile Case Study

A product line of a communication company has three Scrum teams in its bottom protocol communication department, and each of them has been practicing Scrum for a year, and each team has built a CI (CI: Continuous Integration) system and started automated testing.

In addition, the single board software layer, which is on top of the system architecture of the product, is delivered by another department, and they have 6 Scrum teams, each of which has been trying Scrum for a few months, also practicing CI continuous integration, automated testing, TDD test-driven development, pair programming, and other technical practices. These 6 Scrum teams obtained the protocol communication code from the 3 Scrum teams of the underlying protocol communication, integrated it with their veneer software code, and released it as a veneer software as a whole.

Since these 6 Scrum teams depend on the three underlying protocol communication teams, one of these nine teams is missing in the project organization of the entire product line if they are to deliver a product of value to the customer. Nothing provided by anyone Scrum team alone generates value on its own.

The teams were running Scrum on their own, but there was no unified mechanism for synergy and alignment with each other to operate, and each Sprint had Team A of the upper veneer waiting for a component from Team B of the underlying protocol to be ready, resulting in a delay in Team A’s delivery.

The product line measured the TTM (TTM: Time To Market cycle time) before and after the Scrum pilot, and although every team was doing the agile transformation, the TTM of the whole product was not significantly shortened.

For such an organization, there is a need to evolve to a higher level of agile: product-level agile.

Stage 2: Product Agile

In a typical medium or large-scale enterprise, a product idea may go through the following stages from scratch until it goes to market.

This process spans multiple departments: marketing, product, R&D, design, production, sales, and operations. For those products with integrated software and hardware, it also requires pulling software projects (or groups of software projects) through with hardware teams to align the delivery cadence to ensure the success of the overall product.

Mary, a lean software guru, has proposed eight lean software development principles, one of which is the principle of global optimization: Only by reforming the entire value creation process, eliminating wasteful links, optimizing the whole value stream, and improving the efficiency of the overall value flow, can we maximize the efficiency of the organization. Therefore, only by moving up from team-level agile to product-level agile can we observe the whole cycle from the customer’s perspective: starting from the presentation of an idea or feedback until it is delivered to the customer, and how to accelerate the process.

Product-level agile is a transformation that takes the entire product value stream as a unit. Product-level agile focuses on a very different perspective than team-level agile. Team-level agile focuses on individual teams’ efficiency, quality, and morale. Product-level agile focuses on TTM (Time to market) reduction of a product or each version of a product and aims to connect the upstream and downstream of the product value stream, integrate the interdependent teams into the same agile framework, adjust the organizational structure when needed, and let each team in the value stream collaborate to deliver, minimize handover and waiting, and remove This will reduce the TTM and improve the quality by shortening the quality feedback time of the product, and ultimately improve customer satisfaction.

Agile Case Study

After conducting product-level agile in the previous case, the communications company applied SAFe (SAFe: Scaled Agile Framework) to break up the underlying protocol team and re-integrate it with the upper veneer team to form a dedicated feature team, thus maximizing the removal of dependencies between them.

Then, applying SAFe’s ART (Agile Release Train: Agile Release Train) mechanism, each Scrum team is included in the ART agile activities, collaborating to plan, aligning the pace, and collaborating closely to deliver, instead of each Scrum team intertwining dependencies and fighting alone.

Agile Product Management Practices

The basic practices of team-level agile provide an excellent foundation for product-level agile. Once you get to product-level agile, team-level agile practices must be solidified. Beyond that, several Agile and Lean practices at the scale are typically attempted across the product spectrum:

• Value Stream Mapping (VSM)
• Lean Kanban approach (Lean Kanban)
• Project Portfolio Planning and Management (Portfolio Planning and Management)
• ART (ART: Agile Release Train) organizational structure and its processes
• Scrum of Scrums

And engineering practices:

• Trunk Development
• Microservices
• Continuous Delivery Pipeline
• DevOps

In many organizations, the worst waste is not in the product creation process but in many products or features that are inherently worthless or of very little value. These products or features should never have reached the second step in Figure 3-2, “forming requirements,” and should have been killed at the idea stage. However, many companies are still doing products with the idea of “the more features, the better” resulting in many low-value products and worthless requirements. Therefore, product and marketing departments must embrace the lean mindset and transform to “less demand, more value”.

Agile for Startups

It is important to note that not every enterprise needs to go through the two stages of team-level agile → product-level agile. In many startups, a single Scrum team can cover the whole value creation process, so such companies do not need to go through the two steps of team-level agile → product-level agile. However, for large product lines with hundreds, thousands, or even tens of thousands of employees, completing the value creation process of a product requires the cooperation of multiple departments or teams, which generally requires going through the team-level agile – product-level agile phase.

Even for non-startups, another transformation strategy can be used: start the top-down transformation directly from product-level agile without going through team-level agile. Specifically, companies pilot the transformation with the entire product as a unit. From the first day of the transformation, all the upstream and downstream teams involved in the product value stream are included in the agile transformation, the organizational structure is adjusted, Scrum teams are formed, and agile thinking and practices are introduced.

The advantage of doing this is speed. Cutting directly from the product level covers many areas and allows management to see changes immediately. But the prerequisite to adopting such a strategy is to ensure that leaders dare to decide to transform the entire product-level organization-wide. In addition, there should be enough agile coaches, and the coaches should not only go deep into each pilot team for coaching but also invest in coaching and promotion at the whole product level. Otherwise, all teams at the whole product level will start agile simultaneously without knowing how to do it, and the chaos will ripple widely and take a long time, making it difficult to produce results.

Stage 3: Enterprise Agile

What is Enterprise Agile Transformation?

Mike Cohn believes that departments and teams involved in product development or manufacturing are already part of the agile transformation process. In addition, support departments such as HR, administration, finance, marketing, sales, etc. They should also be included in the scope of agile transformation. It is not that these departments need to carry out agile activities themselves, but that their existing processes should not contradict agile. Otherwise, they will become the gravity of organizational transformation and slow the pace of organizational transformation.

Agile Transformation Examples

A server in one of the product lines of an enterprise needs to be expanded. To apply for a high-capacity server, the procurement requires a seven-level approval process, and after the approval process is completed, the procurement will take at least three more months. Therefore, it takes at least six months from the application submission to the server’s receipt. Such efficiency is a serious drag on product delivery efficiency.

In situations like this, it is necessary to make changes in these support departments, using the business teams as their customers, looking at the efficiency and working style of the support departments from the customer’s perspective, and considering how to improve the agility of these support departments.

This phase is called enterprise-level agility.