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. And work in large, complex organizations tends to flow across organizational silos. Yes, significant strides have been made in creating integrated teams that collapse some organizational silos. And yes, on those teams, costly handoffs 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 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. 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.

If that was true, during World War II the Third Army would have picked Betty Grable to lead them instead of Patton.

Response:

:-) …and your point? 

This smells like positioning. Its unfortunate. Personally, I’m losing interest in Scrum and how its sold to software developers. I’m much more interested in the thoughts and ideas of people working in the trenches and sharing what works for them. Sometimes this is Scrum, sometimes its not.

Having said all that, I also believe that the process of self-organization can only exist within communities that know each other well. And typically, that ability to know each other diminishes severely once the number of people in that community exceeds 150. So, if the self-organization model is going to thrive and not end up in what I might conclude would anacrahnistic chaos, it will depend on a clear and valuable mission, a group of people who take the lead in a facilitative instead of an autocratic approach, and a small enough organization within which people can get to know and trust each other.

Not sure there’s anything new there, but thought I’d add it just in case.

Enjoy,

David Spann

I think this basically is a “managerial” form of the usual IT arguments over “Agile or not Agile”. I personnally think the way an IT team is organised is not really a key to success. It certainly is a key to well-being and pleasure at work, but let’s face it: a team of good developers will be successful whatever methodology they use, and a team of crappy ones will always equally fail. If there was a key methodology to success over here, we would all know it, wouldn’t we?

I think this is the same with self-organisation. The way a manager delegates, empower his team or acts as an autoritarian tyran is NOT a key to success.

Update: Jim Highsmith has now made the article public at the Cutter blog. 

That’s a bold claim. I wonder, can you can support it with evidence?

Response: Hi MG, That’s a tough challenge :] I suggest you read the Wikipedia entry on anarchism (as a starting point) and then read the New Testament and a Gandhi biography. Draw your own conclusions.  To bring it closer to home… perhaps Thomas Paine was an anarchist too.