An Agile Foundation
Before jumping right into SAFe, let’s start at the foundation – what is Agile? The Agile methodology is a system development and project management framework in which multiple iterative, dynamic phases known as sprints, are used to break down projects into more manageable chunks.
A result of the Agile Manifesto developed back in 2001, Agile methodology is rooted in four pillars or core values and twelve principles. We’re not going to dive any further into the history, but certainly, if you’re interested, you can find multiple resources spread across the web. Most commonly used in application or product development to address the constantly changing nature of these processes, Agile renders previous traditional models like linear project management (e.g. waterfall) much less effective.
Fostering a collaborative, team environment and focused on delivering results to meet customer needs, the Agile method serves as the umbrella for several variations of the framework. Whichever approach is chosen be it Kanban, Scrum, Adaptive Project Framework, or one of a handful of others, the scope is focused at the team level. So if you need to extend the principles to a larger level, such as team-of-teams, an entire organization or a larger portfolio, you can’t just supersize it to achieve better outcomes.
Discovery
To solve a problem, you must first admit that there is one and then seek the appropriate resources to solve it. This is the start of the process of discovery. Here in the context of adopting SAFe, the process involves five steps.
First, with the end goal being to deliver exceptional value, to make this possible, whether that customer exists internally or externally, take a look within your organization for those teams that must be in close alignment and tightly integrated. You’ll want to identify at a broad level, dependencies, if mismanaged or discovered late, could hamper success when it comes down to crunch time.
Next, work to develop an understanding of how these collaborating teams are presently operating, such as, how their work is created, defined, and prioritized. How is it tested at both a component and solutions level, and then deployed? Which individuals are dedicated full-time and to which assignments, which are only partially assigned, and to which tasks?
Details to questions like these will really start to build the picture of roles and responsibilities and identify areas where operating in a more collaborative, coordinated manner could yield better flow of value. For example, is there an extensive amount of rework taking place at a certain stage of development due to little (or no) integration earlier in the process?
Third, make an evaluation of the teams’ compositions. Are they organized or aligned based on skill sets, to a specific component of the overall project, or something altogether different? Independently, what value do they deliver?
Fourth, what cadence does each team typically work within? Are the teams already following an agile methodology, working within a consistent sprint length? Stepping back and comparing the cadences of the teams, how do they differ? With whom does the decision lie as to what the final, combined project should look like and what is the level of priority to get it completed?
Finally, between these teams, are they using Agile/Scrum or Kanban processes? Is there a common language or set of terms as to how they first describe their part of the solution, and then, as to how they perform and deliver their portion of the end product?
Making a concerted effort at the outset, in the discovery portion of the process, to flush out the answers to questions like these will make the adoption of SAFe a much more fluid process, helping to guarantee its success!
Assemble The Team and Educate About SAFe
With the plethora of information that you’ve just researched and compiled, it’s now time to turn around and build the team of teams and get them up to speed, educating them with some commonalities.
Harkening back to the parable of the Tower of Babel, things are destined to fail when we all don’t speak the same language. Language in this context means using the same terms, vocabulary, and verbiage to describe our work so there is a common understanding among all involved. The classic example is the “definition of done”, but this also includes defining what the common cadence timeframe and increment dates are to be.
This is also the point in the collective journey to assign (or reassign) teams and specific Agile Release Train (ART) roles such as Product Owner, Release Train Engineer (RTE), and System Architect. It’s also a good time to simulate what a Planning Interval (PI) would look like with your teams and how its elements would be executed.
We would feel it remiss if we didn’t discuss the need at this point and going forward for implementing a “single source of truth” (SSOT). This is a digital solution that provides a combination of transparency and the facilitation of processes, critical events (such as the PI), and identifying those dependencies that were partially gleaned in the discovery phase. We happen to know of such a tool; Agile Hive.
To learn more about its capabilities, particularly as that “single source of truth”, check out our article here.
The PI – Plan and Execute Together
The Planning Interval (PI), specifically a successful completion of the PI, is often considered the crux of the larger determination as to whether a successful SAFe implementation has been made.
Typically lasting between 8 and 12 weeks, with timeboxed iterations of development within that larger timeframe, the PI consists of the core planning, development, validation and testing, and finally delivering value by those teams involved in the ART.
Proper synchronization and development of the cadence for PIsand the iterations within a PI enable each ART to plan the subsequent increment of work, set limits on the work in progress (WIP), summarize value for the purposes of feedback and assessment, and finally ensure the ART retrospectives inspire relentless improvement.
Typical PI Timebox
Source: © Scaled Agile, Inc.
Each PI is a period of creation, collaboration, learnings, and a series of pivots, inspecting and adapting as work progresses.
A Retrospective
The Retrospective, or “Retro”, is to be a regular event held after the completion of an interaction to determine essentially what went well, what didn’t, and what can be improved for the next one.
Attendees for an ART Retro typically include the ART-level roles, Product Owners (PO), Scrum Master/ Team Coaches, all teams and all team members, and any additional stakeholders which could include team members from other Agile Teams or ARTs. The Release Train Engineer will most often assume the role of facilitator, helping develop the agenda, keeping the event to the agreed upon timebox, and most importantly, ensuring that improvement items are captured in the backlog for the ART.
Retros consist of both a quantitative and qualitative review. The quantitative is the yes/no, by the numbers portion. Were iteration goals met, was work completed transparently (yes or no)? Additionally, flow metrics are evaluated to discover potential bottlenecks. This includes a velocity metric which is the indication of the average amount of product backlog turned into an Increment of value during an iteration. Additional analysis addresses topics like whether defects are addressed, and the like. The goal is not to place blame, but to stimulate collective ownership of improvements.
On a qualitative level, teams assess improvements that were identified in the last Retro. Looking then in comparison to the current processes, a small number of improvements are identified as to how those can be improved in the next iteration. These improvements will all differ in size and scope, so as to properly set the stage for successfully completing each, smaller “chunked” stories are identified to be tackled in subsequent iterations.
Ready To Get Started?
We hope we’ve provided the necessary food for thought to get your SAFe transformation underway. While it can certainly seem like a daunting undertaking, you don’t have to walk the path alone. The team here at Agile Hive doesn’t just provide the industry’s easiest “SAFe in Jira” software solution, we have extensive consultative resources for you to take advantage of.
To learn more about how Agile Hive can be that “single source of truth” through your entire SAFe journey, reach out to us to learn more and when you’re ready, schedule a demo with us!
Further Reading
Agile Hive Integration with Collaboration Technologies
System Architect Using Scaled Agile Framework (SAFe®)
Release Train Engineers – Empowered for Greatness with Agile Hive
Product Management Using Scaled Agile Framework (SAFe®)
SAFe® – The Pros and Cons for Scaling Agile
Agile Hive Implementation Project
In Focus: Who or What is the LACE?
SAFe with Atlassian tools: Agile Hive is a Scaled Agile Platform Partner
