BT

Better Agile Adoptions

Posted by Dan Mezick on Sep 21, 2013 |

It’s obvious that the Agile movement is not producing the kind of transformative results that are entirely possible. If current approaches actually worked well, then by now, thousands of organizations would have reached a state of self-sustaining, ongoing, “freestanding” agility.

Clearly, that is not the case.

Stories abound about typical failure patterns.  Organizations that seem to start well eventually slide back to waterfall practices. Organizations employing coaches spend millions to obtain a mere 25 to 30% improvement in whatever they are measuring!

Software development at scale is a very difficult undertaking. The Agile mindset and related principles, patterns and practices can help tremendously. At issue is how to achieve this. What is clear is that few people (if any people) know how to repeatedly generate long-lasting & sustained Agile adoptions at scale. How is this actually done? Who actually knows how? As a consulting and coaching community, we have failed to deliver the promise of Agile to our clients and the wider world. We are stuck.

Typically, Agile practices are implemented as a mandate. Prescribing practices makes no allowance for what people want, what people think, and what people feel. The prescription reduces engagement and causes the intelligent and creative people who do the work to “check out” and disengage.

Usually, the following pattern is used to implement Agile methods, usually after a small pilot test of Agile with a small team:

  • Authority says we are all “going Agile”
  • Authority says we will be using a specific practice, like Scrum, or Kanban, or some other Agile practice, method, or framework. The message is that this is not negotiable.
  • Authority selects a coach on the basis of his or her expertise with the prescribed practices. Typically, Scrum skills. The coach is imposed on the people, just like the prescribed Agile practices.
    • The people who do the work are triggered to disengage by the experience of a low sense of control and a low sense of inclusion and belonging. They learn that the new game is vague, and participating is definitely not opt-in. The Agile adoption is not an enjoyable game because the game is not well defined, and there is no opportunity to opt-out.

Participation in the typical Agile adoption is not an invitation but rather a mandate and a prescription. This is a recipe for a failed Agile adoption. Recall that a hypothesis of Open Agile Adoption is that mandates reduce engagement, and that invitation and opt-in participation increase it. Also recall that another hypothesis of the technique is that engagement is essential for a rapid and lasting Agile adoption.

The people who create software programs typically have these characteristics, especially compared to the general population:

  • High level of intelligence
  • A tendency to be introverted
  • A self image that includes these stories:
    • I get paid to solve problems”
    • I am smart and creative”
    • I get paid for my technology expertise”

Mandated Agile adoptions tend to be repulsive to the intelligent, problem solving people that do the work. One reason might be that these folks literally love to solve problems, including “process problems”, like “how to implement Agile at our company.” Now, since most of the folks are introverted, if we do not ask them what they think, something really terrible happens: they do not tell us.

Often, the very people who do the work, these problem solvers, have an opinion or an idea that can help. By not asking them for help and instead issuing a prescribed mandate, we miss an opportunity to receive help, and also create the potential for considerable resentment. This is a double-barreled negative outcome. We miss what might be the very best ideas, and we miss a huge opportunity to engage.

Better Agile Adoptions

Open Agile Adoption™ is a technique based on invitation, not mandates. A hypothesis of Open Agile Adoption is that mandates reduce engagement, and that invitation and opt-in participation increase it. Another hypothesis of Open Agile Adoption is that engagement is essential for a rapid and lasting Agile adoption, and that Open Space tends to invite engagement and thereby increase it.

A core hypothesis of Open Agile Adoption is that engagement is essential, and that invitation can increase it.

Instead of issuing a mandate of specific Agile practices, Open Agile Adoption employs this pattern, based in invitation:

  • Explain the business case for moving in the Agile direction. Explain the challenges the business is facing in terms of competition, pricing pressure, obsolete products etc.

  • Make it clear the enterprise is heading into an Agile direction. Explain that the Agile direction is definite.

  • Invite everyone involved into the process of writing the Agile story. Communicate that leadership does not have all the answers and is looking for the very best ideas people have to make the move to Agile genuine, authentic, rapid, and lasting.

  • Make it plain that everything that is tried as an Agile practice is an experiment, and is optional, and is going to be inspected, and is not set in stone. For example, if the org is giving the Scrum framework a try, it is an experiment, and subject to later inspection. If an off-the-rack practice like Scrum cannot be tailored and customized to fit well, it will be discarded, and we will try something else that might work. We might even “roll our own” practices, using the Agile Manifesto as our guidance.

By doing it this way, the people doing the work can engage, and have a strong sense of control and of belonging.

Most Agile adoption problems map back to sociological dynamics, not practices. In reality, practices get altered to fit the sociological reality. Story points, for example, are usually the first practice to get “gamed” in a mandated Agile adoption. It’s not the practice of using story points that is the problem—it is the sociological reality that is actually running the show.

A hypothesis of Open Agile Adoption is that the introduction of Agile is a very triggering for most participants, causing them to disengage and even resist the Agile adoption effort. For managers and systems architects, the worries triggered by Agile are very acute. Mandated Agile practices simply amplify these worries by causing disengagement and ultimately, resentment.

One way to handle the stress and worry routinely created by Agile adoptions is to look to cultural anthropology… for ideas about how to do better. As it turns out, all kinds of cultures in all kinds of places have employed rites of passage to handle the stress of transitions. A move to Agile is obviously a very big transition.

Open Agile Adoption leverages know-how from cultural anthropology, and creates a rite of passage that begins with an Open Space meeting. The entire passage rite is a kind of game. In place of a mandate is an invitation to play the game . Inside the middle part of passage rite, learning takes place as the result of experiments. People play with Agile. The serious learning is harvested and integrated by the organization at the end: again, in Open Space.

Open Agile Adoption Terminology

The following terms and words are employed in Open Agile Adoption, so you might want to take a moment to examine these definitions:

Liminality: A stressful state of being created by transitions. Agile adoptions create liminality.

Passage Rite: A ritual for handling the stress of change inside a culture. Passage rites help handle the liminality created during changes in status.

Communitas: The spirit of community. Open Agile Adoption creates these feelings of belonging and inclusion.

Master of Ceremonies: An essential role in a rite of passage. The person occupying the Master of Ceremonies role during a passage rite functions as a kind of referee, a keeper of “the rules of the game”.

Chapter of learning: In Open Agile Adoption, a unit of organizational learning with a clear beginning, middle, and end. Chapters of learning occur between occurrences of Open Space meetings.

Open Space: A meeting format with a specific structure and containing specific elements. Periodic Open Space meetings are an essential and core aspect of Open Agile Adoption.

Open Space Proceedings: Documentation of the events contained within an Open Space meeting. Proceedings contain a summary of the events in words, diagrams, and pictures.

Open Space Sponsor: A person in the organization with enough authorization to convene an Open Space meeting of at least one day in duration.

Open Space Facilitator: In the Open Space meeting format, a person authorized by the Sponsor to assist in the execution of the meeting. Open Space facilitators help to create an atmosphere of openness and “hold the space” open throughout the Open Space meeting event.

Coach or “Agile Coach”: A person hired by the organization to assist in the implementation of Agile methods and practices.

Beginning Open Space: In Open Agile Adoption, an Open Space meeting that begins or opens a Chapter of learning.

Ending Open Space: In Open Agile Adoption, an Open Space meeting that completes and terminates a Chapter of learning.

Leveling Up: In the gaming community, the term is used to describe a change in level or status in the game. “Leveling up” means progressing or graduating to a new level of competence.

Using this terminology, we can now examine the concepts and facilities of the Open Agile Adoption approach, in the next article.

About the Author

Daniel Mezick is a management consultant, author and community organizer. He is the founder of the Agile Boston community of practice. He is the formulator of Open Agile Adoption, a technique for creating rapid and lasting enterprise agility. Daniel is the author of THE CULTURE GAME, a book describing sixteen patterns of group behavior that help make any team smarter. The book is based on five years of experience coaching 119 Agile teams across 25 different organizations. Daniel’s list of clients includes Zappos Insights, CIGNA, SEIMENS Healthcare, Harvard University and many smaller enterprises. Learn more and contact Daniel at www.DanielMezick.com.

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT