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

When Agile Fails

Mitch Malloy
Mitch Malloy

It happened again. Everything was working beautifully. The teams were meeting their commitments, trying new approaches and genuinely having fun being productive. Then [fill in the blank] happened. Like me, I’m sure you have all sorts of real-life experiences. As Agilists, we seek to fail early and often. We know that every failure is a learning opportunity, but how do we respond when Agility just isn’t embraced within the organization? We gave it our best shot and now things seem to be going in the opposite direction. I guess it’s time to throw in the towel, right?

Maybe. Maybe not. You know your goals better than anyone else and you know your situation. Me? I just have a big blank on my paper with a lot of assumptions. We could try to find someone to blame, such as the infamous ’They’:

  • They couldn’t embrace an Agile mindset.”
  • They weren’t willing to recognize the problem.”
  • “I took them as far as they were willing to go.”
  • They thought they were Agile, but they were practicing faux-agile.”

Maybe we all share the blame and defeatedly admit that “We tried to be Agile, but it just didn’t work for us.” Fair enough. But through the years, I’ve noticed we sometimes learn the wrong thing from a failed experiment.

I’ll use myself as an example: when I was in high school I did some field events in Track, and I decided to see how I would do in a running event as well. Without any training (and especially with any spectators!), I timed myself for a race against the clock to see how I compared with other athletes in that event. As you might expect, after timing myself running solo, I walked away discouraged and told no one about my failed attempt. My time wasn’t quite as good as the guys already training for that event. As I matured I learned a lot, such as how to run and how to train. I even coached Track & Field for couple years, and I would use my failure as an example for my student athletes. As a coach, if I had someone come off the couch to complete that event with a time like my private attempt, I believe I could have taken them to Regionals… possibly even State. The whole point of the story is that my inexperience and fear led me to a wrong conclusion and I emotionally shut down, declaring a premature defeat.

Fear and inexperience are obstacles to overcome, and it’s especially difficult when we’ve learned the wrong lesson from a failed experiment. It takes humility to move past failures and courage to move beyond failed learnings in our personal history. But the obstacles are often greater when working with others. It takes patience and boldness to confront and break down the failed lessons of what others have learned. Along the way, it’s easy to get into a fight or flight mentality: EITHER I fight these people to make Agile a success here OR I leave to find the plush lands of Agility Nirvana that exist elsewhere. But as pointed out in the book “Crucial Conversations” there’s a third option we should always consider: we can choose to dialog.

If I’m truly an Agilist, and by that I mean someone who ascribes to the values and principles of the Agile Manifesto, then how should I respond to failed attempts at Agile? Failed attempts can take the form of an anti-pattern exhibited by an individual or at a larger scale as a failed organizational transformation. Do I truly value Individuals and [healthy] Interactions? Am I committed to collaborating, and are others willing to collaborate? If the other person has shut the door, locked it, and then nailed it shut, then it doesn’t matter how much you try, that door is closed, and it’s time to move on. But if there’s a chance of opening that door, shouldn’t we try?

Do I consider how the 12th principle may apply to a failed transformation?

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Why not take an Lean-Agile approach to opening the door further? Plan -> Do -> Check -> Adjust. Intentionally work with others to retrospect on what works and what doesn’t. I believe that cadence builds discipline, so creating a rhythm to retrospect will be more effective, but if the environment is not open to that yet, take a more informal approach. Something that has worked well for me in the past as a change agent is to focus on issues others can agree upon and prioritize the ones from that list that we’ll resolve first. This builds trust with others and often creates a willingness to collaboratively resolve other issues. It also models a collaborative spirit to help foster a continued growth in healthy patterns.

The bottom line is that Agile is a journey, not a destination. Although some are much further along than others, I don’t believe that anyone has fully arrived. So it’s up to us, as Agile leaders and enthusiasts, to lead with service to others and get back on the path. We own it to them and we owe it to ourselves.

copyright ©2018 Mitchell Malloy

In Search of Agile

Mitch Malloy
Mitch Malloy

I can’t tell you how many times I’ve read a job description or been told about an incident where someone clearly misunderstood Agility. And if I’m completely honest with you (and myself), I’ve participated in the shock, dismay and talk surrounding such incidents. But I have a new perspective on this type of event that has only grown in my role as an Agile Coach: this is an opportunity to be a change advocate for Agile.

The fact that someone has a misconception about Agile demonstrates some level of interest in Agility. I can take a judgmental approach to their misunderstanding and find all the reasons why that person or group should know better, or I can take a more graceful approach and seek to understand the root cause. Is it because everyday demands have pushed people into old habits? Do they feel a pressure that’s generating anxiety, resulting in fear-based decision-making? Or perhaps their Agile training never graduated to understanding. Or maybe their understanding hasn’t evolved yet into a new habit of thinking. Perhaps it’s as simple as they don’t really want to understand but feel a need to pretend they embrace it. The root cause directs the appropriate solution.

As an Agile Coach, I’m constantly assessing how I should respond to the various antipatterns I see. Do I ignore them temporarily while I help people address higher impact issues? Or do I need to intervene, and if I need to confront the issue, how should I approach it?

I’ve learned that confronting each and every issue all the time demotivates. If I’m hyper-critical, then I’m breeding a hyper-critical environment, which cultivates fear. But if I only encourage good behavior, I’m not really mentoring others and leave them with a sense of anxiety about how they are really doing. To be a Servant-Leader, I need to serve others as well as lead them with humility and boldness. As a leader who serves, I must be mindful and proactive.

I suggest this is the calling of every Agile leader, and every Agile leader should expect to repeatedly encounter dysfunctional mindsets and behaviors. I also suggest that every Agilist is called to lead from where they’re at, regardless of hierarchy level or “position”. Every Agilist is a change advocate for a set of values and principles, regardless of where we happen to be in our individual journey.

An Agile leader is in search of Agile, not as a destination but as a journey, mentoring others in that same journey. I haven’t found Agile Utopia yet, and I honestly don’t know anyone who has. That doesn’t mean that it isn’t worth the journey. Those who embrace an Agile mindset and work collaboratively to refine Agile techniques find a more productive and more enjoyable journey than the people who remain stuck in less rewarding patterns. So if someone exhibits a misunderstanding, that’s an opportunity to engage a fellow traveler.

So when we discover a dysfunctional mindset in others (or in ourselves), we should ask the following questions:

  1. Is this something that requires an intervention?
  2. If not, how should I be mindful to enable a self-learning opportunity?
  3. If I need to intervene, how can I present this in a way that it can be best received?

When we are in search of Agile, we need to create the change we seek.