BrazilOvercoming dysfunctions in the SAFe transformation framework
The Scaled Agile Framework (SAFe) is the world’s leading framework that supports enterprise-wide Agile change. But applying SAFe doesn’t come without its dysfunctions – Francesco Corda and Ali Hajou from BlinkLane Consulting outline three common flaws encountered in practice and how SAFe leaders can overcome them.
1) The Product Manager is not the boss of the Product Owner
SAFe enables the synchronization of Agile teams to create team of teams, therefore elevating its focus to program execution. Adopting this construct brings inevitably to the table a new series of roles that replicate the triad of Scrum at Program level. Whereas in Scrum the Product Owner serves as the content authority, in SAFe roles such as Product Management appear, with clearly differentiated responsibilities.
The focus should always be on customer centricity. Product Owners, 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 Big Picture is often misunderstood as a traditional hierarchy.
Unfortunately, it has been seen that many Product Owners lose authority and decision-making power following the introduction of the higher-level roles. Product Managers are higher level in scope responsibility, not in ranking. The more that happens, the more the Agile Release Trains become detached from the customer.
How to avoid this dysfunction:
1. Coach Product and Solution Management to transit from command and control to servant leadership style. Their main job should be 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.
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 can introduce new features and user stories, share his insights.
Product Managers and Product Owners should 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, quick customer requests, technical enablers, ideas from the team members, operations and maintenance.
2) Epics do not (only) cascade from the top
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 a strong tendency of assimilating it with a job title emerges. 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?
How to avoid this dysfunction:
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.
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 organization. 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. Managing the dependency does not increase Agile maturity
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. During this event, the main deliverables of the team of teams are visualized, together with the dependencies between the various teams.
While Program Increment Planning is a critical event to raise transparency and predictability, many organizations adopting SAFe believe that visualizing and managing dependencies during such an event is the endpoint of the transformation. On the contrary, this is only the beginning of their journey. 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.
How to avoid this dysfunction:
1. Create a strategy to increase the cross-functionality of the teams, as 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 roadmap to enable cross-functional teams starting from the current state of the organization adopting SAFe.
2. Prioritize your improvement actions as change agents (without losing the big picture). 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.
3. Let teams take ownership of future changes. 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 it has been said before, there is not such a thing as the perfect ART design.
The Agile Release Train 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.
Conclusion
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.
