What?s wrong with this scenario? Bob, your VP of Engineering brings a ScrumMaster, a Java developer, a UX (user experience) specialist, and a Linux admin into his office. ?We need to build this widget app,? he says, describing what a product manager told him she wanted. ?So go ahead and self-organize.?
Bob?s intentions are good, right? After all, Agile teams are supposed to be self-organizing. Instead of giving the team specific directions, he laid out the general goal and then asked the team to organize themselves in order to achieve the goal. What could be more Agile than that?
Do you see the problem yet? Let?s shed a bit more light by snooping on the next meeting.
The four techies move to a conference room. The ScrumMaster says, ?I?m here to make sure you have what you need, and to mentor you as needed. But you three have to self-organize.?
The other three look at each other. ?Uh, I guess I?ll be the Java developer,? the Java developer says.
?I?ll be responsible for the user interface,? the UX person says.
?I guess I?ll be responsible for ops,? the admin volunteers.
Excellent! The team is now self-organized!
What?s wrong with this picture, of course, is that given the size of the team, the constraints of the self-organization were so narrow that there was really no organization to be done, self or not. And while this situation is an overly simplistic example, virtually all self-organizing teams, especially in the enterprise context, have so many explicit and implicit constraints placed upon them that their ability to self-organize is quite limited. As a result, the benefits the overall application creation effort can ever expect to get from such self-organization is paltry at best.
In fact, the behavior of self-organizing teams as well as their efficacy depend upon their goals and constraints. If a team has the wrong goals (or none at all) then self-organization won?t yield the desired benefits. Compare, for example, the hacker group Anonymous on the one hand with self-organizing groups like the Underground Railroad or the French Resistance in World War II on the other. Anonymous is self-organizing to be sure, but has no goals imposed externally. Instead, each individual or self-organized group within Anonymous decides on its own goals. The end result is both chaotic and unpredictable, and clearly makes a poor example for self-organization for teams within the enterprise.
In contrast, the Underground Railroad and the French Resistance had clear goals. What drove each effort to self-organize in the manner they did were their respective explicit constraints: get caught and you get thrown in jail or executed. Such drastically negative constraints led in both cases to the formation of semi-autonomous cells with limited inter-cell communication, so that the compromise of one cell wouldn?t lead to the compromise of others.
In the case of self-organizing application creation teams, goals should be appropriately high-level. ?Code us a 10,000-line Java app? is clearly too low-level, while ?improve our corporate bottom line? is probably too high-level. That being said, expressing the business goals (in terms of customer expectations as well as the bottom line) will lead to more effective self-organization than technical goals, since deciding on the specific technical goals should be a result of the self-organization (generally speaking).
The constraints on self-organizing teams are at least as important as the goals. While execution by firing squad is unlikely, there are always explicit constraints, for example, security, availability, and compliance requirements. Implicit constraints, however, are where most of the problems arise.
In the example at the beginning of this article, there was an implicit constraint that the team had precisely four members as listed. In real-world situations teams tend to be larger than this, of course, but if management assigns people to a team and then expects them to self-organize, there?s only so much organizing they can do given the implicit management-imposed constraint of team membership.
Motivation also introduces a messy set of implicit constraints. In enterprises, potential team members are generally on salary, and thus their pay doesn?t motivate them one way or another to work hard on a particular project. Instead, enterprises have HR processes for determining how well each individual is doing, and for making decisions on raises, reassignments, or firing ? mostly independent from performance on specific projects. Such HR processes are implicit constraints that impact individuals? motivation on self-organizing teams ? what Adrian Cockcroft calls scar tissue.
A Hypothetical Model for True Self-Organization on Enterprise Application Creation Teams
What would an environment look like if the implicit constraints that result from traditionally run organizations, including management hierarchies and HR policies and procedures, were magically swept away? I?m still placing this discussion in the enterprise context, so business-driven project goals (goals that focus on customers/users and revenues/costs) as well as external, explicit constraints like security and governmental regulations remain. Within those parameters, here?s how it might work.
The organization has a large pool of professionals with a diversity of skills and seniority levels. When a business executive identifies a business need for an application, they enter it into an internal digital marketplace, specifying the business goals and the explicit constraints, including how much the business can expect to pay for the successful completion of the project given the benefits to the organization that the project will deliver, and the role the executive as project stakeholder (and other stakeholders) are willing and able to play on the project team. The financial constraint may appear as a fixed price budget or a contingent budget (with a specified list of contingencies).
Members of the professional pool can review all such projects and decide if they might want to participate. If so, they put themselves on the list for the project. Members can also review who has already added themselves to the list and have any discussions they like among that group of people, or other individuals in the pool they might want to reach out to. Based upon those discussions, any group of people can decide they want to take on the project based upon the financial constraints specified, or alternately, propose alternate financial arrangements to the stakeholders. Once the stakeholders and the team come to an agreement, the team gives their commitment to completing the project within the constraints specified. (Of course, if there are no takers, the stakeholder can increase the budget, or perhaps some kind of automated arbitrage like a reverse auction sets the prices.)
The team then organizes themselves however they see fit, and executes on the project in whatever manner they deem appropriate. They work with stakeholders as needed, and the team (including the stakeholders) always has the ability to adjust or renegotiate the terms of the agreement if the team deems it necessary. The team also decides how to divide up the money allotted to the project ? how much to pay for tools, how much to pay for the operational environment, and how much to pay themselves.
Do your application creation teams self-organize to this extent? Probably not, as this example is clearly at an extreme. In the real world, the level of self-organization for a given team is a continuous spectrum, ranging from none (all organization is imposed by management) to the extreme example above. Most organizations fall in the middle, as they must work within hierarchical organizations and they don?t have the luxury (or the burden) of basing their own pay on market dynamics. But don?t fool yourself: simply telling a team to self-organize does not mean they have the ability to do so, given the goals and constraints that form the reality of the application creation process at most organizations.
