It seems clear that the author of the post is very fond of the wonderful utopia-fully world things.

The list of cited assertions will be true only when developers (talking only on software) are very (but very very) good developers.

How many developers are able to take right decisions based on overall business criteria such as sales priorities, customer's actual needs, marketing intentions, productivity optimization, ... as well as decisions related to its main responsability such as maintenable designs, suitable usage of patterns, good user interfaces, code optimization, etc, etc, etc ???

Only a few ...

Different responsabilities must be distributed among different people with different profiles, experience and background and, belive it or not, it is also demonstrated to be "better" (not the best !!).

I don't think it's necessarily an either/or situation. What you're describing sounds awfully like a committee. I believe you need individuals responsible for teams (and, looking higher up the organization chart, departments etc.). However, the good points that you describe only get killed off if you set up a dictatorship. Any half-decent leader will encourage contribution from the team, who will recognize when good decisions are made given the circumstances (which they are made aware of).

@FHierro,

> It seems clear that the author of the post is very fond of the wonderful utopia-fully world things.

It's not clear.  Can you explain why?

>How many developers are able to take right decisions based on overall business criteria

>such as sales priorities, customer's actual needs, marketing intentions, productivity

>optimization

Not many.  Certainly not me, but that's not the developer role.  That's the product owner (or "customer") role.  As a developer, it's not up to me how to balance sales priorities with marketing, etc.  That is a very tough job indeed, and if the software team is tasked with that, it's poorly managed (or a company of 1).  Rather, a healthy software team will have qualified people manning all necessary roles.

>Different responsabilities must be distributed among different people with different profiles

You have it correct here, so I'm confused about your meaning in the previous paragraph.

------------------

In my last engagement, I trained a product manager who had never done that job before (had never been involved with software).  If was tricky at first giving up control of the roadmap priority (I was in a management position on the team), but as a company we made it his responsibility to weigh all business factors to have the roadmap prioritized and clarified.  It took a few weeks, but in the end, we decentralized control, and the team sped up considerably.

As Ian notes above, I think it is a matter for finding an appropriate balance based upon the individuals and the situation.  As Jeremy notes that are good things that can possibly happen with a self organizing team and bad things that can happen with central leadership.  To be fair, however, there are also some bad things possible with a self organizing team and good possibilities with a central leader.

Lacking a central leader, a self organizing team can generate a power struggle as members try to take on decision making authority.  The group can split into two competing groups.  Though a central leader cannot prevent this type of group dynamic, he can take steps to minimize its effects.

Meeker team members and those with less confidence can end up doing most of the menial tasks while the more interesting tasks go to the more aggressive and more self confident.  A central leader can overcome this tendency by steering some of the more challenging work to the meeker members and ensuring the more outspoken do their share of the boring tasks.

It is easier for someone to carve out a role on a self directed team and stagnate.  It is useful at times to have a central leader who can push someone in a new direction.

I am not in favor of a completely self directed team, but neither do I favor having an absolute leader who makes all decisions.  I feel the ideal is a leader with a light touch who is able to adjust his style based on the situations and personnel on the team.

> The list of cited assertions will be true only when

> developers (talking only on software) are very

> (but very very) good developers.

Were we trying to take on something as failure-prone and complex as a software project with mediocre developers?  Hmm... never really thought of arbitrarilly putting so much at risk.  Interesting approach.  Kinda like letting the lunatics run the asylum.  Makes for good headlines.

I never can figure this out - if you have mediocre developers, why do people never invest any time and money to make them better?  

Scott - Agreed.  You either have invested wisely in some people that you can trust to do their jobs or you're wasting your money.  It's no different than anything else.

WayneMack - "A central leader can overcome this tendency by steering some of the more challenging work to the meeker members and ensuring the more outspoken do their share of the boring tasks."

I'm sorry, I've never seen this work.  The busier/productive the leader, the more likely he/she will let inertia carry everyone forward.  After all it's working, right?  It's just like coaching kids sports teams, you decide Jimmy can catch, and that's all he'll ever do.  You don't take your #1 QB and teach him to kick field goals.  

On the other hand if you have a good team of people you've invested wisely in (ie not wasting money, and thus competent enough to enjoy customers) then that team tends to be self-correcting.  If I see Joe has done UI work for the last 3 years, I'm more likely to see if he wants to take one of "my" device driver tasks.  As a team member, I'm more open to people trying new things because it's not directly my fault if the team falters for a couple days, unlike the "Commander" who will be criticized if output appears to drop for a week.

That said, there has to be a leader.  No doubt about it.  You stick 5 developers in a room and withold pizza until they come up with a decision and someone's going to die.  We definitely need nudging and a final authority to appeal to.

I can personally attest to the success of self-organizing teams (organic).  I manage a team of 15 developers all with varying skill sets and I am a true believer that the collective consciousness of many is far more powerful then the individuality of task based assignment.  The most important aspect of successfully managing a team of developers is easy.

1. You have to be a developer yourself.  If you don’t know how to code don’t manage developers period!!!!  And knowing COBOL doesn’t count!

2. You have to manage the team not the individuals.  Think of yourself more as a coach not a manager.  Maximize your assets by understanding your team’s weakness and strengths.

3. If you have mediocre programmers (first off yikes!) second as long as they show a willingness to learn, paired programming is the key to success for bringing the juniors up to par with the seniors.

4. Empowerment, allow EVERYONE to take ownership of stories and task.  If a junior wants it let him/her role with it.  Your TDD practices along with the pressure from their peers will make certain it is done correctly.  Ever fumbled the ball playing football?  I am sure your team wasn’t too happy with you and you made certain not to do it again.

5. Embrace the fact that your team need to understand their goals!  What they are playing for?  What is the goal for the week (Velocity, Stories)?

6. They need a way to measure and understand if it is 1 and 10 or 4 and 20? Information radiators coupled with a good agile project management tool such as Target Process, RallyDev or even XPlanner can help with this.

7. Coach them every day!  Think of your standup as halftime.  If they are behind you need to pep them up help them understand the why the defense is getting beat or why the offence can’t score.  If they are ahead you need to continue with the positive motivation.  

8. Get rid of your heroes!!!! You know who they are the ones that always want the ball who yell at the other players for not doing what they want.  They are a cancer and must be removed.

I can go on…I smell a post coming

Joe Ocampo

There's actually an interesting read on this, a book titled "Creating Leaderful Organizations" that I recommend.  It's an interesting idea which I happened to post about myself a while back.  Always good for stirring up a debate.

I work in a highly C&C environment (by its very nature) and unfortunately there's no changing it -- so I've had a lot of time to think about this very subject. I've boiled it down to this:

If you want to be really successful, hire talented, smart people and enable them to be talented, smart people. If you have to impose restrictions and process to prevent errors from happening, it's usually to compensate for a weak or uncooperative member of the team.

Unfortunately, in many circumstances, process and security restrictions are unavoidable: a.) Government work in general, b.) SOX requirements c.) HIPPA (or other various medical-privacy-related regulations).

It has been my experience (not that that counts for much) that it is darn near impossible to do any sort of agile-type development in this kind of environment. Waterfall is almost completely inherent and required in the system (even though, not surprisingly, it's even less successful than in other 'normal' waterfall scenarios).

It seems that some sort of iteration is inevitable no matter which 'methodology' you choose or is hoisted on you and the more process you have in place, the more difficult and painful this iteration is (and the more frustrated everyone gets).

The only way I've found to work in this type of environment is to have one really Smart Person(tm) (though I'll settle for a Knowledgeable Person(tm) when it is the only alternative) from each interest group and keep these people very close so that the turn around time for the red-tape is kept to a minimum.

I posted something kind of like this a couple of months back about the hardest part of being an agile manager.  See www.agileprogrammer.com/.../22180.aspx

Good post. Further to your first point about decision making latency: The latency is proportional to the distance the decision maker is away from the point where the decision is needed. This is often far away from the coal face (hierarchically, geographically, or both).

There are knock-on problems: Small decisions aren't possible because the latency is too great - you'll spend all your time waiting around. And because decisions are bigger than they need to be, they aren't easily reversible. (If you try to reverse them you have to traverse the hierarchy again adding more latency). Which means it's more difficult to fail fast, learn, and try something else.

Self-organisation only works if people are (and importantly feel that they are) empowered to make decisions, own the necessary authority, are prepared to be responsible and hold one another accountable to their commitments.

well, why does sound like it's two divergent approaches when i see that it's not?

the mistakes that happen in teams that has TeamLeader (IMHO) is not due to the structure, but it's due to the way it's done.

it boils down to the behavior which the TeamLeader takes to solve issues; so if he did the right thing (by being a true leader and giving good chances to others to proove them selves...and all the good suff jeremy said about self-organized team)...if the team leader paved that environment...then you have a successful team.

on the other hand...if the Team Leader's idea about team leadership is to be self centralized and sololy making decisions without any consultation..then thats the failure.

emphasizing on what WayneMack said; it's proved, throughout history as community-structured beings, it's proved that leadership is an essential strategy in order to drive communities (teams are small communities).

where to drive it? well...that is answered depending on what leader you put on that community.

but imagining a team without a leader holds with it all the chaotic attributes something can be described of.

my end point is that you can have the beauty of the two worlds by putting a knowledgable (and thats not in technology only) and smart leader who can get the best out of his team, by helping them, supporting them, GUIDING them (not forcing them)...etc

we are providing solutions to the wrong causes

Most organizations are modeled on military ones.  In a military organization it makes sense to have clear heirarchical structures with little room for questioning or innovation from those who havent earned their stripes.  Most businesses at least claim that they want to be innovative and empowered (especially in our field), and the members of this field tend to be highly trained before they even join the tream (compared to a recruit).  We also have few life-or-death decisions cross our desks.

Based on that, I'm not sure you HAVE to have a central leader IF your employees are trained, enthusiastic, professional, etc.  I'm pretty certain you need a central leader role, but I don't think you have to put anyone in particular into it.  If you have people that you have invested wisely in and they can keep their egos in check, then there's no reason why the juniorest of the group can't lead the way.  In that vein, being the TeamLeader is more like being a parent, you need to enpower your children to lead the way so they can take your role someday.  

So how do you empower the team...uhh...by leading well?  In the beginning you're likely to have one or no members that can create a team concept.  The end goal remains to create a team of leaders.  And once everyone is a "leader" there is no central smart leader, but a self-organized kick-arse team where the least capable can shape and manage the vision.

Of course, I'm not sure if that works well unless vision/leadership is shared and egos are left at the door.  That may be too hard to pull off in an organization, in which case strong decisive leaders or the ability to weed out undesirables  are needed.  I think you can go very far with a strong leader, but I think the potential is even higher with a TEAM of strong leaders.

The McCarthys have extensive experience in helping people to self-organize into a hyper-producive (jelled) teams. see

http://www.mccarthyshow.com/

One of many things I love about Ayende is the tagline in his blog " Specialization Is For Insects

Pingback from  On Software Teams « Tuff Stuff

This entry is definitely going to be a mixed entry.First off I want to point out a cool tool with source...

It's been about half a year since I threw out my My Programming Manifesto , and I've started

About a year ago I hit a patch where I wasn't able to blog much (something about finding a new job

I sat down and re-read my last blog entry. It might have come off in a way that I might not have...

Pingback from  The role of Team System in a Software Factory « IntoFactories.NET

Pingback from  fitnesse.codebetter.com/.../Self-Organizing-Teams-are-Superior-to-Command-n_2700_-Control-Teams.aspx

A disciplined, unemotional approach to stock investing is the most efficient method of portfolio management. Use objective metrics to save time in selecting the best stocks to buy and decide when to sell.

Negative Attitudes are a Cancer to Successful Teams

A hot topic in the agile world is "self-organization". The reaction against tight command and control management structures has swayed the pendulum all the way over to chaos. First, I understand that every team is different, and my views are tainted by

If I have a team of 7 and all 7 of them want to lead, manage and no one wants to do the work.....then self organization seems to introduce a forum for ego centric behavior and ultimately heavy conflict.  This might be darwinian in some respects, but ignores the pragmatic reality that I need them to get things done.