Achieving Agile mastery

According to the latest Business Agility Report (2020) the global pandemic has resulted in the largest pivot since its recorded history in how organizations operate. It has shown us that uncertainty and unpredictability impact our organizations on a daily basis. Customers’ expectations continue to evolve, and employees seek more meaning and clarity in their work to be engaged. More than that, organizations had very little time to adjust to the new modus operandi. The need to transform towards a state of “Business Agility” becomes stronger and stronger. Simply said: the world changes, we change. And not as a strategic theme for the upcoming 5 years, no, we change our modus operandi immediately. As a matter of fact, more organizations are commencing their transformational journey, and those already on that journey have shown a 9% increase in Agile Maturity (2020, Business Agility Report).

On the wave of this steady trend, the Scaled Agile Frameworkis still the dominant language for adopting enterprise-wide Lean and Agile in the market. As the 14th Annual State of Agile Report states, SAFe has gained 5% of the market share year-on-year, outdistancing the next nearest response Scrum of Scrums.

However, applying a framework does not mean gaining substantial business outcomes, in fact, far from it. Despite its popularity, SAFe receives criticism from the Agile community as an all-encompassing and heavy-weight operating model that is too prescriptive and fails to deliver real change.

In our opinion a framework becomes a way to learn the language of a new operating model. This means that the operating model still has to be uncovered by following the guidance, inspecting the progress, and adapting the practices. A framework such as SAFe is therefore a way of not having to invent the entire journey towards Business Agility. As a matter of fact, since the framework is frequently adjusted to incorporate the learnings of implementation best-practices, those following the framework are inherently learning from approaches and mistakes from other enterprises. However, at the end of the day, what matters most is how the framework is applied, based on the context of organization that is adopting it.

Over the last years, Highberg has noticed several challenges that repeatedly – to varying degrees - come up when applying SAFe. A common thread strongly emerges; organizations need to be aware that implementing SAFe is never the goal, but obtaining significant business outcomes is. Applying values and principles and changing the culture and mindset of the organization are the real gamechangers behind successful SAFe transformations.

Here in this article, we address the three most common challenges experienced by Highberg across various SAFe transformations, in different industries. Our goal is to help leaders and change agents to avoid them and significantly improve the effectiveness of the transformation towards Business Agility.

Stop searching for hierarchy!

SAFe enables the synchronization of Agile teams to create team of teams, therefore elevating its focus to program execution. If the solution is too complex to be addressed by 5-to-12 self-organizing, cadenced and synchronized teams, another visual layer is introduced within the framework called the Large Solution layer.

Adopting this construct brings inevitably to the table a new series of roles that replicate the triad of Scrum at Program and Large Solution level. As shown in the picture below, whereas in Scrum we find the Product Owner as content authority, in SAFe roles such as Product Management and Solution Management appear. The roles therefore have their own ‘sphere of influence’, which might overlap occasionally, but have clearly differentiated responsibilities.

SAFe provides a clear idea on how these roles should be organized and interact with each other.

The focus is on customer centricity. Product Owners, as representing the voice of the customer, should be the foremost leading roles in what delivers value and prioritizing use cases. Yet, given our mental constraints that have been nourished in more than 50 years of traditional practices and hierarchies, the layered visual representation of the SAFe BigPicture is often misunderstood as a traditional hierarchy.

It has been acknowledged that in large organizations there is a strong tendency to automatically match the current hierarchy of roles with the governance suggested by SAFe. For example, the Product Manager is a more experienced and skilled person than the Product Owner. When scaling up and setting up a solution train, the Solution Manager enters into play on top of the Product Managers. That is not necessarily wrong, but it can be perceived as adding an additional level of managerial hierarchy. It makes sense to have a competence-based governance to align the various stakeholders and contributors in delivery. Unfortunately, we have seen many Product Owners losing authority and decision-making power following the introduction of the higher-level roles. Product and Solution Managers are higher level in scope responsibility, not in ranking. It often occurs that features in the Program Backlog from Product Management are the sole source of new product development. The more that happens, the more the Agile Release Trains become detached from the customer. In these cases, the ART does not embody customer centricity, but lives up to “Product Management Centricity”.

1] Coach Product and Solution Management to transit from command and control to servant leadership style

Product and Solution management should be supported in such a way that they change their mindset and become – as explained by as Robert G. Greenleaf in his book - servant leaders for all the Product Owners in the train. Their main job is to raise transparency of the vision of the product, share information about market trends and create alignment and cohesiveness among all the ideas that come up at product level. The great Product Managers are those who leverage on the collective power of the product ownership team, without harnessing their accountability to add value to the customer. Through clear accountability, the authority of the Product Owner as voice of the customer needs to stay in place.

2] Emphasize the “round tables” metaphor

As it happened at King Arthur’s court, Product Management needs to keep clear accountability of the prioritization of the program backlog even tough every Product Owner at the table has the ability to introduce new features and user stories, share his insights. Product Managers and Product Owners cooperate as a team together. Product Management needs to allow Product Owners to work together to interact with customers to maximize the value of their own team backlog without losing the big picture.

3] Setup clear policies to manage the different backlog layers

There should be clear policies to manage the different backlog layers. New Features from the Program Backlog should not solely occupy the capacity of the Agile Teams, nor the content of the Team Backlogs. Product Owners need to be able to give space to unforeseen items, technical enablers, ideas from the team members, operations and maintenance. Nobody, not even a Product Owner, is able to ‘take responsibility’ for a product while simultaneously being forced to be fed new work that has to be included unquestionably.

Mom, where do epics come from?

The Epic Owner is another role that is often misunderstood within an Agile Transformation. SAFe visualizes the role at the top of the framework, in line with the Portfolio level.

When pitching the responsibilities of this role we have noticed a strong tendency of assimilating it with a job title. At least, a common belief that an Epic Owner needs to be a highly influential or a senior person in the traditional setup of organization. It is usually represented by a departments’ heads and directors. Essentially those who are traditionally in charge of ideating large initiatives.

Again, that is not necessarily true. SAFe makes it very clear that Epic Owner is a role, not a job title. Moreover, an Epic Owner is a person that understands to take a few steps back with their own change initiatives is sometimes necessary to prioritize other urgent or valuable Epic candidates. If we rebrand silo-oriented project managers to Epic Owners, then why do we expect that they all-of-a-sudden start making customer-oriented decisions that might not be related to their own Epics anymore?

1] Bring awareness at company level that anyone, literally anyone, can become an Epic Owner

Eric Ries states in his brilliant book “The Startup Way” that entrepreneurs are everywhere and “organizations that wish to transform towards agile way of working must give every employee the opportunity to be an entrepreneur”. The link with SAFe transformations can be found in the role of the Epic Owner.

In fact, a good Epic Owner needs to collaborate on the Epic with multiple actors on the initiative proposed. This is supposed to be one of the most fluid roles within the enterprise. From team members, to Product Owners, to sales assistants, organizations need to allow all voices to be heard, and then judge ideas and initiatives using Lean Portfolio Management. But if you decide to be an Epic Owner; it becomes your responsibility to shepherd an Epic through the pipeline (i.e. Portfolio Kanban).

2] Adopt Design Thinking to leverage on bottom-up ideas and create an environment in which use cases can be pitched by everyone in your organisation

Organizations need to enable the conditions to reveal internal innovators. Design Thinking workshops can be a useful practice to make innovation emerge while keeping it aligned to the strategic drivers of the organization.

The workshops should be designed in such a way that a multi-disciplinary and diversified team of people participate. Put together people with different expertise, gender, age, seniority. It’s through these events that a passionate and enterprising Epic Owner can emerge, obtain visibility and create value.

3] Enable your Innovation Accounting system

Organizations should enlist a series of entry requirements to conduct a fast screening of ideas, and through LPM, establish an epic committee. This refers to what we call within the Continuous Innovation Framework, designed by our colleague Arent Van’t Spijker, the Innovator and Continuous Innovation Board (CIB).

The objective of this board is to check if the pitched idea corresponds with the organization’s strategy and priorities, and then, validate that time and resources are spent on the most valuable initiatives.

These initiatives should then be supported through innovation accounting: a new accounting system that evaluates progress of seed-stage ideas when all the metrics typically used in established organizations (e.g. revenues, customers, ROI etc.) are not applicable. The CIB has the objective of managing lean budgets based on how fast the new ideas grasp market feedback through a series of experiments about their feasibility and/or value hypothesis.

Do not only manage dependencies, solve them!

The Program Increment Planning event is one of the most distinctive elements of SAFe. This two-day big room event allows for large group of people (50-120) to align and plan together for the next 10-to-12 weeks.

One of the main outputs of the event is the Program Board. A Program Board is a large tactical chess board. It helps to manage delivery risk by understanding the knock-on effects of delays, dependencies, and deliveries.The main deliverables of the team of teams are visualized, together with the dependencies between the various teams.

The program board is one of the most effective tools that can be brought along during a transformation. Yet, many organizations adopting SAFe have not fully grasped the principle behind the application of this artefact. If you have seen such board to be developed during the PI Planning and completely neglected until the next PI Planning, then you know what we are talking about. To leverage on the full power of an Agile Transformation the main driver should be eliminating the dependencies between the teams in an Agile Release Train.

Such a thing as the perfect ART design does not exist (this is a topic for another article all together). In addition, some dependencies have a positive effect on the train health. However, we believe that starting from the first PI Planning a good use of the Program Board can be done by iteratively adapting and evolving the design in order to reduce the number of red strings to gain major effectiveness thanks to teams’ autonomy and independence as value production machines. Whereas the objective is to create stable, long-lived teams, it is inherently accepted that during the first 3-to-4 PIs the ART design will be refined towards a more optimal solution.

All scaled agile set-ups are strictly dependent on the context. Sometimes it is easy to put in place already high performing teams of cross-functional teams. Some other times, over-specialization and resource scarcity makes it impossible to achieve efficiency and productivity benefits immediately. Depending on the context, it might be necessary to form component teams; teams that are dedicated to one specific technological stack, system, rather than a customer/end-user facing product.

In these cases, change agents should have a pivotal role in using the program board as input to establish a real strategy to increase cross-functionality inside the train. Who to include in the development of the strategy; how about the people that do the work. Collaborate with the value deliverers from the agile teams to understand bottlenecks, understand flow metrics, and brainstorm about the activities to be done to have more teams with an ability to deliver value with minimal dependencies with other teams.

LeSS helps us to visualize the different phases in which that can be achieved. It gives us a roadmap to enable cross-functional teams starting from the current state of the organization adopting SAFe.

Here an example related to the journey undertaken by Agile teams in a Telco organization from being component based to become feature teams, autonomous in the production of value.

2] Prioritise your improvement actions as change agents (without losing the big picture)

Once an Agile Release Train is running, changes need to be planned and prioritized carefully. A radical change in the ART design will be likely to provoke too strong disruption on productivity and mental balance of the people involved.

Change agents should therefore identify a sequence of small improvement actions dedicated to achieving the maximum benefit with the less transformation effort. Our tip therefore: upon launching your ART, already plan and communicate a date six months from now where the ART design is going to be evaluated collectively using empirical data of the last six months. You are welcome!

By exploiting the Program Board as a leading indicator, change agents can visualize and prioritize improvements in re-design by addressing first the teams that suffer the most from a high number of dependencies. Successive improvement steps in the ART design will apply the same logic.

Lastly, it is the change agents’ responsibility to make sure that the RTE, Scrum Masters, and the team members understand and think about any dependency-problems. That is vital to avoid that the change agent becomes an ivory-tower manager, and to retain the big picture without incurring in sub-optimal optimizations.

3] Let teams take ownership of future changes

Change agents can have a pivotal role in the first ART design. It is best practice to simulate several ART designs during the launch of a new ART. However, once the ART is running the same group of change agents should give more space to self-organization and autonomy of the teams of teams.

By leveraging on retrospectives, Agile teams are the best ones to know how to improve their own set up. Only in this way the ART will be able to adopt relentless improvement mechanisms in later stages of maturity. As we said before, there is not such a thing as the perfect ART design. The ART and its surroundings will constantly be evolving towards the equilibrium. Change is inevitable and self-organization and adaptation are the tools that will guarantee to always be in an optimal design.

The idea of business agility is to have self-organizing teams of self-organizing teams that require an understanding of the environment, stakeholders and the impact of their decisions upon them. To do that, organizations need to achieve transparency - in both product and process - and the ability to make changes and decisions accordingly, hence decentralize decision making.

Simply applying SAFe does not necessarily means achieving agility. Organizations that are seeking to achieve real business outcomes through an Agile way of working need to direct their efforts towards understanding the principles behind every transformation action.

By creating a network organization, enhancing inclusiveness of bottom-up initiatives and focusing on creating teams autonomous in the production of value, companies will be able to apply SAFe to achieve a customer-centric and adaptive organization. As a consequence, that will lead to better business outcomes.