We recently published a series of posts on key success factors for technology-enabled business transformation projects (Part 1 and Part 2), as well as on end-to-end mindset, which triggered some discussions with clients. Through this, we learned about some heavy struggles they faced when adopting agile ways of working in any large-scale technology-enabled transformation.
Therefore, I felt it was necessary to take a step back and focus on some fundamentals that need to be in place for Agile to deliver its expected benefits.
Common Organizational Mindset Shift
The Agile Manifesto was born at my favorite ski resort, Snowbird. It’s been my yearly ski trip for about 20 years, right around the same time Agile was conceived. By the way, it does have the greatest snow on earth!
While Agile promotes self-organizing teams and empowerment for teams to drive and take decisions, first and foremost successful teams require an agile mindset. This is not a “Yoda thing” but centers around walking the talk, being collaborative and transparent as well as learning from successes and failures quickly.
We often encounter companies implementing agile procedures and practices (“doing Agile”) while disregarding the change management aspects of instilling agile mindset, values and principles among their teams (“being agile”). A truly agile team requires a new form of (“servant”) leadership, leading with context instead of control. Such leadership needs to be comfortable with handing over decision making power to the people closest to the content. We consistently make the experience that leadership experienced in delivering waterfall projects requires significant enablement trainings on agility.
Organization & Governance
Agile is not a license for the team to “just do it”. Especially in large-scale agile environments, a strong governance framework with well-defined roles and responsibilities is required. In addition, it is paramount to empower the people driving the agile roles, to excel at their jobs:
Product Owner
The product owner needs to have a clear vision of the direction (NorthStar) and lead the team and each activity (sprints) towards it. At the same time, the Product Owner needs to manage stakeholders to reduce different pulls from competing business priorities.
Scrum Master
The Scrum Master and the Product Owners need to be joined at the hip to plan and drive the team in time-synchronized sprints (time boxed increments delivering pre-defined and tangible outcomesd) to ensure a timely and integrated delivery. The Scrum Master needs to take into consideration the simultaneous moving parts ; dependencies to parallel initiatives or teams can be managed on a sprint-by-sprint level, with interim milestones serving as integration points.
In our view, the Scrum Master must have a background in the respective domain and technology being implemented – we often see companies hire platform and process agnostic project managers as Scrum Masters, which can often lead to disaster, especially in Pharmaceutical/GxP-regulated environments.
Chief Scrum Master
Scaling agility (reference: SAFe) to large business transformation programs adds complexity as it requires continuous harmonization in ways of working as well as mature integrated planning driven by the Agile Delivery Teams, and orchestrated by experienced Chief Scrum Masters (ideally people with rich integration management experience). This role is a key enabler in ensuring the delivery teams apply a systematic thinking and end-to-end mindset to their work.
Agile Delivery Teams
There are two basic skills, business analysis and development. These need to be able to translate the NorthStar of Product Owner/Scrum Master to a “show and tell” of the solution. The effectiveness of the team will depend on if the members’ dedication (know-how of the solution and process well) or floating (jump from one process/solution to another). In general, the more dedicated the members are to the process/solution, the fewer iterations will be required to build, test, and deploy the solution.
Quality, Demand Management and Documentation
Often, we think Quality & Demand Management and Agile are oxymorons. We attribute quality, testing, and planning as a bottlenecks, and slowing things down. This is far from the truth. What slows things down is poor requirements, testing, impact analysis, and lack of upstream/downstream planning. So, the devil is in the details when it comes to Agile, and embedding quality assurance procedures as part of the regular sprint structure is advisable, especially in a Pharmaceutical & Life Sciences environment.
In general, documentation should be reduced and not a major artifact with Agile. However, for regulated industries, this is not the case. On the contrary, this needs to be well defined with strong guardrails. Modifying or creating new guidelines midway through simultaneous sprints will result in a lot of self inflicted rework of documentation that distracts from the benefits of Agile. And don’t forget the frustration of the team members.
One size fits all vs Fit for purpose
If all the fundamentals are not in place, achieving Full SAFe® will be very challenging and there is a high chance of failure. Or there could be waterfall approach that is disguised as Agile by means of simply using agile terminology.
Naming a meeting as a stand up, does not mean Agile is being lived. If a stand up becomes an hour or more or a sprint is taking months without any delivery then this needs to be challenged. So, does this mean it’s all or nothing? No, there is a middle ground, which we call Hybrid Agile approaches. We usually build such hybrids as interim states into the transformation roadmap from waterfall-run to fully scaled agile organizations, allowing for the shift to take time and letting the people grow towards it.
Programs that try to force feed Agile with training sessions and reorganization for large complex organizations should be questioned (evolution vs revolution). The heart of any organization is the diversity of the people and the importance of leading each one towards Agile should not be underestimated. Agile is not plug and play. We have tools and frameworks to help you with your readiness and work towards Agile in a practical matter.
Avoras Agile Offering
At Avoras, we are involved with Agile transformation for large complex organizations in Pharma and Healthcare. Our DNA is to listen and be your independent sparring partner, designing a tailored Agile transformation journey to realize your business values. Contact us to learn more.
