CUTTER BUSINESS TECHNOLOGY JOURNAL  VOL. 30, NO. 8
  

Over the past few months, I’ve been coaching clients who are in the early stages of adopting Agile approaches for software. Most of them are adopting Scrum, but a few are adopting Kanban.

Universally, they complain that their teams aren’t stepping up to the:

• Empowerment

• Responsibility

• Accountability

• Passion

• Energy

• Creativity

that are implied as part of the culture of self-directed, Agile teams.

Often the teams appear to be frozen. They’re not able or willing to take accountability for their projects. Their energy levels are low. They seem to want to walk through the delivery of their systems. Overall, their posture is one of continually needing to be told what to do.

To say that the clients are disappointed is an understatement. And these comments are coming from all levels of the leadership teams.

It May Not Be the Teams’ Fault …

But I have a shock for these folks. It may not be the teams that are the problem. It may be the leaders that are standing in the way of the teams’ self-organization.

How, you might ask?

Well, lately I’ve been referring to the problem as not giving teams enough space — space to grow, space to become autonomous, space to become self-directed.

You see, 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? Let’s explore a few 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 solv­ing 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. So, don’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 remember once delivering a virtual Agile class for a Ukrainian team. I spent a couple of hours emphasizing the mindset of agility, including the collaborative aspects. 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.

Team Leads

I’ve run into quite a few organizations of late 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, any­one 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.

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 when­ever 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 inter­actions. 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.

Team Organization

One of the craziest ways to build an Agile team is to connect a disparate group of remote folks from around the world and then call them a team. They’ve never worked together or even met, but they’re a team now because the organization chart has labeled them as such.

Are they really a team? Of course not.

Instead, try to build your teams as closely as possible. Colocate as many as you can. If they have to be distrib­uted, then have as few time zones between them as possible. Also invest heavily in collaborative tooling to support their teamwork.

I often get told that remote Agile teams simply don’t work. Yet I’ve seen remote or distributed Agile teams work quite well when the organization spends the time (and money) to get the team together periodically, especially when the team is being formed. This time can be well spent in chartering the team and establishing ground rules.

Don’t get caught up in that old excuse that previous budgetary decisions have cast your remote organization for you, that it’s unchangeable. You can always change your strategies over time and reorganize to improve the teaming orientation of your organization. Point being: you have choices and should move to colocated teams as soon and as much as possible.

ScrumMasters

I don’t know what it is about today’s organizations, but I encounter so many that aren’t willing to fund and hire ScrumMasters in their Scrum adoption efforts. Or they overload their ScrumMaster with far too many teams to support. Or they multi-task the role on top of other organizational roles.

Why?

Often it’s because they don’t understand the role. They trivialize it and minimize the need for it. However, Scrum clearly states that solid teams include a focused and dedicated ScrumMaster. It’s an important part of a Scrum team, and it’s not really optional. It’s a full-time role or job within each team.

I also believe it’s a crucial one. Sure, the simpler parts of the role — say, impediment removal — don’t nec­essarily demand a ScrumMaster. But the parts that involve coaching the team and guiding them toward continuous improvement, effective collaboration, and high-quality product delivery take an experienced and knowing hand.

Give your teams space by providing them with focused and capable ScrumMasters. Then support the ScrumMasters with ongoing training, coaching, and mentoring.

If you don’t see the value proposition for a ScrumMaster, run an experiment. Simply hire one, a good one, and assign them to a team. Next, give them some leeway and measure the difference they make in team morale, focus, efficiency, and results.

If you run an honest experiment, you’ll be as convinced as I am of the value of the ScrumMaster role.

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 for your ability to foster and support failure (aka learning) is not simply saying it. 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 to your teams your true feelings.

Are you just saying it, or do you truly support your teams’ learning and discovery?

Trust

I’ve come to understand that trust is one of the most fundamental ways that leaders can give their teams space within an Agile transformation effort.

Do you allow your teams the freedom, the trust, to become truly independent, self-directed, and accountable? Or do you have a “trust but verify” mindset, where you ostensibly trust your team but rarely give them the space to truly feel trusted?

I’ve found that trusting when the going is easy is, well, easy. You’ll know your trust-ometer is where it needs to be if you still maintain your trust when:

• Your teams’ estimates are not in line with external expectations. In fact, they’re three times as long as you need them to be. However, instead of second-guessing your teams, you trust their estimates and begin to manage the expectations.

• Your teams have encountered a problem that is slowing them down. Or they’re trying to decide which design is the best. Or there’s conflict on the ultimate direction and they need arbitration, but you trust them to sort it out on their own.

• Your teams are taking a direction that you’re unsure of — in other words, taking an approach that is different from what you would do. Every fiber of your being is saying, “This won’t work,” yet you take a step back and trust their instincts for the solution.

• Your team is falling behind schedule. And you’re beginning to doubt their decision making and work ethic. Historically, you would have given them a quick kick in the pants to motivate them. Now you trust that they’re doing everything within their power, and you support them in any way you can.

It’s in these and similar situations where you demonstrate trust for your teams and their motivations and support their go-forward efforts. This is also where they start to feel trusted and really grow and learn as true Agile teams.

Celebration and Fun

I don’t know about you, but I’m a fairly hard-driving leader. I push myself and my teams to always be looking to deliver more and to deliver more efficiently. This leadership style really aligns well with the Agile objective of continuous improvement.

There is also a fundamental flaw in this approach.

That is, I often fail to stop, look behind me, and celebrate the accomplishments we’ve achieved. Or to spend time learning from and appreciating the journey, for that matter.

One of the most important aspects of solid Agile leadership is creating the space for retrospection or reflection within teams. Tightly coupled with that is the need to create space for celebrating your journey’s accomplishments.

This is one of those areas where you can lead by example for your teams. Take time yourself to recharge your batteries and to have some fun. And fund the teams for a celebration of their choosing.

Wrapping Up

I want to make one final recommendation.

The best way to influence your teams and give them space is not by your words. It’s by your behavior — by walking your talk. The more you can model the above behaviors, the more space you will give your teams, and the more they will grow in their Agile maturity. Words matter, but your behavior and actions matter so much more.

For you Star Trek fans, outer space was always “The Final Frontier.” I beg to differ. I now think that team space is the final frontier. And it may be just as hard (or harder) to achieve than leaving earth’s orbit on another adventure.

Why?

Because traditional management techniques and approaches are a strong part of our DNA and incredibly hard to shift away from — especially when we are challenged or under stress. But if your goal is to foster sustainable, empowered, trusted, and engaged self-directed Agile teams, then shift you must.