5 Little Changes that Will Make a Big Difference to your SAFe Transformation

Mitch Malloy
Mitch Malloy

A colleague suggested I write this article, and I quickly agreed, thinking to myself, “No sweat! There are so many little things that can make a big difference. I can type this out in no time.”

Now pause. Go back and review that last thought. Do you see a flaw in my logic here? “There are so many little thingsI can type this out in no time.” Did I really think a long list of things would make this task any easier? That it would make the writing process fly by?

It took me three weeks to write this article. The fact that there are so many small changes that can have a huge impact on a SAFe® Transformation made my heart beat a little faster every time I thought about it. I kept putting my thoughts down and picking them up again, and the list kept growing and growing.

Isn’t this similar to any organizational transformation (or large initiative, for that matter)? Every good idea gets added onto the transformation until you aren’t sure where to start or end. Ideas grow and take on lives of their own, spawning more ideas. The resulting list can become overwhelming, potentially frightening those involved and even driving them to resist.

Fortunately, the solution to my problem and the organizational transformation problem above are the same: put on your Product Thinking Cap and prioritize ruthlessly, coming up with a short, doable list of the most important things that can make the greatest impact. Your list doesn’t have to be perfect or comprehensive, but as you focus on small efforts with the biggest impact, you will begin to move forward in the right direction.

Below are my Top 5 suggestions for little changes that will make a big difference in your SAFe Transformation. It’s my belief that these practices go a long way to energize Agile Transformations at any level, from team adoption to global enterprise transformation. There are nuances, but the principles remain the same.

1. Emphasize Mindset over Toolset

There’s a reason why the Scaled Agile Framework® (SAFe) training classes emphasize Values and Principles at the very beginning. They describe a mindset that is essential to scaling agility within an enterprise environment. Without the right Lean-Agile Mindset, a SAFe Transformation is often ineffective, despite all the great tools included. As I often say, “The mindset fuels the toolset!”

What is the difference between a toolset and a mindset? A toolset is a toolbox of practices that can be used to implement a solution. ScrumKanbanXP, and SAFe are all frameworks and/or collections of practices that can be pulled out of an Agile toolbox. A mindset is your understanding; the key to knowing which is the right tool for the job. I can use a screwdriver to beat a nail into a piece of wood, but it takes understanding to know I’d be better off using a hammer.

Mindset vs Toolset

Just like carpenters who apprentice under a master gain an accelerated understanding of woodworking, SAFe Teams and Senior Leaders who train with a deeply experienced coach gain an accelerated understanding of SAFe. As a SAFe Program Consultant (SPC) and Agile coach, I train people on how to use various toolsets, but more importantly, I help others to develop the Lean-Agile Mindset, which isn’t immediately intuitive and often doesn’t become real until several iterations into the application of a new framework. As teachable moments materialize, I look for opportunities to tie values or principles to the problem being solved, reinforcing Lean-Agile thinking.

So often, people want to do Agile without being Agile. In essence, they want to implement the practices without changing the way they think. Someone will ask how to do something (usually in an email, text, or IM) without context for the problem being solved. Typically, a quick response without a conversation can create more harm than good. Context and understanding are critical when using any of the tools in the Agile toolbox.

If your organization can’t embrace the Lean-Agile Mindset, then you will not have a sustainable SAFe Transformation. Remember—the mindset fuels the toolset! There’s a saying in the martial arts: Learn the way, then make your own way. Once the new way of working transforms how you think and becomes part of you, only then can you truly start to walk down the path of Agility.

2. Model Agility – Be Agile as You Do Agile

CollaborationWhen leading a SAFe Transformation, it’s so important that your behavior models the values and principles found in the Agile Manifesto and SAFe. Start by leading yourself first. For example, if you want to encourage others to be fearless, then act fearless, choosing to be motivated by joy and enduring hardship without losing your cool. If you want to encourage collaboration, then collaborate rather than dictate.

Try not to fall into Command and Control Management, the traditional “do as I say and not as I do” style of leadership that creates fear, confusion and inhibits transparency. This approach discourages the self-organization necessary for SAFe and other Agile frameworks.

There are times in a transformation where it is appropriate to take a prescriptive approach (see SAFe Principle #8), but the goal is to move toward a facilitator role and become a Servant-Leader. Maximize the capabilities of your team by empowering them. Ask thought-provoking questions and provide goals without giving directions. By allowing your teams to think and act for themselves, they will develop their own leadership skills.

An impactful SAFe transformation leader understands that Agility is a journey and not a destination. You and your team may find yourself slipping into the comfortable old ways of Command and Control and order-taking. Rather than becoming discouraged, reinvigorate your Lean-Agile Mindset by acknowledging what happened, and then demonstrate relentless self-improvement by retrospecting how you will act in the future. As you do, you will be able to respectfully pull others back onto the path of Agility. Doesn’t this sound like a healthier approach than the fruitless criticism of a person’s inability to transform?

3. Define the Minimum Viable Transformation (MVT)

Stock photo 1If you are a leader modeling Agility, then you are value-focused and seeking to minimize the amount of work not done, especially with respect to the Transformation itself. If that’s the case, doesn’t it make sense to describe what the Minimum Viable Transformation (MVT) looks like?

In some cases, launching a train and walking through a Program Increment (PI) might be enough. In other instances, mentoring over a longer period may be necessary to achieve the desired goal. First you have to ask yourself, “What are the goals or desired outcomes of this transformation?” Doing without understanding is NOT the behavior of a Lean-Agilist, so defining an MVP and hypothesizing benefits should be part of your transformation. The decision to persevere or pivot should be evaluated throughout the transformation and as understanding grows, a new MVT may be established.

4. Engage Leadership; Don’t Just Inform Them

As you move the down path of transformation, having described an MVT and hypothesized benefits, who can validate that you are going down the right path? And if the MVT changes or your hypotheses produce unexpected results, then who can make the decision to either persevere or pivot?

Business leaders often expect they can step out of the way once they’ve engaged someone to lead an organizational change, but expectations for their role need to be made early and repeatedly in a SAFe Transformation. They can’t simply be informed of the progress; they need to understand how their role plays a critical part in the organizational change.

Leadership requests and behaviors can either reinforce or weaken transformation efforts. For example, holding individuals accountable rather than teams will lead to command and control behaviors and other anti-patterns. This is especially true when holding individuals accountable for metrics.

Metrics are neither goals, nor accomplishments. As the Agile Manifesto eloquently states, working software is our primary measure of success. Metrics can be gamed and used to cloud the real issues, or they can shed light on how to help and improve teams. Encourage your leaders to find the context for those metrics. If leadership places an emphasis on metrics themselves, their well-intentioned workers will put in the effort to have the best possible metrics. But if leaders emphasize delivery of quality software in their participation at System Demos and PI Planning events, then guess where their people will focus their efforts?

The importance of good leadership in a SAFe Transformation can’t be emphasized enough. If leaders model Agility by participating and collaborating across functional areas, then their behavior will be a powerful force for the change they want to see. If they fail to model Agility and don’t motivate their teams, then the Transformation is likely to stagnate.

5. Organize for Success

organize for successSo much can be said about how to organize for success, and yet the specifics are unique for every transformation. How do you know where to start? For many companies, this means bringing in an experienced external coach who will walk through the transition with you, helping you define what success looks like and how to measure it along the way. He or she will know what questions to ask, such as:

  • To what extent can teams be collocated?
  • Do you have the right people in the right roles?
  • As the team and program ceremonies are implemented, can other redundant meetings be removed?
  • Do the budgeting and portfolio management support the new way of working, or are they set up to create tension?
  • Are Agile Release Trains (ARTs) aligned along Value Streams or are they siloed along technology stacks?
  • Do teams and Trains know how they will respond to unplanned work requests?
  • Have expectations been set with Business Partners so they know how to interact with the new working model?

An external coach (or two) can help you find answers to these questions and navigate the change. And while external coaches are certainly an enabling factor to any successful SAFe transformation, at some point, they need to remove themselves from the client’s site. The goal of any good coach is not to become a permanent fixture, but to make necessary adjustments and get out of the way. An experienced consultant energizes both internal coaches and senior leaders to renew the Lean-Agile Mindset and model agility, thereby creating a sustainable transformation that lasts long after that coach leaves the client site. In other words, they help with these 5 little activities that make a big difference in your SAFe Transformation.

How well are you doing the little things that make a big difference in your SAFe Transformation? Check in with this 10 Question Survey, which shows you how well you’re doing and offers solutions based on how you score. 

Take the Survey

Catch Up, Clean Up, & Move Up!

Mitch Malloy
Mitch Malloy

The Scaled Agile Framework (SAFe) recommends an Innovation & Planning Iteration, often called the IP Sprint. The practice isn’t completely unique to SAFe, but it’s an important part of the framework. The IP Sprint is when planning and preparations for the upcoming Program Increment (PI) occurs, and it helps build predictability for PI commitments serving as an estimation buffer for anything that had to spill over. Once a team’s PI commitments have been met, the IP Sprint is a great time to see some extra magic emerge. Instead of just delivering the value that others have envisioned, teams are empowered to build the value that they’ve envisioned.

It’s a great practice, but as important to SAFe as the IP Sprint is, I still hear some common questions and misconceptions. So I’ve put together the following FAQs.

How can we trust the teams to use this time wisely?

This question indicates a lack of trust in either the character or the capabilities of the team members. I hear this so often, and in my more brazen moments I respond directly: “Why would you hire people that you don’t trust?” Although said with a smile, it points to the root issue. In this situation, I believe the best way to build trust is to become vulnerable and extend some trust: give the teams a chance to prove they are the competent professionals we thought we hired. I have yet to be disappointed in how teams steward this responsibility. Often, they choose to do something that is very much needed and would otherwise remain hidden until it became a problem.

Isn’t this just supposed to be a tech sprint?

It’s not a tech or engineering sprint; it’s an Innovation and Planning (IP) sprint. It is when both the Inspect & Adapt (I&A) and PI Planning occurs. It serves as a buffer for teams that have not already met their PI Commitment and helps build predictability in the PI Objectives. Assuming teams can meet their commitment prior to the IP Sprint, the developers pick activities that they believe will add value.

Does the Product Owner need to be involved in the IP Sprint?

Why wouldn’t they be? Do you want them to feel like they are part of the team? What are some ways that they can enhance the IP Sprint by their participation while also (1) maintaining focus on the finishing the PI well and (2) preparing for the next PI? SMs, POs and Dev Teams should talk to make sure everyone’s voice is heard on how to approach the IP Sprint and make the best use of this time.

Do we need to do all that “Scrum Stuff” during the IP Sprint?

Why would you NOT use the same rigor? There may be a reason, but for teams new to SAFe (e.g. – Agile Team has been practicing SAFe for less than 3 PIs) I don’t recommend trying something new; seek to improve upon the ScrumXP or Kanban practices already being applied. There may be good reasons for more mature teams to try something different. However, they will still want to apply an empirical rigor to what they attempt in the IP Sprint: enter the Iteration with a hypothesis for what will happen if you do something differently, then evaluate that hypothesis in the retrospective and determine how to respond.

What do teams do differently during this sprint from any other iteration?

Developers may choose to refactor code, develop the next killer app for their company, remove tech debt, or explore a new way of doing something.

It can be a good time to upgrade skills with formal training, exploration enablers and process improvements. For example, the team may want to take an innovative idea and implement it while experimenting with mob programming. Or maybe it’s a good opportunity to build T-shaped skills within the team.

How Can the Team Use the IP Sprint to Upgrade Skills?

Continue to apply the same rigor in the IP Sprint as with any other Sprint. Be sure to understand the value of the activity and use clear acceptance criteria that creates something demonstrable. You can’t demonstrate that you’ve read 5 chapters in a book, but you can tie the knowledge to something concrete. For example, you could present the applicability of a technology or practice for future initiatives. You could also prototype using a new language or tech stack, or you could summarize findings in a white paper. Product Owners should help the teams develop User Stories that explain the value of what they are doing. Scrum Masters should challenge the team to make it tangible / demonstrable / practical — and not just an abstract exercise.

What else should the team consider?

  • Teams will want to adjust their Sprint commitment to adjust for the additional Program Level ceremonies.
  • Developers should write stories that describe what they want to accomplish (User Story Voice including value statement and clear acceptance criteria), and they should approach it with the same level of rigor as any other iteration, including the communication of IP Sprint accomplishments. Otherwise the perception will grow that the IP Sprint is a non-productive period.
  • Consider how and when to communicate the accomplishments of the IP Sprint. Even better, consider how to celebrate the accomplishments and leverage the innovations so it never feels like throw-away work.

Ultimately the IP Sprint is a time to catch up, clean up and move up. Do it well and leadership won’t question why you’re doing it. Instead, they’ll wonder how they ever survived a rapidly changing business environment without an Innovation and Planning Iteration.