January 2016 CLP/CLE LeSS Newsletter


Author: Bas Vodde

Since last newsletter, several case studies have been published:

Some LeSS related videos you might be interested in:

And then some LeSS related articles:

B-17E Bomber – Tight coupling of Color Coding with Numerical Data

Note: This post has been created to aid you in reading another post about RAGs, the initial paragraph of which can be found here: http://www.projectmanagement.com/articles/315648/The-Fallacy-of-Red–Amber–Green-Reporting

(also, cross-posted here: http://www.keystepstosuccess.com/2016/01/fallacies-of-rag-reports/)

“Our fuel is low.  Are we going to make it?”

Lt.  Mitchell, the pilot of Boeing B-17E, kept pulling hard on the stick, taking his Flying Fortress with its 8-men crew, into a climb, at the angle that was much steeper than what was recommended, even for a bomber with “empty belly”.  The aircraft lost a lot of fuel while doing a round circle to the target, while fighting winds and severe turbulence.  Although the weather conditions on the way back home were much milder, the fuel tanks, peered with bullet holes, were leaking and it was bitterly ironic for Lt. Mitchell that after successfully completing the mission, without losing a single crewmen, he would have to crash-land his plane into the Pacific Ocean, such short distance from a home base.  The pilot’s decision was to use the remaining fuel to climb as high as possible and then take his chances of losing fuel at high altitude, by gliding towards the mainland.

  • “How are we doing on fuel?” – screamed Lt. Mitchell to his navigator Lt. Johnson.
  • “We are about two notches from red” – the navigator replied.

Once receiving the answer from his navigator Lt. Johnson, the pilot immediately knew that he had only about 440 liters of fuel left (of the overall internal fuel capacity of B-17E).  The pilot made this determination based on two basic facts: he knew what each ‘notch’ meant on his fuel dial, in terms of liters, and he knew that ‘red’ represented a specific zone on fuel dial, when an aircraft was in high danger of crashing, based on real life statistics and engineering calculations.  In fact, for an experienced pilot like Mitchell, the exact “liters remaining” or “about two notches from red” were equally informative statements – they both helped him visualize how many more miles his plane could stay in air with the engines running. The pilot knew well his plane’s instruments panel and could quickly visualize the arrow of a fuel gadget, respectively to “0”, with or without color coding.  But even a very experienced pilot would need to know an average liter per kilometer rate of fuel consumption, in order to derive how long he can keep his plane in the air.

During WWII, when sophisticated simulation equipment was not available, it would be up to a skilled crew (pilot, navigator) to manually calculate their chances of safe landing: calculations were done based on raw numbers available on a navigation panel and on flying conditions.  Back then, it was always up to a human to determine “when does amber become red?” and how weather conditions factor in.  Truth to be told: depending on wind direction (headwind vs. tailwind, turbulence, plane weight), the actual point of crossing from amber going into red, could shift against or in favor of the odds of a crew to flight to safety.


The arrows above should read as follows:

  • Arrow point to Left: “Headwind”
  • Arrow pointing to Right: “Tailwind”

Note:  Numerical values above are selected arbitrarily, for explanatory purposes only, and do not reflect technical specifications of B-17E

While, modern simulation tools can do this automatically, by factoring in multiple influencing factors, back in the 40’s it was up to skilled crewmen to manually calculate their odds. And it had to be done super-fast.

Continue reading:  http://www.projectmanagement.com/articles/315648/The-Fallacy-of-Red–Amber–Green-Reporting

Agile Coaching – Lessons from the Trenches

black_green_black_thin_2Authors: Gene Gendel and Erin Perry

High performing organizations, high performing teams, and high performing people do not often happen organically. They are a return on investment.

We’ve spent time in the trenches, both giving and receiving coaching, at organisations of all sizes: from small startups to large enterprises. In this article, we will use our hard fought experience to shed light onto Agile Coaching. First, we will take a step back, helping define what being an Agile Coach means and what skills are necessary to be successful in an organization. Then, we’ll examine patterns and anti-patterns for both in-house coaches and coach-consultants. We will shine light on how to enable coaches to be successful in your organization…

Read the rest of this post: http://www.infoq.com/articles/agile-coaching-lessons

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: https://www.scrumalliance.org/community/articles/2014/july/unspoken-agile-topics#sthash.OczxUhvv.dpuf

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: https://www.scrumalliance.org/community/articles/2014/july/motivation-3-0-is-required-to-transition-from-trib#sthash.sQjXb3CU.dpuf

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