I’ve been thinking recently that the term “self-organizing” has outlived its usefulness in the agile community and needs to be replaced. While self-organizing is a good term, it has, unfortunately, become confused with anarchy in the minds of many. Why has this occurred? Because there is a contingent within the agile community that is fundamentally anarchist at heart and it has latched onto the term self-organizing because it sounds better than anarchy. However, putting a duck suit on a chicken doesn’t make a chicken a duck. As larger and larger organizations are implementing agile methods and practices, the core of what it means to be agile — an empowering organizational culture — will be lost because large organizations will reject the cultural piece of agile because they know a chicken when they see one.

So what words do we use to bring the concept of self-organizing back from the brink of anarchy and return it to the realm of empowering, servant leadership rather than no leadership? In my first book, Adaptive Software Development, I used the term Leadership-Collaboration management to replace the concept of Command-Control management. This book went into great depth about the concepts of leaders (as in a person) and leadership (as in any team member can provide situational leadership) as an active part of an agile community and what that leadership model looked like. In his book, Managing Agile Projects, author and Cutter Senior Consultant Sanjiv Augustine also addresses this issue and calls for management to have a “Light-Touch.” The more I think about Augustine’s term, the more I like it, so I’ll offer a combination term to replace self-organizing: Light-Touch Leadership.

First, I’d like to get away from the idea that agile teams are leaderless and that leadership only revolves around the team depending on the situation (this type of situational leadership does occur, and often, it just does not replace a good leader). There is just too much experience and management literature that shows that good leaders make a big difference. The anarchist wants to eliminate leaders and merely go with situational leadership. However, there is also a large contingent in the agile community that think the right approach is to change the style of leadership, not to eliminate leaders. It’s easy to rail against poor managers or leaders and advocate eliminating them. It’s much harder to work with organizations to change their leadership style to one that supports an agile environment.

Some advocates of empowerment have been carried away. They forget that in the management literature empowerment is a fancy new term for delegation — delegation of decision-making authority. Does empowerment mean that project teams get to make all decisions related to their project? What if there are five teams working on a project, does each team get to make architectural or development infrastructure decisions independently? Light-Touch Leadership means that decision making is delegated to the lowest level possible and as many decisions as possible are delegated to the team. However, delegating decisions in an organization isn’t a simple task; it requires tremendous thought and some experimentation. To me, Light-Touch conveys the right mix of delegation of decision making to teams while retaining appropriate decision-making authority with the leader or in other parts of the organization.

While Light-Touch Leadership may be “light” in terms of decision making, it is heavy in articulating goals, facilitating interactions, improving team dynamics, supporting collaboration, and encouraging experimentation and innovation. These characteristics of a leader are more critical to success than delegation of decision-making authority, but decision making is still an important piece of the leader’s role. When a good Light-Touch Leader is working, she or he is nearly invisible. Things seem to happen smoothly and the teams operate seemingly without a leader.

Leading is hard. If it was easy, every company would be “great,” to use Jim Collins’ term ( Good to Great). Anarchy isn’t the answer; it’s merely a simplistic solution to a very complex problem: managing organizations. What we need are good leaders. What we need is a better leadership style. What we need are managers and leaders who work hard at empowering their teams to the right extent. What we need is Light-Touch Leadership.

My team has been practicing Scrum for over a year. Both our output and our quality are night and day compared to our pre-Scrum environment. Scrum is all about self-organizing teams, but there are still processes and boundaries. It is far from anarchy.

Creating great teams is a delicate balancing act. The term light-touch is appropriate. It also brings to mind a quote from the Tao Te Ching which says “Ruling a large country is like cooking a small fish.” The inference is that too much handling and it can break apart.

Bad leadership can handle teams too roughly or not at all, neither of which is good. May the term “right-touch” leadership is also appropriate. In creating agile teams, leaders may have to “dial” their style at different points in the learning process between light touch, medium touch or perhaps, in some specific instances, heavy touch. Whatever kind of touch it is, it is one that appropriately keeps agile teams together and productive.

From where I sit, to say we have to change leadership style to support an agile environment sounds a bit backwards. Good leaders would know that they need to alter their style to support agility. Leaders (from wherever they sit) are active agents that produce the change needed, not the other way around.

Is it too late to change leaders style deep in leaders’ careers? Or do we simply need to find agile leaders and grow them early in their careers?

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.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. 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.

I feel sure that agile team members and agile managers alike feel committed to the principle of self-organising teams. Although I also feel sure that many managers are so used to command and control that they struggle to implement this principle

I also feel sure that agile managers are equally concerned with managing wider organisational issues and goals. And concerned that some self-organising teams may also be so used to command and control that they wander directionless, or stray off the path the organisation wishes to follow.

So sometimes, quite naturally, those two things will conflict. And it’s on these occasions, the manager has to coach, steer and sometimes direct.

I also feel sure that sometimes teams lose their motivation. The manager is not the only person in a team who can provide the leadership to avoid or recover from this situation. However the manager is the person the organisation has made responsible.

By contrast, though, a manager who is completely disengaged, empowering their teams to the fullest extent, is unlikely to inspire.

I’ve written a few blog posts on this topic that might be of interest…

Jim -
Thanks for this perspective. It puts words around one of my problems with “Agile” methodologies and the “practitioners” thereof. I put the words in quotes because the people of which I speak have taken “agile” to mean “no rules” and “no leadership” and “no accountability”. It is these anarchists who keep organizations from trying agile mehtodologies.
I will be using (with attribution, of course) your words to help people understand the difference between “agile” and “anarchy”.

This article seems like one that has a “shocking” headline to grab attention and traffic, yet critiques something very valuable to Agile for reasons that are not relevant to those same teams. Whether or not some people in the Agile community have expressed opinions that from your perspective are “anarchist” is not important to agile teams today. The reality of today’s marketplace is that the large majority of IT projects are not Agile. The large majority of the marketplace do not know Agile as a methodology. The large majority of Agile teams are less than 1 year old. Based on all of these factors, the term “self organizing teams” is highly useful, because it points to a very different leadership model than the dominant mainstream PM oriented model. The other terms are to my mind much less clear. What is “light touch” to an action oriented PM of 10 years experience? The reality is that as managers transitioning to Agile, there is, like the teams, a very different way of working, and a very different body of work to be done. The Agile community to date has done a poor job of articulating what that work is, however there is excellent guidance available in the principles and practices of lean and the toyota production system. I hypothesize that very few businesses in knowledge work understand and have made visible their value chains for example. Instead we have a current preoccupation in IT management of outsourcing teams and development, and with it the potential for continuous improvement and innovation. Perhaps a better focus would be on the new work managers need to transition to? We ask developers to learn test driven development, its time to ask managers to learn TPS, value stream maps, continuous improvement, Pull, Flow, “go and see” (gemba attitude) appropriate agile metrics, etc. and to start bringing their A game to the table. That will be real compelling learning based leadership that teams will respect.

I think there are several organizational issues that could be “unpeeled” with Jim’s comments. First, I believe that teams can work well on their own if their mission is well understood and communication channels are honest and transparent. Secondly, I believe a facilitative-like leader can help even the best teams find resources, resolve conflicts, and move towards their destination quicker than if that person was not in position. Thirdly, I believe organizations made up of collaborative leaders, motivated and creative teams of people, and a transparent process for allocating resources will always create better results than those in which autocratic controls are enforced.

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 be 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.

This is fantastic. It echoes my thoughts on this subject as well, and crystalises why I was so disappointed in Minneapolis but came away from Washington happy.

Getting things done is about discipline. In the “bad” old days of the “Waterfall”, the discipline was enforced from outside the team. With Agile, the team members need self discipline. A leader is still required in Agile, but that leader changes through time. During the Analysis (Feature Injection), the Analyst with most experience will lead the testers and developers. During the Test Specification, the most experience tester will lead the analysts and developers, and finally the most experience developer should lead the design and implementation development so that they can then hand back to the tester, and then analyst for implementation.

One problem I’ve seen is that some leaders do not have the discipline of letting go. I almost wonder if we need to develop our followship skills. (Servant leadership)

That way we let the kids run off but if they are heading into danger we can zip ahead and head them off before they head over the cliff.

Thanks Jim. I think you’ve just set me up for the next five years as well.

Self organizing teams exist. You cannot make them go away by laying down the law with inverted pyramids of oversight just as you cannot make them appear by removing any oversight. In summary You cannot make them go away by labeling them light touch or even big foot.

Self organizing teams are the way work really gets done. In command and control environments they become the ‘underground’ the ‘skunkworks’. The ‘go to gang’ senior management counts on to pull the company’s (chest) nuts out of the fire.

Self organization happens with and/or without management, leadership, or even hall monitors.

What Agile does is takes all the wasted energy out of being self organized and makes it the way the organization runs. This happens because Agile – xp and Scrum in particular – and MAKES management be accountable and responsible for their part of the bargin namely making decisions as to visions, goals, and the WHAT we do. It takes away from management the illusion that it is capable of determining HOW things will be done in the detail. Before you go off , WHAT we do contains all the stuff needed to get the job done – in the eyes of management and the customer. Agile again particularly in xp and Scrum demand that all actions be measured for the value they add to the customer and this inspection must call for the WHATS we do to adapt to the value proposition the customer has.

What this ends up being is Agility in High Ceremony Contracts with governments and legal laden agreements is entirely different than Agility in the Game industry – EXCEPT for the simple fact that neither does one stitch more than needed to get the job done. This happens because people take back their self respect through their self discipline and make it happen. That is what Agile self organization is really about. When a group of self organized people join together to get the job done, be it software, building design, or cleaning the stables. It gets done in a way that everything that needed to be done is complete and nothing diminished the value to the customer.

In closing, self organizing teams reflect what big people do when they go to work everyday.

Often I feel that people would place me in the “anarchist” column. I use the term here in the sense of someone who wishes no one to tell them what to do or how to do it. I know that I reject “most” forms of coercive control and authority, which is the definition of anarchism provided by Tobias’s blog in response to this post.

Jim Highsmith (here to after referred to as Jim) wants to return to the realm of servant leadership. That is return the concept of self-organizing teams back to the realm of servant leadership. I do not believe that we are returning management back to servant leadership because generally management has not been a servant in their role.

If we take software development and divide it into two parts, the business part and the technical part, then I agree that the business part does not have situational leadership as its only means of leadership.

In Agile, IMO, we do not want a feudal system. Ricardo Semler talks about Semco and states, “Product managers reporting to Product directors. Salespeople answered to the marketing director, so on and so forth. It is a feudal system, isolating one team from another, and generating solutions and strategies that serve one department at the expense of another.”

Another quote from Semler, “Man is by nature restless. When left too long in one place he will inevitably grow bored, unmotivated, and unproductive. The cure, I believed, was to encourage managers to exchange jobs with one another.”

Semco felt a minimum of two years and a maximum of five years at any job was sufficient. Plan ahead, maybe even one year, so that the transition to the new job and its responsibilities will be smooth.

Jim talks about how it is easy to rail against poor leaders and much harder to work with organizations to change their leadership style. I agree completely.

If you define a great company as a place that has forgot socialism, captialism, just-in-time deliveries, salary surveys, and the rest of it, and is concentrating on building organizations that accomplish that most difficult of all challenges: making people look forward to coming to work in the morning (paraphrased from Semler) then I agree that a great leader will be at the helm of such a company. If you define a great company as financially successful and use no other metric then the leader could be a great leader or a tyrant.

Jim states that the core of agile is “an empowering organizational culture”. Or to put it in other terms a n culture of delegation and trust.

This is not the common definition of Agile that I am familiar with, however, I do believe that such a goal is worthy.

It is a very difficult task indeed to create an organization of trust and delegation.

For instance, some executives are judged by their ability to make quick decisions on the spot. This is often called an executive decision. An executive could be perceived as weak if he said, “Wait, let me ask Pat, Lynn, and Kim for some advice and then I will get back to you.” In a world where such behavior may be seen as weakness there is truly a lot of work to be done to change the leadership style necessary to support an “agile environment”.

I don’t see an issue with the term, or with the concept, of self-organizing team as long as the scope of self-organizing is limited appropriately. Short answer, assume people can fill in the details.

If there hasn’t been a lot of feedback (relative to the shock value of the article title), it could be that many see the concept of self-organizing as a non-issue. As with everything else, and everything with Agile, it is the implementation of the principles that is the challenge (a.k.a. the devil is in the details).

I personally don’t have a problem with the term “self-organising” as I’m sure anyone who’s worked as a Scrum Master/Agile Coach will testify the biggest headache is getting the team and the business to talk and remain focussed on the goal. There is a legacy of command/control & blame working practices that people are reluctant to give up over night.

There is always going to be a degree of hand holding required to make everyone work as a team of peers but I see that as part of the process.

Seems to me this article was written with not a full understanding of what agile is about. We as well have been using scrum for years with a huge improvement in our output in both quality and quantity.
Self-organizing teams usually wind up picking (directly/indirectly) a ‘leader’.
The side-effects and benefits of agile is the removal of unnecessary people in a system. It takes a while for people to learn how to be self-organizing – that’s where a coach helps. But to expect change overnight is the exact mentality that got industries into a bind; investing in the immediate return is way to short-sighted and thus unable to adapt.

Agile is about “What works”, “sustainable pace”, and not being thought to be mad or maverick the whole time by the senior management who hold the purse strings (and we’ll never get rid of that level however we try). If we remain maverick, senior management will always see us as a risk. We need to be innovative and lean, but without reinventing the wheel each time we embark on a project. There are certain patterns of team structure which will repeatedly emerge from the self-organisation, and which we can re-use. Scrum is not the only Agile approach. For Agile with clear team structure, take a look at DSDM Atern on http://www.dsdm.org (it’s free to look even if it does ask you to sign in). Here we have, I believe, the “light touch” approach – the re-use without imposition of anything mandatory. Just because roles are defined does not mean we have to slavishly adopt them. Agile is about common sense and establishing the environment in which we can exhibit this common sense.

The point of “self-organizing” in Scrum is that the team needs to find the fastest path to the goal and execute on it. The management can’t know what the situation on the front line and the team needs to take the best possible action in real time. This is the way the Marines have to work as soon as they enter a combat situation. And the same approach is very disciplined at Toyota.

The anarchists can be dealt with by demanding that teams know their velocity and showing they are constantly improving while delivering on the product backlog in order of business value This turns out to be as much of a management problem as a team problem because good teams do not go into a hyperperforming state until management is crystal clear on the business goals and has a product owner function that clearly delineates functionality with an agile specification that the devlopers can cleanly deliver on. The product backlog needs to be estimated carefully by the team that is going to deliver it.

Surveying teams all over the world shows that the majority of companies can’t deliver on this. As Edward Deming pointed out they incent individuals to optimize locally generating internal competition and confusion which suboptimizes global revenue. Professor Peter Senge at MIT (see The Fifth Discipline, Second Edition) views U.S. management as based on medicrity where people who do not understand process force their employees to work harder and harder to become less and less production. Thus the discussion this week is when Toyota will force GM, Ford, and Chrysler into bankruptcy.

I’m currently senior advisor to a Venture Capital group working with their portfolios companies. We will only fund agile companies. The biggest problem is gett the management to understand how a “pull” process works. Many of the CEOs went to business school, some of them even to Harvard Business School, and they missed the course on why Toyota is eliminating the U.S. auto industry. The business school professors tell me it is their fault because most of their students want to learn global finance and they could care less about productivity.

So the anarchists you are worried about certainly exist but they are a small minority and not the main problem. At the venture group we focus on the management and educating them at the Board level because that is the core problem.

Over the last one month, I have been taking a close look at the underpinnings of Agile – the Twelve Principles of Agile Software. Specifically, with reference to their applicability to enterprise-class system development.

Most of these principles attempt to provide simple solutions to a complex problem, which is the same as simplifying the problem itself.

While “simplify” is a good slogan (and I use it too at times when the complexity completely defeats me), it should not taken too far either. Everything in moderation.

[...] Self-Organizing Team versus Anarchy First, I’d like to get away from the idea that agile teams are leaderless and that leadership only revolves around the team depending on the situation (this type of situational leadership does occur, and often, it just does not replace a good leader). There is just too much experience and management literature that shows that good leaders make a big difference. The anarchist wants to eliminate leaders and merely go with situational leadership. However, there is also a large contingent in the agile community that think the right approach is to change the style of leadership, not to eliminate leaders. It’s easy to rail against poor managers or leaders and advocate eliminating them. It’s much harder to work with organizations to change their leadership style to one that supports an agile environment. [The Cutter Blog » Blog Archive » No More Self-Organizing Teams]. [...]

[...] Some people have called this light-touch leadership – decision making is delegated to the lowest level possible and as many decisions as possible are delegated to the team. Characteristics include: articulating goals, facilitating interactions, improving team dynamics, supporting collaboration, and encouraging experimentation and innovation (from No More Self-Organizing Teams). [...]

So you don’t like anarchism as a term? Why? You give no reason for this – anarchism is a broad church – just like capitalism or company – but it only means without a hierarchy.

Similarly the term leader has become loaded and perhaps you should avoid that term in a similar light? I feel the term manager is better. In comparison the word leader in German is Führer – that is now avoided and instead the functions and term that would be used is now co-ordinator. The dictatorial elements being avoided in most settings and power redistributed.

Self-organized, co-ordinated teams might be a better way to present what you talk about. The co-ordinator OR manager then just performs a rôle much as the secretary performs a rôle or the “plant”. Prof. Belbin explored this in his analyses of teams.

The problem comes when people load the terms Leader or Anarchist – and invest therein other things that are not quintessential – so for example the co-ordinator, does not have to decide everything! And neither do the individual teams have to be antagonistic or spurn co-ordinator’s counsel because they are self-organizing and have to be autonome.

so rather than contradicting myself – I am saying that the term anarchist if properly understood is fine. no need to compromise with the term self-organize and then to avoid that for agile – which no-one understands.

[...] Some people have called this light-touch leadership – decision making is delegated to the lowest level possible and as many decisions as possible are delegated to the team. Characteristics include: articulating goals, facilitating interactions, improving team dynamics, supporting collaboration, and encouraging experimentation and innovation (from No More Self-Organizing Teams). [...]

[…] Some people have called this light-touch leadership – decision making is delegated to the lowest level possible and as many decisions as possible are delegated to the team. Characteristics include: articulating goals, facilitating interactions, improving team dynamics, supporting collaboration, and encouraging experimentation and innovation (from No More Self-Organizing Teams). […]

Categories

About the Blog

The Cutter Blog is an offshoot of Cutter Consortium, a boutique IT and Business Strategy consulting firm located in Boston, MA. Cutter's worldwide network of consultants offers clients analysis of the lastest industry trends, customized consulting and executive education opportunities.

Offering more than just a quick fix -- our size and focus allows us to "get deep" into the challenges faced by our clients so we can provide real and lasting solutions. Want to know more? Visit www.cutter.com.