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 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:https://lithespeed.blogspot.com/2007/09/agile-project-management-role-of.html
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.
