Agile Facilitation Jobs In Maryland

One of my Agile adoption clients, this one in Maryland (about 40 mins east of DC with no traffic)  immediately seeks several people for full-time hire to facilitate the ongoing work of 18 existing software teams relatively new to Agile software development.

In this role you are a member of a 6-person team responsible for facilitating higher performance across the entire enterprise…

…The ideal candidate has:

  • Passionate interest in the dynamics and application of self-organization
  • Solid understanding of Open Space concepts and facilities (strongly preferred)
  • Direct facilitation experience (general meetings, World Cafe etc)
  • Familiarity with Agile software development; especially the Agile Manifesto 4 values & 12 principles
  • Familiarity with www.OpenAgileAdoption.com concepts and components
  • Familiarity with Kanban, Scrum and related Agile practices (user stories, planning poker, retrospectives etc)

…If you are a successful candidate, you’ll be mentored and guided by professional Agile coaches. These temporary external coaches (myself included) will begin vacating throughout the Open Agile Adoption implementation period (90 to 120 days) after bringing you up to speed…

The primary responsibilities are:

  • Facilitate various team meetings
  • Sense what you teams need from a sociological point of view
  • Create conditions for self-management and self-organization to manifest
  • Work with peers and people in higher-authorized roles to create & then continuously maintain the conditions for high performance and continuous improvement
  • Be diplomatic and adept in communicating as needed, up and down the organization
  • Work within and contribute to an enterprise-wide community of practice
  • Encourage a culture of facilitation

These are full-time positions. This is a ground-floor opportunity to facilitate, full-time for a living. You’ll work in an Agile environment where periodic, enterprise-wide Open Space gatherings are part of the plan. Knowledge of the software side of things is important, yet less important than your grasp of Open Agile Adoption (www.OpenAgileAdoption.com) sociology and related topics.

If you have solid facilitation experience, and

  • are seeking a great full-time job in facilitation, and
  • have more than a clue about Agile software development, and
  • live near (or are willing to relocate to) northern Maryland, then:

….please contact me by email with “Maryland Jobs” in the subject line.

Reach me via www.DanielMezick.com

Broken Promises

We are at a tipping point in the Agile story.

For almost a decade now, highly authoritative “agile enablement firms” have been telling management that it is perfectly OK to mandate the use of agile practices, and that everything will be OK.

They’ve been told that the opt-in engagement of the people who do the work does not actually matter. As long as the highly authorized leaders are in, we will be OK. The people and the culture will change if you authorize the agile coaches to implement this new set of practices, and/or this new “structure”.

In the present day, we have large corporations trying 2, 3, 4 times to get it right by using this approach. Millions upon millions are being spent on management-mandated agile training, management-mandated agile practices, and management-mandated agile “coaching”.

It’s the elephant in the room. The leaders of the agile institutions and those who orbit around these institutions are saying absolutely nothing about this in the public square.

And there is a term for this: it’s called whistling past the graveyard.

The answer of course it to replace the management-mandate of agile practices with an enterprise-wide invitation.

And invite everyone in the organization into the story, and into the process of writing the new story.

That requires the formally authorized leadership to actually admit they do NOT have all the answers.

It also requires agile coaches to routinely and deliberately deflect all projections of authority.

These are huge impediments to the successful implementation of agile ideas at scale– the implementation of agile thinking across an entire enterprise.

The solution is actually very simple. Instead of pushing a process change, use “pull” instead. Use invitation, instead of that nasty mandate.

Open Agile Adoption (OAA) is one way to use invitation and “pull” to successfully introduce Agile into your company.

If you are considering a new Agile adoption, OAA and “pull”– powered by invitation– can actually help you get traction right away.

If you already tried a management mandate of Agile, OAA can help you do a reset…and turn that thing around.

 

 

 

 

 

 

Imposing Agile Practices: Does It Actually Work?

The OpenSpace Agility approach has created some questions. Some of these questions, collected from around the web, appear below. Some of the questions are very specific and very interesting (I think.) I’ve included them here. These particular questions are harvested from recent interactions with professional Agile coaches who are active on Twitter.

 

Related Links:

OpenSpace Agility  Explained

20 Minute Video of Daniel Mezick Explaining OpenSpace Agility Agile on INFOQ

OpenSpace Agility Client-Interview Videos

 

 

The Questions:

 

Q. Guide them through change, but not impose. What if they don’t want to change?

A. Respect the no. Let the org…the self-organizing system…figure out how to address this problem.

 

Q. Would you let a developer you were paying personally choose their own approach?

A. This is a non-starter kind of question. The typical context of an Agile adoption is an existing organization with an existing IT department or development team group.

Q. Are there any constraints you’d be willing to impose or mandate?

A. OSA tolerates the “imposition” of an Agile direction, even though that can be a problem. The Agile direction has to be in service to something- something besides Agile itself.

An Agile direction, articulated by formally authorized leadership.

Agile: in service to what?

 

Q. So you are willing to impose constraints?

A. The idea is to open up a conversation about how Agile ideas can help. We invite the folks to play with the various Agile practices. Iterations, Retros, and so on. We explain to them that they can try any practices they like which do not offend the majority of the Agile Manifesto’s 4 values and 12 principles. We encourage them to know the Manifesto well, and find practices that align with those values and principles.

Practices change, principles don’t. We explain that and turn them loose into a time of “authorized experimentation.”

Q. Deliver working software every two weeks?

A. Iterations are an Agile idea that aligns with the Manifesto: “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.” Let (aka “authorize”) the teams to experiment with that!

Q. Work in a cross functional team?

A. Once again, allow experimentation. Do not “mandate collaboration. “

Q. Plan in functional slices of the product?

A. Allow experimentation. Do not mandate behaviors. Instead, ask them to align everything they do to the Manifesto.

Q. Those are constraints. They are also agile process. But we can’t say that we are mandating agile?

A. The output from an experiment is learning. In OSA we invite experimentation. We invite learning.

We make the distinction in OSA between the naming of an Agile direction, and the mandating of specific practices. Direction-setting is an important activity for formally authorized leadership. In OSA we stop short of mandating specific practices. Instead we invite the teams to experiment. Martin Fowler in 2006 writes the important essay “The Agile Imposition”. This is essential reading for anyone considering mandates of Agile practices. Quoting that essay: “So I hope I’ve made clear that imposing agile methods is a very red flag.”

 

Q. I’m starting to wonder if there is a nuance here that I am missing. This makes NO sense to me.

A. The nuance is: human engagement powers successful process change. Disengagement can slow down and eventually ruin your process-change plans. Therefore, engagement is essential. OSA is all about creating engagement on the premise that human engagement is absolutely essential.

Q. Are we really talking about an approach or disposition? We invite rather than mandate? Like non-violent comm.?

A. Invitation is respectful and can create engagement. Coercion and mandates are fundamentally disrespectful, and can create disengagement.

Q. “…I would place constraints on team such as I want X feature in 2 week Quality MUST be high. Outcome focused. “ What’s the difference between that and mandating agile?

A. The difference in the OpenSpace Agility approach is this: we place the people inside a period of time when the primary outcome is learning, through experimentation. The period of experimentation is actually a designed experience.  It is designed as a rite of passage. See also http://en.wikipedia.org/wiki/Rite_of_passage

 

Q. Is it the social implications of agile we don’t want to mandate? Not the process aspects?

A. OSA is a sociological approach based on opt-in engagement. Remember, the premise is that human engagement is essential. Jeff Sutherland has data on Scrum (see http://assets.scrumfoundation.com/downloads/2/scrumpapers.pdf?1285932052) saying teams can double productivity and double again. A central hypothesis of OSA is that higher productivity is correlated with higher levels of human engagement.

 

 

Q. Like, I won’t mandate you trust someone? Or be vulnerable in a retrospective? Or create safety for someone?

A. I’m sorry if you think you believe that this kind of thinking and action can be forced on someone by some kind of external authority. I have never seen it done.

Q. I won’t mandate you like each other, or work as a high performing team?

A. High performance is mostly a function of self-organization. Self-organization is a goal of OSA. We create the conditions for self-organization to emerge. We do not pretend we can manufacture or mandate it. In OSA we create the conditions and the conditions always include a legitimate (opt out with no sanctions) invitation.

Q. I’d suggest there is no way to mandate that stuff anyway. You can only mandate behavior or process compliance.

A. In a prison, you can mandate behavior compliance and process compliance. Are workplaces prisons? I guess some kind of are…maybe.

Harrison Owen is fond of saying that the Law of 2 Feet is always active—that is, people are exercising their options, including the option to disengage. A central premise of OSA is that you cannot actually mandate behavior or process compliance, because people “check out” and disengage on you instead of playing your mandatory-to-play game. Good games have opt-in participation. That requires the consent of each player.

 

Q. Like, my desired result is you work in a team & deliver a working tested increment of product every two weeks?

A. Yes, this is much closer to the idea of OSA: we name the issues we are facing , we suggest some experiments with Agile practices. We inspect the experiment. The constraint is “use any practice that supports and is not obviously in conflict with the 4 values and 12 principles of the Agile Manifesto.”

Q. Again, we must be arguing some semantic nuance I don’t understand

A. Again, the central idea is very simple: Engagement is essential. Great teams, great products and great organizations exhibit very high levels of human engagement. Engagement is essential. Mandates tend to dampen engagement while invitations (such as an invitation to attend an Open Space meeting) tend to increase it. Engagement is essential.

 

Q. If you are willing to mandate team based iterative and incremental delivery, how is that not mandating agile?

A. First, learn to differentiate between mandating an Agile direction and mandating specific Agile practices. The constraint is is “use any practice that supports and is not obviously in conflict with the 4 values and 12 principles of the Agile Manifesto.” From there, common sense governs. Quote from Martin Fowler, Agile Manifesto signatory: Imposing Agile methods on a team is in conflict with the principles of Agile and have been since inception.” See also http://newtechusa.net/agile/people-then-practices/ and http://martinfowler.com/bliki/AgileImposition.html

 

Q. (say) they are failing now doing ad-hoc or waterfall. What if they want to do an 18 month waterfall process? Can I ask them not to do that?

A. See the above question. In OSA we start and end in Open Space. In between we experiment with practices, using the Agile Manifesto for guidance. Make sense? Quote: “An important consequence of these values and principles is that a team should choose its own process – one that suits the people and context in which they work. Imposing an agile process from the outside strips the team of the self-determination which is at the heart of agile thinking.” – Martin Fowler, “The Agile Imposition”, see http://martinfowler.com/bliki/AgileImposition.html

Q. Okay, you’re willing to mandate producing value every two weeks?

A. No. There is no mandate, there is an invitation to experiment and create learning. Again, the Agile Manifesto is the guide: Is the idea of producing value every two weeks consistent with the Manifesto? Yes, it is. The difference in OSA is that we are inviting people to play a game, we are not mandating this or that.

Q. What kind of result then can I mandate? Valuable software on some regular interval?

A. Why mandate a specific outcome like iterative delivery when you know you need the human engagement of the team? In OSA we teach the Manifesto and invite the teams to try an experiment, for example experimenting with Scrum. The difference between the mandate and the invitation is huge. The mandate is experienced as command-control and coercion, both of which reduce engagement. The invite is experienced as a respectful request to engage in a game. Every good game has opt-in participation. See also http://newtechusa.net/agile/how-games-deliver-happiness-learning/

 

Q. What if they want to do an 18 month waterfall process? Can I ask them not to do that?

A. In OSA, we “explain the why” of the Agile experiment, in an invite to attend an Open Space meeting. That invite is an invite to explore a theme, a theme like “Agile: In Service To What?” or “What Do We Want Agile to SOLVE?” We then schedule another Open Space about 12 weeks out. In between, we authorize experimentation with Agile, defined as using practices that support the Manifesto principles. Is an 18-month waterfall process consistent with that? No. And in this scenario, the folks themselves will not go that way, because an 18-month waterfall would not be in alignment with the Manifesto principles.

Q. Can we mandate that people show up and do work or do I have to invite them and coach them on that 2?

A. This is a silly question.

Q. I am desperately trying to understand the POV here. I am trying to understand that nuance. What is the difference between mandating agile and mandating some of the other outcomes that folks have suggested? Maybe you can do a post for me or something, because honestly, I am really, really confused.

A. A central premise of OSA is that engagement is essential. Mandates reduce the sense of control and belonging. This kills engagement. It is really, REALLY this simple.

Q. Is the nuance I am missing that people have to be invited to participate, but if they don’t I can coach them out?

A. The nuance you are missing is that the very people who are allergic to your mandate are often the people who have the very best ideas on how to make Agile work inside their team and inside their company.  Inviting all the people to experiment and then inspect the results has a way of getting people in. Those who do not get in receive feedback from peers on what is working and what is not. A goal of OSA is to get everyone in.

 

Q. Is the nuance I’m missing that we have to take a disposition of invitation, we have to lead, coach, and help people along…

A. Yes, a premise of OSA is that engagement is essential and that mandates can kill engagement. Therefore, we replace that disengaging mandate with an engaging invitation to play a game: the game of experimenting with Agile practices to see if they actually work.

Q. …we all agree that they can’t do waterfall, not produce incremental value, allow defects to carry forward, else they leave?

A. We issue an invitation to attend a themed Open Space meeting. After that we play with practices and see if they serve. Quote: “Not just should a team choose their own process, the team should be control of how that process evolves.” – Martin Fowler, The Agile Imposition. See http://martinfowler.com/bliki/AgileImposition.html

Q. I’m not pushing a side, i am trying to understand and no one can explain to me what it means not to mandate.

A. To not mandate means to invite. To be inviting. To replace the coercive command-control mandate with an invitation to play a game of experimentation which will be inspected. This tends to engage people. The premise is that engagement is essential.

Q. Dan explicitly asserted that you cannot mandate an agile transformation. We have done this many times with great success.

A. I love success stories and I am sure you have many. Let’s run the numbers. Since 2001, the year of the Agile Manifesto, that’s about about 13 years, I’m guessing there have been over 10,000 attempts at successful adoption of Agile. (That’s probably low). I’m also guessing that 99% of these have been implemented as mandates of Agile practices. Right? Is that a fair and reasonable assumption? By that measure, the 500 or more legitimate success stories are actually outliers! Those 500 success stories represent about 5% of the sample, meaning there is a 95% lack of success is this hypothetical example.

Say there were actually 1500 verifiable success stories out there, about the mandate of Agile practices. In the language of wagering, that means you’d still be about a “6 to 1 dog” (with odds about 6 to 1 against you) when making that bet.

There’s loads of experience data. Where in that data is the overwhelmingly positive evidence that mandating Agile practices actually works? There is a lot of data from organizations like Gallup which shows that engagement is correlated with things that are really good, like employee retention and employee morale and better products.

Question: Where is the evidence that these mandates of Agile practices are actually increasing employee engagement?

Q. So I am trying to understand what he means. There is some nuance I am clearly missing. Trying to understand what that is.

A. The nuance is very simple. People have to be willing. You can create indirect opposition, resentment and so on by forcing agile practices on people without their consent. The clear solution is to replace the mandate of practices with a genuine invitation to experiment with them.

Q. I think you can mandate going to agile, but then have to win the hearts and minds of the people involved.

A. Almost. You can win the hearts and minds of the people involved. Mandates create feeling associated with a loss of control and belonging. In his book DELIVERING HAPPINESS, Zappos CEO Tony Hsieh explains how the senses of control and of belonging are essential for human happiness. See page Appendix A page 233. When people lose a sense of control, they may tip into the state of Learned Helplessness. Martin Seligman did experiments that exposed this dynamic. It stems from a lack of perceived control. Is this what we want to start happening inside our Agile adoption programs? See also: http://psychology.about.com/od/lindex/f/earned-helplessness.htm and http://youarenotsosmart.com/2009/11/11/learned-helplessness/

 

Q. But if they choose not to participate, and that is their choice, they may have to find employment elsewhere.

A. This is true. However, in OSA, the adoption is emergent and adaptive—not prefabricated and forced via a mandate or coercion. This is a very big difference from the mandated approach. In the OSA approach, the adoption has emergence baked in from the beginning. Everyone is invited and those who opt-in are co-creating it.  Everyone has a decent sense of control and strong sense of belonging. The group senses things together, along with the person who no longer fits. Authority does not tell the person they are fired. Instead, emergent order creates a shared sense of agreement about reality by and between the members. When the new culture of learning takes root, the unengaged person and the tribe both realize what is no longer working.

Q. I’m not suggesting we enslave people, but if I decide to run my company using an agile approach that is not debatable.

A. As the owner, if a command-control approach works for you, great. Keep doing that.

Q. I will teach, coach, mentor, help them understand, be kind and gentle along the way and give them time to learn.

A. That is a good idea, consistent with the Open Agile Adoption approach.

Q. But if there is no option but to do agile or leave, that is fundamentally a mandate.

A. In OSA, formally authorized leadership works from a belief that people actually want to do great work, and will do great work if you create the conditions for it to emerge. Essential elements of these conditions include a sense of control and a sense of belonging. Invitations to engage can encourage both. The sense of control and belonging show up when people are actively making decisions about the customization and tailoring of practices they are choosing with others in the group. The co-created agreements associate with a sense of control and membership.

Q. Maybe as you suggested the word mandate carries some baggage for people that I don’t have. Like calling people resources.

A. What it is called does not matter: if you reduce the sense of control and sense of belonging below a certain level, or lower, the participants will stop playing the game and check out. When that happens, it’s “game over” and the Agile adoption is dead in the water.

Q. Ah, so mandate implies one-way communication. That is insightful… I didn’t interpret the word that way.

A. Yes, and an invitation is a two-way communication. The OSA approach replaces mandates (which can feel coercive) with an invitation (which can feel inclusive.)

Q. Okay, so that is insightful for me too. I think agile is a way of working, but it doesn’t require an agile mindset.

A. Yes, and if there is no Agile mindset at the beginning, that probably means the folks at least have to be consenting to what is happening. If there is no mindset and there and no consent, what is there? Answer: compliance, resentment, learned helplessness. See also http://en.wikipedia.org/wiki/Learned_helplessness#Summary

Q. If I act with agility, the feeling of agility will follow.

A. Maybe. If you are willing. If you are experimenting. If you have actively consented to play the game. If you have AGREED to “act as if”, to “suspend disbelief”, to “pretend this might work” for a little while.

Otherwise, maybe not. The feeling of agility is probably not going to happen if you are feeling compelled, coerced or forced. If you are feeling a low sense of control and a lower sense of belonging.

Where there is no consent, there is often a general feeling that something just ain’t right. At first, you may have difficulty being able to name and identify these feelings.

Q. I don’t believe that it is an effective strategy to transform 6000 people through cultural indoctrination

A. Open Agile Adoption is not a cultural indoctrination program. There are NO  attempts at “persuasion” to get  “buy-in” from teams, in OSA. This is because genuine engagement is deeper than that.

The OSA method is a way to introduce process-change through a consent-based approach that uses invitation and the use of Open Space to create an experience. The OSA experience is designed to encourage self-organization at scale. It creates the conditions for a rapid and lasting Agile adoption.

Q. I believe you have to get the systems in place to enable agility and that will allow the mindset of agility to follow.

A. A core premise of OpenSpace Agility is that people want to be part of creating the solution (sense of belonging) and want to consent to that (sense of control). When you force Agile practices, there is no experimentation. There is no belonging as there is no shared-agreement. There is simply a forced march to collaboration. A forced march to “mandated collaboration”. This is a terrible idea.

Q. I do believe [OpenSpace Agility] is very contextually sensitive, not impossible to do it the other [mandated] way.

A. Almost every big change in almost every organization is context-sensitive. Right?
A core premise of OpenSpace Agility is that engagement is absolutely essential. Another core premise is that a mandate of practices can quickly reduce levels of engagement by reducing the senses of control and belonging. If this is true, then OpenSpace Agility is widely applicable. It is applicable in almost any enterprise that wants a rapid and lasting Agile adoption.

Q. Dan just happened to say that my way doesn’t work and there were no examples of it working. I disagreed and offered to introduce him.

A. I say that mandates reduce engagement, and that engagement is essential for a rapid and lasting Agile adoption. If your way is to mandate, I am doubtful it creates rapid and lasting Agile adoptions.

I am sure you have some success stories in your sample. However, the sample size across the entire Agile experience is at least 13 years of mostly-mandated Agile adoptions, worldwide! That might be 10,000 or more attempts at mandated Agile adoption. So, if Agile-practice mandates are a good bet, and actually work, we’d by now  be able to point with pride to thousands upon thousands of verifiable and unmitigated success stories.  Right?

Thirteen years and thousands of attempts to force Agile practices. Where are the thousands upon thousands of verifiable success stories?

Why is it a crime to ask this question?

Where is the “mound of data” with verifiable results that strongly support the mandate of Agile practices?

Q. The only thing I wanted to assert here is that both ways can work.

A. If Approach-A works 15 time out of 100, and Approach-B works 85 times per 100 trials, both can be said to work. At issue is the expectation. One, Approach-A, has very negative expectation, we can expect on balance to fail (LOSE MONEY) most of the time. The other, Approach-B, has very positive expectation; we can expect on balance to succeed (WIN MONEY) almost every time. Both can be said to work some of the time. They have widely different “expected value.”

The mandated approach might work maybe 15 times per 100 attempts. Are those actually good numbers? Are we actually happy with that? Today, we are collecting data on a NEW approach. An approach that focuses on engagement, on the premise that human engagement is essential from the very beginning.

Summary

The OSA approach assumes human engagement is essential. It replaces the mandate with the invitation. It is an approach that attempts to improve the odds for success in getting a rapid and lasting Agile adoption, by acknowledging the reality of imposed mandates and replacing those mandates with opt-in invitations. The method includes leadership storytelling, the use of Open Space, deliberate experience design, game mechanics and more, all in service to the creation of rapid and more lasting Agile adoptions.

***

 

 

 

 

 

 

 

Agile Coaching Values Explained

In a previous post, we outlined 4 Agile Coaching values and 8 related and supporting principles.

Mandated practices may prevent a rapid and lasting Agile adoption, by reducing feelings of control and belonging in the very people who do the work.

Embedded coaches present 5 days a week often prevent teams from taking up their authority to lead in the creation of their own Agile practices and processes.

Here is a bit more detail on the 4 values and 8 principles, for your consideration. You are invited to consider this detail and how it might apply to your own Agile work as a coach, client, or team member.

These Agile coaching values were authored by the following professional coaches in the Greater Boston area (listed alphabetical by last name):

 

4 Agile Coaching Values

 

Creating Independence over generating billing

Coaches are often drafted into the role of “authority in chief” and with that comes the risk of substantial client dependence. Coaches value creating client independence and client self-sufficiency over all other considerations.

Championing Learning over avoiding risk

Continuous learning is destabilizing to existing culture. Questioning long-help assumptions can be risky in an organization that values stability over learning. Agile coaches value the building of a capacity of continuous learning in the orgs they serve. This includes encouraging the client to identify, expect and manage the many risks of genuine organizational learning

Building Relationships over building transactions

Agile coaching is a very lucrative profession. Coaches have creditors like everyone else. The development of relationship with the people in the client organization must take precedence over financial considerations if the coaching is to be effective and lasting.

Inviting Participation over assigning responsibility

Assigning responsibility without authority is a recipe for failure in any attempted adoption of Agile methods. Instead of a command and a prescription, the people closest to the work must play a part in designing the solution. Agile coaches encourage formally authorized leaders to avoid mandating participation in prescribed Agile practices. Agile coaches encourage leadership to invite the people who do the work to participate directly in the design and implementation of any move to Agile and Agile practices.

 

8 Agile Coaching Principles

We use these Principles to guide our work with clients:

 

Voluntary engagement of everyone involved in organizational change is an essential requirement for success.

Mandating an Agile practice is the same as mandating collaboration. This is a contradiction of terms and is also contrary to the letter and spirit of the Agile Manifesto values and principles

 

Coaching every single day in an organization creates a serious risk of client dependency and is to be avoided, consistent with common sense and good judgement with respect to client needs.

Dependency on the Agile coach is harmful to coach and client and is to be avoided at all costs. Occupying the Scrum Master role of Scrum for an indefinite period of time is not coaching and reduces the learning capacity of the client organization.

 

Organizations are responsible for their own learning. Arms-length, time-boxed working agreements between clients and coaches are essential.

Coaches and clients work best together when they agree to a time-boxed structure for executing on coaching. Teams and entire organizations take more responsibility for learning when they know the teacher is not available for an indefinite period of time.

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.

Coaches and clients work best together when it is understood that the coach’s role will change and that the intent of the coach is to vacate as soon as possible. The promise of Agile is served when client organizations can routinely reach a state of self-sustaining, “freestanding” agility.

Coaching requires the willingness to identify any cultural impediments to continuous improvement, and to communicate these to the people in the organization who have the authority to address them.

Agile is Trojan horse for bringing in a substantial change in culture. Coaches have an obligation to see to it that leaders occupying roles highly authorized roles commit to using their authority to remove cultural impediments to rapid and lasting agility.

The primary task of a coach is to help improve the effective results and working lives of the people employed in the organizations they serve.

Agile practices create engagement and good results–  in part by putting decision-making authority in the hands of the people who do the work. Agile coaches encourage leaders to make this happen.

The ability of an organization to respond to change is the primary measure of progress.

Agile coaches are in the business of teaching and encouraging practices that lead to adaptability and the ability to handle rapid change. Agile coaches teach entire organizations how to learn, and adapt—without the ongoing need for the presence an external authority named ‘coach’

Leaders in an organization must continuously signal positive encouragement, and create safe space for others to think and learn, if positive culture change is to be lasting and effective.

Agile coaches are obligated to teach organizational leaders how to best create an environment that is open and safe for experimentation and the learning that comes from that.

***

Agile Coaching Values

Agile Coaches are familiar with the patterns of naive and vulnerable client organizations that are new to Agile. In our view, Agile Coaching professionals have an obligation to help clients understand what is best for them. In the beginning this is seldom the case. The Agile coach is obligated to do the right thing. This always includes encouraging and helping the client take 100% responsibility for their own learning.

This usually means the coach must routinely and politely decline opportunities to play a larger, more authoritative 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 first. This includes challenging the client org to take 100% responsibility to reach a self-sustaining state of Agility, without the need for the 5-days-a-week presence of the external coach.

These Agile Coaching values and principles listed below are a good and solid basis for guiding coach-client relationships and interactions. These values and principles are listed in the familiar ‘agile manifesto‘ format.

The content- these values and principles– are optimized on the continuous, progressive and ongoing organizational learning of the coached organization.

 

In serving our clients, we have come to value:

Creating Independence over generating billing
Championing Learning over avoiding risk
Building Relationships over building transactions
Inviting Participation over assigning responsibility

We use these Principles to guide our work with clients:

Voluntary engagement of everyone involved in organizational change is an essential requirement for success.

Coaching every single day in an organization creates a serious risk of client dependency and is to be avoided, consistent with common sense and good judgement with respect to client needs.

Organizations are responsible for their own learning. Arms-length, time-boxed working agreements between clients and coaches are essential.

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.

Coaching requires the willingness to identify any cultural impediments to continuous improvement, and to communicate these to the people in the organization who have the authority to address them.

The primary task of a coach is to help improve the effective results and working lives of the people employed in the organizations they serve.

The ability of an organization to respond to change is the primary measure of progress.

Leaders in an organization must continuously signal positive encouragement, and create safe space for others to think and learn, if positive culture change is to be lasting and effective.

 

***

These Agile coaching values were authored by the following professional coaches in the Greater Boston area (listed alphabetical by last name):

Pat Arcady, Freestanding Agility (www.freestandingagility.com)

Dan LeFebvre, Freestanding Agility (www.freestandingagility.com)

Daniel Mezick, New Technology Solutions Inc (www.DanielMezick.com)

Frank Saucier, Freestanding Agility (www.freestandingagility.com)

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.

 

Agile Coaching: Core Values & Supporting Principles

The idea of hammering out a set of guiding Values and Principles for Agile Coaches is an idea whose time has come. Increasing reports of problems in Agile Coaching are tarnishing our profession and diluting our effectiveness as change agents. This is a very serious problem.

A set of community-built, open-source Values and Principles is one solution we can all act on today. Rather than looking to institutions to lead us, or assigning blame, we can choose instead to look to ourselves and do something about it, right now. Click. Done.

I invite you to come and play with this idea. The aim of the group is to hammer out an opt-in set of Agile Coaching Values and Principles for Agile Coaches, with intent to improve the working lives of Agile Coaches and Agile Coaching Clients throughout the world.

Please come and play!

 

 

 

Click here to JOIN the Agile Coaching Values discussion group on Google+

Will you please also forward this invitation to other agile coaches and agile coaching clients that might be interested in this conversation?

Thank you!

Intrigued? Here is more detail:

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.

These Agile Coaching values and principles listed below are a good and solid basis for guiding coach-client relationships and interactions. These values and principles are listed in the familiar ‘agile manifesto‘ format.

The content- these values and principles– are optimized on the continuous, progressive and ongoing organizational learning of the coached organization.

 

In serving our clients, we have come to value:

Creating Independence over generating billing
Championing Learning over avoiding risk
Building Relationships over building transactions
Inviting Participation over assigning responsibility

We use these Principles to guide our work with clients:

Voluntary engagement of everyone involved in organizational change is an essential requirement for success.

Coaching every single day in an organization creates a serious risk of client dependency and is to be avoided, consistent with common sense and good judgement with respect to client needs.

Organizations are responsible for their own learning. Arms-length, time-boxed working agreements between clients and coaches are essential.

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.

Coaching requires the willingness to identify any cultural impediments to continuous improvement, and to communicate these to the people in the organization who have the authority to address them.

The primary task of a coach is to help improve the effective results and working lives of the people employed in the organizations they serve.

The ability of an organization to respond to change is the primary measure of progress.

Leaders in an organization must continuously signal positive encouragement, and create safe space for others to think and learn, if positive culture change is to be lasting and effective.

Embedded/”integrated” coaching

Here is the definition:

Embedded Agile Coaching: Agile coaching that has a “coach” personally present, full-time, at the client site, for 3 business months or more, where the coach is often (but not always) observed taking up the Scrum Master and/or Product Owner role for substantial amounts of time.

Embedded coaching 5 days a week sets up at least the following potential dysfunctions:

  • Excessive projection of authority on the ‘coach’ by the client, leading to the coach inappropriately accepting responsibility for the client org’s learning.
  • A client desire to see the coach ‘doing something’, leading to the misguided idea that having the coach function as Scrum Master for all the teams is a useful and good idea. (It’s not.)
  • Diminished client learning, caused by the ‘coach’ becoming an authoritative fixture in the organization, the one who provides answers.
  • A tendency for the coach to support Mandated Collaboration

 

 

Agile BS: The Productization of Agile

There is a preponderance of BS in and around the Agile community right now. Scrum has become productized, and ‘agile enablement’ firms touting that ‘agile is all we do’ are selling one or another variety of snake oil. Boston is a place where this is especially acute.

David Anderson, a guy who wrote a book called Kanban, is calling this out, and he is not alone. He spells it out here:

There is an initial assessment or appraisal…then some proposed future state envisaged…the new future state process is designed and it becomes the target outcome for the transition that is introduced and managed through the change management process.

This is a traditional 20th Century approach to change. It offers the reassurance of a defined outcome, and the outcome is envisaged either using a prescription from a text book, or by utilizing a model and designing a solution. The issue with this is that it assumes the problem exists in the complicated domain…

…It is ironic that the approach to Agile transitions has been a very non- Agile, big design up-front, make and follow a plan, approach. The fact that many Agile transitions are challenged and underperforming (and I’ve been saying this for at least 5 years now) may be that the approach being used is inappropriate to the domain of the problem. What we need is an Agile approach to change – an approach that incorporates feedback loops and evolves as new information emerges.

(See the full blog post here)

Andy Singleton, a friend of mine in Boston who makes great tools for distributed teams, is also on to something also, when he writes:

Pair programming:  Great for vendors, bad for customers.  Pair programming is like those girls that go to the restaurant bathroom together.  What are they doing?  If you are a vendor selling “pairs”, you have an awesome situation where you can charge twice as much, and you can easily churn guys on and off the pairs, one at a time, to steal talent for turnover or new projects.  If you are customer, you pay twice as much and you get churn.

(See the full blog post here.)

These writing from these two gentlemen are pointing to the productization of Agile. It’s a sad state of affairs that appears to be encouraged by the Scrum Alliance and the Agile Alliance.

Organizations need to think for themselves and be responsible for their own learning. Each firm must create a custom solution from practices that are based on solid principles. David Anderson and Andy Singleton are on to something. One size does not fit all.

The productization of Agile is happening now. The message is: one size fits all.

And it’s all BS.

 

 

Agile Enablement: Now in a Spray!

“Agile enablement is all we do” is a phrase used by some firms that sell Agile as a product. The basic idea here is that this one firm with a designed, “proven” approach can solve all your Agile problems– can be your “panacea”– so long as you write a big check.

This is very misleading, since Agile is not a product. Some folks with a very creative sense of humor are bringing this to attention with “Agile In A Can“– in effect, delivering Agile in as a spray-on product. Imagine spraying Agile on your managers, your developers, or your task boards, like deodorant or cologne. You get the idea.

(NOTE: You can follow @AgileInACan on Twitter )

The notion you can write a big check and then get visible, instant Agile going is seriously misguided. Your organization must be committed to learning, UP FRONT, and take responsibility for that learning after a while being guided by an external coach. And in time, by going forward– without that external coach. This is your goal: self-sustained, “free standing” agility.

Some service firms out there are selling the idea that you need a coach present each and every day, 5 days a week, for at least 12 weeks. Otherwise, you may fail !

This is called “embedded agile coaching” or “integrated coaching”. It sets up an nearly-automatic, unhealthy dependency on your “coach”. The implication is, “We are the experts. We have loads of experience, look at our client list. We have the one true way, this is absolutely the right way to do it. You may fail otherwise. We are the experts, and we are here to help you.” Out comes the contract and when you sign it, you lock in legally to pay for five days a week for 12 weeks.

What this does is simple. It sets up the “coach” to be present 8 hours a day, every single day. After a while, it becomes very obvious to you, the customer: the coaching job is definitely not a full-time job, even when coaching 1,2, or 3 teams.

How to get the coach busy doing something? The obvious fix is to make the “coach” the Scrum Master for all the teams right? ….so the coach is “doing something”, and is “earning their keep”. Makes sense right? Not exactly. Now the dysfunction kicks in.

The coach is now the authority, the person your Agile adoption most depends on. What usually happens is, this person takes up the Scrum Master role while not really teaching this skill to others in your organization. This makes the “you will fail without us” theory a self-fulfilling prophecy. If that “coach” leaves, no one really knows how to be the Scrum Master.

This practice of “integrated agile coaching” is really just a gamed scenario for installing a billable person in your shop each and every day for 60 days in a row. At a high bill rate. To generate loads of revenue. That’s it. It’s about revenue generation. For them to keep it going beyond the contract term, you need to stay dependent.

Don’t think so? Consider this report that says many customers are reporting that “agile is a scam to sell services”. Are these practices I am describing fueling this trend?

Did the customers surveyed in this scathing analysis of agile  buy 5-days-per-week, “agile integrated coaching”?

Are you looking to buy some agile coaching? OK. Here is the pattern.

The rigged game presented to you by the  “agile coaching innovation” firm goes something like this:

The Goal: Maximize Revenue Generation

The Rules: The coach is going to set up camp in your shop 5 days a week for 3 months. You the customer must sign a binding contract for “integrated” coaching, which is 5 days a week, for a 3 month minimum (a legally binding, ironclad revenue guarantee. You cannot get out.)

Scoring: The game is scored by the minimum 3-month revenue generation and the ongoing creation of more dependency on the coach from the client. Primary device to do this: be there 5 days a week, and work to occupy/own the Scrum Master role on every team. (NOTE: A good coach will teach others in your organization this role, and vacate the Scrum Master role as soon as possible and without delay !)

Opting-In: You the customer are either in or out based on the 5-days-a-week-for-3-months contract. Did I mention the high bill rate? The insistence on this engagement structure as the terms of engagement tests your willingness to play the dependency game. If you go for the contract, that means you are willing play the dependency game. By signing, you are agreeing to much more than you bargained for…

And dependency IS the name of the game!

Here is a good article on agile coaching, from the Agile Journal. It is from 2009.

Look at what it says:

However a Coach works, and whatever approach they take they the Coach needs to avoid creating a learned dependency.  This happens when the team comes to depend on the Coach.  Coaches need … to withdraw when the time is right and let the team continue.

While many companies will have their own coaches on staff and some will work with teams day-in, day-out for months or even years, there is a lot to be said for…limiting the period of coaching.

Yes, some “agile enablement” service firms selling “integrated Agile coaching” are eager to set you up in their “agile enablement” game, a game that maximizes billing-revenue for them first, and enables Agile for you second.