I have been going back in forth with several coworkers on two seemingly contradictory points. We want to see teams self-organize and take personal ownership for what they do and how they do it. Simultaneously, most teams can’t seem to make the leap at first. As Jeff Sutherland has proposed, sometime teams need “Shock Therapy” to become effective Agile teams. Yet this seems counter intuitive to the idea of self managing teams. By definition, does the jump start actually impede the team from achieving self-sufficiency. How does an organization know when structure is needed for a team or when it is ready to move on it’s own?

The premise to a shock therapy bootstrap is that, by using a strict framework to introduce a team to Scrum, the team can learn the mechanics faster and become productive. Many items that are important in the long term, such as the team agreeing on a definition of when their work is done, are dictated by the jump-starting ScrumMaster. Later, when the team has achieved a certain level of productivity, the ScrumMaster backs off and eventually lets the team adjust their practices, so long as they remain true to the principles of Scrum. The natural concern is that eventually the team must outgrow this arrangement or begin to chafe under the control. Indeed, it would seem that such a strict interpretation, if it were to go on indefinitely, would become quite a hindrance to the team. It is as if there’s a progression a group goes through as it matures to a productive team.

While I could try to define an entirely new hierarchy, I decided to apply to Maslow’s hierarchy, which consists of 5 levels. The key to this model is the nature of the hierarchy. If a lower level is not met, then a higher level does not matter. If someone’s safety is threatened, their esteem and sense of accomplishment will not matter towards their happiness. Conversely, once a level has been achieved, getting more of that will not make you happier. Physiological things, such as air and water, are good examples of these factors, or even the person who wins the lotto only to find it doesn’t actually improve their life. Attempting to meet a given need for one individual may not be at all valuable based on where they are in the hierarchy.

If we take this same structure and apply it to a software development team, we see a reasonable alignment between the five levels. While Maslow’s hierarchy was based on human needs, our approximation would be that meeting the needs of a team allows it to be more productive.

1. Physiological – This would be the basic tools and resources required to run a team. It could be workstations, software or perhaps even funding
2. Safety – This would better be characterized as “order”. Team members would not need to worry about product owners completely changing what they want mid-iteration.
3. Love/Belonging – While we don’t need to venture into love at the work place, the value of a team’s cohesion and trust is quite important.
4. Esteem – self worth within a team would first be based on technical mastery, it may be engineering best practices, business accumen, or whatever other domain the team operates within.
5. Self-Actualization – This highest level would be when the team moves beyond simple efficiency and begins to focus on effectiveness. It would be represented by a group that takes advantage of the ability to change course between iterations and focuses on business value and continual improvement.

In general, it seems the lowest levels relate to basic order and structure. If we look at the shock therapy model, we see attempts to meet the three basest levels. Effectively enforcing a basic implementation of scrum meets the needs of the security level. The key goal of identifying a major pain point and resolving it, talks to ensuring physiological needs are met. Even the approach of coming as an outsider to help improve team cohesion addresses the third level of belonging. Thus, this approach may provide an effective bootstrap to quickly meet the lower needs and ultimately move to those levels where the team focuses on efficiency and effectiveness. Of course, for a team to achieve a true sense of achievement and actualization, the ScrumMaster would eventually need to back off, consistent with the model of staying with a team for a finite period of time and phasing in a permanent replacement. In fact, I could see a serious risk if such an approach were implemented and the jump-starting ScrumMaster never backed off.

Beyond demonstrating the shock therapy model, this idea of a progression lends insights into my own personal experiences. When discussing this framework with a coworker, one of the first things he pointed out was that no company would really be willing to spend money on the lower levels. In fact, when dealing with clients, they are generally focused on the top levels of improved efficiency and effectiveness. This would certainly help demonstrate challenges I have seen as a coach trying to help a team self-organize when it is completely overwhelmed with the change initiative in general. This also offers some guidance when ambitious teams are trying to figure out which practices to adopt when, the example of adopting XP practices before or after implementing a basic scrum comes to mind.

This still is not a perfect model, as one could argue that a need belongs to different levels, and hence there is not a perfect science for assigning the precedence of needs. The real importance of this framework is to identify a team’s position along a developmental path and to help them move along it as opposed to view the team’s practices as a set of capabilities to simply be achieved. Such a perspective allows a coach to properly balance when discipline is required and when self-organization is ready to occur.

I certainly have more to say on this topic, as applying the model to different situations can help explain why certain types of intervention and coaching may or may not be successful. There is also the challenge that most organizations looking to capitalize on Agile – or any improvement process – are concerned with the top levels of efficiency and effectiveness, not the lower order ones required to achieve them. I have also used Maslow’s hierarchy for simplicity sake, but am not sure that a more complex one, such as Bill Torbert’s 7 levels of Action Logic as defined in the book Action Inquiry would more accurately represent a team’s progression. In the meantime, I would certainly be curious what other people think or if they’ve used something similar in their practice.