This question comes up more and more: Is pushing practices on teams aligned with Agile values and principles? The answer may surprise you…let’s take a look.
Specifically: How does the OpenSpace Agility approach differ from the typical style of forcing practices on teams?
It comes down to “open space,” where conversation and connection is valued, versus “closed space,” where conformity and compliance is valued:
- Fundamentally, OpenSpace Agility (OSA) creates an “open space” where everyone affected by the “Agile transformation” gets an opportunity to express what they think and feel, about how it is going.
- In OSA, the emphasis is on cycles of experimentation, and inspection of the change process itself, at the level of enterprise or “the whole group.”
- The result is very high levels of self-management across the enterprise. This is why OSA works.
- Meanwhile, the typical “Agile transformation” creates a “closed space” where where everyone affected by the “Agile transformation” gets an opportunity to “be obedient” and “be told what to do.”
- In the typical “Agile transformation,” the emphasis is on a “push” of practices upon teams, usually by entirely well-meaning yet fundamentally misguided executives.
- The result, sadly, is very high levels of disengagement and even active resentment across the enterprise. This is why typical “Agile transformations” fail, and do not actually “transform” anything at all.
You can learn more about OpenSpace Agility here: http://www.openspaceagility.com/about
The following is a compare-and-contrast of the OSA approach, and the typical, commonly accepted and commonly implemented assess/train/coach “Agile transformation” approach. The intent of presenting this data is to establish the fact that OSA is 100% aligned with Agile principles, while the typical assess/train/coach “Agile transformations” is clearly not aligned with Agile principles in any coherent way.
|Well-established Agile Pattern||Does the “pull”-based OSA Approach Support This This Aspect of Agile?||Does the typical “push”-based approach Support This Aspect of Agile?|
|Build projects (and products) around “motivated individuals.”||YES. In pull-based approaches such as OSA, we identify willing people and work with them, training and coaching the teams that explicitly opt-in to this style of work||NO. Typical assess/train/coach “Agile transformations” do not make any distinction between willing and unwilling teams. This is the same as disregarding the Agile Manifesto.|
|Iteration||YES. OSA’s enterprise-wide iterations are called “Chapters” and are 45 to 100 days, and punctuated by a whole-group meeting in the Open Space format.||NO. The basic process is waterfall: assess, then train, then coach. And this is “until further notice,” with no whole-group iterative inspection event focused on inspecting the *process* of changing.|
|Experimentation||YES. This is core of pull-based approaches and OSA. During a 45 to 100 day enterprise-wide iteration, teams conduct experiments with practices that align with the Agile Manifesto. They then inspect the experience with these practices using a whole-group meeting event.||NO. Typical assess/train/coach “Agile transformations” typically follow a strict framework-based sequence, and the practices in the framework are forced on the teams who are affected. Teams are not encouraged to experiment with practices. Instead they are told to follow a procedure mandated by executives and implemented by the Agile “coaches” who serve these executives.|
|Inspection/Retrospective||YES. Every iteration in pull-based OSA starts and ends with an whole-group, enterprise-wide meeting in the “everyone is invited” Open Space format. The actual process of changing is inspected, by everyone affected, to make sure the change is actually serving the organization’s wider business objectives and the people who make it happen.||NO. Retrospectives are usually at the team level, usually never the “whole group, everyone invited” enterprise level. In those very rare cases where the whole group engages together in retrospective, the focus is always on the projects and products rather than an inspection of the process of changing. And if they do inspect the change-process, it is only the short list of “higher ups” who are quietly invited to attend a closed-door meeting. Typical assess/train/coach “Agile transformations” never engage in whole-group inspection of the change-process itself.|
|Adaptation||YES. Within the constraints created by the Agile Manifesto’s 12 principles (or better,) the entire enterprise engages in adaptive behaviors. Pull-based approaches like OSA encourages enterprise-level adaptive behavior.||NO. Typical assess/train/coach “Agile transformations” do not inspect the process of changing with the whole group, so there is no adaptation-in-fact. Instead, there is usually a forcing of practices on teams, with no whole-group discussion of how well those mandated practices are actually working.|
|Organizational Learning||YES. The pull-based approach generates organizational learning by inviting everyone into a periodic, iterative, whole-group, consent-based process that encourages everyone to participate and contribute to the inspect-and-adapt process. These whole-group meetings are important “signal events” that trigger and leverage whole-group collective intelligence, which is the true heart of Agile||NO. Typical push-based assess/train/coach “Agile transformations” never engage in whole-group inspection of the change-process itself. It’s compliance over consent, imposition over invitation, and mandate over mutual respect. Organizations cannot learn in the “closed space” created by these design elements.|
|Self-Management||YES. Pull-based approaches in general (and OSA in particular) encourages self-management by encouraging executives to encourage teams to make decisions that directly pertain to the team’s work.||NO. Typical push-based assess/train/coach “Agile transformations” make decisions for teams, and typically without their consent. This lack of consent encourages disengagement (and even resentment) instead of engaged self-management.|
|Self-Organizing Teams||YES. Teams are provides with enough decision-making authority to manifest genuine self-organization.||NO. Self-organizing teams get that way by choosing who has influence over decision-making. In typical push-based assess/train/coach “Agile transformations,” teams do not make decisions that affect them. Instead, an external “authority” tells them what they “should” do. This is in complete conflict with the Agile Manifesto.|
|Give them the environment and support they need||YES. In OSA, execs authorize teams to make decisions that pertain to their work and work process. OSA encourages the harvesting of whole-group collective intelligence.||NO. Typical assess/train/coach “Agile transformations” assume that “executive buy in” is all that is necessary for success. This is the same as completely ignoring the Agile Manifesto. (In truth, *everyone* affected must agree to at least “suspend disbelief” if the Agile initiative is to succeed.)|
|Trust them to get the job done||YES. In OSA, execs learn to signal support for iterative work, inspection, adaptation, and team-level decision making with intent to foster and manifest self-managed teams. In OSA execs learn to trust teams to do the right thing.||NO. In typical assess/train/coach “Agile transformations,” teams are not trusted; instead the practices are trusted, and assumed to be sufficient, regardless of what teams think about these practices. This is the same as completely disregarding the Agile Manifesto.|
|Individuals and Interactions||YES. OSA punctuates enterprise iterations of change with whole-group Open Space events. These events are focused on people and communication, that is: individuals and interactions.||NO. Typical Typical assess/train/coach “Agile transformations” focus on practices and processes and tools. There is typically no whole-group participatory process. Instead there is trust and emphasis placed on proper processes, tools and practices. Once again, this is the same as completely disregarding the Agile Manifesto.|
|Respect for People (a core pillar of Lean)||YES. In OSA, practices are not imposed on teams. Instead, team members are invited into an Open Space event to discuss Agile Manifesto principles and do experiments that use these principles as guidance.||NO. Imposing practices on teams not only KILLS any potential for “self organizing teams,” it is fundamentally DISRESPECTFUL of people.|
|Continuous Improvement (a core pillar of Lean)||YES. OSA represents genuine PROGRESS and gets better results compared to to the failed status-quo of imposition.||NO. The process of introducing Agile into organizations has not changed in over 15 years. Forcing training and practices on the whole organization does not produce transformations and if it did, we would be celebrating literally *thousands* of verifyable success stories worldwide. This is obviously NOT happening, Agile adoptions routinely FAIL worldwide and the Agile Industry is completely silent about it. The alarmingly high rate of FAILS is the biggest issue facing the Agile Industry today and the “thought leadership” is either not thinking, not leading, or both.|
You can learn more about OpenSpace Agility here: http://www.openspaceagility.com/about