This is the fourth post in the Practice Makes Permanent series. You can get caught up by reading the first, second, and third posts.
Any SAFe® implementation relies heavily on one of the 10 Critical Success Factors: Real Agile Teams and Trains. Let’s break this conversation down to make it easier (small batches, right?) and talk about the “Real Agile Teams” part (the next blog in this series will address the “and Trains” part). The “Agile Teams” article does a great job of describing cross-functional, high-performing teams.
What is a real Agile team? In this post, I hope to avoid the standard message about “what is a team?” and instead share some thought-provoking ideas about what a true
True Agile Teams
I came to a discovery a few years ago: there is no such thing as an Agile team.
Think about it. The Agile Manifesto Principle 12 states, “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” To me, this means that a team never arrives at true agility, but is constantly striving toward agility. Sure, you can call your team Agile. But, as soon as your team believes they have “arrived,” they have begun to stagnate. True agility is only found when we’re eager to learn what’s next to improve, and when we realize how much room for improvement still exists.
If you’ve ever rowed a boat upstream then you know what happens when you stop rowing—you go back downstream. There is no steady state. If you’re not moving forward, you’re moving backward. This is the reality of relentless improvement and of the spirit of Agile Manifesto Principle 12. Your team(s) may have made incredible progress towards agility, but until you realize it’s a never-ending journey, your path forward will always be in jeopardy.
Leaders often tell me that they want to empower their teams because they believe that empowered teams can deliver more value. That’s a valid belief, but leadership often doesn’t understand that our natural state is empowered. In his book Turn the Ship Around Captain David Marquet stated:
“We’re taught the solution is empowerment. The problem with empowerment programs is that they contain an inherent contradiction between the message and the method. While the message is ‘empowerment,’ the method—it takes me to empower you—fundamentally disempowers employees. That drowns out the message.”
In other words, to empower teams (and team members), we must first acknowledge that we have disempowered them through the systemic constraints we have created. If you want true Agile teams to constantly strive toward agility, the secret is to get out of their way. Create an environment with complete clarity on what needs to be done, then trust the competency of the people you have hired to do the right thing. As Marquet stated, “We realize that we don’t have the power to give these talents to others, or ‘empower’ them to use them, only the power to prevent them from coming out.”
So how do you empower teams?
Remove Constraints around Team Members
In Team of Teams: New Rules of Engagement for a Complex World, General Stanley McChrystal observed, “For people who perceived themselves as skilled workers, being recast as mindless cogs in a larger machine was degrading.” Businesses hire the best and the brightest they can possibly find, but in many cases, these skilled people are used as the “mindless cogs” in a machine. They’re asked to do small, separated components of work without being allowed to see or add value to the system overall. In many cases, this is due to a lack of clarity. The teams are given only enough information to solve the task at hand, but not enough to apply their shared intelligence to solve the overall problem in the best way possible.
Select a decision that typically requires sign-off or approval by management or leadership. Deploying to production is a common example.
Ask the person that approves this decision what they are using as criteria to make the approval decision.
Work with the teams to create a framework that will give the approver the confidence that the decision is being reviewed correctly.
Provide the information that the approver has to the team so that they can make the decision by combining what they know (local context) with the approver’s vantage point.
Let the team make the decision but allow the approver to see and hear the decision as it’s being made. I like using Marquet’s approach to this practice by having the team state something like: “We intend to deploy this package to production. All functional, security, and compliance tests are passing. All code has been checked into version control. Appropriate code reviews have been completed. The rollback process is in place and has been tested.” Using this statement of intent is a great way to allow teams to make the decision while keeping the approver in the loop. Over time, the approver will gain confidence in the team’s ability to correctly determine this decision.
Now you can move on to the next decision. And the next, and the next…
Psychological flow is a concept stemming from a 1975 study by Mihály Csíkszentmihályi who measured test subjects’ happiness metrics at random times throughout their days. Csíkszentmihályi discovered that people are at their happiest when they are in an environment of:
Intense and focused concentration on the present moment
Merging of action and awareness
A loss of reflective self-consciousness
A sense of personal control or agency over the situation or activity
A distortion of temporal experience, as one’s subjective experience of time, is altered
Experience of the activity as intrinsically rewarding also referred to as autotelic experience
Boiling this down, people are most happy when faced with a clear challenge that’s not too difficult to achieve and is intrinsically rewarding.
If you read my previous blogs, then you know that I’m also a motorcycle road racer and instructor. I have experienced psychological flow many times when in a really good battle with fellow competitors. We all know the finish line, we all know the risks (some better than others), and we are hyper-focused on achieving our goals. This is my happy place. And one of the best parts of this flow is the ability to talk with my fellow racers, who previously wanted to beat me to the finish line but now want to share the experience, after the race.
There are many ways to improve team culture, but incorporating psychological flow is a critical component. We all hear about “self-organizing teams” in Agile, but this doesn’t mean the teams self-form. It means they are formed with a purpose and given specific challenges to overcome with minimal guidelines. Leadership’s motivation is to remove impediments from their team’s path even if the leaders are the key impediment.
If you want to have real teams striving toward agility, one of your first steps is to ensure they are properly challenged. Don’t bring them long lists of requirements. Instead, bring them a problem to solve or an opportunity to embrace. Then step back and watch the engagement begin. Culture changes every day. Take purposeful steps to create the culture needed for real Agile teams.
Crave Fast Feedback
We’ve all heard the need to “fail fast.” At this point, it’s almost cliché. But does it mean we set the teams up so that they will fail quickly? That sounds very demotivating. What fail fast really means is to create an environment where it’s safe to fail. We set out on paths that seem valid, but we continue to look for qualified data that helps with the pivot-or-persevere moments.
Two things need to happen when we hit those pivot decisions. One, celebrate that we were able to truncate an invalid path before pursuing it too far. Two, incorporate the learning from this pivot so that we’re better prepared to find more successful paths and narrow in on the right specifications. For more on this topic, review SAFe Principle #3: Assume variability; preserve options.
Real Agile teams crave feedback that’s accurate, timely, and useful. Teams need fast feedback to quickly fail and invalidate paths; otherwise, they begin to lose focus and validated direction. Do you want to see your teams striving towards agility? Create an environment where feedback continuously flows to the teams.
“Team Leader” Is an Antipattern
Well, at least in the conventional sense. Team leads typically have one or more of these traits:
They’re the person who has exhibited the most skill
They’ve been with the company the longest
They have the most application or product knowledge
But are those the right reasons to look to this person for leadership?
All of us have worked with the “rockstars” of product development. They always have the answer, they can solve just about any problem, and they seem to know how everything works. But why don’t the rockstars create a rock band? Shouldn’t those with that much skill, experience, and knowledge try to bring others up to their level rather than continuing to stand out from the crowd? Solos are great, but we all want to hear music from the whole band.
Let’s look at a much more successful team lead approach, the Kaizen leader. In my experience, the whole team thrives when its leader is focused on continual, relentless improvement. Since leadership should be a role that is held as needed (rather than a title), team leadership can switch from one person to another as new improvement opportunities arise. Create a team environment where this is part of the culture and becomes part of the team DNA.
When talking about enterprise transformation with internal change agents, I often hear “that won’t work here” or “our culture just doesn’t work that way.” You know what? They’re right. Not with the current culture or reality.
However, remember that culture changes every day. Our job is to implement some of these team approaches to create a culture where transformation can really thrive. Teach, learn, and focus on the fifth lean principle of Pursue Perfection: “Perfection is like infinity. Trying to envision it (and to get there) is actually impossible, but the effort to do so provides inspiration and direction essential to making progress along the path.” To pursue perfection in a team is to be more excited about the journey than the destination. Teach your teams to view the pursuit of perfection as a worthwhile but never-ending journey of improvement.
I hope this post helps you to look at things through a different lens. Look for the next post coming soon that will add some of the same thought-provoking concepts applied to the ART.
About Dwayne Stroman
Dwayne is an Enterprise Transformation Coach and Trainer and SAFe Program Consultant Trainer (SPCT) with more than 20 years of experience. He is ultra-passionate about helping large organizations learn how to build the right products and deliver optimal value through learning and customer validation. Dwayne uses his SPCT role to help several Fortune 100 companies, as well as many growing companies in finance, retail, healthcare, and logistics, realize the benefits of a Lean-Agile mindset. Connect with Dwayne on LinkedIn.