Category Archives: Coaching

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.   One example of one’s own job insecurity is hands-off code ‘chief architect’ who wants to build his own power tower of control to ‘own’ enterprise architecture (see graphic below).

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.

Bad Choice of Verbs Associated with “Agile”, by EFL People

These days, almost everyone knows that organizations cannot “do” agile; they can “be” agile.  And today, this contrast is used not just by agile coaches and scrum masters.   Everyone likes building this fancy figure of speech in their daily lexicon: managers, analysts, developers.  Great!!!  Below is a snippet from Wikipedia, defining the word “agility“, using the most natural reference:  a human body.

From reading the definition, it appears that body agility is equivalent to a body fitness/health.  And if so,  it would be fair to assume that when we talk about organizational agility, we also talk about organizations, being fit and healthy (organizational fitness/health). Just like a body cannot “do fit” or “do healthy”, organizations cannot “do fit” or “do healthy”.

But while wrongfulness of “doing agile” is mostly admitted today, there are many examples of using other sophisticated synonyms of “doing” that hint to the fact that people are still NOT clear about what “agile” is.

As the title of this post suggests, and this is where the biggest irony comes from,  the most advanced EFL people (EFL = English First Language 😉) have been making the most noticeable language omissions, while attaching “sophisticated/fancy corporate terms-verbs” (other than “do”) to the word “agile”.

Below, is the list of verbs that are not advisable to be used in conjunction with the word “agile”:

  • “Implement Agile”
  • “Adopt Agile”
  • “Use Agile”
  • “Introduce Agile”
  • “Accept Agile”
  • “Follow Agile”
  • “Move TO  Agile”
  • “Transition TO Agile”
  • “Transform TO Agile”
  • “Install Agile”
  • “Administer Agile”
  • “Leverage Agile”
  • “Upgrade to Agile”
  • “Practice Agile”
  • “Establish Agile”
  • “Experiment Agile”
  • “Standardize Agile”
  • “Execute Agile”

Question: So, what can be done to protect yourself and your organization from a misuse of the above jargon? 

Lets turn our attention to history….

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 documented here

So, truth be told, because the English meaning of ‘agile’ is not as intuitive as the meaning of ‘adaptive’, today, there is a huge number of fad/jargon and terminology overloading/misuse that make the original meaning of agile so diluted and abused.  

As it was meant originally: Agile == Adaptive ==Flexible.   So, here is a great litmus test, if a the word “agile” is being used correctly: can it be seamlessly substituted with its synonym “flexible”, without losing a meaning?  (Ironically, being “flexible” is also an indicator of being healthy, physiologically, as well as organizationally).

05/26-28: Scrum Coaching Retreat | Kiev, Ukraine

2017 Scrum Coaching Retreat in Kiev  is in the books!!!  The event has brought together a few dozens of agile coaches and trainers from nearby and far away.

The participants came from different backgrounds and focus areas but due to everyone’s extensive experience in self-organization and self-management, got the show on the road very quickly.  After a short round of self-intros, each participant introduced a few topics that they wanted to discuss. By using a combination of dot-voting and affinity clustering techniques, the group came up with a handful of key topics that everyone wanted to deep dive into.  The group broke up into four teams, with each team picking one high-priority topic – to be worked on in consecutive three (3) sprints.

The team I joined (“Happy 7”) picked up the topic “How to influence decisions of senior management directly, from the bottom of organizational pyramid”.  The team consisted of experienced ScrumMasters, Team-level and Enterprise-level coaches.

The problem statement that defined our team’s effort was:

“There are so many instances, of challenges and obstacles that teams face, are not being heard at the top of a food chain.  And even when they are heard, often, original messages get distorted and lose urgency, as they travel up through multiple “translational” layers.  What can be done to fix this problem?  What techniques could be used to effectively segregate impediments that are local and can be resolved by teams and the ones that are systemic/organizational – and must be aggressively escalated upward?” 

The problem above has direct dependency on organizational design, specifically, on its thickness: the number of organizational layers between working teams (on one hand) and senior leadership/paying customers (on the other) – is a well-recognized challenge today.

Our working group has identified the following organizational design scenarios that define dynamics and human interaction in modern Product Development:

  1. Development teams and Product Owner belong to the same organization and end-Customer is positioned internally
  2. Development teams and Product Owner belong to the same organization and end-Customer is positioned externally
  3. Development teams represent Vendor-company and Product Owner represents Client-company and relationships between Vendor and Client are based on:
    • Out-staffing model – when a vendor provides human assets (developers) that are then owned by a customer, from management perspective, whereas legal ownership (e.g. insurance, taxes) is still by a vendor
    • Out-sourcing model – when an entire project gets outsourced to a vendor and a paying customer has no or minimal interaction directly with human assets (developers) that do work (most of communication flows through Engagement Management)

Interestingly, since many of our working group members had a lot of experience with #3 option above, the primary focus of our discussion was about how to bring closer senior leadership of paying customers and agile teams of delivering vendors, closer together, despite multiple “anti-agile” organizational layers that frequently reside in-between the former and the latter.

The ultimate result of our brainstorming was the invention of a non-commercial, collaborative game that was given the name of Influence Poker.

Our game’s purpose was:

  • To identify challenges that delivery teams often face
  • To classify challenges, based on origin, severity and implications
  • To discuss potential ways of resolving and/or escalating challenges
  • To ensure resolution ownership and transparency on its progress

Note: The initial contributors to the game creation were: Serhiy Lvov, Kiryl Baranoshnik, Artem Bykovets, Alexander Karitsky, Mark Summers, Jonas Mann and Gene Gendel .

The most serious organizational design challenge, when a paying customer engages with a vendor-company, is seen with an out-sourcing model.  Here, no matter how agile/robust technology teams are, their ability to deliver effectively is hindered by:

  • Involvement of Delivery Manager (usually, placed on a client site) who owns a relationship with a customer, serves as a single filter-channel of communication between a customer and teams, makes commitments and furnishes progress reporting on behalf of teams. The same person also streamlines feedback from a customer back to teams and frequently assigns work to team members.  This is usually accompanied by micro-management and command and control behavior.  The situation can be further worsened by the presence of Vendor Management function (customer side) that enforces SLAs, SOWs and other formal contracts between a customer and vendor: this just adds additional tension to a relationship and moves further apart end-customers and delivery teams.
  • Weakening of Product Owner role – the importance of this critical Scrum role gets downplayed, because a customer company no longer sees value in direct communication with technology teams.  Instead, Delivery Manager is treated as a single person, responsible for project delivery.  This dramatically narrows all communication media that are used in Scrum (holding events, sharing artifacts).

The above two challenges are inter-related through a positive feedback loop: the less disengaged Product Owner becomes, the more pivotal the role of Delivery Manager becomes.  The opposite is true too: strengthening the role of Delivery Manager, leads to further “excusing” Product Owner from stepping into the game, as Scrum requires.  This is a viscous, de-stabilizing loop that continuously weakens Scrum.

Please, look out for the Influence Poker.first official release that is coming soon! It may greatly help your teams visualize their organizational problems and discover potential workable solutions.

Note: For attendees and participants, here are additional shortcuts:

2017 Agile Maine Day Recap

The 2017 Agile Maine Day event is in the books.  Great event organization. Great energizing crowd. Amazing presenters and speakers.

Below are the summaries of two selected presentations, whose themes were mostly relevant to System Thinking and System Design:

Don Macintyre’s topic “Agile Leadership” was about Radical Management (Steve Denning’s teaching) and covered:

  • Shifting focus from making money for shareholders to focus on delighting customers through continuous innovation
  • Managers focusing on controlling individuals to Managers empowering and supporting self-organizing teams
  • Shifting from controlling work with bureaucracy to guiding innovation with priorities
  • Shifting from predominantly valuing efficiency to valuing Continuous Innovation
  • Shifting from top-down command structures to horizontal communication and collaboration

Don also talked about Agile Leadership Mindset and stressed the importance of the following behavioral transitions:

  • From Directing to Coaching
  • From Hiding Failure to Learning from Failure
  • From Telling to Collaborating
  • From Avoiding Blame to Seeing Feedback

Bob Sarni’s – “Radical Collaboration” delivered the following main message: “Organizations cannot compete externally until they can collaborate internally

Bob referenced the book “Corporate Culture and Performance” by John Kotter and James Heskett: Non-enhancing Cultures vs. Enhancing Cultures, alluding to the fact that sometimes the best way to overcome resistance, is to remove resistors.

The following four quadrants of self-discovery were covered:

  • Who we are (Self-mastery):
    • Self-Awareness
    • Self-Esteem
    • Emotional Intelligence
    • Values
  • Interpersonal (Social Intelligence):
    • Communication
    • Trustworthiness
    • Cooperation
    • Rules of Engagement
  • What we Do:
    • Project
    • Product
    • Task
    • Service
  • How We Do it:
    • Systems/Processes
    • Decision Making
    • Structure
    • Policies

Bob also stressed the point that when it comes to going through organizational changes, companies tend to focus on Practices, instead of focusing on underlining Principles and Values. This results in unsustainable, short-term successes only.
Another great quote from Bob’s session: “Business Analysis have their focus on the outer side of business”, mainly focusing on questions of ‘what should we be doing?‘ and ‘how can we do it better, faster and more efficiently’.  It turns out that the inner side of the business is where the greatest opportunity for radical improvement resides”.  The inner side of the business contains the heart and soul of the business.

Finally, Bob talked about Red Zone vs. Green Zone Behaviors (refernicing work of James Tamm)

Bob also described Pink Zone behavior that usually manifests itself by the following actions: Leave, Quit, Hide, Passively Resist, Appease, Give in

(At closing, a kodak moment with Dan Mezick and Bob Sarni)


2017 Big Apple Scrum Day: Coaching Clinic

The Third Annual BASD (2017) event is in the books.  27 people have been served by the coaches, whose cumulative experience and depth of knowledge were just immense.  Many thanks to Zuzka Sochova, Kim Brainard, Bob Galen, David Liebman and Jim York for making this happen.  This event had the largest every presence of Certified Enterprise Coaches (CEC).

Below is the summary of quotes from the people that attended the Coaching Clinic:

  • “Awesome session. Wealth of knowledge.”
  • “Pleasant convo. Vague question but got some interesting answers.”
  • “Bob helped me with several concerns I had. He broke things down and emphasized the importance of always looking at things with a whole team approach. Will use feedback.”
  • “Dave: – great shaking, -good advice, – will use immediately.”
    “Very helpful and informative, It is always good to learn other perspectives”
  • “Great insight and way to look at personal issues.”
  • “Dave game me some good marketing advice about marketing myself”
  • “Bob listened, provided valuable feedback and helped me walk out with actionable items. Thank you!”
  • “David – useful suggestion.”
  • “Refreshing and very pragmatic session.   Great advice and specific to my exact topic.”
  • “Awesome coaching from Kim. Look forward to taking her feedback to work.”
  • “Practical & useful talk about Scrum roles with development team (PO & SM).”
  • “Great feedback from Dave. Great advice about how to run meetings and to get work done.”
  • “Great pointers to look for next steps. Good and honest advice. Informative discussion.”
  • “Got coaching from Jim on rolling out agile more broadly. Jim was really helpful and got us to the heart of where we should focus. Thank you!”
  • “Dave shared personal experiences that helped me identify possible resolutions to my problem. Very clearly followed the steps from the coaching stance. Got definite actions to try.”
  • “Great advice for retros from Kim.”
  • “Had a session with Jim about career path and my goals. He was extremely helpful. Listened to my concerns and helped with ideas.”
  • “Great therapy session! Was able to get real life examples in the feedback.”
  • “Meeting with Jim was worth every nano-second. He reset my thinking about focus but more importantly, my intention with short-term and long-term goals — but especially humility. Excellent!”

Agile Flyer – 04-09-2017



Public Announcement:
Scrum Alliance® Announces Partnership with LeSS Company


Denver, CO,— SCRUM ALLIANCE® – The news are finally out and public: On 4/7/2017, Scrum Alliance interim CEO Lisa Hershman, has announced that Scrum Alliance,
most established and influential professional membership organization and certifying body in the Agile community,entered in partnership with LeSS Company to support widespread adoption of Large-Scale Scrum (LeSS).

-Read the entire press release…

Join your local LeSS communities today.

Applying LeSS Thinking to Basic Scrum
“LeSS Hexagon of Values”

As per Scrum Guide, “…Scrum is a framework for developing and sustaining complex products…
It [Scrum] is lightweight, easy to understand and difficult to master”.
The guide talks about basic Scrum, or Scrum by one cross-functional team that works for only one Product Owner, on one single product.
The guide also mentions situations when multiple Scrum teams must work on the same product backlog and share the same Definition of Done (DoD) – an example of scrum scaling.

Large-Scale Scrum (LeSS), on the other hand, is a product development framework that extends Scrum with scaling rules and guidelines, without losing the original purposes of Scrum.…”.
Some of the hallmarks of LeSS are:

  • It is the framework that requires organizational de-scaling (simplification), to scale basic Scrum
  • It is the framework that strongly relies on effectiveness of organizational design and system dynamics of multiple organizational layers, departments and spheres of control
  • It is not merely a group of teams doing their own Scrum, while working for different product owners and supporting different products.
    Rather, it is a group of teams (2-8) that works together, synchronously, on the same product and serves the same product owner.

-Read more…


More Selected Periodicals:
Unspoken Agile Topics

This paper, originally written in February 2013, brings to light some of the least-discussed topics and consequences of “broadband agilization” that currently take place in the industry.
The materials of this paper are subdivided into two general sections:

  • The first section describes certain impacts that Agile has on individuals and their personal career advancements.
  • The second section describes organizational-level Agile impacts that pertain more to client companies that undergo Agile transformation,
    as well as service-providing vendor companies that deliver Agile-transforming expertise to their respective clients.

-Read more…

Be an Educated Consumer

You just bought a house and decided to renovate. You brought in a contractor to estimate the work that you want done. What is your biggest fear? Here are a few possibilities:

  • The work will not be done.
  • The work will not be done on time (winter is coming and you need wall insulation before it gets cold).
  • The work will be done on time but it will cost you much more than you can afford and more than this job really costs.
  • The contractor is charging you more than he should; he is taking advantage of your ignorance.
  • The quality of the work will be poor but, unfortunately, you will not know this until all of it is finished and you have to move in (after you pay in full).

-Read more…

Fresh Collection of Ad-hoc Agile References:

I continuously collect articles and publications that come from everywhere: colleagues, coaches and trainers, clients, occasional encounters.
I keep a comprehensive list of resources here, categorized by themes.
Some of my most recent samples from the collection are below:


Connect with a Certified Coach for Online Coaching!
(re-published from Scrum Alliance newsletter)


Challenges with Agile Training: Examples, Reasons, Consequences

Virtual networks of professional agile coaches and trainers is good place to pick up some most thoughtful and provocative agile discussions.  The most reputable networks that I know of, and happen to belong to, are the communities of: Certified Enterprise Coaches and Certified Scrum Trainers (both, from Scrum Alliance), and Candidate Large Scale Scrum Trainers and Coaches.  These communities are great because there we continuously  share our experiences and learn from one another.

The summary below is the result of one such in-network discussions that spans in duration for more the a year. It is focused on in-class training experiences and highlights  – some of the most common challenges that we encounter with our students in pre-, in- and post-classroom situations.  Some of our observations are specific to internal classes, some – to public and some – to both.

Below, are some of the common challenges with Agile Training that we face:

Training “Wrong” Attendees with “Wrong” Intentions

At times, we get training attendees that have never held agile roles (e.g. ScrumMaster, Product Owner, Team member), … nor did they ever have an intention to do so.
While agile education is recommended at all organizational levels and for all horizontal structures (perhaps, with different focus, depending on audience), what is sometimes observed is that certain types of individuals show no signs of desire to truly understand to further implement newly-learned agile principles. Instead, their true desire, seems to be, in understanding agility concepts just enough to be able to figure out a way of creating “anti-dote” against them.  Typically, this is seen with individuals that are concerned with their own role security (not to be confused with job security) as it frequently gets challenged in agile and lean organizations (includes processes, tools and roles).

This situation is rather difficult to control in public classes, where any individual who pays a fee, can attend.  However, it can be (and should be) much easier to control with internal training. By requesting class attendees to come in ‘clusters’, as hands-on technical teams that share work already, accompanied by their respective business counterparts, trainers can ensure that right people are gathered together in the same classroom, at the same table, for shared learning, collaboration, and simulation exercises.  This is the most effective way to ensure that in-class learning will retain its momentum, when people go back to their work areas and start implementing newly gained knowledge in practice.
It is important to note that for any trainer who is planning to engage with trainees for a longer period of time and coach them, it would be especially important to have right people in the room during training – together.

Training “Certification Collectors”

It is not uncommon to see individuals that come to training with the main goal to add another trendy certification to their collection.  This is mainly fueled by job market demands, as hiring companies create job requisitions and look for a “soup of certifications”, sometimes, asking for most awkward and, sometimes, conflicting combinations.  For example: “A candidate must have CSM, PMP, PMI-ACP, SAFe, PRINCE2, etc”.  Most of such jobs are usually poorly described and contain erroneous statements about actual role expectations.

This situation has been observed much more frequently in public training courses, where individuals pay their own money to attend.  Less so, this has been observed with internal training, where students do not pay their own money to attend (nor do they get certified). As such, their eagerness to maximize ROI from attending aa class is much lower.

Also, as a side-effect of this unfortunate pattern, blind pursuit of certifications by non-practitioners who don’t have any intentions to put their learning to practical use,  also dilutes meaningfulness of certifications in the market and adds even more confusion to hiring companies.

Influence of Past Quasi-Agile Experience or Misguidance

Some individuals come to training after prior “agile theater” experience.  Please note that in this post, the emphasis is made on specific cases, when prior agile exposure was of low quality and had created confusion or conflict with new learning.

Bad agile experience may come in various forms.  For example, poor agile implementation “on the job”-  often due to a complete lack of training and misguidance by management.  Another example would be previous low-quality/misleading agile training that was delivered by unqualified guides.  The adverse effects of these types of wobbly foundations are observed equally frequently with public and private training.

It is worth mentioning some well-known sources of unqualified guidance:

  • Vendor companies that lack internal agile expertise or track record of teaching.  Historically, such companies have done mostly staffing/recruiting or management consulting of some sort and just recently decided to step into ‘agile arena’ in pursuit of additional revenue (pretty common these days).  Such companies “get lucky” when their is long-standing clients pull their names off a preferred vendor list and ask to fulfill agile staffing needs.  Usually, hiring companies that use this approach get exactly what they paid for :).
  • Internal employees that have been promoted/fast-tracked into trainers or coaches to fulfill a growing internal company demand for agile guidance.  Such individuals, most of whom do not have any prior field experience as coaches or trainers, are too restrained to existing organizational norms and standards: they are not reformists and challengers by mindset; they are conformists and executioners. Thus, in classroom settings, they present “by the book”, at rudimentary level and steer their followers towards “…this is how things are done around here…lets conform our Scrum to constraints of our organizational design and our internal best practices…”.  Such agile guides are not very effective in handling out-of-the-box situations or addressing serious inquiries that require deep understanding of organizational design and system dynamics.

Internal agile trainers that have been more successful in their work than their peers, usually position themselves in a way that they have, first and foremost, ensured their own security and operational safety that is required to drive organizational changes from within. Secondly, such individuals also have a very strong connection with external professional circles of trainers and coaches, though which they explore horizons of their learning beyond boundaries of a single organization and continuously hone their craft as trainers and coaches.

Lack of Pre-Training (Self-Study)

Almost any trainer will appreciate having in her class well-informed students (a.k.a. “educated consumers”) that have done recommended preparatory self-study before attending training.  Self-study helps normalizing basic understanding of concepts and level-setting students’ expectations from in-class learning.  It also, potentially, reduces the amount of basic, rudimentary questions that unprepared students often ask in class: about terminology, conventional abbreviations, jargon, etc.  By spending less time on explaining basic book definitions, an instructor can spend more time on collaborative activities, role-playing, discussing real-life simulations and doing practical exercises.  This case of low preparedness is more frequently seen with internal training, where a company sponsors an event (even, when an external trainer is hired from outside, employees don’t pay from pocket) or training is totally free (done by an internal trainer).  Just like in the situation described above, students’ desire to maximize ROI is lower than in public training, where people invest their own time and money to attend.

Attempts to Change Training Content to “Conform to Reality”
  • “Is it possible to shorten our training from 2 days to a few hours?”
  • “Can we conduct training just for IT people, since it is hard to justify to our business partners why they need to be away from their desks for a few days?”
  • “Can we conduct training just for business people, since our IT people are already well-trained in agile, “doing stand-ups” and using Jira/Rally to track time spent 🙂 on tasks and they see no value in going through another training, alongside with business?”
  • “Can we review training materials upfront, to make sure that we don’t waste any time on topics that are not relevant to us and ensure that we conform to our existing organizational reality (philosophy, norms, rules)?”

These types of requests are almost unique for internal training arrangements.  Frequently, they come from first- and mid-level managers that get their marching orders to “do agile” (a.k.a. “support-in-spirit”) from senior leadership, and while orders are given, the empowerment to make sure that things are done properly– is not there.  Such corner-cutting and artificial scope reduction has its own reasons. Here are some of them:

Sometimes, agile training is perceived by both: attendees and their managers – as an easy way of meeting personal objectives in order to receive good performance appraisals (when students are asked in class why they are there, they frequently respond that “…it is in our personal development plan and our management wants us to do it, because everyone else is doing it…”.  [Author’s irony: “if everyone was jumping off the roof would you do the same?”].  There is no clear understanding, purpose, vision or goal.  There is no clear strategy on how to put new learning to work, after attending classroom training.

There are other times, when attempts to change training content are caused by a desire to circumvent or avoid sensitive topics that could be perceived by some as politically-incorrect implications of organizational dysfunction.  For example, topics about harm of performance appraisals and monetary rewards, weaknesses of conventional budgeting, inappropriateness of old methods to procure for agile roles (e.g. product managers, T-shaped developers or agile/technical coaches), ineffectiveness of waterfall requirements in agile product development, shifting control and responsibilities form first-line management to teams, etc.).  In these situations, agile training might be reduced to a discussion of “best practices” (agile tooling, metrics collection, agile status reporting, etc.) or reviewing some sort of an internal agile guide for best practices that usually comes in a form collection of publicly available, commoditized (internet) information.  On the other hand, there are situations, when internal agile training turns into a battle field between people, whose hidden friction and conflicts of interest become more obvious because of agile topics and associated  with them transparency.

Attempts to Steer Training Content towards “Unique Situations”

Somewhere like the above, this case of uniqueness is more frequently seen with public training, where people come from different companies and pay for training out of their own pocket.  While their intentions to get “more bang for buck” are good and well understood, sometimes, methods are not.  There are instances, when students attempt to steer discussions towards their unique situations at work, by frequently interjecting with inappropriate comments or asking an instructor to reflect, in real-time, on their personal work experiences.  If this happens too frequently, it becomes disruptive for other students and reduces effectiveness of basic learning for everyone.  It becomes a trainer’s responsibility to ensure that special cases and real life scenarios are reviewed at appropriate times, preferably, with participation of other students, in team break-out sessions (could be also facilitated by a trainer).  Such cases of uniqueness are not as frequently observed with internal training because there is much less variance in situations within the same company.

Requests for Exemption from Training by “Special” People

There is a fundamental difference between support- in-spirit (a.k.a lip service) and true, genuine hands-on involvement and support-by-action (a.k.a. gemba).  Unsurprisingly, there is a shared belief among organizational coaches that: “…a coach can take an organization in its agile journey only as far as an organizational leader is willing to go…”.  It is imperative that senior leadership that is behind agile transformation is well informed and educated.  While content of agile education for senior leadership (executive training and coaching) may differ from content taught to feature teams, ScrumMasters and Product Owners, it must be delivered as the earliest phase of transformation, to prepare seniors for inevitable organizational changes: structurally, culturally, processes -, norms – and values-wise.

Unfortunately, there are many cases when senior leaders excuse themselves from agile education.  They delegate this critical activity to more junior people beneath.  Soon, this leads to misalignment and disconnection between teams that are trying to implement agile changes and senior leadership that is trying  to effectively support the effort, but cannot – due to lack of understanding of systemic and organizational implications.

It is a rarity to see senior leadership attending public training – they just find it too difficult to allocate time for this external activity.  With internal training, things are somewhere better, but not by much.  On occasions, senior leaders will attend initial part of agile training, and try to motivate their subordinates by personal example.  While it is somewhere useful to create initial momentum, it is not sufficient.  As a rule of thumb, having a senior leader sit though an entire experience of in-class learning that includes collaboration, system modeling and practical exercises, alongside with a feature team developer or product owner, is extremely rare. As a result of this, leaders leave with superficial knowledge and limited understanding of what their teams will be experiencing on practice.

Lack of Classroom Participation

In public training, it is hard to attribute lack of students’ participation to any specific cause; it is rather situational. Factors may vary from student’s disinterest in a topic (e.g. a person attends only for certification, as described above) to an instructor’s inability to effectively engage with a class, …to anything in-between.

With internal training, however, the situation is slightly different.  Here, in addition to a wide array of factors, suggested above, there is an additional important factor of individual safety.  Existing organizational structures (e.g. reporting lines, chain of command, seniority) may seriously influence in-class environment and dynamics.  Junior folks may feel unsafe and act submissively to others, whose seniority is higher, either by reporting structure or by experience.  It is not uncommon to see first-line managers and team leads attending internal training, alongside with their subordinates and more junior co-workers, and dominating in classroom by trying to set a pace and tone.  What sometimes worsens a situation even further is that, inexperienced internal agile instructors that are also a part of the same organizational structure, are not able (or not willing) to control in-class dynamics to ensure safe and democratic participation by students: they lack their own personal safety and hesitate to put a hard stop to misbehavior of empowered bullies.

Too Much Reliance on Training Materials

This is probably one of the most difficult paradigms that is hard to break: there is often so much reliance on documentation that goes as far as violating the second postulate of Agile Manifesto.  Most commonly, this is seen in internal training, at companies that mostly rely on their internal ambitions and self-confidence to become agile. When it comes to internal communication or information sharing, employees are accustomed to lengthy, “high-density”, corporate-style presentation decks.  They carry this experience into agile training, where now it becomes their expectation of what agile training materials should look like: they look for lengthy pages of instructions and execution plans.

Speaking of training materials, it is relatively easy to distinguish training materials of a professional trainer and materials produced by an internal agile champion, who has little experience in the field.  In the former case, materials are usually light in verbiage, more illustrative, graphical and entertaining; they mainly serve as conversation enabler and a “pacer” for an instructor.    In the latter case, materials are very data-dense, fine-printed and require intensive reading.   Unsurprisingly, when students attempt to follow pages of heavy presentations, they disengage from their classmates and instructor.  This further reduces learning and information retention.  This is also a primary reason why there is so much reliance on slides post-training.  Students mistakenly believe that what has been presented on slides is a prescriptive set of executable instructions.  Upon exiting “deck-driven” training, people end up ‘renting’ decisions that were suggested on slides, instead of deriving and owing their own decisions.  Instead of leaning more towards experimenting, inspecting and adapting, people look for directive guidance and “best practices” from a trainer (whose experience might be also questionable).

A few classic erroneous requests that thrown at internal trainers:

  • “Can we review training materials upfront so we can evaluate relevance of training to how we work today, so we can decide if we should come?”
  • “Can we be excused from training but review training materials instead to get up to speed?”
  • “Can training materials be finalized and standardized across all current and future training for all teams?”
  • “Would it be OK if we joined via audio or video bridge and closely followed training slides, instead of attending in person?”

What some people also don’t realize is that today, the best training/educational information is an absolute commodity and it is freely available on the internet.  Today, a heavy training deck has practically no intrinsic value because it is, most likely, a digest of books and articles created by others with a lot of copy-pasting involved (often, plagiary).  From a standpoint of a professional trainer or coach: if someone is looking for so much reliance on training materials and execution scripts, they may just purchase a really great agile book and read it on their own, instead of coming to class.


Challenges with training (both public and internal) may cause further downstream adverse effects, beyond classroom:

  • For public training, this may potentially lead to bad reputation of a trainer or give undesirable publicity to his/her course value
  • For internal training, especially in situations, where it is followed by longer term coaching (could be also done by the same person that delivered training if he possesses coaching skills), this may lead to inability to effectively assist a team in their agile journey.

2017 Business Agility Conference – NYC

On 23-24th of February, there was the first ever 2017 – Business Agility Conference, held in NYC.  The event could be best described as “…2 days of authentic short stories and facilitated deep dives on business agility; focus on organizational design, market disruption and product innovation, agile outside IT and next-generation leadership…” (quoted from

The uniqueness of this event was due its demographics, and in particular: due to the breakdown of attendees – based on their organizational roles.  Although agile conferences (both, local and global) are never geared towards Technology and Information Systems only, this particular event was specifically geared towards business. As it can be seen from the statistics below, there were a very large number of people that represented Senior and Executive Management (more than 45%).

As always, another large share of attendees was represented by organizational and agile coaches.

It is also interesting to know that there were practically no discussions at the event about Scrum, Kanban, XP, tools, processes or frameworks, at the event.

My personal, experience as one of the facilitators of this event, was enriched by reuniting with some folks, whose work had significant impact on my own work:

With Steve Denning  With Mike Beedle With Bjarte Bogsnes

Note: Special thanks to Mike Beedle for mentioning my name in his Enterprise Scrum Executive Summary. (download pdf report to view)

Highlights from Steve Denning’s Presentation:

According to Steve Denning – the author of Radical Management, 20th Century Teams – were “teams” in name-only.  Team of the 20th century were gears of a classic, bureaucratic organizational machine, characterized by: top-down management, individual responsibilities and little interaction among people.  On contrary, real Agile teams require: autonomy & cross-functional structure, collective accountability and high degree of interaction. Steve focused on the following four main Agile themes:

  • Delighting Customer – there needs to be a fundamental shift in how management perceives relationships between Firm and Customer. This shift is best described by Copernican revolution: no longer Firm remains a centerpiece, with Customer revolving around it. Instead, Customer becomes a centerpiece and Firm revolves around Customer, delivering products, services and ensuring overall satisfaction.  Pre- Copernican Management belief was in making the main purpose of a firm to generate money for its stakeholders and was best described by Jack Welch’s quote: “…The dumbest idea in the world…”  The Post-Copernican Management belief is that, as was described by Peter Ducker in 1954: “…the only valid purpose of a firm is to create a customer…”
  • Descaling Work – in a volatile and complex modern world, where uncertainty and ambiguity prevails, any attempts to resolve big problems simultaneously, with one big-bang approach, are no longer effective. Instead, work must be dis-aggregated in small batches and performed by small, autonomous, cross-functional teams.
  • Enterprise-Wide Agility – to consider Agile as “IT thing only” is a huge mistake.  Attempts to improve organizational agility, with only a few small teams trying to “do agile”, with the rest of the organization remaining top-down, bureaucratic, slow-moving behemoth will result in a failure.  In order for the whole organization to become more agile, it has to embrace the entrepreneurial mindset front-to-back and top-to-bottom.
  • Nurturing Culture – is a huge undertaking that each organization must commit to and flourish from within. This includes leadership strategies, organizational structure, culture, norms, values and principles.   Excluding organizational design and system dynamics from agile transformation efforts by senior leaders is a costly mistake.

Throughout his presentation, Steve Denning highlighted additional important aspects of organizational agility:

  • “How many layers should Organization have?” –  There is no perfect number to give, but the fewer – the better. What matters is that there should be full transparency and direct communication between: Management, Customers/Users and Workers (employees, contractors, suppliers)
  • The Law of Network – “plugging” agile team into a bureaucratic environment may create visibility of local efficiency but over time will lead to unbearable friction between “old” and “new”.
  • There is a lot of “Agile PR” and “fake Agile” – it is usually brought about by IT attempts to embrace agility, with very limited support from business.  Frequent claims from management (sometimes, very senior) that is indicative of their gross misunderstanding of organizational dynamics is:
    • Agile is only for software
    • Agile does not scale
    • Agile cannot handle complexity
    • Agile is not reliable
    • Agile does not last

Steve Denning’s discussion was summarized by the example of Microsoft:  “In 2004, Microsoft was viewed as a huge battleship, slowly moving through waters at relatively low speed, and not being able to turn quickly and cost-efficiently.  In 2015, Microsoft is viewed as a flotilla of speedboats, moving fast but synchronously, and being able to turn “…on a dime for a dime…” (the author’s of this post quotes C. Larman)”

Highlights from Bjarte Bogsnes Presentation:

The chairman of Beyond Budgeting Roundtable (BBRT)  Bjarte Bogsnes, who has a long international career in Finance and HR, with successful implementation of BB at two large European companies, Statoil and Borealis, presented a short synopsis on Adaptive Management Model.

(Note: Being Bjarte’s follower and advocate for years, I recommend for your attention the following personal summary page: for in-depth understanding of Bjarte’s work).

Bjarte made a clear distinction between Management and Leadership.  People obey Managers (usually, mandatory) and follow Leaders (always, voluntarily).  Management is focused on: Rhythms (around events), Targets, Plans and Forecasts, Resource Allocation, Performance Evaluation and Rewards Distribution.  On contrary, Leadership is focused on: Purpose, Values, Transparency, Organization, Autonomy and Customers.  A lot of focus in Bjarte’s discussion was paid to ineffectiveness of fixed (“accordion-like”) budgets that are driven by calendar years, not by business cycles; harm  and dangers of producing and measuring wrong KPIs (often mistakenly considered as “KPTs”, where “T” stands for “truths”); lumping Budgets, Forecasts and Resources Allocation into one single KPI number, and then, coupling such ill-defined KPIs with individual appraisals and monetary rewards/bonuses – the main cause of system gaming and unethical behaviors that many organizations see today.  Bjarte’s presentation was followed by comprehensive collaboration, by many individual teams that used a variety of visualization techniques to illustrate a future state of agile budgeting & finance:

Other Great Highlights:

There were a few other great discussions that took place at the conference.  Here are a few excerpts that are worth including (paraphrased here):

  • From Charlie Rudd: “…Organizational Change Management != Organizational Transformation. Many more people tend to resist to the former; much less so to the ladder…” and   “…In Change Management, processes and system behaviors are predictable.  In Transformations – they are not…”
  • From Paul Cobban: “…Agile Education is not just for doers. It is also for Executive folks…Exempting themselves from continuous education, Executives lose touch with reality” and “…Stop Starting and Start Finishing…(or learn how to manage WIP at enterprise level)”
  • From David Grabel: “…Agile is not just for IT. A great example of Agile adoption success is Marketing…” and “…Adoptive, agile Marketing can drive organizational agility at large…”
  • From Venkateswaran NS: “…Do senior leaders have good vision? Does middle-management have right job descriptions (for themselves and their subordinates)?…”
  • From Pat Reed: “…Business Agility – is bravery to step into the area of unknown…” and “…the phrase ”I will believe it when I see it”…should become “I will see it when I start believing it”
  • From Fabiola Eyholzer: “…HR should stand for Human Relationships not Resources (from the author of this post: there is a common belief that calling humans as ‘resources’ is demotivating and disrespectful)…” and “…most discussions between employees and HR are scripted and lack sincerity and open-mindedness due to the fact that there is always a legal aspect to it and both parties are great of doing CYA…”
  • From Chip Loving and Jason Hall: “…Management by Objectives is wasteful and harmful…” and “…Transparency != Awareness…(from the author of this post: being able to see something and fully comprehend it, is not the same thing)” and “…Quarter-based profit sharing that is peer-based and transparent is much better than end-of-year subjective discretionary bonus decided by people that are mostly remote from action and area, where real business value is produced…”
    • From the author of this post: example of most harmful intensives allocation schema and less harmful intensives allocation schema

Product DetailsFinally, some great new publications were presented at the event.  I came to discover that my colleague and friend, agile coach Dana Pylayeva has published her new book “Introduction to DevOps with Chocolate, LEGO and Scrum Game”.  It goes on my To-Do list to read.

11/30-12/2 – Certified Agile Leadership (CAL) Class in Orlando


This was an amazing two and a half-day working session, with participation of organizational leaders and enterprise coaches coming together from different parts of the world: Sweden, Costa Rica and USA.

One of the co-creators of Certified Agile Leadership (CAL) course – Pete Behrens took the mixed group, consisting of managers and coaches through a very engaging training experience. CAL curriculum was geared towards improving theoretical expertise and practical skills of people that operate in various agile leadership capacities.  Presence of both, managers and coaches in the same room throughout the entire training, ensured that many real-life scenarios  were simulated and explored in-depth.

There were a few Enterprise Coaches in the room who assisted the instructor with facilitating the course: Rick Regueira,  David Barnholdt and me (Gene Gendel).

Note: It is worth noting that with exception of a short Case Study presentation, where the use of .ppt slides was inevitable, the entire course was based on very direct interaction, facilitation and the use of very effective graphic visualization techniques (see below).

Stage Setting: Learning Objectives

CAL’s learning objectives included the following (top themes):

  • Governance policies that enhance organizational agility
  • Organizational Structures that support agility
  • Factors that influence organizational culture
  • Alignment of leadership development framework with agile
  • Alignment of organizational metrics with agile behaviors
  • Management trends and their historical fit with business
  • Economic/market factors that lead to rise of agile approaches
  • Relationship of complexity/uncertainty to agile approaches
  • Organizational challenges with understanding agile
  • Benefits of becoming Agile Leader
  • and more…


Case Study Review

The goal of this session was to deconstruct two types of case studies presented, to better understand how two different companies try to be more agile, respectively. The two companies presented were: Consulting Company (name obfuscated), with its “Create” culture and SalesForce with its “Compete” culture.

Both companies were analyzed along the following three dimensions:

  • Organizational Structure
  • Organizational Policies
  • Organizational Metrics


It was interesting to see how agile works differently in the environments of Creation vs. Competition.

Types of Organizational Culture

Deconstruction of the use cases (above), was followed by a conceptual discussion of “Agile Culture Compass”, where the following four types of Organizational Culture were plotted on the dial:

  • Collaborate Culture
  • Create Culture
  • Control Culture
  • Compete Culture

Then, some additional additional dimensions, were added to the ‘dial’, as illustrated below:orlando_cal-10

Exercise: Graphic Visualization

In the practical exercise that followed, the class was tasked with graphic visualization of the four types of Organizational Culture (click on the thumbnails below to enlarge):

orlando_cal-4 orlando_cal-3
orlando_cal-2 orlando_cal-5

Exercise: “In or Out” Canvas

In the next session, the class was presented with the four “poles” of Agile Culture Compass (four different culture types) and a variety of attributes, that were ad-hoc mapped to the cultures. Attributes used were: values, principles, norms, companies’ names, organizational goals/vision, etc. The class was tasked with properly re-mapping the attributes to the most suitable cultures: some attributes remained “In'”, some had to be moved “Out”.

What is shown below is the final state: after all available attributes were properly mapped to the respective culture  (click on  the thumbnails below to enlarge).

orlando_cal-6 orlando_cal-9
orlando_cal-7 orlando_cal-8

Types of Leadership

orlando_cal-1In this discussion the group took a deep dive into leadership types.  The following three types of leaders were identified:

  • Expert Leader – a person who gets things “done” by actually doing work.  Such leader thinks of himself as a “jack of all trades”, a hero, a super-performer, commander-controller, who wants to be a primary channel of information flow, in all directions. Such person wants to control all communications in 1-on-1 relationships, with his personal presence.

  • Achiever Leader –a person who gets things “done” by delegating work to others, while retaining tight control of everything that takes place.  Such leader, while he micro-manages others, is very competitive and strives to outperform his peers but he knows how to do so by manipulating his subordinates, to do work for him, “his way”. A leader like this, usually has a good grasp of organizational strategy and is focused on others, pushing them to the their performance.  His main message to subordinates is “are you with me or not?”.

  • Catalyst Leader – a person who gets things “done” by empowering others and stepping back.  Such leader prefers de-centralized decision making matrix over centralized control, and creates an environment of safety and trust.  In his vocabulary, the word “we” supersedes the word “I”.  He acts as a coach-enabler and views other people as valuable assets, not as mechanical executioners.  A leader like this has a great vision and is focused on high-level goals.


(click on the thumbnails below to enlarge):

orlando_cal-14 orlando_cal-39 orlando_cal-38

Discovering more System Variables

In this exercise, the group explored additional factors (system variables) that influence organizational agility.  This was done in the form of graphics (click on the thumbnails below to enlarge):

orlando_cal-15 orlando_cal-16 orlando_cal-18

 Reconstructing It back:

This was one of the key “aha” moments in the workshop.  After identifying and thoroughly discussing the three types of leadership (Expert, Achiever and Catalyst) the following important discovery was made:

  • Both, Experts and Achievers mostly operate under conditions of Duality: black OR white/right OR wrong
  • Catalysts, for the most part, operate under conditions of Multiplicity: shades of gray, options (AND). They are also much more collaborative


 Exercise: More System Variables

In this exercise, more factors (system variables) were discovered and related to organizational agility:

  • Economics
  • Complexity vs. Uncertainty
  • Management Trends



 Organizational Challenges: Statistics

In this session, every manager and organizational coach was asked to share some of the most common organizational challenges with agile adoption that they have experienced at work or while serving their clients.

Then, the group reviewed and further discussed industry research statistics on organizational challenges (below):orlando_cal-22

Exercise: What Leaders Need to Understand

In this exercise the class was divided in a few groups, with each group working on graphic representation of the following three areas, where organizational leadership must have expertise, in order to succeed with agile:

  • Organizational Structure
  • Organizational Policies
  • Organizational Metrics

Then, the class discussed why so many organizational attempts to become more agile fail.  Success rates of agile efforts coming from inside vs. outside were discussed (click on thumbnails the below to enlarge):

orlando_cal-23 orlando_cal-28 orlando_cal-29 orlando_cal-30

Change vs. Transition & What’s In-Between?


The group made a very interesting distinction between two frequently overloaded terms: Change vs. Transition.

  • Change = EVENT –  was defined as a more abrupt, binary process that could be metaphorically described as“Lets Go”, coming from very strong and passionate leaders
  • Transition = JOURNEY was defined as a more gradual process, where things happen much slower


The group also identified a number of reasons why organizational changes often fail and how improving values of organizational leaders could bring  more sustainable changes.


 What Should Leaders Focus On?

The class discussed the most important areas of focus for organizational leaders who want to implement agile changes and organizational coaches who want to be successful in assisting their clients in agile transformation journeys. Two main focus areas were identified:


 Exercise: Causal Loop Diagram (CLD) to explore System Dynamics


Causal Loop Diagrams (CLD) the graphic visualization tool that is widely used in Large Scaled Scrum (LeSS) to illustrate system dynamics, was used in this practical exercise (facilitated by me) to discuss the relationship between high levels of  employee engagement and its downstream benefits to an organization.  The use of this light visualization “tool” sparked a lot of interest in class and was used in the following exercise to discover organizational impediments, bottlenecks & friction (see below).

Exercise: Organizational Impediments, Bottlenecks & Friction

This practical session revealed a number of already known system variables, whose relationship and cross-dependencies, however, were not immediately clear. By using CLDs, many of such relationships were discovered. Also, in the course of the discussion, people came to agree that bottlenecks (“soft” obstacles) and impediments (“hard” obstacles) are best not to be split as separate groups, as they, effectively, mean the same thing. A more effective way of distinguishing between “soft” and “hard” obstacles, could be – by ranking them (click on the thumbnails below to enlarge):

orlando_cal-42 orlando_cal-43 orlando_cal-44

Agile Leadership Benefits

By the end of the workshop, the class came up with the list of benefits of agile leadership style. They were also graphically illustrated by using a flavor of CLD approach:


Workshop Feedback (Incremental)

Throughout the workshop, feedback was provided incrementally, and the format used, closely resembled a sprint retrospective.   Questions, suggestions and comments were addressed continuously, in the order of arrival.



This training workshop was a great mind-shaping exercise for everyone.  The sequence and style of content delivery tremendously helped with information absorption and its retention.  Small group break-outs and role-playing helped experimenting with new coaching and facilitation techniques.  For everyone in the room, it was a great opportunity to share every-day challenges and “domestic problems” but in a very safe and uninhibited way.

For me personally, as an organizational coach, this course helped tremendously to systematize my existing knowledge as well as grasp additional concepts that I will be putting to use in a near future.

This course is strongly recommended for managers, senior organizational leaders and organizational coaches that want to learn system dynamics and better understand implications of organizational design and culture on overall system agility.