Thursday, January 13, 2011

The Fundamental Unit of Agile: The Self Organizing Team

[This blog post is a reprint of an original article I wrote for PM Boulevard. I’m reprinting it here as they require signup to read their stuff.]

In the Agile space there is a lot of talk around “self-organizing teams”. This term is plagued by the same problem as many other trendy catch phrases; it’s made up of a bunch of words that everyone knows which are strung together in such a way that everyone believes they understand what they mean.

There is already a ton of information out there on what a self organizing team is, but for the sake of completeness I will give a quick review.

A mature self organizing team should:
- Understand generally what its goals and constraints are. - Continuously learn about itself, its environment and be able to adapt. - Routinely question the status quo, seeking to remove waste and improve. - Be given the responsibility and authority to actually do everything above.

Sometimes folks get the impression that self organization is a purely ad-hoc, do-what-feels-good, Lord of the Flies environment conjured up by developers to get rid of management and that it will never scale to the enterprise. This could not be further from the truth. Self-organization requires professionals to maintain a high level of discipline in a structured environment. A true self organizing system will scale indefinitely, and, while many of the ideas involved with self-organization indeed challenge traditional Taylor-esque management structures and styles, it does not imply a lack of leadership, communication or coordination.

Often times organizations struggle with how to achieve self organization. This is especially true for businesses that are migrating from traditionally “managed” teams or a command-and-control hierarchal structure. Two areas that cause the majority of the problems with creating self-organizing teams are 1) an understanding and supportive organization and 2) a willing and able team.

An understanding an supportive organization:
It’s one thing for an organization to say it supports self organizing teams and another thing to actually do it.

The first step is to get the current software development management around the teams to understand their new role. The wrong thing to do is just let go of the reins and expect teams to all of a sudden fend for themselves. Management needs to transform into mentors, coaches, and motivational visionaries there to guide teams and help them overcome the eventual obstacles they will encounter.

The second step is to engage the rest of the business to understand their needs and work organizationally to adapt business needs to self organizing practices. This will likely be new information to many other departments in the organization and there could be some challenges as their status quo gets ruffled. The key is to show them the benefits of what they are gaining and mitigate the feelings of loss due to change.

To be certain, this is not an IT-only shift. The biggest mistake management or senior leadership can make is to assume this is not a fundamental change in how the organization, as a whole, will operate moving forward.

A willing and able team:
Not to be underestimated are the challenges and changes an individual team will undergo during its metamorphosis to self organization.

First there has to be a level a willingness on the team, even just to try. The basics should be described to every team member; that they all have a shared accountability for the success and improvement of the team, that is it everyone’s job to learn, ask questions and to challenge things that don't seem to make sense and so on. Sometimes teams jump at this opportunity and others shy away from it. If many of the members are used to traditional hierarchal teams they may want to just come to work and “do their job”. It is important to explain to those individuals why the particular changes are being made and how these types of teams increase the quality of software as well as allow the organization to adapt to changes more fluidly over time.

Unfortunately, not all individuals will acclimatize to this. While this is pretty rare, occasionally it may be required to inform a team member that this is the intended direction of the team, and that if they are not comfortable with the new environment, perhaps they would be better suited elsewhere in the company. To be clear, a transfer of this type should be made genuinely and not as a my-way-or-the-highway threat.

The second consideration is to determine if the team in it’s current state is able. A team needs to have some members that are likely to emerge as leaders as well has have individuals with technical proficiencies and domain knowledge. Sometimes the team lead, tech lead or manager is already providing sufficient leadership, but not always and not always in all areas that require leadership. Often times, in a self organizing team, multiple leaders will emerge. That’s okay. It’s not like leadership is defined or imbued with a title anyway right?

So this all seems really complicated and risky. Why bother?
To be sure, migrating from traditional teams to self-organizing teams should not be trivialized. Quite often it can be useful to being in someone from the outside to spend time with a team to help them with this transformation. This “coach” is certainly not required, but having an effective change agent knowledgable of agile engineering practices and methodologies generally is, whether that person be internal or external. It’s also important to remember it doesn’t have to happen overnight (and probably shouldn’t), simply keep the principles in mind and continually adjust towards the goal.

Edwards Deming showed that, even with automotive factory workers, empowering the lowest levels of an organization greatly increased quality, productivity, and job satisfaction while simultaneously keeping problem solving and decision making flexible and adaptive. This is especially true, and perhaps even necessary, for long-term success when “managing” or organizing knowledge workers. However, in the end your organization can reap the same benefits Deming found. Your software teams will be able to create higher quality products while feeling more autonomy, purpose, and mastery in their jobs while keeping your organization more responsive to change.

No comments:

Post a Comment