Bad Smells: Appraisals and Performance Reviews Influenced by Agile Coaches

Agile/Scrum coaches should not position themselves in ways that will give them an authoritative/commanding role within an organization, where they coach. If this happens, organizations/people that are being coached will not gain long-lasting learning.  The result of such engagement, will be have a ‘quick fix’ at most, but it will not be sustainable.  Coaches will be perceived, as “Command and Control” figures, and this will lower their chances of helping an organization to develop, its own, autonomous, independent, self-sustainable Agile practices and Kaizen culture.

If the above is ignored, organizations may expect, at most, short-term improvements that are based on directives, commands and “best practices” (of course, there is no such thing as every practice is conditional), given by coaches.

In his book The Culture Game, Daniel Mezick well describes the do’s and don’ts of an agile coach (Chapter 17). This
philosophy neatly applies to agile coaches that operate as consultants.

How about coaches who are not consultants?

A situation is even more challenging for Agile coaches that are employees of an organization they coach for.  Here, coaches may get drafted into activities that are considered as an organizational norm but conflicting with a required coaching stance.

Here is an example of one such a challenge:

Being requested (usually, by line management) to do a performance appraisal on an individual being coached, or provide feedback that would be treated as an input to performance appraisal process of a coachee is a breach of a coach-coachee informal agreement of mutual trust. (This is not to be confused with constructive one-on-one feedback that coaches  give to their coachees continuously, as part of daily coaching, training, mentoring and counseling support).

Drafting a coach into a process, formally or informally, where he/she may impact  employees’ compensation and career development is a bad decision.  This will create a serious conflict of interest for a coach and will adversely impact his/her relationship with a coachee (trust, openness), and therefore, ability to positively influence professional growth of a coachee.

Impartiality and neutrality of a coach is highly important. Only by remaining neutral and non-authoritative, will a coach be able
to help an organization and its employees to self-discover, improve, and become autonomous in their journey to success.

Just like external coaches-consultants, internal coaches should stay away from activities that are considered as anti-coaching patterns.

Unspoken Agile Topics

black_green_black_thin_2Author: Gene Gendel

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.

The reader will most likely focus on the section that best represents his primary interests and concerns. However, it is recommended that both sections are read in full, as in unison they create a better holistic perspective of the industry changes brought about by Agile-mania.

The reader will be taken out of his comfort zone and forced to think more uninhibitedly and realistically about those aspects of Agile that may not be as obvious and are not explicitly covered in other literature…

– See more at:

Non-IT Kanban Implementation at Scale

A few days ago, I went to the happy hour of a local staffing firm that specializes in placing Agile technical and leading resources. They had moved into their new office and were treating. (I’ve known these guys for many years and was not looking for a job.) As I was walking around the office, what caught my eye were a few huge whiteboards attached to the walls. One of the boards was in the recruiting area, another one in the account-opening area. I moved closer to see what was on them. Both boards had multiple columns and rows. I focused on the column headers of one of the boards. Most of the columns looked like sequential steps of one long process: resume submission of a job seeker to a client company.
I took a closer look at the other board and, after a few minutes of interpreting its column headers, realized that the board represented the steps in the account-opening process. The boards did not seem to be related and they seemed to be maintained by different teams—one by recruiting, another one by account opening. I looked around for a few more minutes and then asked the regional director to validate my observations and assumptions.
This is what I found out:
Without naming it explicitly, the teams have been using Kanban boards to manage their daily work flows—recruiting did their thing, accounts did theirs. I also learned that each team gets in front of its respective board every morning and discusses things in ways that are similar (not the same) to what Scrum teams do in daily stand-up meetings.
The boards were not connected. The swim lanes did not represent SLAs or levels of escalation. The lanes were not dependent. The swim lanes represented different business tracks that did not even require escalation—they were sort of independent.
And so they seemed. But then we discussed it in more depth and realized that since they are consuming the same team resources, there is a relationship. There were no WIP limits on the columns. So it became apparent that the teams were not actively managing the queues. However, they were visualizing them well. Then we discussed further whether the two boards were as independent as they seemed.
And this is what we discovered:
Tickets that were moving across the accounts board represented client-companies that went through various states of the account-opening process. But then, on the recruiting board, each client company represented an individual swim lane—a major work track that was further subdivided into more granular tracks, each representing a requisition number. What moved across the recruiting board were tickets that represented names of individual candidates.
So the boards were not independent: Each ticket that came to the last queue of the accounts board automatically became a major track (could be empty initially) of the recruiting board.  Then, if a requisition number came along, it would become a mini-track.
We were dealing with a non-IT enterprise (mini)-level Kanban implementation that still needed some fine-tuning and polishing
up: converging one Kanban board into another, establishing WIP limits on each queue (column) of each Kanban board, introducing buffer queues (e.g., “something”-Ready). The setup also required some additional thinking about whether there were any other intra-company processes that needed to be visualized and aligned with the known ones.
I hinted to the regional manager that by “Kanbanizing” their overall enterprise business, and perhaps adding a few burn-up charts that represented how accounts got opened or candidates got placed over time (assuming a time line of, let’s say, 2014), they could really “agilize” the process of placing Agile technologists. They would demonstrate to their clients that they know the business they recruit for, and clients might just like it.
I also left excited, knowing that I have a nice non-IT Agile story to tell—something that would once again support the notion that enterprise-level applicability of certain Agile processes has a place in real life.

Be an Educated Consumer


Author: Gene Gendel

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).

Why is this happening? Because you lack expertise as a consumer. Because you don’t know the market you are in. Because you don’t know how to look for the warning signs of an agreement gone bad. You are not equipped with knowledge. You are not an educated consumer….

Motivation 3.0 Is Required to Transition from Tribe Stage 3 to Tribe Stage 4


Author: Gene Gendel

In his book Drive, Daniel Pink says that when it comes to motivation, there’s a gap between what science knows and what business does. Our current business operating system is built around external, carrot-and-stick motivators — which don’t work and often do more harm than good. We need a system upgrade. And the science shows the way.

This new approach has three essential elements:

  1. Autonomy: The desire to direct our own lives
  2. Mastery: The urge to make progress and get better at something that matters
  3. Purpose: The yearning to do what we do in the service of something larger than ourselves

According to Pink, humans evolve through three distinct stages of the Human Operating System:

  1. Motivation 1.0 presumes that humans are biological creatures, struggling to meet basic needs for food, security, and sex. This system is mainly good for survival struggles.
  2. Motivation 2.0 rests on Theory X of Human Motivation, when management assumes that employees are lazy, tend to avoid work, and best respond to rewards and punishments in their environment.
  3. Motivation 3.0 rests on Theory Y of Human Motivation, when management begins to understand that when it comes to intellectual work, employees are ambitious and self-motivated and will exercise self-control. This system presumes that humans seek purpose maximization no less than profit maximization…

– See more at:

Scrum and Kanban at the Enterprise and Team Levels


Author: Gene Gendel

Scrum, as the most structured of all Agile frameworks, is a great way to ensure predictable, strategically planned, incremental product delivery. Scrum ensures good responsiveness to frequently changing market demands. Although nonprescriptive, Scrum clearly defines certain roles, responsibilities, and ceremonies.

Kanban, for the most part, is silent about certain aspects that Scrum suggests explicitly (e.g., team size, velocity, story point estimation, timeboxing, Scrum ceremonies, etc.). Kanban is less structured than Scrum. Being a true pull-based system, Kanban is a great work-flow visualization tool that can be effectively used for WIP management. It is a great tool to use in production support or the gradual redesign of legacy systems; business priority-driven new product development is not the main goal….

Handling Interruptions in Scrum: 4 Options (Part 2)

black_green_black_thin_2Author: Gene Gendel

There are four commonly known ways that teams use to handle production support, or other “interrupt” items. Frequently, these items are classified by “levels” of priority/criticality, with L1 being the lowest and L3 being the highest priority. As we continue from Part 1 of this two-part article, we look at the remaining two ways of interrupting Scrum sprints–and share what can be done about them.

Read more at:–4-Options–Part-2-

Handling Interruptions in Scrum: 4 Options (Part 1)

black_green_black_thin_2Author: Gene Gendel

In an ideal world, a cross-functional Scrum team must be fully focused on Scrum. The team is also expected to hear a voice of one customer only: the product owner. But what happens when reality intervenes and you get pulled in other directions?

In this two-part article I will:

  • Highlight common interrupt challenges I’ve encountered for organizations new to Scrum in general, and large organizations in particular
  • Outline four common interrupt scenarios and explain what you can do to handle these interrupts and maximize your productivity.

I’ll use the example of my old-time friend “Joe,” a senior software engineer who served as ScrumMaster on one of the Scrum teams….

Read more at–4-Options–Part-1-

Epic-Level Estimation

Author: Gene Gendel

Imagine: You are about to form a new feature team that is composed of bright, cross-functional experts, self-motivated and self-managed. They all worked in Scrum settings before and are fully supportive of Agile principles. The organization they work for is properly structured and it nicely supports the adoption of Agile/Kaizen culture.

Imagine that the team interfaces with an experienced PO who comes from an end-user community, has a lot of client-facing product management experience, fully understands principles of Agile product development, does not tolerate waste, appreciates benefits of incremental value delivery, is fully empowered, and knows how to effectively partner up with technology. . . .