The Beating Will Continue Until Your Performance (and Morale) Improves

A very nice benefit of interacting with many people in the broader agile community is the opportunity to make friends, share experiences and try to help others.   People from across the world are part of this community.  We don’t always talk just about agile philosophy and frameworks; we share the trials and tribulations we encounter in our work and our organizations.  And it is in that vein that I mention my friend, Bubba.  Bubba is not his real name, of course, but a colloquialism that fits the inner innocence of his persona like a favorite sweater.

Bubba is a kindred spirit to me and I suspect that we may be alike in many ways.  It seems, like me, he can find himself in some pickles at his work as a result of brashness and impudence.    He seems to survive in a fairly steady work environment and until fairly recently was doing very much what he wanted to do in his work – training, coaching and helping people in their endeavor to work better and with more satisfaction, mostly through the use of Scrum and similar frameworks.  But, in a conversation with me a while back, he described a vicissitude that rattled him to the very core of his soul.   It originated as the result of a rather obscure platitude that by virtue of an innocent event became the stage for the travails he described to me.

This story really begins many years ago when, like me, Bubba introduced Scrum into his company.  His company is steeped in conservative culture and tradition.  Its industry has been around for dozens of decades and the company is over 50 years old.  Bubba has been a bit of an enigma – he told me he was once described as highly regarded by the production workers in his IT shop, but a bit detested by a fair number of his manager peers.  He attributed this to his advocacy of self-organization / self-direction among teams and minimization of management oversight and intervention.  He strongly promoted the adoption and use of agile-based software development principles and practices and this was also viewed with suspicion by some of his management peers.  He trained, coached, and helped many teams and while some managers doubted his intentions and motivations, his cause was seemingly supported by the senior management of his IT department.

Then, there seemed to be a change in the heart of the executive leadership at his company and they backed off of support of the adoption of agile practices (at least by that name.)  His influence began to wane as he was removed from influential participation with the department’s coaching group.  His direct management was also starting to exert pressure on him to take a less aggressive posture in his encouragement of use and adoption of the practices.  He had heard that a monthly agile newsletter distributed widely to the department was to be discontinued.  He didn’t like what he heard and suggested to the person who had published the newsletter that he would seek to take it over and perhaps even publish it in some covert way.  In a very Dilbertesque event, the person who had been publishing the newsletter inadvertently sent Bubba’s email to the newsletter’s broad internal agile community distribution list.  This list included several senior management people.  The poor editor could only respond to Bubba with an “Oh Shit!!!” in an email.  But, the damage was done, though Bubba had no idea how ludicrously malevolent that reaction would be.

The first indication was a response from an IT VP who admonished both Bubba and the newsletter editor for their insolence in sending such an email to the entire agile community mailing list.  Bubba responded to the VP that the editor had sent the email by mistake and that the intention of communication between Bubba and the editor was to find a practical way to keep information about agile practices coming to the community.  Bubba thought that should likely be the end of it, but was he mistaken!  A day later, Bubba’s manager summoned him to the manager’s office.  Bubba was in grave trouble according to the manager, possibly in danger of being removed from his position.  To Bubba, this seemed the ultimate over-reaction, but there was little doubt about the gravity of the situation from the solemnness of his manager.

A few days later, the manager delivered a letter to Bubba detailing among several items, a “lack of confidence in your ability as a leader in our department and reflects your allegiance to agile principles and disregard of department direction…Current consequences consist of our performance discussion and the associated impact your midterm performance evaluation, which is now set at unsatisfactory. We expect immediate, visible, and consistent display of actions and behaviors that align with company and department expectations.”  The letter included a list of 14 activities which Bubba was “restricted” from participating in, which included several facets of agile engagement – training, coaching, mentoring, etc.

“Wow.  That is pretty harsh!” was all I could initially muster in what had to appear to be the ultimate understatement to Bubba.  “They really have marginalized you.  What is most appalling to me is that they have applied the company performance rating system in an arguably inequitable and egregious manner that might actually be dishonest.   Do you have any recourse?” 

No.

“Well.  You might be better off leaving.”

At that point he explained that he is only one, maybe two years from retirement at his firm.  They are one of the few companies left in America (it seems) that still has a full pension plan available to vested employees that can be commenced upon retirement from the company as early as age 55.  So, Bubba feels trapped and it is not an enviable position.  Ironically, the use of the performance rating system as a stick in this case, rather than a carrot, demonstrates reasonably well the fallacies and despicabilities of these systems as described by W. Edwards Deming in his seminal book Out of the Crisis.  Deming writes Traditional appraisal systems increase the variability of performance of people.  The trouble lies in the implied preciseness of rating schemes. What happens is this.  Somebody is rated below average, takes a look at people that are rated above average; naturally wonders why the difference exists. He tries to emulate people above average. The result is impairment of performance.  

That isn’t the only result.  The fear factor naturally sets in and pretty soon horizontal violence becomes evident.  The disparate power structure also has other hideous and incestuous behaviors that can further demoralize workers.  These and other reasons are why Deming listed performance appraisal systems as #3 of his 7 deadly diseases and obstacles that stand in the way of company transformations for the better.   Performance management systems create an environment for game playing and they inhibit the ability of people to have “crucial conversations” where issues can be discussed in a healthy way.  Bubba told me that trust no longer exists between him and his manager, and he does not see a way to rebuild it.  There could be a way, but this rather bizarre reaction to a non-event has solidified the unequal power structure that surrounded the relationship.  I asked Bubba if there were other issues identified in the letter and he described a few others.  None of them seemed to rise to a level where such remedial action would be deemed necessary. 

This event took place several months back and I asked Bubba what awaits him at the end of the review cycle, which is approaching.  He isn’t sure and he seems resigned to whatever comes about, satisfactory or not.  What is apparent to me is that Bubba, a 20 year employee of the company, has been reduced to simply sustaining for some remaining period of time.  He is not a broken person, but simply derailed.  I know of his capabilities and contributions to the agile community at large, and it saddens me to see this happen especially since it did not need to happen at all.  I hold out hope for him, that he will find a way to survive this.  If anyone can, it is likely my friend, Bubba.

We Appreciate and Respect Demming, Except When We Don't

Spoke with my friend, Levi, the other day via Skype.  That is a wonderful communication tool.  We visit frequently and he brought up his company's IT department planning message for 2012.  In that message, Levi’s IT department states that it wants to provide solutions to better meet its customers’ needs and desires, grow and be profitable in its business areas, and develop its people.  These all align with his company’s 3-year goals (i.e. focus on its customers, manage its business effectively, and develop its people.).

Such annual messaging is routine in many if not most US businesses; it is intended to provide a map for the next year and align the actions with strategic goals. An interesting anomaly in Levi’s company is something it calls its 2015 Vision.   According to Levi, its 2015 IT department visions are:

·     Be a provider of solutions

·     Build a skilled, passionate, and loyal workforce

·     Achieve operational excellence by leveraging data

·     Use technology to effectively build the company brand

·     Redistribute people to grow the company (Levi says the company uses the term  “resources” rather than people, but he knows what is meant)

These are separate from its company’s goals. So, its IT workforce is expected to contribute towards the fulfillment of its 3-year goals and demonstrate behaviors that align with its 2015 vision. The focus of Levi’s discussion with me involved the last of the 3-year goals – develop people – and its goal to build a skilled, passionate, and loyal workforce.  On his IT department’s website is a statement it categorizes under the Skilled Workforce section of its 2015 Vision.  It effectively states that the company must invest in people who have a “willingness” to align with the company long-term strategies and the people must also be willing to work in technologies that are “high value.”  It then states that meeting “performance standards” is an expectation for “continued employment opportunities.”  Translated: you have to be skilled in the technologies used by the company and you cannot be a slacker, whatever that term means.

And it is here that the rub with Levi rests.  A number of managers in his company tout an admiration of W. Edwards Deming, the famous quality and management guru.  But when Levi points out to them that performance management systems are one of Deming’s “7 Deadly Diseases” (i.e. severe barriers to company improvement), the tenor about Deming changes to “Well, he was misguided in that area.”  Now, Levi’s company has even brought in Six Sigma training, which evolved from Deming’s philosophy of Total Quality Management (TQM.)  So, Deming is seemingly appreciated and respected at his company…except when he isn’t.
It’s worthy to review the #3 item on Deming’s 7 Deadly Disease list (which comes from Deming’s book, Out of the Crisis):

Personal review systems, or evaluation of performance, merit rating, annual review, or annual appraisal, by whatever name, for people in management, the effects of which are devastating. Management by objective, on a go, no-go basis, without a method for accomplishment of the objective, is the same thing by another name. Management by fear would still be better.

Deming goes on to ridicule these systems (more accurately, to eviscerate them) in his book.  He writes on page 102 of Chapter 3 in Out of the Crisis:

[The performance measurement system] nourishes short-term performance, annihilates long-term planning, builds fear, demolishes teamwork, nourishes rivalry and politics…It leaves people bitter, crushed, bruised, battered, desolate, despondent, dejected, feeling inferior, some even depressed, unfit for work for weeks after receipt of rating, unable to comprehend why they are inferior. It is unfair, as it ascribes to the people in a group differences that may be caused totally by the system they work in (my bolded emphasis.)

Deming defends his position and argues the logic of his reasoning for several more pages in the book.

Back to Levi and his IT department.  He shared with me the department’s philosophy about developing its people:

Our ability to be a provider of solutions relies upon every employee. We must improve and strengthen the performance of our workforce. [Management] must get better at setting the performance expectations of its people and engage in constructive and straightforward conversations about how people can differentiate and elevate their performance. We must create a positive and productive atmosphere of collaboration that allows employees to question [management], provide feedback [to management about people], and give input [about performance measurement.] [Management] must recognize the need for learning agility and adaptability. Each employee must be engaged and committed to exploring new technologies and generating ideas for continuous improvement. Everyone is accountable for maintaining relevancy and competitiveness and for evolving to fit the needs of the organization.

Sounds inspirational and appropriate – no?  However, Levi mentioned many of the shortcomings and fallacies that infuse performance management systems, especially as applied to technology workers (knowledge workers.)  As Deming has stated, the process must be highly politicized because there is no way to account for the system portion of so-called performance.  Also, many of the measures are arbitrary and behaviors will adjust to be normative towards the measures.  It reminds me of Wally in Dilbert when, upon learning that his performance will be measured by the number of lines of code he writes, declares “I’m going to code me minivan!!!”  The worst part of these systems is that they stifle teamwork and teamwork is acknowledged almost universally as a key ingredient in the delivery of technical products.

So, Levi is despondent because he knows any performance management system is highly subjective and tends to measure just about anything but personal performance, but the so-called 2015 Visions have placed even more emphasis on it.  My, oh my…

Levi commented to me:

“I don’t know anyone who has ever had “constructive and straightforward career development conversations.  Who do you have those with – my manager?  I’ve tried and it’s like staring into the abyss.  My belief, perhaps naive, has been that if I have to tell someone how good of a job I am doing then I am not really doing a good job.”

He continued, “This is just the opposite of how we really assess performance and career development at work.  Case in point: the cynical but all too real, ‘I am going to write me a top rating!’  Too many people have tooted their own horn just to make themselves seem like they deserve better than others.  And this behavior is encouraged by management.  Just recently, my manager told me to change my performance document to make it sound like I was doing certain things and I was the standout.  The reality (which is how I wrote it and he even knew it without reading it) was that I worked with other people, team members, etc.  Yes, there are plenty of folks who could be adding value and being more productive if they were in different situations at work.”

“But, again, this is opposite of the assessment and career development structure in place.  I’ve seen too many analysts with the delusions of being management or architects who just go through the motions of a given position so they can get out of it as quickly as possible and climb the ladder.  I’m sorry, but this neither adds value nor contributes to better productivity at work.”

I responded:   “What I sense here is the notion that your management wants everyone in Lake Wobegone to be (way) above average.  Of course, that cannot happen and they fail to appreciate that people bring diversity of strengths and talents to the table, and some (many??) may work in a capacity that does not even leverage their greatest strengths.  And they cannot overcome system constraints.”

“I know a person who actually may be a good example – he is an admittedly an average worker in his role simply because the traditional expectations to be a highly rated worker in his role repulses him.  So, he essentially evades demonstrating or promoting the very “skills” and “competencies” they desire in his role.  He is an enigma to his management because the projects he has worked on have been vastly successful.”

“But the reasons for his successes cause his management to get grumpy – such as his advocacy of self-directed and self-organized teams, for instance.  Also, his emphasis on coaching and training the people with whom he works to operate independently of traditional project managers is contrary to the culture.  Those are not the skills or competencies found in the project manager role descriptors.  Now, if they actually asked him what he really wanted to do and let him do it, he would be training and coaching full time, I expect.  Of course, they don’t want him to do that because that is not what he is paid to do in their eyes.  So, he is in a pickle and his management is in a quandary.”

“You and I can both think of lots of people who are not doing what they want to do or what they are good at doing (and usually those are one in the same, but not always.)  Even you may categorize yourself in that boat.”

At the end of our conversation, he grimaced and shook his head.  I couldn’t offer much more than my hope that his department might come to its senses.  He ended with “I think it will take a revolution – perhaps a mass exodus of good people who just are fed up with it all in the end.”  Perhaps…that might be a good thing for those people and sad thing for this company.

Maybe They Will Believe a 9 Year-old???

I was sitting at the kitchen counter this evening when I received a call from a colleague who works for a prominent consulting firm.  He is a lead on a project that is customizing one of his firm's tools for use by another company.  We discussed the status of his project tonight – actually the status of “his side” of the project (his client has people working on "their side" of the project, too.)  He is concerned because a wicked technical problem may throw a wrench into their ability to meet delivery promises that have been made by his company. 

I turned to my 9 y/o daughter who was eating dinner next me.  “Lindsey, if I asked you to complete a very difficult jigsaw puzzle in a week, what would you tell me?”  “Well,” she paused, “I would want to know how big the puzzle was and how complicated it was – what was it a picture of?”  “What if I told you that it was 1000 pieces and it was a picture of a castle and that was all I knew?” 

“Hmmmm…” she pondered, “I would tell you that I don’t know if I can get it done in a week, but I would try my best.”  I lowered the boom: “What if I had made promises to very important people that you would get it done?”

“You shouldn’t be making promises for me.” she said.

“Exactly," I said, "What if I told you to work on it day and night for a week until you finished it?”  “You mean without going to school, or playing, or anything?” She asked.  “Yes.  You would work it on it unless you were sleeping."  She thought a moment, “That would be a very mean thing to do, Daddy.  I would have to say no."

It surely would be...and good for you, Lindsey, for having the smarts and courage to believe you would say no.  And maybe those who were demanding completion of the puzzle might believe you and accept your answer...maybe.


In these situations that confront my colleague, where promises are made by those not actually doing the work on behalf of those who are doing the work, discussions, negotiations, and agreements are hatched between two organizations without really understanding the true and complete nature and complexity of the effort.  True understanding of the work and its complexity emerges in technical product development through exploration and discovery along its development path – almost every person with just a limited amount of experience in the technical product development field soon learns and accepts this (or suffers a terminal dose of denial.)

However, date and cost commitments are often made on behalf of the yet-to-be-assembled development team by the people who are not actually going to do the work but nonetheless have a considerable stake (often financial) in the on-time and on-budget delivery of the product.  They make such promises with sincerity and good intentions, but with little or no reliably predictive data to back up their estimates now turned promises of delivery within a predicted time and budget.

So, the innocent team then assembles, begins to investigate the work and build the product, and its discoveries soon reveal at least one and often times many wicked problems that require great thought, effort and even application of the scientific method to solve.  The complex system reveals innumerable possibilities of solutions, each of which may cause more problems through the interaction of multiple agents. To top it off, Mr. Murphy lurks about and inevitably shows up.   And so, the best laid plans begin to go awry and unpredictability and uncertainty sets in.  People become nervous and anxious and demands begin to come forth – “just work harder” and “get to the root causes” are some of the refrains heard.  Telling the truth soon becomes unfashionable, or perhaps there is an inclination to tell the truth in some "correct way.”

As the time gets shorter, tempers start to flare and blaming soon follows, especially when it is apparent that the team will likely deliver “crap” in order to make the date.  Perhaps someone will actually courageously surrender their political virginity and career aspirations by proclaiming that the product will have to be delivered late to actually be qualitatively acceptable.  Either way, unpleasant fallout occurs and people suffer – the team, the customers, those who made promises, those who believed the promises, and those who were expected to deliver on the promises.  This whole process can fit into a Dilbert comic strip and it is repeated again and again with the notion that the results will be different.  Total insanity!!

Lindsey finished her dinner. “Daddy, do people really ask people to do those kinds of things – work really long hours to do things other people promised?”  “Yes, they do, at least sometimes.”  She shook her head, “I don’t think I want to work in a place like that.”  Good for you, my daughter.  Neither do I.  Neither...do...I.

Will We Ever Learn? Or, Old Habits Are Hard to Break

Spoke with my friend, Levi, recently. He works at a large company where the IT department develops internal products to support its operations and sales force. It also buys COTS products at times and modifies them as needed before installing them or having them installed.
His company has a large testing organization that is responsible for supplying and maintaining various test environments (and it also develops testing procedures and processes and supplies test people - know by the despicable term "resources” – a very poor euphemism for people.) Levi received a note recently from the senior leadership in the testing area wherein it was written that there were various insidious issues impacting the stability of various production and test environments. People impacted by these environment outages included internal and external customers, external sales people, and various IT department areas. The frustration level was (and still is) critical.

In my ScrumMaster classes, we watch Ken Schwaber's September 1985 Google talk video. From about minute 25 to about minute 40 in that video, Ken describes the historical process used to create what he termed "design dead software" - software and technical infrastructure that has become so fragile and lacking in quality over time that it eventually effectively collapses into a smoking heap of crap. The result is a company that fails and is either consumed in a takeover or simply vanishes.

The process of creating this type of brittle technical environment is fairly simple. First, people in the company (usually management with the proverbial sticks) demand that product be delivered by some usually arbitrarily selected date and that date typically does not allow for sufficient time to bake the technical pie to a qualitative state of “done.” Project management typically refrains from objecting to the inanity of the date for fear of being beaten with the sticks and it reaches into its “bag of tricks” to make magic happen and meet the date. I first learned of this infamous bag of tricks years ago from a project manager. The tricks include putting people on the death march (working overtime including holidays and weekends, etc.), insisting that people put other work aside to focus on the project work, putting more people to work on the project (in defiance of Brooks’ Law), and cutting short later phases of the work (most often in the case of waterfall, testing and Jerry Weinberg appropriately describes the test trimming problem in this fable from his AYE conference.)

That such insanity has endured for so long is a testament to the belief in magic. And to the technical community’s inability or lack of desire to stand up to this contemptibility. Schwaber and others have long insisted that agile approaches and the agile cultural phenomenon emerged as a counter to the enduring legacy of this hideous problem. He has insisted (and there is no reason to doubt him) that Scrum was created to bring professionalism, honor and respect back to IT workers. The problem has been that no one has addressed the big elephant in the room: traditional scientific management and its desire for absolute predictability. Discussion of this problem can extend to a myriad of paths, but the bottom line is that as long as traditional management exists in academia and in practice, efforts to change long-standing organizational cultures will largely fail. The market place will eventually do what we cannot. Stephen Denning describes this need for transformation in his excellent work The Leader’s Guide to Radical Management: Reinventing the Workplace for the 21st Century.

Levi has spent 7 years trying to influence, change, cajole, impact, and manipulate an existing traditional corporate culture in an effort to adopt (or at least contemplate adoption) of an agile-based culture. Alas, he reports that the results have been marginal at best, highly repercussive to him personally, and futile for many people in his company who were optimistic (perhaps as seemingly naively as him.) Levi still holds out hope, but it has seemingly diminished much lately.

So, his people are left to their usual devices in tackling these environment problems and others in the usual manner by the usual application of reductionism and fix by patching, along with date bets and velocity bets that increase the likelihood of eventual design dead software. Then, someone might be able to swallow up this currently proud company or it might just go extinct. Time will tell.