Agile – business with excellence

June 11, 2019June 11, 2019

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

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 things…I 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. Scrum, Kanban, XP, 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.

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

When 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)

If 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

So 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

April 25, 2019March 28, 2022

The Fast Track to Agility

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.

March 29, 2019March 31, 2019

Catch Up, Clean Up, & Move Up!

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.

March 13, 2019March 13, 2019

The Scrumban Spectrum

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/

January 29, 2019March 29, 2019

Servant-Leadership Revisited

If you walk around in Agile circles, you’ll hear the phrase “Servant-Leader” all the time:

“The Scrum Master is Servant-Leader to the team.”
“Create a culture of ‘Servant-Leadership’.”

Practically speaking, though, what does it really mean to be a Servant-Leader? We hear the term so often it may have become a cliché. Practically speaking, how can we cultivate a culture of ‘Servant-Leadership’ if we don’t stop to consider what it means?

There can be a natural, internal tension between being a servant and a leader, and a person can be a servant or a leader and yet fail to be a Servant-Leader. Read that again and ponder it for a moment. When we think of servants, we typically consider them as being hierarchically beneath the person they serve and when we think of leaders we often consider them as above others in the organizational structure or team dynamic. But if we stop to think about it briefly, a servant is simply someone who serves while a leader leads others. There is nothing intrinsically hierarchical about these roles. A servant is not necessarily lower and a leader isn’t required to be over someone else to lead them. No pecking order is required.

We know that someone can serve others poorly. People will often complain about receiving bad service at a restaurant or from a service provider. Likewise, leaders can steer others well, not-so-well, or even in a completely wrong direction.

When I was younger, having just transitioned from active duty Navy to the Naval Reserves, I was assigned temporarily to the Pentagon for 2 weeks. One day while waiting in the lunch line with an active duty Master Chief, a couple of sailors started to get into an argument, and as things were beginning to escalate, the Master Chief turned to me and said: “Sir, aren’t you going to do something?”. Now if you don’t understand the hierarchy in the Navy, let me explain. A Master Chief is treated with great respect because it’s the highest enlisted rank, and most enlisted men never reach that pinnacle of success. But every officer is senior to a Master Chief in terms of rank, and I was an officer. Despite that, I felt inadequate for my position not because of my training or expertise but because I was a reservist. In my own eyes, I didn’t consider most reservists to be competent or worthy of respect, and so I said to the Master Chief: “I’m just a reservist.” To which the Master Chief replied: “Sir, you are an officer in the United States Naval Reserve.”

He was right. I realized in that moment that I was leading poorly through my passivity, and being the senior most person, I had a responsibility to step into a heated situation and cool it down, so I did just that. The Master Chief and I proceeded to eat our lunch and I thanked him for spurring me on to the action that was needed. And after lunch, I did what I was in the habit of doing at that time and went off to pray for a few minutes before starting back to work. In that moment of introspection, the thought occurred to me: I was a leader. I could be a good leader or a bad leader, but either way, I was a leader. The Master Chief could have easily stepped into the situation, and I have no doubt he would have done just that if I hadn’t stepped up. He led me in the way I needed to become a better me.

I learned a lot that day, about myself and about what it means to be a leader. Leaders take action that makes others want to follow, but a leader doesn’t have to be in a leadership position to drive others into action.

We used to have a term that I don’t hear much anymore: Public Servant. It’s been replaced more often than not by the word “Politician”, which is how we view most of the people in office. Politicians lead others, but they often do so in pursuit of their own interests. Contrast that to what it means to be Public Servant, someone who serves the public, a service that is done from a position of strength and benevolence.

We often confuse role and position, but the calling of positional leaders is to demonstrate a higher standard for oneself with:

A humble awareness of how a higher position can be abused, and
An intentional determination to see oneself as an equal in a different role.

So practically speaking, what does this servant-leadership look like in an Agile organization? It means that leaders encourage the smart people they’ve hired to respectfully challenge everything that doesn’t make sense. It means that people don’t stay in their lanes, but actively look for how they can help each other out. They actively seek to serve and lead, filling in each other’s gaps as needed on the journey toward a clear and common goal. It means that everyone seeks to lead others to relentlessly improve in the delivery of value.

It also means that we don’t expect our strengths to be the strengths of our team mates. Our unique strengths are played as needed to complement the strengths of our team. Like a sports team, we may need to position our individual strengths in preference for how they can best help the team win… because the fact remains: we either win or lose together.

November 17, 2018January 29, 2019

When Agile Fails

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 12^th 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.

August 16, 2018January 29, 2019

In Search of Agile

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:

Is this something that requires an intervention?
If not, how should I be mindful to enable a self-learning opportunity?
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.