By: Darrell Ponzio, Senior Director
An organization’s adoption of the Scaled Agile Framework (SAFe) is often aided by an implementation partner. On-site training is almost certainly provided to the team members involved in the transition and a heightened sense of modernization and buzz abounds. There is a lot of nervous energy mixing with a willingness to “give this a try…”, and teams are often newly created to coincide with this changing landscape.
The organization’s employees find themselves digesting a breadth of new concepts and terms while translating their ‘normal’ work-life routine into agile inspired themes and concepts. Agile Release Train (ART), Value Stream, Epic, Program Increment (PI), Feature, Sprint, Story, and Scrum flood the teams who now must also adopt and adapt to new roles such as Business Owner, Product Owner, Scrum Master, and Release Train Engineer, among others.
The Glow of Agile
During the first months after implementation of agile delivery, daily stand-ups, sprint planning, and sprint reviews quickly structure the workweek. While training is still fresh, team members involved in sprint execution tend to work cohesively and collaboratively, enjoying a whole new way of delivering business value, basking in the warmth of attention from curious senior leaders, and sharing the responsibility to remind each other of the tenants of agile.
As the team moves into its next phase of existence, a false sense of comfort can pervade. Attendance in sprint meetings (I mean ‘ceremonies’ – they’re ceremonies now) begins to wane. It is often Product Owners (POs); those team members pulled from their comfort zone and are now responsible for defining stories and prioritizing the work, who go missing. This is damaging for a few reasons. First, a healthy, well-groomed backlog is the fuel that drives a fully utilized scrum team, and this cannot exist without a fully engaged Product Owner. Without a healthy funnel of prioritized work, team efficacy is lost. Second, the skills required of a Product Owner and the role itself are likely new for the incumbent. Without practice, those newly learned but perishable skills will become stale and eventually atrophy.
There is No Pixie Dust
Why do teams lose the focus and attention of their Product Owners? Typically, the finger is pointed at either a mismatch of the person’s skills to the new role or to work outside the scrum team that the person retains which draws time and attention away from the Product Owner’s new responsibilities. Consider this anecdote: people are good at what they love and love what they’re good at. The typical Product Owner is a business manager or leader who is a passionate expert in their business. Throwing those people into a few training classes, possibly obtaining POPM certifications along the way and then throwing them onto scrum delivery teams does not suddenly transform them into agile evangelists. There is no pixie dust – a new good/love relationship is not guaranteed. The awareness and energy that comes with a good agile training class will fade quickly in the weeks after a newly minted Product Owner is tossed into the strange and frenetic world of program delivery. This can occur because many POs are not prepared well enough during training to execute their role. Proper follow-on observations and active consultation by the agile implementation partner is critical to avoid a slip into complacency and a return to old-school approaches.
The Four Ways to Ensure Agile Sustainability
1. Program fatigue is real and can foment finger pointing more quickly when transitioning to agile delivery. Identify a strong agile evangelist who can engage your agile implementation partner and your internal senior leadership to ensure they are committed to a long-term investment in the adoption of agile delivery. It is this commitment that positions the right investment in on-going adoption of agile practices.
2. Active and aggressive coaching after the initial implementation of agile becomes essential to a team’s success. Those filling the Product Owner role must be afforded more than initial training – they need frequent, on-going, proactive reinforcement of agile principles and best practices with corrective guidance and advice.
3. The PO is the scrum team member responsible to prioritize the work – and the rubber meets the road with how the work is structured. Pay on-going attention to how stories and features are built. Many new teams and their PO’s will build features that have nothing to do with business value; instead, they build a logical sequencing of development – define, develop, test, release. Falling into this pit eventually robs teams of a real sense of accomplishment and masks visibility of the benefits for program sponsors.
4. A Program Increment (usually 5 or 6 sprints) should never pass without the team delivering something they can demonstrate. Be clear early on that the PO is responsible for delivering demonstrations of releasable code at every PI Planning event. Knowing this will force PO’s to sustain the right mindset as they are forming their features. In order to demonstrate releasable code that provides business value, the planned features must be crafted in a way that articulates business value. It also forces the scrum team to have a common understanding of the PI objectives.
If your organization is considering moving to an agile environment or has recently moved to agile and the path is a bumpy one, NEOS can help. We have experienced professionals who have years of industry knowledge coupled with hands-on experience tackling the most challenging agile workstreams.