Managing Performance by Extrinsic “Motivation”

“The idea of a merit rating is alluring. The sound of the words captivates the imagination: pay for what you get; get what you pay for; motivate people to do their best, for their own good. The effect is exactly the opposite of what the words promise.”

-Edward Deming, “Out of Crisis”

This article took me almost 10 years to write… This has been a long journey for me.  As an organizational and agile coach, I base views not merely on feelings and emotions but rather on hard scientific evidence, research, review of literature, analysis of work from other credible resources that I have been collecting over years. And of course, continuous assessment of my personal experience.

So, I wanted to start this discussion with Wikipedia definition of Performance Appraisal:

A performance appraisal (PA), also referred to as a performance review, performance evaluation,[1] (career) development discussion,[2] or employee appraisal[3] is a method by which the job performance of an employee is documented and evaluated. Performance appraisals are a part of career development and consist of regular reviews of employee performance within organizations.”

Interestingly enough, while all three terms are being included in the same definition (“review”, “evaluation”, “appraisal”), in practice, companies predominantly use the term “review” to describe PA, as it implies less scrutiny and preconception towards an employee. But does this change the essence of the process if less abrasive terminology is being used?

 A typical PA process includes setting individual career goals, by an employee that should, presumably, be her own goals but nevertheless must be in-line with organizational/department career goals that usually sent by senior management and then cascades down to line management.  It is expected that throughout a year, an employee has to steer herself towards pre-set goals, while performing her day-to-day job responsibilities.

Every company that supports PA process has a scoring system (variations exist) to rank employees, against other employees, based on score that an employee earns, while performing her yearly accomplishments (goals set vs. goals achieved). Some organizations offer a mid-year (quarterly, at best) check-point to an employee when, along with her line manager, she reviews how she performs with respect to the goals, she set originally.  Practically, no companies handle PA as an actively managed, iterative agile process: there is typically one mid-year check point and end-of-year final decision.

For most companies the whole PA process, typically serves the following three main purposes:
1. To identify low-performing employees that are potentially a subject to downsizing (or kept where they are)
2. To identify high-performing employees that are potentially a subject to promotions and compensation increases
3. To decide how discretionary incentives (bonuses) should be distributed among employees

While on its surface PAs still appears as an effective way to ensure quality of employees and to provide benefits to an organization, under the surface this process presents real challenges. These challenges become more apparent at organizations that attempt to adopt more agile culture, since in agile environments system organizational dysfunctions get exposed much better.

But before we dive deeper in the discussion, let us first briefly refer to some credible research and studies that exists today:

In his book “Out of the Crisis”, originally published in 1982, Edward Deming discusses Seven Deadly Diseases of Management and refers to individual performance reviews and performance evaluation as Disease # 3. Deming’s philosophy of transformational management is about seriousness of barriers that management faces today, while improving effectiveness and striving for continual improvement. Deming argues that by trying to evaluate and measure workers with the same yard stick, managers cause more harm than good to individuals and to companies.

Tom Coens and Mary Jenkins offer specific suggestions on how to replace performance appraisals with a more effective system that emphasizes teamwork and empowerment in their book “Abolishing Performance Appraisals: Why They Backfire and What to Do Instead.” Coen and Jenkins discuss new alternatives that produce better results for both managers and employees.

In his Forbes article “Eliminating Performance Appraisals”, Edward E. Lawler III, a distinguished professor of Business at the University of Southern California, advocates why organizations stop doing performance appraisals. Professor Lawler states that performance appraisals frequently do more damage than good, with damage levels fluctuating between wasted time (least troublesome) to reasons for alienation of employees and creating conflicts with their supervisors (most troublesome).

Garold Markle, an author, executive consultant and speaker, leverages his studies and experience with systems theory to illustrate his points with real-life examples of why employees and managers both have come to believe the “ubiquitous performance evaluation as industry’s poorest performing, most ineffective, and least efficient personnel practice”. In his book “Catalytic Coaching: The End of the Performance Review”. Markle provides an innovative way to measure ineffectiveness and inefficiency of performance evaluations and then introduces his catalytic coaching to replace them. His statement is awakening: “People hate performance reviews”.

In his book “Drive”, Daniel Pink offers a paradigm-shattering view on what truly motivates people in their lives. Pink draws on four decades of scientific research on human motivation, to expose a mismatch “between what science knows and what business does”. Pink challenges the mistaken belief of many that people doing intellectual work, will demonstrate higher performance, when incentivized monetarily. Based on Pink’s research, it becomes clear that individual performance evaluations and individual appraisals that are linked to monetary rewards, are not an effective way to steer individuals to become more efficient and productive. Therefore, they should be abolished.

Finally, in his book “Implementing beyond Budgeting: Unlocking the Performance Potential“, Bjarte Bognes, who has a long career with HR and Budgeting departments, unveils ineffectiveness of conventional budgeting processes that so many companies still follow today.  Bjarte, describes common fallacies associated with “accordion” or “against the wall” budgeting that is done under assumption that “…the world will end on December 31st…”.   By offering many real life examples and cases studies of the companies that have instituted alternative budgeting approaches, Bjarte forces his readers to fundamentally shift their mindset, away from some outlived “de facto” concepts.  For example, one of Bjarte’s recommendations is to decouple what has been mistakenly lumped together for years: Targets, Forecasts and Resources, and treat each one as an independent system variable.  The connection is astonishing.

On many occasions, in his book, Bjarte, connects the dots between conventional Budgeting process and conventional Performance Management process – both of which harmfully feeding off of one another.

And the list goes on….

So, now lets take a closer look at the problem on-hand, with some specific examples:


Fabricating Goals to Game the System

Are goals that employees officially set for themselves (in a system of record) truly reflecting their genuine, personal goals?

It is not uncommon that real personal goals are risky and challenging to achieve or may take longer than initially expected. Some other goals may be situational/opportunistic: they may change as a situation changes or unforeseen opportunity presents itself (job market trends, other job opportunities, personal life).  People want to have freedom and flexibility to adjust their goals to optimize their personal benefits and this is a human nature.  There is no real personal benefit to an individual to “set in stone” her personal development goals at year-start and then be locked to them at year-end, as if not meeting those goals equates to penalty.  In general, in order to set her real goals, a person needs to know that it is safe to actively manage them along the way and, if needed, safely change and/or fail them, without fearing negative consequences.

But is there any safety with PA processes if job security, career advancement ability and ability to collect fair compensation are at risk? If there is no personal safety, the exercise of setting personal goals becomes nothing but a routine of faking objectives that are “definitively achievable”. People are forced into system-gaming, to minimize the risk of being penalized by their management, if goals are not met. Setting individual goals becomes just a formality that brings no true value to an employee.

The process of individual performance reviews becomes even less meaningful if people work in small teams, where swarming (working together on the same task) and collective ownership is important, while joint delivery is expected. In cases such as these, people are forced into unhealthy competition with each other over goals, trying to privatize what should be owned and worked on collectively.
Another challenge with evaluating employees’ individual career goals is that in pursuit of personal goals, people frequently “drop the ball”  and pay less to attention common goals. Again, this dysfunction becomes much more vivid in “going-agile” environments, where agile frameworks (e.g. Scrum, Kanban, LeSS) de-emphasize individual ownership and reinforce importance of collective ownership. Often, close to mid-year and end-year performance reviews, collaboration and mutual support of team members worsens, as silos get created and everyone starts to think about their own goals, at expense of shared goals. This translates into productivity drop: swarming, velocity and throughput go down; cycle time goes up, queues grow and handovers take longer.

SO, lets take a look a few hypothetical examples that are based on real life scenarios:

Example 1:

Jane is an employee of a large insurance company.  She is being requested to enter in a company’s system of record her personal goals – things that she intends to achieve throughout a year.   Jane is smart and in order to avoid any unwarranted risk, where her personal success depends on success of others, she creates goals that are free of dependencies.  Jane creates a set of personal goals that other group members do not know and don’t care about.  Her line manager John, also discourages Jane from sharing such information. 

However, Jane does not work alone.  Her day-to-day work is tightly coupled to work of other people in her group: Jim, Jeff, Jill, Joe and Julie.

Jane really values team work. She also feels that by closely working with her group members, by swarming and sharing day-to-day activities, she can earn a lot more than if she worked by herself.   This is where Jane decides to put her full focus: on team work. She does not feel that creating an additional set of personal goals can add real value to her professional growth.  But Jane needs to “feed the beast”: she needs to provide her line manager with a list of “achievable” bullets that the latter can measure.  At the same time, Jane does not want to create a conflicting situation with her colleagues, by diluting her focus on shared goals and shifting it to personal goals. So, what does Jane do?  She fabricates her personal goals: “quick kills” and “low hanging fruits” – something that she can easily claim as her “achievements”, without jeopardizing common interests of her team.  Jane is forced to “game” the system to minimize harm to herself and her team.

In his book “Tribal Leadership”, David Logan describes five tribal stages of societal evolution. According to his research, corporate cultures typically oscillate between Stage 3 (“I am great and you are not”) and Stage 4 (“We are great and they are not”), with agile organizations trending more towards Stage 4. When individuals are motivated by force (a.k.a. “manipulated”) to think more about individual performance than about collective performance, they mentally descend to Tribal Stage 3 and, as a result, drag along their organization to this lower stage. It is very important for organizations and their senior leaders to understand that motivation is one of the most important factors that drive evolution of corporate culture.

Note: To understand how Motivation Evolution (defined by Daniel Pink in “Drive”) relates to Tribal Evolution (defined by David Logan in “Tribal Leadership”), please refer to this tool.

So, clearly, in the example above, Jane’s mindset is at Stage 4 and in order to descend to Stage 3, she “plays unethical game”.

Unhealthy Competition, Rivalry and Jealousy

Let’s face it, overemphasizing individual performance evaluations and allowing them affect job security, promotions and compensation of individuals does not come free of charge to organizations.  Organizations pay and they pay dearly.  Bad norms and processes come at expense of lowered collaboration, unwillingness to share knowledge and provide peer-to-peer support, increased selfishness and self-centric behaviors. For individuals that are encouraged to work and produce collectively (e.g. Scrum or Kanban teams) unfair performance evaluations frequently result in jealousy and feelings of unfair treatment. These dysfunctions become more frequent around times when employees are due to mid-year and end-year reviews. PAs have seasonal adverse effects on individuals’ ability to focus on work and, as a result, prevent them from producing high quality products and focusing on satisfying customers.

It is worth mentioning, ironically, that when dysfunctions are uncovered, it is agile that becomes the target for blaming.  But agile is hardly at fault here as it only provides transparency and reflection of already existing deep systemic dysfunction.

Example 2:

Jane works alongside Jim, Jeff, Jill, Joe and Julie.  All of them are smart, self-motivated and talented technical experts that cumulatively have more than 70 years of software development experience.  Their work is intense: there are lots of deliverables and their timeframes are rigid.  The group serves the same client for a number of years and, so far, a client is happy.  Work that this team performs, requires a lot of collaboration, collective thinking and brainstorming, teaching/learning from each other and, of course, collective delivery.

But then comes a mid-year review period and Jill notices that Jeff is not as supportive of her as he was at the beginning of the year.  Jeff becomes less responsive to Jill’s requests, he does not share his knowledge as readily as he used to; he does not give advice. Tasks that used to be handled collectively by Jill and Jeff are now illogically split by Jeff as he tries to focus only on what he assigns to himself.

There is also a noticeable change in Julie’s behavior.  Julie becomes very eager to be the one who stands in front of a client and presents deliverables of the whole team.  This responsibility used to be rotated from one person to another, with no one caring too much about being a “spokesman”.  But as mid-review came, Julie clearly stepped up to be the main, customer-facing presenter.  Julie also tries to make it very obvious to John (the group’s manager) that it is her – Julie, who presents to a customer. Julie wants to be viewed as a “centerpiece” and tries to gain most of spot light. 

Jim’s contribution to the group’s efforts has also decreased.  Early in the year, Jim used to be a very active participant at the team’s brainstorming meetings and workshops.  As mid-year arrived, Jim started spending a significant share of his time working on items that are not related to the team’s shared work; his focus has noticeably shifted to personal work that he chooses not to discuss with others.

Since the beginning of the year, it has been customary for the group to go out for drinks to a local bar, every Friday.  But this tradition is now barely followed, at mid-year period.  There seems to be less desire for the group to socialize outside work settings.  Everyone finds an excuse not to make it.  The group’s synergy has gone down noticeably.  What used to be a well jelled team of great collective performers has turned into a group of self-centered individual achievers that want to be acknowledged for their heroics.

“Scripted” Ranking to Force-Fit into Bell-Shaped Curve
Typically, when an organization ranks its employees based on individual performance, a bell-shaped curve is produced, where samples (ranked employees) are binomially distributed around the median: majority of samples are centered (“center mass”), representing average performing employees, left tail – representing low performing, and right tail – representing high performing (over-achievers). Statistically, a bell-shaped curve is a normal distribution of any large sample. The symmetrical shape of a curve (“bell”), however, can be influenced by additional three main factors (forces):

  • Platykurtic distribution – it lowers amount of samples around the median (average performers) and increases amount of outliers (under-performers and over-achievers), equally on both sides. A curve remains symmetrical.
  • Leptokurtic distribution – it increases amount of samples around the median (average performers) and lowers amount of outliers (under-performers and over-achievers). A curve remains symmetrical.
  • Uneven distribution of samples on left and right sides from median – Typically, this increases amount of samples on left (under-performers) or right (over-achievers) tails of a curve, while also disturbing symmetry of a curve and evenness of sample distribution around median (average performers). A curve loses its symmetry

This statistical distribution is tightly coupled to actions that management takes towards its employees at year-end. However, the shape of bell curve, does not “drive” (as it might be expected) managerial year-end decisions. On contrary, managerial decision shape up a curve.

Managerial decisions are driven by financial conditions of an organization as well as other strategic organizational plans. When managers review their employees, they have to account for such factors to make sure that a bell-shaped curve does not exceed organizational capabilities of promoting too many employees and giving out too much money. Effectively, the entire process of performance assessments becomes a retro-fitting exercise that shapes a bell curve, basing it on organizational capabilities. This makes the process, practically, staged or “scripted”.  What further ads to the irony of this situation is that at times an employee may report into a manager that does not even have sufficient skills for perform an objective assessment of an employee’s performance.  For example, an architect or a software engineer that reports into a non-technical manager (e.g. PMO) has a much lower chance to objectively discuss her work accomplishments and receive an objective feedback during PA.

There is a need for an alternative approach that will help dealing with overly complex, over-staffed organizations that spend so much time and energy trying price-tag its employees.

Here is an idea: how about more thorough checks of background and references, more rigorous interviewing processes that involve practical (hands-on) skills assessments, try & buy periods, before hiring an individual full time or some other, more objective methods?

Instead of attracting cohorts of workers of questionable quality and then dealing with inevitable force reduction or worrying (or pretending to worry!) about employees maintaining and/or improving their quality, hiring managers should be striving to acquire and retain lower quantities of higher quality workers: self-motivated, enthusiastic professionals, with a proven track record and clearly defined career goals…AND be willing to pay them higher compensations. This may require offering more competitive base salaries, and abolishing manipulative discretionary incentives: removing money from the table makes intellectual workers think more about work, and less about getting paid. This approach would also ensure that quantity of employees is kept at a minimum (this also ensures lowering overhead, complexity reduction, organizational descaling), while maximizing quality. Such alternative should render performance reviews much less important or even obsolete as there will be no need to reduce employees at year-end or thin-slice discretionary incentives among too many candidates.


Example 3:

John is a line manager for the development group. John has great organizational skills, he is well spoken and can greatly articulate his wishes.  But John, has never developed software products; he is not technical. John knows that all of his team members are “good guys”: knowledgeable, enthusiastic, and mutually supportive.  But when the team works together, John really cannot validate quality of work that they produce.  (Luckily, there is one reliable measurement of the team’s success – it is customer satisfaction).  The only thing that John can validate is the team’s vibe and spirit.  But even when John notices disagreements or temporary misalignment among the team members, it is impossible for him to offer a constructive advice or understand a root cause.  What is even more challenging and frustrating for John is that due to the nature of team’s work (closely collaborative, collectively shared) he cannot objectively assess individual performance of every team member.  In conversations with John, the team members rarely use the word “I”; it is typically “we”.

John is in a tough position.  How can he decide who the best performer on his team is and who is not?  John needs to be able to ‘rank’ his people and based on ranking, decide who gets promoted and paid more at the end of the year.  Deep at heart, John feels that everyone deserves a promotion and monetary “thanks” but he cannot satisfy everyone.  John’s management informs him that only one person from his team can get promoted and the amount of discretionary money allocated to his group is limited; in fact, it is less than last year.

Around mid-year time, John begins evaluating how each of his team members has performed up-to-date. John does this based on “achievable” goals that were set by each employee at year-start.  John’s inability to truly understand the nature of peoples’ technical work adds to his challenge…and frustration.   He cannot objectively evaluate his employees, let alone rank them against each other.  

Meanwhile, John’s management expects from him a ranking model that will fit into a bigger picture of an overarching ranking model, for a given year.  It means that even if John feels that all of his members are outstanding performers he will not be able recognize this officially.  At most, he will be able to recognize that they have achieved their set goals.  Further, based on what John learns from his management, he has to commit even less noble act.  Learning that certain percentage of a company’s workforce has to be reduced, John has to identify people from his group for future downsizing.  It is clear to John that people that are outstanding performers are not to be downsized (potential HR “cases”).  Therefore, John decides to force-fit some of his team members into a bell-shaped curve, away from the right-sided tail, towards the middle (average performers) and left-sized tail (underperformers).  John uses organizational “script” to play his own game.  What John does, is a wasteful act that is full of subjectivity and ambiguity.  The process is also destructive to the team’s cohesiveness and morale.  John is at risk of losing some good people sooner than he could imagine. 

Truth be told, a natural “knee-jerk” reaction of any employee when she is told by someone why she is not “perfect” and what she needs to do to improve is defensive.  Of all reasons, the biggest reason why she would become defensive is her resentment that someone will subjectively “evaluate” her and decide how much she is worth.  Although an individual may keep her feelings and emotions concealed under the umbrella of political correctness and diplomacy deep under covers, there is emotional harm being done.


Generating Waste
Rarely, do companies consciously analyze how much time and effort is being spent on performance evaluation process itself: by employees, by line management, by senior management and by HR. Unfortunately, for large, enterprise-size companies, these expenditures are already “budgeted for”. From the standpoint of lean thinking, today’s typical process of PA conducted by line managers is a clear example of organizational overhead that slows cultural evolution and prevents companies from maturing to Pink’s Tribal Stage 4.

Example 4:

All members of the team: Jane, Jim, Jeff, Jill, Joe and Julie spend a lot of time during the year writing and reviewing their personal coals.  John spends a lot of time reviewing and discussing personal goals of each team member.  John also spends a significant portion of his time with his line management, discussing achievements and intended ranking for each of his subordinates.  Overall, the amount of time this entire group of people spends on the PA process creates a lot of unnecessary procedural overhead and over processing. Annually, PA processes cost companies hundreds of thousands of dollars in wasted time by employees, at many organizational levels.

Alternative Approaches to Performance Reviews

Are there any working solutions to this problem? Is it possible to ensure that organizational behavior towards its employees (e.g. motivating and incentivizing) is more in-line with what is best for an organizational prosperity, customer satisfaction, waste reduction and creation of more pleasant work environment, and Kaizen culture? Is there a way to depart from archaic, 100+ years old Taylorian management principles, Skinnerian behaviorism, outdated norms and behaviors, without causing too much stress to an organizational ecosystem, perhaps, by offering alternative, less harmful solutions?

Lets be clear on something: ideally, the end goal of any organization should be to abolish individual performance appraisals completely and substitute them with other, more effective methods of individual motivation – at least for intellectual workers that are expected to work in team settings.

But for now, let’s look at some possible alternatives that can help companies gradually depart from individual performance appraisals, towards less harmful approaches.

Here are some potential, “second-best to a complete abolishment”, alternatives to discontinuing PA and incentives allocation process:

  • Instead of prizing individuals, prize teams and do so based on what an entire team has produced, not a single individual. If individuals must work in tight collaboration with each other and are expected to cross-pollinate with knowledge and domain expertize, what is the point to stress individual performance and superior excellence of each individual? Let a team, internally, decide who is elevating them above the water and who is dragging them down to the bottom. Individual underperformers will be quickly identified in such settings, and a team will either expel them or help them improve. Also, please note that prizing a team (monetarily, team bonus) does not have to be coupled to “performance assessment”. This could be done, simply, as a profit sharing model between business and technology: if work by technology has noticeably improved business profits, why cannot business say “thank you” to technology for its hard work in the form of sharing profits?
  • Take away singleton decision making capability of defining what a team deserves (in terms a monetary prize) out of line managers’ hands and spread wealthacross multiple parties: make it based on customers/stakeholders satisfaction, senior management satisfaction, third party feedback, etc. But again, judge teams, not individuals (important!).
  • Make monetary incentives allocation more objective and formula-driven, than subjective and single opinion-based. Here are a few suggested formulasto do this (other options exist):
    1. Monetary incentives are equally allocated among all employees whose work is tightly coupled to a shared goal, and where collective ownership is expected
    2. Monetary incentives are allocated in proportion to base salary of each employee: decide on employee’s “cost-basis” when she is hired (based on expertize, experience, etc) and then fall back to option “a” above
    3. Monetary incentives are allocated based on team’s internal voting, done confidentially (incremental, 360 review by all team members).
  • Please, visit the following links for graphic illustration of Conventional and Alternative incentives allocation schema.

Note: Consider the above options as temporary solutions, second-best to completely abolishing discretionary monetary incentives for intellectual workers that work in team settings. Although, team-level incentives are less dangerous than individual incentives, they may still bring harm: they make people think about getting paid, not about doing work.  There is still some risk that entire teams may engage in system-gaming.  Chances of that would seem to be lower than system-gaming by individuals. 

Ideally, for any kind of intellectual work, the topic of discretionary moneys should be removed from the table completely: people should be focused on doing work, not on how they can game the system to get a higher pay.


The famous quote from the book “Out of Crisis” written by Edward Deming (originally published in 1982) summarizes this topic well:

“The idea of a merit rating is alluring. The sound of the words captivates the imagination: pay for what you get; get what you pay for; motivate people to do their best, for their own good. The effect is exactly the opposite of what the words promise.”


  • Deming, W. E. 1993. The New Economics for Industry, Government & Education. Cambridge: Massachusetts Institute of Technology Center for Advanced Engineering Study.
  • David Logan; John Paul King; Halee Fischer-Wright. Tribal leadership: leveraging natural groups to build a thriving organization. New York : Collins, ©2008
  • Tom Coens and Mary Jenkins. 2012. Abolishing Performance Appraisals: Why They Backfire and What to Do Instead.
  • H. Pink. 2011. Drive: The Surprising Truth About What Motivates Us. Riverhead Books
  • Garold Markle. 2000. Catalytic Coaching: The End of the Performance Review.  Quorum Books
  • Edward E. Lawler III. 2014. Eliminating Performance Appraisals
  • Jeffrey Pfeffer, Robert I. SuttonHard, 2006. Facts, Dangerous Half-Truths And Total Nonsense: Profiting From Evidence-Based Management
  • Tom Coens, Mary Jenkins, Peter Block., 2002. Abolishing Performance Appraisals: Why They Backfire and What to Do Instead
  • Alfie Kohn, 1993, Punished by Rewards
  • Samuel A. Culbert, 2010, Get Rid of the Performance Review
  • Adobe Systems set to scrap annual appraisals, to rely on regular feedback to reward staff
  • Microsoft’s Downfall: Inside the Executive E-mails and Cannibalistic Culture That Felled a Tech Giant
  • Get Rid of the Performance Review!

2016 Big Apple Scrum Day Coaching Clinic | NYC

30 people were served at NYC Scrum User Event – Coaching Clinic!!!  Lots of fun and interesting discussions.

basd_2016_gene basd_2015_gene-1 8
Questions & Discussion Topics with Coaches:
  • “Removing the noise”
  • Growing agile advisory practice
  • Picking up after failed agile transformations
  • Transition from waterfall to agile
  • Scrum at enterprise organization
  • Scrumming in agency setting
  • How to get good practice with Scrum?
  • Career in Scrum/Agile
  • Implementing Agile culture: values, alignment, hiring
  • Empowering genius without dis-empowering the rest
  • Scrum attendance
  • Breaking Epics into correctly sized stories
  • How does Infrastructure work?
  • Effective retrospectives
  • Issues with distributed teaming (e.g US s. UA)
  • On-board offshore coaches
  • Organizational change
  • Coaching non-dedicated teams
  • Moving into a coaching role
  • Test automation
  • Working with untrained teams.
  • How to teach principles to old school mindset people
  • Advance from SM to agile coach
Feedback from Attendees to Coaches:
  • “Thanks for letting me know that I am not crazy and there is hope”
  • “Understanding ‘hierarchy’ of teams and the company in which they operate”
  • “Useful advice on splitting between technical debt rewrite and big value”
  • “Scaling with Scrum vs. Kanban”
  • “Good feedback confirmed that some of my direction is correct”
  • “Great suggestion to take back with me. Definitely will look to reach out for future questions. Thank you.”
  • “Very good feedback on story points and velocity”
    “This was extremely helpful, including workable solutions”
  • “Awesome advice”
  • “Great suggestions”
  • “Very valuable”
  • “Got great suggestions on PO collaboration”
  • “Awesome. Appreciate real world examples”
  • “Awesome inputs”
  • “Very interesting and helpful session”
  • “The coach asked all the right questions to get to the root of the challenges I am seeing”
Memorable Moments:

6 4 2 7

May 11 – LeSS Talks: Coordination and Management in Large Scale Scrum

First, we covered basic dynamics of Scrum (roles, artifacts, ceremonies).
Then,  we shifted gears to ‘activities on a typical project’ and the group 20, or so, did a “brain dump” of all possible activities they could think of at the moment.  Then, we removed redundancies, cleaned up the board  ….played “Who Stole my Cheese?” game, by mapping all activities on the board to the main three roles in Scrum (Product Owner, Scrum Master, Team).  We had very few unassigned activities that we labeled as ‘Other’.  Then, we had more discussions about how a team should claim back management responsibilities as it matures, over time.  Then, we talked about management & coordination in LeSS.  Then, we talked about management & coordination in LeSS Huge.  Then we had more system design discussions: great questions and points of view.
Thanks to all participants for making this a live, collaborative event.

Gene is singing baritone 🙂

Mike is adding spice with bass 🙂


…”mass-entry” of project activities on the wall….


…assigning project activities to Scrum roles….


…the wall is getting busy….


… discussing project roles and posting them  through a tablet….


…more tablet entries….stickies go right no the wall….


…mini-group collaboration…entering through tablets…

…another group in action…..



SAFe: Market Share Increase. Rapid Growth. What is the recipe?

Some time ago, there was a webinar recorded by VersionOne: How to use SAFe® to Deliver Value at Enterprise Scale Q&A Discussion with Dean Leffingwell).   If you fast-forward to about 23 min, 20 seconds into the recording, you will hear the following statement: “…We don’t typically mess with your organizational structure because that is a pretty big deal…”

This statement somewhere puzzled me.  While graphic representation of SAFe framework is nowhere short of supporting organizational complexity, I was still under impression that organizational design improvements/simplification are included in SAFe teaching.  To me, an ability to influence first-degree system variables, such as Organizational Structure, is critical.  Without this ability, any attempt to improve organizational agility and system dynamics would be short-term and limited.  Even such important second-degree system variables, as organizational culture, values, norms, behaviors, policies, agile engineering practices usually bring limited results if organizational structure remains unchanged.

…But regardless of my recent new learning I admitted to myself that SAFe still remains a very successful (financially) and popular product that many organizations are willing to buy-unwrap-install….Fast forwarding…


Lately, there has been so much buzz in agile arena about scaled agile frameworks.  I just came back from Scrum Global gathering in Orlando, where I heard a lot of discussions about agility at scale and various existing agile frameworks that companies use.  Following Orlando discussions, I have seen a wave of email exchanges and blogs on the same topic, some of which involved seasoned organizational coaches and trainers.  I have noticed that there has been a lot of focus on SAFe (Scaled Agile Framework): opinions, comments, attempts to compare to other agile frameworks.   There are two things, in particular, that stroked me as odd:

  1. It seemed that some seasoned coaches and trainers don’t explicitly state their views.  When I read indirect statements  or views, I remained wondering how a person really felt about the subject.
  2. Among blogs and other posts that I saw, I was not able to see any discussions that covered aspects of SAFe that were of particular interest to me.

But before I go any further, here is my personal disclaimer:  I am neither SAFe practitioner, nor trainer or coach.  I have not attended a comprehensive SAFe course… However… I have studied/researched SAFe extensively on my own. And I do know some companies that have implemented SAFe (I have talked with some of their employees).  And I do know a significant number of individuals that have been trained on SAFe.  And I do know a handful of respected coaches that recommend SAFe.

Now, let me put “SAFe” topic to the side, for a moment, and shift gears to something else (we will all come back to SAFe in a minute):

I want to bring up the topic that has been a beat to death horse for awhile, for everyone who understands agility: the topic of tooling.

When it comes to discussions of agile tools, more experienced agile coaches have a long arsenal of arguments to use with their clients, prospects to explain why ‘agile tools’ are not most important for being agile.  Here some classic examples:

  • 1st postulate of Agile Manifesto: “Individuals and interactions over processes and tools”
  • “A fool with a tool is still a fool”
  • “The best tool in Scrum is a whiteboard (or excel, at most)”
  • “Agile tool is not a right solution for your deep organizational problem“
  • “Never begin your agile education with tools. Always learn principles and concepts first”
  • “Agile tool is a poor substitution for collaboration that you may never have. If you start exchanging information through a tool you will lose the benefit of a live discussion.  If you absolutely just introduce a tool, do it later in a process, when people gain sufficient amount of knowledge and experience”
  • Etc, etc, etc…

We, as coaches, are never shy to express our strong views (sometimes, overly strong) that tools are NOT a good solution to organizational problems and NOT the best method (by far) to transform organizations.   And I am glad we are not shy about that.   This is why we are called Organizational Coaches – we look at organizations holistically.  For us, tooling is just a tiny fraction of a much bigger organization puzzle.


But I still want to confess, with regards to tooling, so here is another personal disclaimer: over the last decade, I have been around and have gained a lot of experience with tools like JIRA, Version One, Rally and others…  I consider this as a personal ‘hobby’ but I know how to decouple it from daily work that I have to do as an organizational coach.  Over the years, I got to know some great software engineers that built the tools mentioned above.  I could probably easily pass for an in-house “agile tool expert” (that is if I decided to change my profession one day) and find a job that says something like this: “Looking for a strong agile tool expert to transform our organization to the next level. PMP certification is a huge plus.”.  Yes, sadly there are many job specs out there that sound just like this 🙁 .

On a brighter side, I could probably also leverage my ‘hobby’, and look at any agile tool, used by a team or a group of teams that claims “to do” agile, and in about 5 minutes find a handful of signs of serious systemic dysfunctions (just in a tool alone!).  So, there is actually some practical use of my ‘hobby’.  In any case, I think I have earned the right to say that I know very well what tools can and CANNOT do for you.  And this is why, I strongly stand with all other coaches that use the arguments I listed above.


 Now I would like to come back to the topic of SAFe and set the stage to my questions, by stating the following:

High Market Penetration of SAFe:

First of all, lets take a look at some relevant data that has been recently published on InfoQ, with the original source being Version One, 10th Annual State of Agile Survey: while still being a relatively new framework, SAFe has acquired a significant share of market place –23% , while demonstrating the highest rate of growth:  “…the largest increase from 19% in 2014 to 27% in 2015…”


My understanding of safety that SAFe brings:

I have heard various opinions about what went into thinking of the acronym “SAFe”: was it an intention to make it sound phonetically “safe” or was it just coincidental that the words Scaled Agile Framework that begin with “S”, “A” and “F”, made up SAFe?  I don’t know.  And I don’t want to speculate.

But let me share my understanding of what makes SAFe – safe:

  • SAFe does not seem to be threatening to first-line management. Thanks to its first two layers (Team/Program & Value Stream) and abundance of processes and roles that are present in both, everyone can find place to work.  Probability of being misplaced or losing a job within SAFe is relatively low.  If we all recall, what happens with implementing basic Scrum, where teams are expected to become self-organized and self-managed, and where the role of Project Manager is not explicitly discussed, we (coaches, trainers) frequently have to answer the following question, usually coming from managers: “what now happens to my role?”  And of course, there are ways to handle this question properly and give good options to those who ask.  My point is that I don’t expect this question to be asked as frequently with introduction of SAFe.  Why?  Because SAFe seems to be a good way to harbor many existing management roles (role security).
  • SAFe looks “homey” to senior management.  SAFe graphic is very rich in colors, objects, lines, layers, icons that represent roles, groups, departments, interactions.  At a glance, SAFe appears as a natural fit and a comfortable habitat for many existing organization constructs.  SAFe does not challenge/simplify existing organizational design; no hints to change/simplify reporting lines or flatten layers (de-scaling).  No need to have unpleasant conversations with employees (!).  Senior managers that are confident that their organizations are well designed and don’t need any major repairs, see SAFe as a safe way to try agility.
  • SAFe does NOT explicitly compete with other agile practices. SAFe uses them all. In fact, a cute yellow smiley-squeeze-toy that many folks picked up in Orlando from SAFe kiosk, explicitly says: “SAFe embraces Scrum“. Indeed, at its multiple layers, SAFe diagram mentions Scrum, Kanban, XP,…and many roles, artifacts and ceremonies and iterations that support all these practices. And this, IMO, makes SAFe really safe, in a very special way: if Company X already uses, perhaps inconsistently, some agile practices, it is relatively safe, and actually convenient, for SAFe consultant to come in and say something like this: “we can help you retain most (if not all) of what you have adopted so far but it will be much better structured under the overarching umbrella of SAFe”.


My understanding of SAFe Partnerships and Strategic Goals:

Here, I am listing only the top few references that I found on-line.  But the list could be much longer if I spent more time searching.  I personally have attended a handful of webinars, where concepts of SAFe were presented, along-side with benefits of tools (by companies that hosted webinars).

Please, finish reading the post first and then come back to the links.

Choices and Partnerships by BIG CONSULTANCIES:


With Rally:

With Jira:

With Version One:

With Version One: Beware of “Trippe Taxation” Problem

Just to be clear for those that may not be as well familiar with these tools as I am (you don’t have to share my hobbies 🙂 ): each one of these tools now has complex “Strategic Layer” that sits at the top of a tools’ “tactical” layer (epics/stories, backlogs, sprints, releases, team views, agile boards, story/task boards, workflow management, etc, etc) – and it is used by a Project, Program and Portfolio Management.  At some companies, where I have consulted, each one of these layers usually has a manager (Project Manager, Program Manager, Portfolio Manager, respectively, etc), someone who is responsible for data collection and status reporting – just like it was without or prior to implementation of SAFe.  Tool complexity is great to offer a nice fit to an existing organizational structure.


What is also not a surprise to anyone is that there are so many large companies that own tens of thousands of licenses for the above mentioned tools.  I consulted to a number of such companies and seen these tools being a “hallmark of organizational agility”.  Please note that very frequently “best practices of use”, even for agile tools, reside within departments like Control & Governance, PMO, and Centers of Excellence, where decisions about “what is best” are made in a vacuum and then are pushed down onto organizational domains that are thousands of miles away.


Here is another safety aspect of SAFe:

SAFe is very safe to client-to-vendor relationships  : it does NOT disrupt existing million-dollar (of course, depends on company size) contracts and license agreements between client companies and tool vendors.  It should be pretty safe, imo, for a SAFe consultant to come in and say something like this: “if you are using JIRA or Rally or Version One or any other tool that has Portfolio Management layer in it, it will be very complimentary to what we can do for you in terms of agile scaling”.   I think that the links that I have provided above suggest exactly that.

SAFe seems to be a great compliment and strategic alliance to some agile tooling companies that have gained a lot of  their own market share.  And it does not matter if JIRA and Version One and Rally or others, could be competitors to each other. They all seem to be great partners of SAFe (I will not speculate on exclusivity of relationships but based on the links above, there is probably none).

Now, after I brought to light some relevant market data, shared some personal views on what I consider as “safety factors of SAFe”  and gave a perspective on some possible strategic alignments that may exist between SAFe and industry leaders in the world of agile tooling, I would like to ask the following two (2) questions:

  • First Question: Do you think that market penetration of SAFe and its adoption success could be attributed to a personal safety of companies’ managers, as I have described above?  Do you feel that ‘role security’ of first-level management in particular is a significant contributor to SAFe adoption rate?  I stress this last point because the role of first-level manager is in super-abundance today at many companies.
  • Second Question: Do you think that market penetration of SAFe and its adoption success could be attributed to (at least in part) to its direct or indirect alignment with industry leaders that build agile tools?  Do you think that “SAFe + XYZ tool” produces a stronger compounded effect on organizations in terms of SAFe adoption, than SAFe applied alone?

Related Publications about SAFe by Agile Manifesto Co-signers and others:

Also, as a reference, some experience reports about the Spotify “Model”: