In my last post I talked about a tendency some organizations (and individuals) have in jumping on the latest fad in building software teams and the methods for producing value. Beyond jumping on tactical or practice bandwagon’s, there appears to be a war going on related to traditional hierarchical organizational structures and traditional line or functional managers.

Now to be clear, my context is 90% from an agile adoption and transformation perspective. And this isn’t some new phenomenon, as it’s been tied almost to the inception of the agile approaches.

There are some books on the market, and this list isn’t exhaustive, that are providing forward-looking thinking when it comes to traditional management. A few that come to mind include:

  • Management 3.0: Leading Agile Developers, Developing Agile Leaders, by Jurgen Apello
  • The Culture Game: Tools for the Agile Manager, by Daniel Mezick
  • The Leaders Guide to Radical Management: Reinventing the Workplace for the 21’st Century, by Stephen Denning
  • Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers, by Lyssa Adkins

Much of what’s emerging is causing us to rethink our leadership and management strategies, which is good. But there is also an undercurrent in the agile community that has been “Manager Phobic” for many years. Let me share an example. This snippet is from a LinkedIn group discussion by an esteemed Certified Scrum Trainer (CST) –

I have witnessed Scrum teams work at high performance with no manager involvement. I have also witnessed them work less effectively with manager involvement. I have not witnessed a Scrum team perform highly with the involvement of a manager. My experiences align with the conclusions reached in research and study by Jon Katzenbach and Doug Smith about teams (the Wisdom of Teams and The Discipline of Teams). According to them (and my experiences support their position), single leader work groups cannot reach the high performance of "real teams" for a variety of reasons, primarily because they are not autonomous and cannot leverage mutual accountability and other social contracts.

Now this statement, on the surface appears informed and innocuous. However, this person is in a heavy influencing position and they’re basically saying that managers can’t be a part of the collaborative model in creating high-performance agile teams. And I’ve heard this as a reoccurring theme throughout the CST/CSC community and from many other agile thought leaders for many years.

There’s another set of patterns I’ve seen in my many years spent in the agile community. It’s related and I want to go there next.

Agile is ALL about (Lean) waste elimination (WFR), isn’t it?

The WFR in this case is work force reductions. It turns out that agile methods appear to be incredibly streamlined. On the surface, they seem to be mostly for developers and everyone else is left to sort out their “connections” on their own. In fact, there have been some pervasive attitudes that surfaced over the years, including:

  • We don’t need no stinkin’ Testers!  In the early days of XP, circa 2000-2001, there was clear discussion about no longer needing software testers in teams. It was actually widespread and I’m aware of quite a few organizations that right-sized (fired) testers. After a few years, it became clear that competent and professional testers had a firm place in balanced and effective agile teams, but the damage had been done.
  • We don’t need no stinkin’ Project Managers!  Another trend surfaced around 2004-2005, when Scrum was starting to accelerate beyond Extreme Programming in agile adoptions. Because of the Scrum Master role, the conversation shifted towards eliminating traditional PMI-centric project managers and even PMO’s in general. Unfortunately, this hasn’t declined as much and many Project Managers feel they have to get acquire ScrumMaster certifications to defend against redundancy and elimination.
  • We don’t need no stinkin’ Managers!  I used the previous two to set a precedent that there is a trend towards implying that, if you’re not “slinging code” you provide no value in agile environments. Customer value being equivalent to lines of code produced. So if testers and project managers provide minimal value, at best, the thinking goes that managers provide zero value. In fact, there is so much “blaming of management” within the agile culture that I’d say the assumption is that management provides negative value. In other words, management is often cited as a failure factor in agile transformations.

Another fine example is the organizational plans coming from Zappos. Zappos has historically been a shining example of an entrepreneurial company that established a special team and customer focused culture that truly was unique and successful. But recently Zappos announced that they’re moving to Holacracy as an organizational model and that it will eliminate the need for all “managers”. Check the reference section for more information.

I’ve been aware of Holacracy for quite some time and I think it an interesting experiment on the part of Zappos. Time will tell to what degree Holacracy works for them and the real impact it will have on their leadership and management teams. Yet, many are pointing to Zappos as another “shining example” that proves that managers are superfluous and that we don’t need them around.

But let’s move from some examples to my point—

Let’s be Clear

While these attitudes, recommendations, and approaches seem to be incredibly pervasive, within the agile community, I believe them to be dead wrong.

What’s happening is that shortsighted agile adopters are way too focused on software development and developers as the value proposition in producing products. This view tends to marginalize roles that don’t fit as easily into agile teams as they would like.

The other part is based in the reality that these groups: testers, project managers, and managers DO struggle in moving from traditional to agile approaches. Often they stubbornly refuse to shift or change and adapt. And they can undermine the entire agile adoption.

In fact, VersionOne has famously done an annual survey that alludes to management issues as being a top five-failure factor in agile adoptions. But I’ve also seen large groups of developers struggle to adapt to agile methods and many don’t ever make the shift. Or they remain change averse and actively undermine their teams in their adoption. Just as some testers, and project managers, and yes, managers do.

But I don’t generalize and alienate these developers—looking to stereotype all of them. Instead, I deal with them as individuals and singular cases. Because for every one of these folks, I’ve encountered five to ten developers who embrace agility and gain benefit from it. And yes, I can say the same for testers, project managers, and managers.

Instead of “bashing” or “firing”, what about…

Instead of phobic distrust of, bashing, marginalizing, or demonizing management, I think there are a few way more constructive approaches for us to partner with managers and leaders who are struggling with the shift to agile methods. I want to highlight these alternative reactions and recommend that we go here first.

1.    Be Respectful – First of all, let’s stop the blame game and name-calling when it comes to our managers. I heard one coach imply that all managers are useless and should be fired. But then say that leaders are required when moving to agile approaches. In fact, leaders are a significant part of a successful transition. I guess that coach was the final judge as to who was a “manager” and who was a “leader”?

2.    Don’t Stereotype – In many ways Dilbert has done all of us a truly terrible service. It’s got us into a habit of stereotyping all managers as pointy-headed incompetents who are only looking out for themselves. Don’t fall into that habit. Treat all of your managers as unique and give them a fair shake when it comes to supporting their efforts to become agile leaders.

3.    Seek to Understand; Be Empathetic – I’ve gotten into the habit of trying to walk in the shoes of my leaders (and my teams) before I pass judgment on their intentions and actions. It often gives me a much more nuanced and balanced perspective. It also prevents me from assuming I understand the challenges and pressure that they are under.

4.    Be Patient – Please realize that it takes time to change. Often it depends on how long you’ve been approaching things, so age and experience comes into play. As does the energy needed to change. Also realize that when the pressure is on, we often revert to our old habits. So it will take time for someone to truly change and become ‘sticky’ as a solid agile manager.

5.    Partner with & Teach Them – Too many coaches focus towards the team in their efforts and avoid coaching management and leaders. I often wonder why; or if money and risk has something to do with it. Regardless, I believe agile coaches should spend the majority of their time in situational coaching of the management tier within organizations transforming to agile. Spend time partnering with them and teaching them solid agile leadership principles.

6.    Listen with Intent – I think sometimes we under and over react to what are leaders are saying and doing. Listen to both the words and the actions of your leaders and managers. Don’t react to each word or poorly phrased message, but consider them within the overall contexts. Realize that we all communicate poorly at times and say things we don’t mean. See through the words to their true meaning within their historical patterns.

7.    Open Dialogue; Tell Truth – I’ve found that leaders really want their teams to “tell them the truth”, as early as possible. While they might not like and sometimes overreact to the truth, they appreciate honesty, openness and courage. Establish a relationship with your manager where you can tell (and also accept) the truth in your communications.

8.    Be Flexible and Context-Based – There is way too much “purist agility” in the world that looks at things from a one-size all perspective. Try to embrace your managers from the perspective of context. Consider what they’re doing and why they’re doing it from within the frame of your companies’ culture. Don’t expect them to always “buck the system” in large-scale ways. They may be waiting for the right moment to inspire a shift.

9.    Don’t Jump on the Bandwagon of “Blaming” Managers – Just because it’s so pervasive in the “agile community”, doesn’t make it right. In my personal coaching experience, I’ve never fired a manager because of moving to agile. We reframed their roles, then trained and coached them along the path of the transition. Nearly all of them made the transition and became successful servant leaders in agile contexts. And yes, many of them retained “management” titles. And to the point of the quote I used at the introduction, we did achieve high performance agile teams with “managers” in place. In fact, in my estimation, they were a part of the reason that we achieved higher performance. That is—their Leadership.

10.    Don’t Underestimate the VALUE of Leaders – One of the greatest risks in marginalizing your managers and leaders is considering them to have no value. Even the bad ones have value in your organization for reporting, budget, HR practices, training, roadmap planning, and yes, leading. I think it prudent to somehow figure out how to work WITH them instead of against them. And if you’ve come to the end of journey, then be mature enough to vote with your feet as you find your next opportunity.

And did I say – Be Patient? Trust me, agile team transitions don’t happen overnight. Developers just don’t magically start writing well designed, coded, and tests components via swarming that meet all aspects of your Definition of Done. It takes time. So how can we fairly expect our leaders to immediately become effective agile servant leaders? Truth is, we can’t.

Wrapping Up

I guess I should come clean. My name is Bob Galen and I’m a manager. I’ve been a manager in Waterfall and Agile contexts for over 25 years. My teams have told me that I’m an effective manager and leader in both contexts. And I’ve been fortunate enough to see several organizations I’ve led become high performing from an agile perspective, believe it or not WITH managers in place.

So, I’m somewhat biased. I think there’s a place for management in agile contexts. And most certainly for a related aspect called leadership. Much of that involves providing the vision and mission around the organization and then providing the team support to meet those goals.

But to be clear, I have seen managers who struggle moving to agile and I have seen the damage they can cause. I’ve fired (or significantly reframed the roles for) some of those managers. Not because some company or book said to do it, but because they weren’t effectively doing their jobs. It was an individual move, not a holistic one.

To do otherwise, to fire all the managers, as part of an agile transformation is in my mind an immature and simplistic reaction to a far more complex evolution. Solid managers and solid leaders are not only needed within agile contexts, they sustain, grow, and empower it. Now you agilistas in the audience please figure out a way to embrace your management.

Stay agile my friends,
Bob.

 

References

Please check out the references below. They provide some supporting context to the focus of the article.

Zappos

General

 

2 Comments