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, and this list is certainly NOT exhaustive, 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.

Wrapping Up

In the next segment of this post we’ll explore some recommendations for effectively handling “management” in agile organizational contexts. I hope you read the conclusion as I think this topic is long overdue.

Stay agile my friends,

Bob.

References

Zappos

• !

General