SAFe© means "Scaled Agile Framework". The SAFe Scrum Master (SSM) works as a Servant Leader to measure & grow business agility.
As described in the Agile Manifesto, our work is about incremental delivery of value and fast feedback. It is "customer-centric" and focused on people rather than processes. It helps dealing with changing priorities and accelerate product release.
The Agile mindset offers a number of practices (stories, demos, retrospectives...) that can be used through different frameworks (SAFe, Scrum, Kanban...). Among them, the "Plan - Do - Check - Adjust" cycle that occurs across all Scrum events and provides a regular, predictable development cadence to produce an increment of value.
About Scrum
Scrum is a team-based framework that was defined in 1986 with the Scrum Guide. I personally like the roles it has defined, the size of a team (2 pizzas should be enough to feed its members!) and the regularity of its timeboxed meetings. Its name (which translates to "mêlée" in French) is taken from the rugby world, hence the multiple pictures you'll see in my articles, showcasing my favorite team : the Stade Rochelais.
The roots of Scrum go as far as the 1970's when product development welcomed new ways of thinking, due to the birth of Information Technology (IT) and computer engineering. This was the time when information went global, software became prominent, and data (especially banking transactions, at first) started to be shared across the globe. As such, the old way of working in sequential mode ("waterfall") was not possible anymore. We had to get rid of old behaviors such as : focusing on deadlines, driving toward specific outcomes, fixing problems for the team. This "built-in instability" (or ability to adapt & change) underlines challenging requirements and, above all, demands a high degree of freedom to meet them.
Therefore, the "rugby" approach where we all go the distance as a single team.
The Scrum Values are :
- courage
- commitment
- focus
- respect
- openness
With this mindset, we integrate the testing teams the earlier possible in the process ("test-first", "shift-left"). It is always easier to change things in the beginning ! The Scrum Pillars, also reflected in SAFe Core Values, are :
- inspection (Built-in Quality)
- adaptation (Program execution, Alignment)
- transparency
Telling Stories
Stories act as a ‘pidgin language,’ where both sides (users and developers) can agree enough to work together effectively.
—Bill Wake, co-inventor of Extreme Programming
In Agile, a Story is a small increment of value that can be developed in days, which is relatively easy to estimate and is part of a bigger Feature (benefit hypothesis, acceptance criteria, priority). A Story can be functional (User Story) or technical (Enabler Story for Infrastructure, Architecture, Exploration or Compliance).
Each Iteration is a work cycle where we :
- extract backlog items prioritized by the Product Owner
- define Stories to create our Iteration Backlog (using methods such as Gherkin = Given/When/Then, INVEST, Story Points = planned effort)
- build/integrate/test the Stories (execution)
- and finally deliver the working software/hardware (review/retrospective).
The Agile Team has 5-10 members, with only two of them having specialty roles : the Scrum Master and the Product Owner. For big-scaled projects, we can have a team composed of Agile teams : we call it the Agile Release Train (ART).
The teams work together during each iteration, called a Program Increment (PI). With a single Scrum team, we would use a work iteration called a Sprint (duration : 1 to 4 weeks). For a coordinated SAFe effort, Iterations are typically 1 or 2 weeks in length. But be it a Sprint or an Iteration, it always ends with a review and retrospective. Remember to Inspect & Adapt !
The multiple roles of the SAFe© Scrum Master
Among his organization, big or small, the Scrum Master (SM) must keep track of its daily tasks which basically converge to the well-being of his teams (SM action plan).
First, I think the SM promotes on-the-same-team conversations. He is, by definition, in service of the team : removing its impediments, helping improve processes, facilitating events, supporting the Product Owner. The SAFe Scrum Master can do this by teaching and coaching SAFe ScrumXP and SAFe, implementing and supporting SAFe principles and practices, and identifying and eliminating bottlenecks to flow -> he can improves team's journey towards technical excellent by focusing on the importance of built-in quality. The SSM creates an environment of safety and ensures all voices are heard. They encourage the team to learn from their mistakes. For instance, during daily stand-up meetings, I like the approach of "walking the board" where we keep everyone focused on all the subjects by detailing each story instead of everyone's tasks.
The Scrum Master can coach multiple teams in the organization : when the time had come for me to experiment that way of working, I was at first a bit afraid of the challenge. Coaching two separate teams at the same time seemed pretty daunting. But I soon realized that working with multiple teams was a good way to help them learn and master the new methods. Actually, it can improve the adoption of Agile practices.
An expression often used to describe the Scrum Master is that he is a "servant leader". What I like about this role is that it can have many facets : I encourage every member of the team to express their opinions, I empathize with my colleagues (what is their daily routine, their way of working...), I ask questions that encourage new perspectives, I also try to think beyond day-to-day activities (what is our long-term operating goal). In a nutshell, I encourage open communication and show appreciation for each team member.
The SM works with the Release Train Engineer (RTE) to ensure the teams meet its overall PI Objectives. These objectives are assigned business value by the Business Owners (BO) to provide the teams with guidance and help them plan the implementation.
FInally, I like interacting with my colleagues during the Scrum of Scrums (SoS), which is a daily meeting with the RTE and the other Scrum Masters. The PO Sync is the equivalent meeting for Product Owners (focused on the Iteration) and Product Management (focused on the release). Product Owners communicate emerging requirements & opportunites and contribute to the Vision.
Performance and meetings
The Program events create a closed loop system, and our Team events run inside it. As such, the System Demo remains the best measure of progress for complex system development. I always keep in mind several things while attending a Team event or any meeting :
- The first one seems obvious, but it is crucial : who is really supposed to be there ? For instance, the Scrum Master doesn't have to be present during Daily Stand-Ups, but he must verify that the meeting actually takes place and that it allows everyone to work in adequation with our goals.
- Does everyone has a good understanding of the topics (and a good Internet connection when in remote) ?
- What is the planned duration for the meeting ? I must verify that we have time to discuss everything during the definite timeframe (i.e. timeboxing).
- And finally, what is the action or information that needs to be specified at the end of the meeting ? Reuniting several people at the same time is rather time-consuming for everyone involved, so it's fundamental to stay focused on the meeting's purpose.
With all these tools, high-performance can be reached and continues to be driven by the following stages :
- forming
- storming
- norming
- performing
- (adjourning)
The dysfunctions in a team (i.e. failure to reach stage 4) can come from absence of trust (Cooperation) / fear of conflict (Communication) / lack of Commitment / avoidance of accountability (Contribution) / inattention to results. It often happens because no one guides the team, or as a result of assumptions that have not been discussed.
What I also enjoy in the Scrum Master role is the possibility to develop several relational skills that deeply enhance the relationship with others.
- the ability to resolve conflicts
- the practice of powerful questioning
- being invested in the team's overall performance and thus each member's successes
- fostering the Agile mindset
- being a Servant Leader as the developer of people
- guiding and facilitating through what can be done for our business now.
This latest point reminds me of the Agile Manifesto and its core understanding of empirism. Through the role of Scrum Master, there is a fundamental feeling of "all we have is now", trying to make everyone be on the same page and march towards our common goal. It is never about following blindly a specific process, but rather embracing change, identifying delays and adapting to the current flow. In French, we would say "c'est du bon sens".
According to Alex Brown, Chief Operating Officer and Chief Product Owner at Scrum Inc., there are three qualities every great Scrum Master possesses.
- A firm grasp of servant leadership & facilitation.
- A relentless approach to the pursuit of Continuous Improvement.
- A good working relationship with the team.
Each Agile team can become cross-functional by defining/building/testing a feature or component, and optimizing for communication and delivery of value. Thus, by providing autonomy, purpose and reducing the constraints, we can unlock the intrinsic motivation of knowledge workers. Change the work habits, and culture change will come!
Since I see it mentioned in some documentation, I would take a step back and not promote "peer pressure" because I feel it is stress-inducing. I think it generates inhibition, friction and more problems. I rather try to emulate the team with an optimistic and confident point of view. When one or several team members are feeling pressure, this can come from their peers (often indirectly), from the Program Management team, or other particular personal sources. This stress then created a lack of commitment or, on the contrary, wanting to do "too much". It is my duty to reassure everyone and help them concentrate on what they can do, step by step, during the current Iteration.
About the conflicts in general, our daily lives (and international news) provide us with too many examples. They often rise from unexamined assumptions. Par programming is a good way to provide transparency.
Planning the next Program Increment
PIs are typically 8 – 12 weeks long. The most common pattern for a PI is four development Iterations, followed by one Innovation and Planning (IP) Iteration. A PI is to an Agile Release Train (ART) (or Solution Train), as an Iteration is to the Agile Team.
The PI Planning is a milestone that occurs during 2 days. It is a real collaboration between developers, PO, Program Managers (PM), SM, RTE, Architects... all the members of the Agile Release Train (ART) ! The goal is to define together the Team Objectives and Program Objectives, visible on the Program Board. Together, we will plan the next Program Increment which will be developed during 4 Iterations, then with a fifth iteration for Innovation & Planning. Though innovation activites can be conducted by teams on the ART throughout all the PI.
The Iteration capacity is calculated by giving the team 8 points for every full-time member (except PO & SM) minus 1 point for every vacation day they have. Every Story that takes 1 day to develop/test/validate is a 1. Iteration Goals help align the team members and the PO to the mission, and the team's velocity obtained from Story Points completed from the last iterations is a good indication of that.
Everybody helps defining the Objectives of the Program Increment. BO set the business context and assign business value, helped by the Top ten Features. It can happen that the team has low confidence in meeting some of them : those are Uncommitted Objectives. They are part of the load but are not part of the commitment. Don't forget to list them, plan them in the capacity, and you can put in early technical or functional spikes to help achieve them later ! Those exploration enablers help uncover knowledge or reduce risk in the next PI.
On the Program Board, we put on display the plans, with its Features and significant dependencies (between teams, or related to Features). Conducting the PI Planning Meeting can be challenging but it is also rewarding, and a good example of applying cadence and synchronization in SAFe. To minimize dependencies, PO can split Stories or move Stories on their team's backlog to another team.
During the 2 days of PI Planning, there are two Team Breakouts : those sessions are facilitated by the SSM. He provides clarifications necessary to assist the team with their Story estimating and sequencing. The Product Owner defines the 'what'; the team defines 'how' and 'how much'. Throughout iteration planning, the team elaborates the acceptance criteria for each story and estimates the effort to complete each one. Based on their available capacity for the iteration, the team then selects the candidate stories.
After the plans have been presented, some questions may remain. Regarding the backlog, it is important to secure it with the definition of Non-Functional Requirements (NFR) with System and Solution Architect/Engineering. Finally, the teams will address the last points and categorize them as such :
- Resolved (no longer a concern)
- Owned (someone has taken responsibility)
- Mitigated (team has plan to adjust)
- Accepted (nothing more can be done)
At the end of day 1, the management review lists adjustments that can be made to accomodate challenges, risks and impediments. They are then communicated back to the ART at the beginning of day 2. Finally, once dependencies are resolved and risks are addressed, we can take a confidence vote using the default method of Fist of Five.
The impression that ‘our problems are different’ is a common disease that afflicts management the world over. They are different, to be sure, but the principles that will help to improve the quality of product and service are universal in nature.
—W. Edwards Deming
Work In Progress
The Program Backlog's content has authority from Product Management who uses the Vision, the Roadmap, driving the PI Objectives, establishing Features and benefit hypotheses. It's PM who owns the decision for releasing changes into production.
Once defined, to achieve the shortest sustainable lead time, Lean enterprises strive for a state of continuous flow, which allows them to move new system features quickly from ‘concept to cash. The primary keys to achieving flow are :
- Visualize and limit work in process (WIP)
- Reduce the batch sizes of work items
- Manage queue lengths (using Kanban)
Finally, during the last iteration of the Product Increment (IP iteration=, the PI system demo feeds into the aggregate Solution Demo (the integrated demo from the ART's final iteration). The SSM can participate in Inspect & Adapt when using ad hoc teams. We should not plan work for the IP Iteration during PI Planning, nor wait for this IP iteration to fix defects.
The Bigger Picture
Implementing SAFe is a challenge. But if your company is ready for this mindset, it is a good idea to start following the activites of the SAFe Implementation Roadmap. In SAFe, Solution Managers use Solution Intent to manage requirements and apply a fixed vs. variable approach to specifying them.
At a macro level, the SSM is able to take in consideration the whole roadmap and its Value Streams (Operational or Development). Above the Agile Release Train, we find the Solution Train :
- Solution Train Events are facilitated by the Solution Train Engineer
- Solution Context defines the environment in which the Solution operates
- Solution Roadmap is for this longer term planning ! (recommended time horizon of 1 year)
Even bigger is the Lean Portfolio Management (LPM) and its Portfolio Kanban (along with Vision and Strategic Themes). LPM empowers the stakeholders to adapt the current backlog and roadmap context, align business strategy and execution (Lean-Agile development), adapt budgeting taking into account the capacity allocation. Once an Epic has a completed Lean business case, the LPM can give a "Go" decision and move it to the Portfolio Backlog. Enabler Epics are used to advance the Program Backlog in order to support upcoming Business Epics. A Lean-Agile mindset is defined by Lean Thinking + embarcing agility.
Lean User Experience (Lean UX) design is a mindset, culture, and a process that embraces Lean-Agile methods. It implements functionality in minimum viable increments and determines success by measuring results against a benefit hypothesis.
Epic -> Capability/Feature -> Story
Trust can be gained with one key ingredient : the predictibility. In a changing world, the defining goal is to stabilize our movements so that reaching our objectives can be more...SAFe ! Enhancing that enterprise agility allows for a faster response to ever-changing market opportunities. And with this mindset, business and development can work easier together.
For instance, it is very reassuring to release our solution upon demand (Continuous Delivery Pipeline also known as "Develop on Cadence, Release on Demand" and bassaed on the Architectural Runway), enabling accelerated release of value :
- Continuous Exploration (CE) - PO & PM hypothesize on what would create value to their Customers - most involvement from PM
- Continuous Integration (CI) - allows to show a true System Demo rather than separate feature branches.
- Continuous Deployment (CD) - decoupling deployment from release
- Release on Demand (RoD) - thanks to "feature toggles", allowing to maintain multiple branches - most involvement from PM
By joining development and operations, DevOps can reveal truly powerful : it is a mindset, a culture, and a set of technical practices. It can help builing applications while overlaying measurements with events and enabling continuous learning cycles. Deliver early, often and deliver value incrementally! Jobs with shorter duration and higher cost of delay are given preference by the Weighted Shortest Job First rule (WSJF). This is also true for batches : large batches can cause severe project slippage while small batches go through the system faster with lower variability.
Through all this, keep in mind that infrequent decisions or decisions with significant economies of scale should remain centralized. And when solutions exceed the typical size of an ART (and portfolio governance is not the primary concern), Large Solutions SAFe can be needed. At this point, the Solution Context can help defining the environment in which the Solution operates.
And the good thing is... it never ends ! With continuous Agile learning, we keep ahead of the curve so that we can build more amazing tools and products in the upcoming surprising years.
© Scaled Agile, Inc.
Read the FAQs on how to use SAFe content and trademarks here : https://www.scaledagile.com/about/about-us/permissions-faq/
Explore Training at : https://www.scaledagile.com/training/calendar/