Posted on

Mandated Agile, Part 2

I have a lot of heat around how Agile gets implemented in typical organizations. I’ve been ranting about the evils and oxymoronic nature of mandated collaboration [1]. Let me explain.

When I say mandated collaboration, I mean the prescription of both Agile adoption and specific practices.

I am clarifying my messaging here: naming a clear Agile direction is OK. However, stop right there. Prescribing practices as non-negotiable mandates and prescriptions is not OK, precisely because it kills engagement, the very fuel of progress….

…businesses are facing all kinds of pressures. The pace of change, driven by technology, is speeding up. So not just lots of change, but the velocity of change itself is intensifying. This is making is essential for enterprises to become highly adaptive. Right away. This means lots of group/team/org learning or what I call Tribal Learning has to be taking place all the time. AGILE CAN HELP.

So: when I say mandated collaboration [1] is dumb, I am NOT saying mandating an Agile direction is dumb. FAR FROM IT. This is exactly what leadership needs to do.

Leadership actually needs to do several things:

  • Explain the business case for Agile. Explain the challenges the business is facing in terms of competition, pricing pressure, obselete products etc
  • Make it clear the enterprise is heading into an Agile journey– an epic adventure. This part is not optional.
  • 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 at the start is an experiment, and is optional, and going to be inspected, and is not set in stone. For example, if the org is giving Scrum a try, it is an experiment, and subject to inspection. If an off-the-rack practice like Scrum cannot be tailored and customized to fit well, it will be THROWN OUT 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 progress [2]. Prescribing practices makes no allowance for what people want, what people think, and what people feel. It reduces engagement and causes people to check out and disengage.

So leadership makes it plain we are moving into an Agile stance as a company. So far so good. Next: Leadership then frames the initial use of ANY practice as an experiment, one that will be inspected for usefulness and effectiveness in service to the stated aims of the Agile adoption.

This is the exact opposite of what usually happens. Usually, the following happens, usually after a small pilot test of Agile with a small team:

  • Authority says we are going Agile
  • Authority says we are doing Scrum, or Kanban, of SAFe, or some other method. The message is that this is not negotiable.
  • A coach is selected by authority on the basis of expertise with the prescribed practices. Typically, Scrum skills. The coach is imposed on the people, just like Scrum.
  • Workers are triggered to disengage by the experience of a low sense of control and progress. They learn that the goal is fuzzy, the rules are fuzzy, the way we track progress is vague. Participating is not opt-in. The Agile adoption is not an enjoyable game because there is no opportunity to opt-in, because it’s not an invitation. Far from it. Agile and Scrum (for example) are a mandate and a prescription.

Folks, this is at best misguided. I’ve explained why in previous posts [1].

It kills engagement, the very fuel of a rapid and lasting Agile adoption.

The good news is, we can prescribe and mandate Agile without mandating collaboration. Leaders can frame the move to Agile as a necessary direction, and then invite everyone to bring the very best they have into the game, and help write the story. Authority can and must frame Agile practices as trials, and as experiments, which is code for saying that initial practices are not prescriptions from authority, and that everyone gets a hearing and will be asked what they want, think and feel about the experience of using of specific practices.

If we do not do this, we can expect the very poor results so-called Agile adoptions are getting after 12 months, 18 months, 24 months. The role of the coach is huge here. We need to stop being party to mandated Agile practices, and…

“Build projects around motivated (opted-in) individuals, give them the environment (the safe space) and support (the authorization) they need, and trust them to get the job done. [4].”

Related Links:

[1] Mezick, Daniel J. Mandated Collaboration: The Recipe for Botched Agile Adoptions. Blog Post. (link)

[2] Mezick, Daniel J. How Games Deliver Happiness. Blog post. (link)

[3] The Agile Manifesto Principles. Web page. 5th item listed. (link)

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Posted on

Principle 4: Apply Self-regulation & Accept feedback

This is one is a series of post on the application of the 12 principles of Permaculture [2] to organizations, and other social systems.  The posts are being generated by members of the Organizational Permaculture [1] group on Facebook. If you like this post, consider joining the group and adding to the  conversation with your own blog post on 1 or more of the 12 Principles of Permaculture [2]

Principle #4: Apply Self-Regulation and Accept Feedback

Principle #4, “Apply Self-Regulation and Accept Feedback” speaks to self-discipline, psychological safety and being open. It is important to note that these personal and system-level properties are a means to an and, not an end in and of themselves. The principle “Apply Self-Regulation and Accept Feedback” mean in part that we intend to tune and tailor our social systems to be highly receptive to feedback. It means we intend for our social systems to be aware.

It also means we work to actively create and then maintain the ability of the entire system to rapidly identify and respond to change.

This is the essence of organizational agility. The agile world uses the slogan “inspect and adapt” to express the importance of accepting feedback and applying self-regulation.

Self Discipline

Collecting observations is essential to responding to change. Observations can be proactive or reactive, active or passive. Reactive observing is what happens after taking an action, such as introducing an experiment.

Proactive observations are observations of the system as it is, without introducing anything new except your own presence.

Feedback as a Resource

Responding to change can be formal or informal, and frequent or infrequent. As a norm, it can even be absent entirely. There is no adapting without inspecting, observing or otherwise experiencing the environment. This plays out in social systems by using any practice that operationalizes the proactive and reactive styles of observation.

Psychological Safety

Technically, Jay Forrester describes social systems as “1st order nonlinear feedback systems” in his paper, Designing the Future. [3] . For an entire social system to become adept at responding to change, a high level of what Amy Edmondson calls ‘psychological safety’ [4] which is the willingness to take ‘interpersonal risk’ during interactions with individuals, in front of the group. Psychological safety in social systems is important for individuals. When the level of psychological safety is low, levels of self-regulation and acceptance of feedback at the level of individual and group will also be low.

Openness

I’ve written on Openness previously when discussing the Five Scrum Values [5]. Openness includes accepting the best idea, regardless of source. Discussing ideas is a way to express the identification of changes, and also a way to discuss a rational and well-reasoned set of possible responses to that change.

Practical Steps

Any activities that formalize frequent generation  and inspection of feedback are directly supporting Principle #4 of Permaculture: “Apply Self-Regulation and Accept Feedback.” Scrum [7] and Open Space [8] both define feedback systems with formal structures. Scrum is a complete framework, while Open Space is a meeting format. Both feature explicit loops of feedback with specific guidance on how to best process the feedback generated.

 

 

 

 

 

 

 

 

Figure 1. Small Session In Open Space.

 

Practical patterns and processes that can support this principle have certain common characteristics.

First, they share a formalization of frequent feedback loops. Scrum is a good example; it has a daily feedback loop (the Daily Scrum) and feedback loop (the Sprint Review) at the end of each iteration of work.

Second, they have an opt-in aspect, the people in the system choose to participate in using the pattern or process, and are not compelled to use it. Open Space is a good example; everything about it from the beginning to the end is an exercise in opting in or out.

Another good example is the Core Protocols. The Core Protocols [9] are structured interactions that have mechanisms for sending and collecting feedback. (Perfection Game and Investigate protocols respectively). Open Space is a 100% opt-in meeting. Scrum defined the Daily Scrum and Sprint Review as formal observe & inspect points.

 

Summary

To be self-regulating, there must be feedback. The more frequent, the better. The frequency of sampling the environment for feedback by observing in social systems can be monthly, weekly, daily or continuous. Teams and organizations that focus on identifying sources of feedback (and who also become adept at processing it) are in position to learn much faster than organizations that do not [6]. This learning in social systems is essential if we are to Obtain a Yield [10].

 

References:

[1] Organizational Permaculture Group on Facebook. (link)

[2] 12 Principles of Permaculture on Wikipedia (link)

[3] Forrester, Jay. Designing the Future at Universidad de Sevilla, Sevilla, Spain 1999 (link)

[4] Edmondson Amy, Harvard University. Paper: Psychological Safety in Work Teams” (link)

[5] Mezick, Daniel J., “Scrum Values”, blog post (link)

[6] Mezick, Daniel J. , “Culture That Learn are Superior”, blog post. (link)

[7] Schwaber Ken and Sutherland, Jeff. The Scrum Guide (link)

[8] Herman, Michael. Essay: About Open Space. (link)

[9] Core Protocols explained (link)

[10] Lloyd, Andreas. “Principle 3, Obtain a Yield”, explained. (link)