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

­­The Fast Track to Agility

Mitch Malloy
Mitch Malloy

If you’ve been in Agile for a while, you’re probably familiar with “The Backwards Bicycle”, and if you aren’t, I’d encourage you to watch it. I guarantee it will be time well spent. However, as much as I value this video, I believe it’s missing something and has misconstrued a concept. As an Agile Coach and Consultant, I’m more sensitive to some things that others may not notice.

As an Agile Coach, I can see where people can have a tendency to learn the wrong thing. For example:

“We tried to be Agile but it didn’t work for us. I guess this is an environment where Agile won’t work.”

But as I probe a little bit, I discover more and can ask questions that help them understand.

“Why didn’t it work? What happened?” Then I discover something like:

“Our deployment processes are too complex, and we can’t deliver software to production every Sprint. Maybe someday we’ll have the infrastructure to be Agile.”

So wth this information, I might ask: “Do you think there are aspects of Agility you could benefit from without having to upgrade your infrastructure?”

This might cause them to pause momentarily, look at me with a “I’m not sure. Are you just trying to sell me something or can you actually help me?” If they decide they can trust me with a little more information and are confident enough to be vulnerable, a conversation opens, and I can usually find ways to help.

There’s saying among counselors and coaches that you can only take people as far as they are willing to go, but I believe great coaches can help people want to go further. I’m not saying that I’m a great coach, but it is what I aspire to be. And I’m stubborn enough to continue to strive for improvement so I can better help the people I serve, finding resources that are sometimes off the beaten path. One of those resources is a book written for ministry leaders but very applicable to the Agile community: R.A.R.E. Leadership. I won’t go into all the practical nuggets I found in that book, but one key point discussed neuropsychology and how our brains work, which brings us back to the Backward Bicycle.

The “The Backwards Bicycle” video rightly emphasizes that Knowledge doesn’t equal Understanding. How many programmers go to a class to learn a new technology and without practice, the knowledge ebbs away and Understanding never grows. And here is where I differ ever so slightly from the key learning of the video…

Understanding is key. It answers the question “Why?” and as Agilists we seek understanding because understanding helps us know how to respond. It takes time and effort to understand. It’s a necessary step to mastery, but mastery requires tenacious intentionality. The repetitive training of our brains creates a change in us where we no longer have to think about how to take that next step so that walking becomes both natural and easy. It becomes a part of us. As RARE Leadership and Backwards Bicycle teach us, our brains get rewired. The thought pattern moves from the slow track of the brain to the fast track. In short, it becomes a habit of thought.

But things can cause us to go back to old thinking habits. Stressors and environmental factors can lead us to motivate with fear even though we know joy creates greater productivity and it fosters courageous teams. R.A.R.E. Leaders need to lead themselves first and a major part of that is rewiring our own brain. We need to take captive each thought until we change the way we habitually think.

Rather than wondering in great frustration why people are falling back into old habits, we understand that they are simply doing what people do naturally, going back to a pattern they learned in the past. So we need to remind them who they are: they are Agilists and as an Agilist, how should they view and respond to the situation?

The Bicycle video gets most of it right. Knowledge is not Understanding, but it equivocates Understanding with a Habit of Thought. As a consultant, I’m sensitive to the use of words, looking for terms that are overloaded (multiple meanings) or terms that have been redefined. I don’t believe the video intentionally redefined the term understanding. Rather, it came across a concept for which mainstream society has no word. In certain religious circles, they use the word “soul” to describe this habit of thinking. It’s the essence of who we are, our way of perceiving without even consciously understanding how we know. In other circles it may be referred to “intuition”, which is often infuriating in a pragmatic business world that wants an immediate answer to “how do you know this?”. In other environments, we refer to this as thought patterns or muscle memory.

Regardless of what we call it, this is a step beyond Understanding. It’s the Fast Track of the brain, a habit of thinking, a hard wiring of the brain that indicates mastery has occurred. So the fast track to Agility in individuals and organizations starts with Knowledge, leading to Understanding, and only with repetition results in some degree of Ba , where we, the knowledge and the experience are one.

Knowledge is not Understanding, and Understanding is a step on the path to mastery.

copyright ©2019 Mitchell Malloy

The Scrumban Spectrum

Scrumban Spectrum
Mitch Malloy
Mitch Malloy

I read article on Scrumban that caused me to look more closely. The author advocated implementing every aspect of Scrum when standing up any Scrumban team. In that author’s opinion all three roles and all four ceremonies of Scrum were needed if a team used Scrumban. Scrum is a widely accepted and (mostly) understood Agile practice so it makes sense that people will gravitate to what they know and lean upon practices that they both understand and feel comfortable with.

However, as Agilists we should always be pushing the envelope of what’s known and experiment with techniques that can help us relentlessly improve. Looking at the 6 practices of Kanban, we can see many aspects of Kanban that have already made their way into common Scrum practices:

  • Visualize Workflow
  • Limit Work-in-Progress (WIP)
  • Measure and Manage Flow
  • Make Process Policies Explicit
  • Implement Feedback Loops
  • Improve Collaboratively (Using Models/Scientific Method)

The Scrum board imitates a Kanban board and helps teams visualize the workflow, often with WIP limits so that teams can optimize the flow. The Review and Retrospectives create a mechanism for timely feedback. Many Scrum practices find their origin from the Lean processes that birthed Kanban. So implementing all the roles and events of Scrum and calling it Scrumban in my mind says you just want to merge the two more.

But when I consider the values and principles of the Agile manifesto, I tend to go a different direction. Think of processes and tools the way we think of documentation and product: what is the minimum that’s necessary to deliver the desired value. Keep the processes lightweight and implement the minimum practices needed to achieve the desired result, adjusting as necessary with each iteration. Understanding all the Lean and Agile tools that are available is good but trying to implement them all in tandem without a clear need is not something I would recommend.

I think of Kanban as a tool that can be used in a more responsive fashion than Scrum, where classes of service are understood and continuous flow is desired. Scrum techniques can be applied where the class of service is less defined and timboxes applied to keep focus and to adjust course in small increments. Some teams deal with challenges that neither tool by itself is fully prepared to address, so they blend the two in order to strike the right balance between the Scrum and Kanban.

Rather than trying to implement everything, I suggest trying to implement the minimum that is needed with a hypothesis for how the techniques that will deliver results for the team. Then assess the outcome in a planned retrospective where the team can further tweak and hypothesize their practices. In this fashion, a team may discover that they really have a new class of service and no need for the other Scrum structure. Likewise, they could also find out that they do in fact need all the overhead of Scrum with a mechanism for addressing ad hoc requests. More likely, they will simply land at a lightweight set of practices that wouldn’t work for any other team but optimizes the value delivery for them using a blend of Scrum and Kanban.

In short, think of Scrumban as Spectrum that may lean toward Scrum or Kanban, borrowing practices from both. Every Scrumban team will find themselves somewhere along the spectrum, and the really nimble Scrumban team will adjust where they are on that spectrum to meet their evolving needs.  

I’d like to hear your thoughts or experiences with this. Reach out to me either through with website or via my LinkedIN profile. https://www.linkedin.com/in/mitchellmalloy/