Self-direction doesn’t just happen because you adopt Scrum, Kanban, or another Agile variant. Or because you say “Agile” 20 times to your teams. It needs a fertile space to grow. It needs to be watered and fertilized. It needs an honest and open environment.
In far too many cases, this is simply not happening.
So, what are the elements of self-directed space? This Advisor explores five that come to mind.
Managers: stop “managing”. The first element is for your managers to stop, well, managing. In other words, stop trying to tell people what to do, estimating their work for them, or solving their problems for them.
I usually share the notion of push versus pull with managers who are making the transition to Agile. You want, at all costs, to resist pushing yourself into the teams — the less frequently you intervene, the better. However, if the teams ask you for help, or otherwise pull you in, then do assist your teams. Push reduces their autonomy, while pull supports and respects it.
I was coaching a leader (manager) just the other day on this notion. Her team was struggling a bit in solving a product design problem for a customer. She had direct experience with this sort of design and wanted to simply direct the team toward the solution. I asked her to wait, to allow the team some time to struggle with the solution.
You could literally see her discomfort with this idea. She was nearly breaking out into a cold sweat, as every ounce of her being wanted to help (i.e., solve the problem for) her team.
In the end, the team came up with a novel and successful approach. On their own.
Be careful what you measure. Measures often drive behavior. For example, if you measure code-complete milestones within sprints, then you’re emphasizing development-done rather than a whole team–done focus, and you shouldn’t be shocked if your team doesn’t jell into a mature Agile team. It might be because of the way you’re measuring or incenting them.
I spent a couple of hours emphasizing the mindset of agility, including the collaborative aspects, while delivering a recent Agile class. Near the end, one young man raised his hand and said:
But Bob, we are not incented to work together. Our compensation model and bonus structure are solely focused on individual performance. I don’t care about my team members’ performance or helping them; I only care about myself.
At that point, I respectfully ended the class.
Solid Agile metrics need to focus on outcomes rather than activity. Another thing about metrics is that they are primarily for the team, so involve your teams in the creation of your metrics.
It follows that the metrics should be team-based rather than individually focused. For example, if you are measuring throughput or velocity for a team, don’t look at individual productivity metrics and compare team members. (Don’t compare team-to-team productivity either.) Keep your lens on the team, on their trending and learning, their results and outcomes, and ultimately focus on their improvement.
Avoid unnecessary hierarchies. I’ve run into quite a few organizations lately that have the notion of team leads within their Agile teams. Quite often these people are also serving as ScrumMasters. In general, I’ve found that any time a team member is declared a lead, they’ll have a requisite number of followers.
That is, the self-directed nature of the team succumbs to the leader. Not always, but often. You can see the impact in backlog refinement sessions, where team members look to understand and size work items. The teams nearly always acquiesce to the views of the leader. If the other team members or the testers consider a story to be 10 points in size, but the leader thinks it’s two points, then the team always seems to normalize to two points. Imagine that.
If I can, I try not to create unnecessary hierarchies in Agile teams. I want the leadership within the team to emerge from each team member as situations dictate. You see, in a self-directed team, anyone and everyone can and should lead as appropriate.
Obviously, the people with more experience will lead more often. But your more junior team members will often get the chance to lead, learn, and grow as well.
Be mindful of language. I know this might sound odd, but I believe that the language you use impacts the space you provide for your teams.
For example, do you refer to developers as “Development” and “Devs”? Do you refer to testers as “QA” and “Test”? If you do, then you’re reinforcing your organizational structure and silos in your everyday language. Silos imply handoffs and a lack of the more natural teamwork and accountability you’re looking for in agility.
I try to change my language to deemphasize organizational silos and instead leverage team language whenever possible, and I encourage all leaders to do the same. And when I say language in this context, that includes all forms of it (verbal, tone, and body) as you communicate each day with your teams.
To show you how seriously I take it, I once worked in an organization as a VP of technology. I started to charge myself $5 for every time I referenced a silo (Dev, Test, BA, Ops, etc.) over the team in all of my interactions. As you can imagine, I failed to always use team-based language. However, the practice of keeping tuned in and accountable to that language made a difference in my teams. My failures also provided a fairly substantial amount of funding for team-based fun.
Foster failure and discovery. I often talk to leaders making the transition to Agile about enabling or empowering their teams to try new approaches and to possibly … fail.
The room usually goes quiet, and everyone gives me a look like I’m trying to sell them a bridge in Brooklyn. The almost universal reaction is: “Bob, we don’t fail around here, so please don’t mention the ‘F’ word.”
The reality is that failure is a part of learning and a part of success. It lies at the core of innovation and creativity. Whether we like it or not, creating great products through software development is an emergent exercise.
As leaders, we need to create or encourage an environment of risk taking, learning, and exploration within our teams. That is, we do if we want them to grow and learn and become outstanding teams. The most important test of your ability to foster and support failure (aka learning) is not simply saying you do. Saying you support failure is easy. What counts is how you react to your teams when they do fail. It’s this behavior that will communicate your true feelings to your teams.
Are you just saying it, or do you truly support your teams’ learning and discovery?
[For more from the author on this topic, see "Creating Self-Directed Teams: It’s a Question of Space."]