Category Archives: Coaching

May 30th-June 1st: Certified LeSS Practitioner Course With Craig Larman | NYC

Another LeSS Training (CLP) with Craig Larman is in the CompuBox.  This highly engaging training brought together 35 attendees from all over the globe.  One of the attendees was Chet Hendrikson.  A bit about Chet:
Chet has been involved with Agile Software Development since 1996 and is the first signatory to the Agile Manifesto. Along with his long-time friend and colleague Ron Jeffries, Chet has made the following important contributions to the global agile community:
  • Wrote Extreme Programming Installed (also with Ann Anderson)
    In 2009, developed for Scrum Alliance the Certified Scrum Developer program
  • Taught the first Certified Scrum Developer (CSD) course
  • Have been curating the Scrum Alliance’s Agile Atlas website
  • Created the SA’s official Scrum description, Core Scrum
  • Speak at conferences, bringing an interesting mix of humor and deep knowledge, and the odd cat picture.

This is what Chet had to say about the course:

“Chet Went to Craig’s LeSS Course”

Many years ago, I wrote an article entitled “Inside every 100-person project is a 10-person project trying to get out.”  That pretty much sums up my feelings about Agile at scale.

My interests have always been with the programmers and their safety and not with how to “Agilize” the organization.  Some of this was a reaction to the failure of most Agile transformations.
But, as someone deeply rooted in the Agile movement, I feel it is important to pay some attention to the “scaling” end of things.  A couple of years ago,  Ron Jeffries and I took (most) of the four-day Implementing SAFe course.  You can read about that at https://ronjeffries.com/xprog/articles/safe-good-but-not-good-enough/.
I have also been paying attention to Craig Larman and Bas Vodde’s Large Scale Scrum (Less).  So, when I saw that Craig was teaching a LeSS Practitioner course in New York on a week I was not working, I signed up.
There were a couple of reasons for me to take some time away from my wife and cats to do this.  First, after having read the LeSS books, I wanted to learn more.  And, secondly, I have always enjoyed my interactions with Craig and wanted to spend some more time with him.
The course is three full days, 8:30 to 6:00, and involves a great deal of hands on work.  And, I do mean work.
Craigs starts the class by saying that “you won’t successfully be able to return to your workplace and ‘give a summary’ of your insights; it is futile & won’t be understood.”
He is right about this.  But I will try and give you my impressions of the course.
One of the key takeaways from the course is something I already believed, which is don’t scale.  Do everything possible to build your product with one time.  If that is not enough, find ways of descaling your problem.  Only if that fails take the steps required to turn your organization into one that can build large products with Scrum.  Doing this effectively will require many changes.  Most of which are about removing management and simplifying information flows.

Craig’s organizing principle for the course is that in order to successfully use these ideas,  you must own them.  Having an instructor, no matter how good they are, no matter the depth of their experience, teach you something is no where as good as discovering the answers yourself.  To this end, we spent most the the course learning and practicing organizational modeling to derive the practices and structures that align with our goals.

In the course, our goals where to create a learning organization that has the ability to “turn on a dime for a dime.”  You may have other goals, but these tools will help better align with them no matter what they are.
Only on the afternoon of the last day did we turn to a full discussion of LeSS.  This was very insightful and was a fitting way to close out the course.
If you are interested in Scrum at scale, I highly recommend  this course.  If you are interested in bringing your organization into sync with its goals, then this is the place to start.

 

Some more Kodak moments from the event are below:






 

 

 

 

 

 

Centralized vs. Decentralized Coaching

Key Takeaways

Read the original post on InfoQ.

  •  There is a frequently seen confusion with respect to the definition of agile coaching: coaching focus (e.g. enterprise vs. team) is confused with coaching alignment (centralized vs. decentralized) within an organization
  • Centralized coaching departments run the risk of turning into a single-specialty organizational silos that are locally optimized for their own expansion and personal success; they are also removed from real action. The reasoning behind: standardization – has its weaknesses.
  • Centralized coaching is often limited to being “responsible for introducing KPIs, documentation of script-style-one-size-fits-all best practices and cookie-cutting approaches”.  This leads to system gaming by other departments and organizational silos that must “meet numbers goals”
  • Centralized Agile coaching makes sense only when it takes place within an organization that is small enough to be effectively managed front-to-back (including its all organizational layers)  and is genuinely supportive of its own coaches, by providing them with “organizational immunity” and operational safety – to enable them perform their challenging duties
  • The main advantage of decentralized coaching approach is that coaches are close to real action: deeply engaged with products/services, and are intimately engaged with senior leadership.  Decentralized coaching is deep & narrow (as opposed to being broad and shallow) and takes time to cause meaningful and sustainable organizational changes.

Read the original post on InfoQ.

2018 BIG APPLE SCRUM DAY: COACHING CLINIC

2018 Big Apple Scrum Day (BASD)  is in the Copy Box.   This was another amazing  annual event, organized by BASD team of volunteers.

The agile coaches-clinicians serviced more than 30 attendees, by addressing a variety of questions and concerns.  While some of the discussion topics were similar to the prior years’ clinics, there was a noticeable increase in maturity of topics.  My personal (Gene is here) unique experience was with the folks that wanted to discuss:

  • Implementing Scrum in non-IT area, where software engineering aspect is not present (mainly, graphic design, content management)
  • Engaging HR of financial/investment companies in discussions about organizational agility (incentives, bonuses, performance)
  • Using Scrum and “Team of Teams” concept in government projects/contracts in the areas of US Military and Defense (the discussion was conducted with someone who had personal, first-hand combat experience in Iraq).

The following coaches have provided their personal feedback:

From Peter Green: I love coaching clinic. For me, it is a bite-size, speed dating version of agile coaching: It’s has a short timebox and both parties tend to feel good about the outcome of the session. Even though it is micro-coaching, over and over we are able to generate some good insights, ideas, or new approaches that have the client excited and optimistic.  Today at the Big Apple Scrum Day, I coached a handful of people with questions ranging from how to better help individuals and teams to how to get upper management engaged in Agile adoption. If you are familiar with the various competencies involved in professional coaching, you would observe that these quick sessions tend to lean a bit more toward teaching and mentoring than a typical, long-term coaching relationship. But that’s great! People are encountering challenges for the first time that many of us grizzled vets have seen many times, and so we can give them some insight into patterns that we’ve seen work and the context that made those patterns useful. But, it’s not all advice; in two or three sessions today, I had a chance to do more “pure” professional coaching, where it wasn’t me sharing ideas or suggestions, but asking open access questions and making observations about body language and tone.
From Jim York:  I always enjoy the comraderie of my fellow coaches at the Coaches Clinics and getting to meet the people who come to chat for a 15 minute coaching session. This year’s Coaches Clinic at Big Apple Scrum Day in New York City continued the tradition. While every clinic is different based on who shows up, there are two clear constants. One is the coaches’ earnest desire to help people with the next leg of their Scrum journey. The second is the energy of the attendees in seeking a way forward.Everyone’s Scrum journey is unique and that is what makes coaching such an interesting vocation. Certainly there are patterns — well worn paths that many have trodden in the search for improvement — but these paths crisscross, double back, circle around, and blend in innumerable ways.  For me, this year’s coaching topics ranged from estimation (what a can of worms that one can be!), how to get started with agile, how to improve team focus and accountability when the team is distributed, and variations on how to be a better coach or trainer for the team and the organization.   Read more….
From Amitai Schleier:  I had a great time at last year’s Big Apple Scrum Day presenting with Ryan Ripley in my home market, so it was an honor to be invited back to contribute to the 2018 BASD proceedings in a new way: as part of the Coaches Clinic, where attendees could talk through a situation they’re facing and, in so doing, perhaps gain some new understanding or insight.  These conversations, while brief, can have profound impact. Five years ago, my first visit to a Coaches Clinic transmuted my curiosity about a career option into the resolve to try it. And here we are.  Yesterday, I don’t think I came close to doing for anyone what Roger did for me. But I did make myself useful, reasoning about the needs of the people in Matt’s situation until we found an actionable idea. Gene Gendel, who organized the Clinic, is collecting experience reports from the coaches.  Despite the prevalence of Lego in Agile coaching games and simulations, I still hadn’t played with it much since childhood. I guess I decided to start practicing because Taavi will be Lego-ready before we know it. I tried to stay off the grid.  It was energizing to punctuate the pace of the one-day conference by visiting with friends — especially Joanne Perold and Barry Tandy, who I’d met online via Agile for Humans, and now in person, all the way from South Africa. I also got a kick out of rubberducking my code problem with Doc Norton, though we ran out of time to pair on it. (Jo and Doc both keynoted.).  Read more….
From Mariya BreyterStart with Why Agile community is well known for transparency, supportiveness, and generous knowledge sharing – after all, this is what Agile is about. This is one of the reasons I volunteered for the Coaching Clinic. Having previously coached at BASD as well as the Lean Startup Conference, I expected to meet new people, support them in their exciting challenges and opportunities, and share my experience of nine enterprise-level transformations I was part of – and all of this happened, and much more. Gene Gendel who runs BASD coaching clinic since the first conference four years ago, made every coach and coachee (I am told there is no such word so I made it up 😊) feel welcome and comfortable. Anyone could sign up for any slot for anyone or for a specific coach, and there were always coaches available in the clinic area to answer any questions or to have a friendly chat with participants. It was a great opportunity to meet other coaches who are all great professionals well known in the field, and many of them are good friends since the first BASD. Everyone who came over for coaching was super nice, generous and grateful – thank you all for making this Clinic a success! Now about the specifics.  Read more….
From Aleksandr Kizhner: BASD2018 conference to me is where my mindset meets action, and this was another excellent conference. Being part of the awesome team of agile coaches – clinicians I’ve struggled with how to condense all my positive experiences into a few bullets point feedback; this may have to be the first of many. Over just one day, I was able to create new connections, engage people in enlightening coaching sessions, and start a number of thought-provoking conversations with other agile coaches.

Few of my sessions focused on the importance of the team culture and surprisingly less on the health of the product backlog, user stories, and technical agile concepts. Many emphases were placed on relationships and trust between team members instead of the typical command and control and process quality assurance that found in traditional software development processes. One of the main benefits I took from being at a coaching clinic, I was being able to meet and network with other people who were going through their own organizational agile transformation. There were a lot of lessons learned shared and views on how to best proceed. 

 

Some Kodak Moments:

Our worksheets:

From left to right: Peter Green, Gene Gendel, Jeff Patton

Scrum Alliance Education specialist Alexxis Holquin:

2018 BIG APPLE SCRUM DAY: COACHING CLINIC (Coaches Worksheet)


This page is being gradually developed towards May, 2018 Big Apple Scrum Day Coaching Clinic.

For similar past events please visit:

Below are some basic guidelines for participating coaches on how to run a coaching clinic during Big Apple Scrum Day.  Experience and working models of previous clinics (Scrum Alliance, Agile Alliance) have being used. If you have other recommendations or additional ideas, please suggest 🙂  .

General Coaching Guidelines:

  • Wear a coaching hat – we shall try to get some from Scrum Alliance folks (their ‘station’ should near the clinic)
  • Walk-ins are OK if we have capacity
  • Each session is limited to 15 min, unless there is no line – then you can attend to another person
  • Appointments get priority over walk-ins
  • It is OK to offer a business  card for future consultation but Do NOT sell services or proactively solicit business, while coaching
  • Paired coaching is OK if we have capacity (one coach works, another observes; then– debrief).
  • Always, start off with understanding what brought a person to the clinic (e.g. “What brought you here?” or “How I can help?”)
  • We can briefly retrospect at the end of the day or, if not possible, later via email

Participating Coaches (BOARD view):

This is us – the clinicians:

Coach’s Name Home base
 Gene Gendel  New York, USA
Jeff Patton  Salt Lake City, UT
David Liebman New York, USA
Jim York  Leesburg, VA
Alexandr Kizhner   New York, USA
Amitai Schleier  New York, USA
Mariya Breytner  New York, USA
Ross Hughes  Burlington, Vermont
Diane Zajac  Erie, Pennsylvania

 

Coaches’ Availability (BOARD view):

In the morning, we shall put up a board in our working area.  On this board, each coach will put his name (on a sticky), in a time slot when he/she is willing/able to offer service.  Example below:

Time Slot Available Coach
8:00 – 8:30
8:30 – 9:00
9:00 – 9:30
9:30 – 10:00
10:00 – 10:30
10:30 – 11:00
11:00 – 11:30
11:30 – 12:00
12:00 – 12:30
12:30 – 1:00
1:00 – 1:30
1:30 – 2:00
2:00 – 2:30
2:30 – 3:00
3:00 – 3:30
3:30 – 4:00
4:00 – 4:30
4:30 – 5:00

Note: Time slots should correlate to the Event’s Main Schedule

 

Appointment Schedule (BOARD view):

On this board, each attendee will put his/her name/discussion topic (on a sticky), into a time slot when they are planning to attend the clinic.  Attendees may request multiple time slots, within reasonable limits. Each request  = one sticky note.  Example:

15-min Time Slot During

Attendee Name/Discussion Topic

Registration
Morning Session Part 1
Morning Break
Morning Session Part 2
Lunch Break
Afternoon Session Part 1
Afternoon Break
Afternoon Session Part 2

Note: Time slots should correlate to the Event’s Main Schedule 

BOARD: Coachee’s Response:

On this board, every clinic attendee  will be asked to write a brief feedback on a sticky note (example from Orlando). They may or may not provide the name of a coach that offered assistance – it is up to them.   We, the coaches, don’t have to watch them doing this.  Once we are done with a coaching session, they can self-manage.

BOARD: Appointment Counter

On this board, we shall be collecting all sticky notes that were served. Attendees will be asked to post them there, after they attended the clinic.

 

 

December 6th-8th: Certified LeSS Practitioner Course With Craig Larman | NYC


Another Large-Scale Scrum Training (CLP), taught by Craig Larman in NYC, is in the CompuBox.

More than thirty people from all-around the globe (North America, South America, Europe) came together for this brain-jelling learning experience! The group consisted of product owners/managers, software engineers, managers and organizational design consultants (scrum masters, coaches and trainers) – people coming from different backgrounds and with a focus on different aspects of organizational agility. What has united them all, however, was their eagerness to learn in-depth about principles of organizational design and implications of Scrum adoption at scale in complex organizational settings.

Course Highlights

With exception of a few rare questions/clarifications, the class spent NO time discussing basic Scrum.  It was implicit (assumed) that everyone in class had strong knowledge and hands-on experience with the basic framework.  On occasions, the topics discussed would bump into “…oh this is not even LeSS-specific; this is just basic Scrum…” but those cases were rare.

Not until day three,is when the class took a deeper dive into LeSS Framework and LeSS-specific events, artifacts, roles…. Why was not it done sooner?   Well…

  • LeSS is Scrum. It is the same very Scrum described by Ken Schwaber and Jeff Sutherland in the Scrum Guide, but done by multiple teams, as they are working together, on the same product, for the same product owner.  LeSS is not “…something that IT does, that is buried in a company’s basement, under many layers of organizational complexity…”. LeSS is an organizational design that uses Scrum (team) as a building block.  Understanding basic Scrum made understanding of LeSS very easy for everyone.
  • The class was made of people that have completed all assigned homework (self-study), before attending. People knew what LeSS picture looks like 😉, when coming in.  Everyone in class was an educated customer.  Importantly: there were no attempts to change LeSS (or change training content 😊  of LeSS), to make it better fit conditions of organizations, where people came from.
  • Spending the first two days on understanding system modelling techniques, differences between causation and correlation (as well as other dynamics) among many system variables, made full understanding of LeSS on day three, come more naturally.

The class learned how to see ‘the whole’/full picture of organizational ecosystem and learned to appreciate why Organizational Design is the first-order Variable that defines System Dynamics (followed by everything else: culture, policies, norms, processes, etc.)

One of my (Gene) biggest take-away points (on the top of an excellent LeSS refresher, from Craig himself), that I plan on using immediately, was the fact from history that was discussed at the beginning of the course (and, sadly, forgotten or known known by many).  And it goes as follows:

…Back in 2001, at Snowbird, UT, where the group of seventeen entrepreneurs-product-developers have met and came up with what is known today as ‘Agile Manifesto’, the two contending terms to-be-used were adaptive (suggested by Jim Highsmith, the author of Adaptive Software Development) and agile (suggested by Mike Beedle).  ‘Agile’ won because of the reasons that are described here.  Truth be told, because the English meaning of ‘agile’ is not as intuitive is the meaning of ‘adaptive’, today, there is a huge number of fads and terminology overloading/misuse that make the original meaning of agile so diluted and abused…. As it was meant to be: Agile == Adaptive ==Flexible.  We all have to be careful with the meaning of words we use, to avoid this painful irony😉.


Here are some Kodak moments from the event:

What Should Agile Leadership Care About?


Agile frameworks (e.g. Scrum, Kanban, XP), individuals’ roles & responsibilities, processes & tools, metrics & reporting, burn-up charts, estimation techniques, backlog prioritization, agile engineering practices, agile maturity models etc. – all of them are important attributes of a typical agile transformation.  However, NONE of them are first-degree-of-importance system variables that are responsible for transformation success.  Most of them, are good superficial lagging indicators of agility but they are all corollary (secondary and tertiary) to another much more important system variable.

What is the most important system variable that defines a company’s agility?  It is Organizational Design –  the most deeply rooted element of organizational ecosystem that defines most of system dynamics.

When organizational leadership decides to take an organization through an agile transformation journey (it could take years, sometimes), it [leadership] needs to acknowledge that real, sustainable agile changes are only possible if deep, systemic organizational improvements are being made.  For that, leadership needs to be prepared to provide to its organization much more than just support in spirit, accompanied organizational messages of encouragement and statements of vision.  Leadership must be prepared to intimately engage with the rest of an organization, by doing a lot of real “gemba” (genchi genbutsu (現地現物)) and change/challenge things that for decades, and sometimes for centuries, have been treated as de-facto.

What does it really mean for leadership to engage at System Level?  First, it is important to identify what a system is: what are a system’s outer boundaries?  For example, one of the most commonly seen mistakes that companies make when they decide on “scope of agile transformation” is limiting its efforts to a stand-alone organizational vertical, e.g. Technology – and just focusing there.  Although this could bring a lot of local (to IT) success, it may also create unforeseen and undesirable friction between the part of an organization that has decided to change (IT) and the part of an organization that decided to remain ‘as is’ (e.g. Operations, Marketing).  For example, if Scrum teams successfully adopt CI/CD, TDD or other effective engineering practices that enable them deliver PSPI at the end of every sprint, but business is not able to keep up with consumption of deliverables (too many approvals, sign offs, red tape) then the whole purpose of delivering early and often gets defeated.  Then, instead of delivering to customers soon, in exchange for timely feedback, teams end up delivering in large batches and too far apart on a time scale.

A successful Agile Leader must treat an organization, that is expected to transform, as a sushi roll.  Just like seaweed alone does not provide a full spectrum of flavors and does not represent a complete, healthy meal, one single department (e.g. IT) is not sufficient enough to participate in agile transformation efforts.  Other organizational layers need to be included as well, when identifying a slice for agile transformation experiment.  A slice does not have be too thick. In fact, if organizational slice is too thick, it might be too big to “swallow and digest”.  But still, even when sliced thinly, an organization must include enough layers, to be considered as a ‘complete meal’.

Note: A great example of treating an organization as a sushi role, while making it more agile, is Large Scale Scrum (LeSS) adoption.

So, what are some key focus areas that every Agile Leader must keep in mind, while setting an organization on agile transformation course?

  • Location strategies. Geographic locations.
  • HR policies (e.g. career growth opportunities, compensation, promotions)
  • Budgeting & Finance
  • Intra-departmental internal boundaries and spheres of influence
  • Organizational Leadership Style
  • And some other areas that historically have been considered as …untouchable

All the above listed areas are defined by Organizational Design and can be better understood through self-assessment, done by organizational leaders at all levels.

Diagnosing Challenges in Scrum

When people go to the doctor’s office, they often complain of superficial manifestations of a problem (i.e., “chief complaints”) that don’t present any serious concerns, but in reality, are indicators of a much more serious systemic illness.

I’ve come to the conclusion that we in the Scrum field are also dealing with a similar type of scenario.

For those of us who have been coaching for a while, it’s probably a common experience to have a team member or a manager come to us with what appears to them as a “key problem,” but in reality, turns out to be a symptom of a much more serious underlying dysfunction.

On June 1, 2015…(read more from the original post)

“Who are the Judges?” Who Decides on Who is Gonna Coach?


Lets kick off this post with the quote from another recent discussion that generated a number of strong comments from experienced professionals:

“…as long as companies remain complacent and reliant on outlived staffing/head-hunting approaches, cold-calling techniques, and ineffective HR-screening processes, performed by people that poorly understand the essence of an agile coaching profession, while trying to procure cheap “agile” resources (using “preferred vendor lists”) or treat seasoned professional coaches, as “requisitions to be filled”,  a coaching bar will remain low, and companies will be getting EXACTLY  what they have paid for: coaches-centaurs (p.17)…”

 

To summarize, the purpose of the above referenced discussion was to increase awareness about implications of ineffective coaches and coaching that exists in abundance today.  Here, lets look at some root causes why this problem exists.

Who Defines the role of Agile Coach?

For the most part, organizational understanding of a coaching role is weak.  Definitions of a coaching role that flow around, suggest that companies are still confused about what coaches do.  Definition of a coaching role is frequently lumped together with the role of a project manager, team lead, business analyst, Jira/Rally/VersionOne administrator etc. While some of these other roles, could represent potentially relevant past experience for a coach, lumping all of them together in one all-inclusive role description, delimiting them by a commas or forward slashes 😊, is ironic, to say the least.  Many of these “ace pilot/submarine captain/NHL star” roles create a conflict of interest not just for people that step into them but for everyone else who gets affected by interaction.  Very often, inaccurate definition of a coaching role leads to inappropriate behaviors by a coach, such as attempts to seek authority and organizational power, exhibition of command & control behavior, competition with people being coached for ownership of deliverables, monetary incentives and other perks.

Once a poorly-defined coaching role description hits the street, it enters a vicious cycle – reinforcing feedback loop.  (described in detail here ):

(Note: the above illustration excludes other system variables that may have effect on the variables and variables’ relationships shown above).

This vicious cycle usually leads to one inevitable result: over-time (usually months; sometimes a few years) companies realize that agile coaching did not bring about enough sustainable organizational improvements, as it was expected.  This further leads to two outcomes, both of which dependent of senior leadership vision and goals:

  • Companies seriously re-assess their own initial actions, acknowledge mistakes made, and then improve coaching standards and elevate the bar in favor of real, experienced coaches
  • Companies, try to water down mistakes they have made, trivialize a coaching role for a lack of it’s benefit and, and by doing so, further reinforce the loop above
Who Really Makes Decisions and Why?

Rarely, senior executives take an active role in a coaching hiring process; exceptions exist but they are rare (usually,  exceptions are seen when things become very urgent – page 14).  But even when they [executives] do engage in the process, it is usually more the act of a formality, to ensure that a hired person “fits the culture”. Of course, and very ironically, one of the key expectations from an experienced coach should be to challenge an organizational structure (both, at enterprise and team level), and since culture is corollary to structure (Larman’s Law # 5), the latter would change (would be challenged) as well.  But this is not something that too many senior executives would like to hear.

For the most part, a hiring process is delegated to first- and sometimes second-line management, as well as internal agile champions that oversee and own agile transformations.  While Larman’s Law # 1, historically, has defined the attitude of middle management towards fundamental changes that challenge a status-quo, the recently added Law # 4 neatly describes “contribution” by some internal agile champions.  And while exceptions do exist, trends and statistics speak louder.

Let’s imagine the process by which an organization wanted to hire an agile coach (as employee or consultant – no difference):
In this process, the interviewers – are individuals described in Larman’s Law # 1 and # 4.   On the other hand, an interviewee, is a seasoned agile coach, with long enterprise- and team-level track record: she is a system thinker, dysfunctions challenger, a real organizational change agent.

Impact on a hiring process by Larman’s Law # 1-type Interviewers:

At an interview, a coach-candidate meets with first- and/or second-line managers that also expect that a coach will report into them, when she joins a company.  During a discussion, interviewers hear from a coach certain things that coaches usually bring up, uninhibitedly:

  • Simplified overall organizational structure, where developers receive requirements and communicate on progress, by interacting directly with end customers, not middle-men
  • Flattened team structure, where developers self-organize and self-manage. Overall reduction of supervision and resource management, in favor of increased autonomy, mastery and purpose, by individuals that do work
  • Harmful effects of individual performance appraisals and subjective monetary incentives, especially in environments, where team commitments and team deliveries are expected

Unsurprisingly, the biggest question that many interviewers walk out with, after interviewing such a candidate is: “What will my role be like, if this coach is hired and brings about above mentioned organizational changes?

 

Impact on a hiring process by Larman’s Law # 4 -type Interviewers:

Knowledge and experience of a coach-candidate supersedes that of internal agile champions and process owners.  Some of the discussions a coach elicits, and answers provides, by far exceed expectations (not to be confused with a term used in a performance appraisal process 🙁 !) of her interviewers.  Some suggestions and ideas shared by a candidate are a great food for thought for senior executives but not at a level, where Larman’s Law # 4-type coaches are authorized to operate.  Interviewers clearly see that a coach-candidate, if on-boarded, soon may become a more visible, influential contributor than the interviewers themselves.   A coach may also bring about some organizational turbulence that will take out of comfort zone some individuals that are resistant to changes.

What are the odds that this experienced coach-candidate will be given a “pass”? What are the odds that she will be even given a chance to speak to senior executives involved in a hiring process, to attempt to influence them,  to open their eyes, to offer a deeper system perspective on a situation, to make them think and talk about the forbidden?

Slim-to-none. 

And this is one of the ways, in which organizations that are complacent about agile improvements, shoot themselves in a foot: they very effectively disqualify qualified agile coaches and by doing so, reinforce the feedback loop illustrated above😉.

You Get What you Ask For: Agile Coaches-“Centaurs”


Why are there so many troubled agile “transformations”?  We frequently hear the following answer: “because companies lack senior leadership support”.  True.  And let’s not trivialize this: without strong and genuine support by senior leadership (beyond slogans and “support in spirit”), without selecting a deep, systemic approach to problem resolution, companies can only expect localized, peripheral and, most likely, short-term improvements.

But is there anything/anyone else that can be conveniently held accountable for failed agile transformations?

How about ineffective agile training and coaching?  [Note: If you are interested in learning more about some of the most common challenges with agile training, please visit this page.  This post is about coaching .]

…There is a vicious cycle that hurts so many companies (can be also considered as a self-inflicted wound):

initially, companies set a low bar for coaches, based on poor understanding of a coaching role  low quality coaches (quasi-coaches-“centaurs”) are hired, most of whom are not even coaches, but rather people that have mastered agile jargon and know how to impress HR and uninformed hiring managers  weak coaches (most of whom have minds of conformists, not challengers) cannot effectively guide companies to fix systemic weaknesses and dysfunctions  teams and departments  don’t really improve; rather create a superficial appearance/illusion of progress (often, to impress senior management)  companies lose faith and stop seeing value in coaching → companies start trivializing a coaching role  companies decide not to spend more money on high quality coaching cheaper, even less effective, coaches are hired (or internal, misplaced people are refurbished into coaches, overnight, as per Larman’s Law # 4) initially, low-set coaching bar, is lowered even further…and so on….

Graphically, it looks something like this:

As a result, what was initially meant as a strategic organization- improvement effort, now takes on a form of just another system-gaming change management fad that ultimately leads to a failure and responsibility/blame-shifting.

What are some of the reasons why the above happens?  Here are some suggested reasons:

  • Companies don’t understand the essence of agile coaching role: it is viewed as another “turn-on switch” management function
  • Leadership does not feel a sense of urgency (p. 14) to make changes and exempts itself from being coached: people are too busy and too senior to be coached; they find coaching trivial
  • Certain organizational pockets are genuinely resistant to/feared of changes that can be brought about by real coaches (as per Larman’s Laws 1 – 3)
  • Market over-saturation with unskilled recruiters that hunt for low-quality coaches and contribute to the above cycle: this further lowers a company’s chances to find a good coach
  • This list can be extended….

Who is responsible for initiating this vicious cyclic dysfunction?  Does it really matter if we identify guilty ones?  Maybe it does, but only, as a lessons-learning exercise.  What probably matters more is how to break out of this cycle.  Where to start: discontinue low-quality supply (coaches) or raise a bar on demand (by companies)?  Usually, demand drives supply and if so, for as long as companies remain complacent and reliant on outlived staffing/head-hunting approaches, cold-calling techniques, and ineffective HR-screening processes, performed by people that poorly understand the essence of an agile coaching profession, while trying to procure cheap “agile” resources or treat seasoned professional coaches, as “requisitions to be filled”,  a coaching bar will remain low, and companies will be getting EXACTLY  what they have paid for: coaches-centaurs (p.17).

Big question

What should companies be looking for when hiring a coach?”

An organization should be looking much father and beyond of what is typically presented in a resume or a public profile of a candidate: usually, a chronological list of an employment history or a long list of google-able terms & definitions,  popular jargon or claims of experience in resolving deep, systemic organizational challenges with Jira configurations 😊.  Much more attention should be paid to the following important quantitative characteristics of a coach:

Coaching Focus: What is an approach and/or philosophy to coaching does a coach have?  This will help a company understand an individual mindset of a coach.

Coaching Education AND Mentorship: What active journey through education, mentorship and collaborative learning in coaching and related activities over significant period has a coach taken?

Formal Coaching Education: What has contributed significantly to a person’s coaching journey, including courses on topics of facilitation, leadership, consulting, coaching, process, and other related activities which have influenced a person’s coaching practice? Such education may not have to be degree-related (training and/or certification from any recognized institution could be sufficient).

Coaching Mentorship & Collaboration: How a coach developed a skill/technique or received guidance to a coaching approach and mindset?  Respect and recognition of mentors – matters here.

Informal Coaching Learning: What important topics outside of Agile/Scrum literature have impacted a person’s coaching philosophy?  This increases chances that a coach is well-rounded, beyond standardized book learning.

Agile Community Engagement & Leadership:  Does a coach engage in agile user groups, gatherings, retreats, camps, conferences, as well as writing, publishing, reviewing, presenting, facilitating, training, mentoring, organizing, and leading agile events?  An active participation and leadership in the agile community is a good demonstration that a coach has not developed herself within a unique organizational silo, by self-proclaiming and self-promoting, but rather has diverse and ‘tested’  industry experience.

Agile Community Collaborative Mentoring & Advisory: Does a coach mentor or advise other individuals (not for pay) on how to increase their competency or development?  Is a relationship on-going, purposeful and bi-directionally educational?

Coaching Tools, Techniques and Frameworks: Does a coach develop awareness and understanding of tools, techniques and frameworks while engaging with organizations?  Has she customized or developed anything that was client/engagement-specific?

In addition to quantitative characteristics , here are qualitative characteristics of a good coach:

Coaching Mindset
  • How does a coach react when an outcome of coaching was different from what she had desired? In the past, how did a coach address this situation?
  • How, based on clients’ needs, a coaching mindset had to change? In the past, what compromises did a coach make? What was learned?
  • What new techniques or skills did a coach learn, to meet a client’s needs?
Coaching Competencies
  • Assess – Discovery & Direction
  • Balance – Coaching & Consulting
  • Catalyze – Leadership & Organizations
  • Facilitate – Focus & Alignment
  • Educate – Awareness & Understanding
Coaching Specialties
  • Lean / Kanban
  • User Experience / Design
  • Scaling Agile / Enterprise Agility
  • Technical / Quality Practices
  • Organizational Structures
  • Lean Startup
  • Product / Portfolio Management
  • Organizational Culture
  • Learning Organizations
  • Non-Software Application
  • Business Value / Agility
  • Technical / Product Research
  • Multi-Team Dynamics
  • Organizational Leadership
  • Organizational Change

[Note: The above, is based on guidelines provided by Scrum Alliance application process for CTC and CEC.]

While running some risk of sounding self-serving (very much NOT! the intent here) : please, be mindful and responsible when you select guidance-level professionals in your agile journey 😉.

Grassroots of Modern Command & Control Behavior


Examples of Command & Control behavior can be historically traced back into centuries, to the periods of dictatorship, imperialism, monarchy, feudalism and even further back, to more primitive social systems.  However, for the sake of this discussion, let’s refer only as far back as Industrial Revolution of the last century.  Back then, workforce predominantly consisted of low-skilled laborers that performed routine, mundane physical work and managers-supervisors that were responsible for setting goals, assigning responsibilities, monitoring progress and praising-penalizing workers, based on individual performance of the latter (using “carrots & sticks” approach).  This type of management was a classic example of what is known as Taylorian Management (Frederick Taylor), according to which, there had to be clear delineation between individuals that performed work and individuals that controlled/managed work of others.  This type of human relationship in work settings was also later described as Theory X Management (Douglass McGregor), and it suggested that managers needed to use totalitarian and repressive style to ensure tight control over workers, because the latter would otherwise not work hard and efficiently enough.

…Fast forwarding to modern days…

Today, we still have many examples of Command & Control behavior that shape relationships among people in modern organizations.  This happens even in situations, where organizations have workers that are very highly skilled and intellectually advanced.  More frequently, this is seen in organizations that are at Laloux’s Orange state of maturity or lower.

While in part, modern Taylorian Behaviorism can be explained by long-lasting “cultural inheritance” that hopefully will wear off over time, it would be interesting to look closer at some specific root causes of modern-days Taylorian behavior.

Although not exclusively, the examples below, are more frequently observed between individuals that are related to each other by hierarchy (boss-subordinate).

Insecurity about own job. Worries about own career growth.

A manager does not feel secure about his own position.  This could be caused by company reorganization (e.g. merge, acquisition, flattening) and a manager feeling that his role may be reduced or eliminated.   This fear of becoming dispensable could be worsened by realization of personal incompetence and/or lack of professional knowledge.  This is frequently seen in situations, where managers, as they have progressed the hierarchical ladder, have given up their hands-on skills and became peoples’ managers.

Misunderstanding roles of other people

A manager does not keep up with evolution of roles and does not understand purpose/importance of some new roles that have emerged in a workplace.  As a result, a manager tries to “map” new roles to old roles and apply the same yard-stick to measure and manage a subordinate.  His own lack of understanding could be frustrating to a manager and, therefore, make him feel defensive in discussions of roles and responsibilities of his subordinates.

Compromised self-esteem and desire to protect own Status Quo

While being a part of a larger organization, a manager might be getting a significant portion of mistreatment, in the form of command & control behavior, from his own superiors.  This is where the desire to protect his own status quo and not to look defeated in the eyes of his own peers and sub-ordinates kicks in.  There is a growing need for self-redemption and the urge the relieve a built-up psychological stress.

Note: All three examples of the root causes of Command & Control behavior above, usually result in a manager becoming passive aggressive and seeking ways to discharge negativism onto others.  Typically, “others” come in the form of a manager’s own subordinates, with the latter becoming defenseless recipients of mistreatment.

“I am Great” competitive stance “Tribal Stage 3” (D. Logan)

With the attitude of “I am great and you are not”, a manager perceives himself as someone who is smarter and greater than his subordinates.  The person that acquires a managerial position, that is sometimes is just a result of skillful pursuit of a new vacancy (e.g. due to reorg, force reduction) and/or experience to navigate organizational political terrain, feels the need to demonstrate his superiority to others.  To continue being perceived as a super-star and to stay in a spotlight of all events that can further multiply his glory, as well as to be able to claim someone else’s credit (delivery, innovation, invention) as his own, a manager wants to keep his subordinates “at bay”, to prevent their independent advancement and autonomy.

Individual resentment and animosity towards other people

While not very common and rightfully speculative, there are situations when outside-of-work relationships or individual perception outside of working environment, define the relationship between a manager and subordinate.  Broken friendship, unsuccessful romantic relationship, differences in personal values, norms or beliefs – all can impact professional relationship at work.  A manager, who has an upper hand, may leverage his superiority to repress a subordinate, in retaliation to work-unrelated matters.  On top of being unprofessional, this behavior could be also viewed as “unsportsmanlike conduct”. 

I am Expert” distrusting stance (distrust in competence of others)

This could be viewed as the least “harm intended” manifestation of command & control behavior.  This is more commonly seen in situations, where a manager still has sufficient hands-on expertise (e.g. technical lead) and can-do work.  Viewing himself as a “super-doer-expert”, a manager usually prefers to “shut the door” and resolve all problems on his own, instead of trusting his subordinates to collaborate and come up with shared decisions.  A manager-doer prefers to make single-handed decisions, while controlling actions and interactions of other people, in a fear that someone’s failure will be perceived as his personal failure.

Below is System Modeling diagram-example that illustrates relationships Command & Control behavior with the reasons described above and some additional system variables that impact system dynamics.