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)

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Agile Coaching and Sports

Question: why do sport teams employ coaches past training camp? Aren’t the athletes professionals capable of their own learning?

This is a question I received recently when I explained that ’embedded” or “integrated” coaching (where a Agile coach is present 5 days a week for 3 months or more) is probably a very bad idea. For those of you new to the idea that embedded or “integrated” coaching might not exactly be good for team-learning, take a look at these links:

Embedded Agile Coaching Defined

Agile Coaching Values

So, why do sport teams employ coaches past training camp?

Aren’t the athletes professionals capable of their own learning?

In my view it is absurd to compare the role of say, a Division1 basketball coach, to an Agile coach. The roles have little if any overlap. For example, is an Agile coach duly authorized to define various team rules, like a pro sports coach is? Is it ever OK for an Agile coach to yell at a team member like a college basketball coach might yell?

It is hard to imagine a scenario where that would be healthy in any Agile coaching context. The role of Agile coach has far less authority than a sports coach. This is self-evident.

Or is it? “Embedded” or “integrated” coaching, where the Agile coach is present every single day, positions the coach as “the authority”.

Is this healthy or even useful?

Is embedding a Agile coach full-time …in an organization ….simply trading one kind of authority-related dysfunction for another?

 

Agile Coaching Five Days a Week, FULLTIME for Three months or More: In Service to What?

Agile Coaches are familiar with the patterns of naive and vulnerable client organizations that are new to Agile. In my view, Agile Coaching pros have an obligation to help clients understand what is best for them. This always includes helping the client take 100% responsibility for their own learning. This usually means the coach must refuse opportunities to play a larger role.

Being there, 5 days a week, full time, for 3 months or more can be lucrative and hard to resist. As coaching professionals, we do our best (and live up to our potential) by serving the learning of the client organization. This includes challenging the client org to take 100% responsibility to reach a self-sustaining state of Agility, without the need for an external coach.

Stating that pro and college coaches play a big role after training camp and that therefore, Agile coaches can do the same is at best misguided. At issue is authority. In sports, the coach is authorized to substantially define the team by defining and enforcing rules. (Example: Examine the book Wooden On Leadership .)

After some basic training, is it EVER right for an Agile coach to define team rules? No. Teams must define their own rules– and culture. Agile coaches have far less authority than pro or D1 sports coaches, many of whom can choose to rule autocratically. Would you want your Agile coach acting that way? I hope not!

Coaches that overstay and “embed” or “integrate” into team life (usually as the ongoing Scrum Master)  are in a position to reduce team learning. This happens when the team does not learn to answer it’s own questions, does not try enough experiments,  and does not engage in enough risky learning.

The following table enumerates some key differences between two roles: pro sports coach, and Agile coach. As you can see, it is an apples-to-oranges compare:

Coach & Team Characteristic: Sports Teams IT Teams Notes
Coach has authority to define rules and therefore define the culture X The best sports team coaches DEFINE the culture of the team. See Wooden On Leadership for details
Coach has total authority to reward and sanction behavior X
Coach has broad influence over who has membership on the team, and who plays X
Coach typically defines basic team rules and enforces them X
Coach specifies the practices and has ultimate authority on how practice and practices are selected and executed X
Coach is typically compensated in part based on team performance X Agile coaches get paid not matter what. IN sports, if your team underperforms,  you are GONE
As a norm, Team defines their own intentional culture based on shared values which may be explained and suggested by coach X It’s absurd to imagine any Agile coach defining and then enforcing a team’s cultural norms
As a norm, Team works from principles typically suggested by coach, that support & express underlying values X
As a norm, Team has opportunity to change practices periodically based on retrospection X Self-governing teams define who they practice and how they execute. This is at best extremely rare in pro & college sports.
Team can mature to the point of no longer needing a coach; a “watcher” or Facilitator or Scrum Master can announce what is happening and stop short of issuing guidance like a coach X
Team’s goal is results as measured by specific progress (wins, frequent delivery etc X X

 

As we can see, in terms of authority, the pro sports coach has near-absolute authority to do the work of defining the rules and influence overall team culture.

In authority terms, these two jobs are not comparable, even though they both use the term ‘coach’ in the job description.

Who Is Ultimately Responsible for the Team’s Learning ?

Teams are. Teams are responsible for learning continuously. No one can do it for them.

Software teams must  take 100% responsibility for the culture design of their own team, and for their own team learning. That’s hard to do when an Agile-authority figure, installed by management, is present 8 hours a day, 5 days a week, functioning as an authority figure, telling the team at every turn what it “should” do. Particularly when the ‘coach’ takes up the Scrum Master role for more than a few weeks, the presence of a fulltime coach crowds the team and discourages team initiative and engagement.

Sports coaches and Agile coaches similar? Yes. But- when an Agile coaches take up too much authority, the results are predictable: reduced team learning, reduced engagement, greatly reduced self-organization,  and suboptimal productivity. For this reason, Agile coaches must look for every opportunity to increase the learning of the organization as a whole, with strong intent to vacate or otherwise evolve the current coaching role as soon as possible. It’s hard to do that when present 5 days a week, for 12 or more weeks while also often occupying the pivotal Scrum Master role.

A far better pattern is to teach a new Scrum Master, one who is internal to the coached organization, and for the external Agile coach to be present on a part-time basis. This places responsibility for learning and improvement on the coached organization itself, which is where it belongs. This is a healthy pattern that encourages healthy and authentic Agile adoptions.

 

Authority Explained

I told you before about the difference between authority and power. Now that we are holding these working definitions, we can drill down…and deconstruct authority in more detail.

I’m drawing from Group Relations work here, and providing actionable guidance for thinking about authority. I am purposely being minimalist here, providing the essentials only.

Remember, authority is defined here as “the right to do work“. Also, keep in mind that authority is always something conferred. It is given, and can be taken away.

Formal Authority

Formal authority is what is conferred when you occupy a formal Role, for example, when you become Treasurer of a non-profit organization. That role comes with a Title, and a collection of Tasks (“work”) you are formally authorized to do. Police for example are formally authorized to enforce the law.

Personal Authority

Formal Roles are well-defined in theory and actually have much more that is undefined and ambiguous. How far can I go? What are the limits of my authority around a task? Etc. It is here that your approach comes into play. Personal authority is your personally held, “perceived right” to do the work a certain way. 

The policeman that pulls you over can let you go without a warning. That policeman makes a decision about how to handle his role in a given situation.  That’s personal authority.

We are all familiar with ‘overstepping’ authority and the related dysfunctions of that. Like a policeman who tries to make you let him into your home when he knows for a fact that he can’t make you let him in, unless certain other conditions are true. That cop is attempting to over-step the formal authority boundary of a role.

 

Understepping and Overstepping

We are far less familiar with ‘understepping’, that is, not fully “taking up” a given role.

This is a bigger and far less understood problem!

When your sense of personal authorization prevents you from fully occupying your formal Role, serious dysfunction results. Why? Because you leave what I call “scraps of authority” lying around. If you do this on the job, for example as a Manager or Director,others are unusually quick at picking these these scraps up, and using them outside of the Role they are intended for– the one you are occupying!

The distortions created by this cause a range of organizational illnesses- a.k.a. “dysfunctions.”

 

Informal Authority

Informal authority comes without formality: without a formal Role and related title, etc. It is the authority that most of the others confer to you. Most of “the others” may or may not occupy formal, highly authorized Roles.  (Usually it is a mixture of people in various Roles.)

The source of informal authority is the willingness of others to have you do some specific work.

We all know of people who get loads of critically important work done, yet they do not occupy a “higher-up”,  formal Role (with formal authorization) inside the group. Yet these folks seem indispensable to how the team or organization functions.

What gives here?

Informal authority shows up as influence. It’s the conferred right to do certain kinds of work. It is conferred from others. It’s based on reputation, and a certain kind of willingness on your part. It is offered to you, and can be accepted by you…or not. It can be given, and taken away.

Summary

I just defined the following for you: formal authority, personal authority and informal authority…subcategories of “authority, the right to do work.” I hope you find these definitions useful. In the next post, I will deconstruct influence, that available-to-everyone, “always-on” ability to literally cause a shift or “change in state” in our socially constructed universes. I plan to discuss willingness, roles, and being “drafted” into roles…with and without your consent.

social construct:

a perception of an individual, group, or idea that is ‘constructed’ through cultural or social practice.

 

Related Links:

http://newtechusa.net/agile/authority-and-power/

http://akriceinstitute.org/displaycommon.cfm?an=1&subarticlenbr=34

https://twitter.com/DanielMezick