GroundhogIn the movie, Groundhog Day, the central theme revolves around the protagonist reliving February 2 over and over again. In doing so, he uses the knowledge to improve himself, and of course, to move the film towards a happy Hollywood ending.

A couple of years ago, Jim Highsmith’s Cutter Advisory on self organization, No More Self Organizing Teams, resulted in a passionate response from Tobias Mayer (and others). I responded via this Blog post.

In the time since, I’ve encountered this debate regularly on various user groups. Do agile teams need project managers or ScrumMasters; or can they simply self-organize? I’ve come to realize that it is one of those groundhog day type questions that keeps getting asked over and over again. I think the question is repeated because someone in one camp or the other doesn’t really like the answer they’ve been given. And so they ask the question again in hopes of getting and an answer closer to one they like.

In the hopes of improving myself, and moving towards a happy ending to this story, I’m reposting my response below. I’ve taken the liberty to update it slightly for readability:

This is a discussion that gets to the essence of Agile methods. Both Jim’s and Tobias’ posts are impassioned and display remarkable shared concern for preserving the hard-won value wrought by Agile methods in tough environments. But there’s also a difference, that though barely perceptible, reveals a divide to those familiar with the territory. The dividing line becomes clearer when one reads the follow up messages — the line faults along manager and non-manager.

To managers, this is about something very, very fundamental. Managers are interested in understanding how to add value on Agile teams and discover the best value-adding role for them on Agile projects. So, to my mind this is really about the role of the manager on the Agile team. See my Blog post on this topic here:

Agile methods have been great about defining how developers can add value. With the product owner role becoming more solidly defined in Scrum, business analysts can jump on board as well as product owners or product owner proxies. But what about managers, and testers (anyone remember those guys who used to show up with reams full of defect listings?). And how about user interface designers (users do like those cool interfaces and design is an increasingly sought-after specialization), production specialists (maintaining production environments that are reliable and secure is an expert skill), etc.

The truth is that, as Agile methods are successfully making the transition into the mainstream, they are being quietly adapted to fit into large, complex organizations. Very few adoptions of Agile in these organization go exactly “by the book.” Work in large, complex organizations tends to flow across organizational silos. Significant strides have been made in creating integrated teams that collapse some organizational silos. On these teams, costly hand-offs have been eliminated or at least reduced. But, the prevailing reality is that, in most organizations organizational silos with division of labor exist in some shape or form. And in most large organizations, those silos are also represented on Agile projects. Therein, I think, lies the core issue. Can division of labor be completely eliminated from Agile projects and teams?

Most managers, I believe, will take the pragmatic view, press for an integrated team, and then manage work across said silos. Others will hold that the organizational structure itself is flawed, and therefore needs to be completely replaced. Rid organizations of the scourge of division of labor, move to completely integrated teams, adopt a craft model, and everything will be solved, they hold. Managers — at least those not appointed by the team — will then not be necessary, they believe. Perhaps. But, as long as organizational silos exist, some division of labor is necessary for effective functioning, and these discussions will continue.

As for leadership, it’s like mom-and-apple-pie. Everyone seems to agree that leadership is a good thing, don’t they? Though how that leadership is appointed, sanctioned or manifested is the subject of debate, I think we all agree that leadership is a good thing on Agile teams.
My own position is that, if we can find ways to reduce non-value added management work caused by the reality of organizational silos (via Lean Kanban systems, etc), we can then all — managers and non-managers alike — get down to the important business of figuring how to lead our Agile teams. Until then, having a role that addresses the management work is simply a necessity.
To that end, Light Touch Leadership, as Jim articulates, is a great way for managers to lead Agile teams in a way that is completely congruent with the Agile value system, but that also acknowledges the reality of organizational silos and division of labor in most organizations.
I think there is definitely a place for a value-adding Light Touch role on agile teams. Light Touch is about managing agile teams with a style that allows team autonomy and flexibility, and a customer value focus without sacrificing control.To learn more about what I deem Light Touch management, go here:
What do you think? Do we need project managers and/or ScrumMasters on agile teams? Please chime in!