In 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:http://lithespeed.blogspot.com/2007/09/agile-project-management-role-of.htmlAgile 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: http://www.informit.com/articles/article.aspx?p=390811.
What do you think? Do we need project managers and/or ScrumMasters on agile teams? Please chime in!
Subscribe to the RSS feed
3 comments:
You certainly do. The organizational structure is much less important than the actual person leading the initiative (http://analytical-mind.com/2009/11/16/hierarchies-arent-evil-but-people-can-be/).
Martin
Thanks for your comment. I like to draw a distinction between management (as dealing with complexity) and leadership (as effecting change).
So while I agree with your post about hierarchies not being inherently evil, I think they can stifle self-discipline, initiative, drive and innovation. Setting up an organizational structure that is known to promote these things can allow us to tap into the potential of both team members and managers.
Why hire good managers and then hinder them with bad bureaucracies? Why not reduce the complexity of the hierarchy so that they can be more productive and focus more on leadership than on management?
This is really the first time I’ve read through this whole thread and it has some very interesting perspectives. Silos do seem to get a bad rap, but I think the term “silo” is symptomatic of a type ineffective incentives and behaviors and not so much a type of organization.
I would say there is a long history of business and strategy literature that attempt to shed good light on why “silos” are in fact a good idea. Division of labor, specialization of task, different business models, different products, different geographies, shared business functions and service, and matrix organizations are all very viable and widely used models of management. All these models create typically some form of hierarchical structures that have different purposes as well as shared purposes. The two challenges that I seem to most frequently encounter with cross-functional projects are first, the amount of meaningful outcome based collaboration required across these silos by leaders and managers seems to be either under-appreciated or simply under-performed. And second, the way the traditional hierarchical corporation chooses to hold these organizations accountable tend put themselves in conflict far too often and certainly do not incent cross-functional outcome-based initiatives. These two issues cause far greater inefficiencies across many organizations I’ve seen, than much of the efficiency that the Lean/Agile disciplines hope to gain.
I don’t know if anyone has seen this speech given by John Chambers to MIT students, but he is at least claiming that he is re-tooling his organization to function in this cross-functional manner.
It is at the very least, extremely interesting: http://www.antonymayfield.com/2009/03/25/command-and-control-is-dead-the-shape-of-next-gen-organisations-is-social-networks/
Post a Comment