SAFe Agile: A Participant’s Perspective

Agility is a key component of any type of growth, including within the workplace.  Within the technical realm of software development specifically, there historically have been two prevailing methods: sequential (waterfall) and incremental (agile).  In the early 2000’s, the Agile framework formally began as an iterative approach to software development. This Agile manifesto includes 4 cornerstones: 

• Individuals and interactions over processes and tools.
• Working software over comprehensive documentation.
• Customer collaboration over contract negotiation.
• Responding to change over following a plan. 

The Scaled Agile Framework (SAFe) was first introduced in 2011 and has gained immense popularity since (70% of Fortune 100 companies and growing) expands on agile methodologies and applies a framework for scaling lean and agile practices at the enterprise level.

Through Zirous’ Project Management office, we have discussed Agile and what that looks like within iterative Zirous projects in the past. As a technical lead and Director at Zirous, I am a consultant and a technologist who has used both frameworks in the past on client deliverables.  The following content around Agile, SAFe agile specifically, are from the perspective of how the constructs of SAFe agile materialize into a vocabulary, structures, resources, and ultimately the deliverables surrounding a technical resource.  As with any framework, there is value and there are limitations, both of which will be discussed from my perspective.

Structure

As an employee at any company, we are striving to make an impact and provide value in alignment with broader company goals.  Within SAFe agile, a technical resource fits into the structure as a valued collaborator within an Agile scrum team. An Agile team is then working in coordination with other Agile teams, as a part of a Program Agile Release Train (ART) team-of-teams. An ART is working towards delivering solutions fed through the highest level Portfolio. Portfolio epics align value streams and company initiatives within value streams of the company’s strategic vision. 

As a technical lead on a SAFe Agile team, I interact constantly with my teammates and meet at least daily.  We are committing as a cross-functional team to work we will complete as a team. As a team, we work through the breaking down and defining the work that needs to be done. Incrementally, through two-week sprints, we then execute on the work defined as a team.  When coordinating with other teams, knowing that they are also working on synchronized two-week sprints, this gives us common ground for the next level up in the SAFe Agile structure, Agile Release Train (ART). An ART is essentially a team-of-teams, charged with the task of driving the larger solution value.  As a technical resource at the team level, many of the daily and sprint-by-sprint operations of the ART are also abstracted.  These are handled by other roles, namely Scrum Masters (SMs) and Product Owners (POs) of each team and the Agile Release Train Manager (RTE) for the ART. 

What is the value of SAFe Agile?

Value to a technical resource when it comes to SAFe Agile can be outlined clearly through the four core principles of SAFe Agile: Alignment, Built-in quality, Transparency, and Program Execution.  

• Alignment: As mentioned above, there is immense value in a common ground when it comes to team structures, team cadences, and clear organizational priorities when we get into initiatives large enough in scope that they require multiple teams executing in-sync. I have the confidence and clarity around where the work my team is doing fits within the bigger picture, as well as the time context of when to expect the commitments the pieces around me from other teams, will be delivered to then produce the entire solution and value to the company.
• Built-in quality: I have specifically seen built-in quality play out in multiple ways, and particularly throughout Community of Practices (CoPs).  Through an organized CoP, technical leads have an avenue to discuss and disseminate standards to the broader cross-functional teams, for example, standards around code quality, documentation, and technical best practices.
• Transparency: Common understanding and visibility between all members of the SAFe Agile ecosystem allow for a trusting, empowering working environment and working relationships. Accountability at all levels is key for both enacting change in technical solutions and delivering on commitments building towards large technical solutions to provide value to the business.
• Program Execution: Without the coordination and leadership required to optimize program execution, the burden of collaboration often stints the progress and day-to-day execution towards a larger technical solution within an enterprise. Team members work together as an ART to deliver on large solutions by enabling technical resources of said teams.  This enablement is done by removing impediments to progress, and ultimately results in motivating high quality solutions in an enterprise environment.

What are the limitations and challenges of SAFe Agile?

Most of the limitations of SAFe Agile from this participant’s perspective come from the overhead SAFe Agile requires to implement. As a technical resource, if not managed judiciously, meetings eat up a large portion of the day. An emphasis on consistency, to manage the components of SAFe Agile reasonably, can lead to the loss of team autonomy that is a hallmark of agile benefits. On the other hand, inconsistencies across teams and ARTs lessen the overall impact of standards and can sometimes lead to a potentially larger tangle and discussion at the ART and Program levels than is effective.

When it comes to planning and timings, although SAFe Agile has concepts of fixed-date milestones, they are still prioritized through Program Epics and iteratively worked toward through 2-week sprints and months-long Product Increments (PIs). If the mentality shift from a waterfall to a more incremental approach isn’t there, many benefits of SAFe Agile, such as self-organizing teams and incremental releases, could be forfeited if participants are continuing to slate all ART or program work into fixed-date milestones without valid external forces driving those dates.

Conversely from the waterfall tendency discussed above, if Program Epics instead over-emphasize Minimum Viable Products (MVPs) and Minimum Marketable Features (MMF), we’re also in a hard spot as technical participants. More often than not, when the MVP/MMF value is realized, since the day-to-day support of the operation is falling to the technical resources, it requires careful communication and prioritization from all levels to move into steady-state support of a solution. Mitigation strategies here could involve work at the ART and CoP levels to establish standards of “Done-ness” and stability that prevent this problem, or additional program-level communication to prioritize moving beyond MVP at the Product level. In either case, oftentimes other prioritized and planned work conflicts with priority of the less glamorous stability features, which is not a challenge unique to SAFe Agile.

Zirous Solutions

In conclusion, the underlying tenets of organizational alignment, transparency, quality, and an iterative approach to delivery are worth exploring as an organization, and integral to Zirous solutions. 

SAFe Agile is not a magic bullet, but it does bring some enticing value and structure.  Companies that have large technical teams, and those who are struggling to align large solutions across a large number of individuals and multiple teams, would potentially benefit from looking into implementing SAFe Agile.  Zirous resources are familiar with implementing projects while incorporating agile methodologies in delivery, and when it comes to an organization practicing either SAFe Agile or other agile frameworks, having players that are “bought in” to this delivery framework is crucial to its success.