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.

Games People Plan and Lessons Gleaned From Them

My fellow Scrum Trainer and Coach, Bob Sarni, and I recently watched a US college football (American style football, not real football) game up close. Bob and I live in the same town and I invited him to work the sidelines with me at an Illinois State University game. That meant that we would maintain the location of a couple of the field markers (i.e. the auxillary down box and the line-to-gain marker) on the home team sideline during the game. It isn't difficult work, though it can get a bit dangerous when plays occur on the sideline near where we stand (we move up and down the field as the play moves.)

We talked before the game about how various sports, including US football, seem to emulate the inspect and adapt pattern of Scrum projects. Bob mentioned that each of the 2 teams does a quick stand up between every play, though there isn't enough time for all 11 players to report on what they did the play before, what they intend to do on the next play, and what impediments they have. Some of that happens spontaneously, of course, (as in "Hey, I was open on that post route to the wide side," etc.), but mostly the players listen to the quarterback call the play or repeat the play that a substitute has brought in from the sideline. Everyone is generally quiet and thinks about what they have to do on the next play. Of course, the quarterback can change the play with an "audible" - code speak that everyone on the team understands (or hopefully understands.) Likewise, the defense has a similar process except the coaches often relay the defensive tactic from the sideline with the use of various hand signals.

As we walked up and down the sideline, Bob and I observed various instances of mis-communications and other mistakes by each team. Teams who practice regularly make mistakes and even really good players make mistakes. But the team has to constantly work together and its "chemistry" has to come together for the chaos of play to take on some kind of beneficial order. That is, the team must work hard for the play to become "chaordic." Really good teams do not lean on any one person too much - everyone must perform well enough in his position so that the team can make order out of chaos. When a player fails at something seemingly insignificant, the entire process can break down and plays fail to the advantage of the opposing team. Teams that consistently perform better than the their opponents will win much more often - gee, that sounds familiar in the world of work!!


Some teams try to play without the between plays huddle (a process called naturally enough the "hurry up offense.") But teams can only run a limited number of plays in this process and there is a greater chance that one or more players will make an error. Because an opponent is involved, such errors can be very costly as they can squelch opportunities for the team and/or present the other team with opportunities.


In my Scrum classes, I often speak about how project teams cannot rely on one appointed or emergent leader. That places too much burden and risk on the success or failure of that person's performance and like a football team that relied upon the QB to "do it all," the project team likely would soon find itself underperforming. The team must accept and leverage that its collective strengths and abilities are much more formidable than a single person or even small group of people and everyone brings some strengths with them that the team has to discover and appreciate. Sometimes these strengths are even hidden in the recesses of unchallenged skills, etc.


So, the next time you watch a game, whether it is US football, "real" football, rugby, etc. you might think about how the 2 teams are faring through optimizing their process of play. It is a process, of course, often times charted out in sophisticated diagrams showing where players should go or be in designed play. But, if you watch carefully, especially with 2 teams that are fairly evenly matched in size, strength, and speed, you will see that leaders of all sorts emerge at different times during the game and the good and great teams inspect and adapt their play continuously in much the same ways that occur in strong agile teams.

And look for people on the sidelines that seemingly have nothing to do with the game itself but are doing some mundane work like taking photos, collecting sound, or simply helping the teams and officials know where important points are on the field (ocassionally these people even get run over by players - that is a risk of the work!) I bet they often spend time observing the nuances of the game - perhaps even how teams apply agile principles in their play.

Talking Scrum, Walking Scrum, Hoping

I corresponded recently with my friend, Josh. He is a manager at a company "down South" and he ranted about a few frustrations he had with some (many??) of his company's managers and workers' about their ignorance of agile and Scrum. I can understand his feelings and why his patience is being tested. His email:

Hey Tom,

Just some thoughts. I am increasingly amazed at our people’s ignorance of agile and modern software development in general. This applies to our management and to our IT workers. We build software here for a living and we ought to be doing it the best that we can. Modern software development involves building and delivering quality software as quickly as possible using excellent practices and principles. To do this effectively and efficiently, we rely on the disciplined use of the agile framework of Scrum and proven engineering practices (at least we say we do.)


As you and I know, Scrum was created in 1993 by Jeff Sutherland and Ken Schwaber. The idea was to focus on the fast delivery of quality software that could be inspected for appropriateness by the customer at regular intervals and, if desired by the customer, shipped immediately. This was a radical departure from the “completely mix and bake” approaches that did not deliver the product until the end of a linear development process. This process involved identification and agreement of all requirements at the beginning, then development of a full design that was elaborately documented, and then a full development cycle that created the software in its entirety based upon the specifications identified in the requirements and design.

This was typically done through a unit and “white box” (code coverage) test level with intermittent incremental regression testing done. At some point, typically well into the development cycle, functional / system (i.e. black box) testing began. At this point, the defect ping pong game started. This caused disruption in the continuity of the programming because developers had to compete with 2 priorities: complete coding or fix defects. Typically, some number of developers were assigned to fixing the defects and this caused problems with coordination of the work and completion of both application functionality and resolution of defects. This describes the legacy of how we did work at our company up until I brought agile in a few years ago.

The software industry continued to practice this insanity and couldn’t understand why it could not deliver quality software at predicted (or demanded) dates. Same with our company. Frustrations increased and in the late 90s the web put even more pressure on development people. Failure to deliver software didn’t just mean that a date was missed and disappointment (anger??) resulted, but more and more revenue was lost and stature in the market place was diminished. Agile permitted for incremental delivery of the software based upon the premise that customers did not know exactly what they wanted or how much. By providing them with the opportunity to see and actually experience the software as it is being built, they can judge how much is enough.

At our company, people were fearful that this would open the door to “scope creep” but the considerations of time and money still come into play (unless there is a infinite amount of both.) So, the customer has to decide what is most critical in the application and whether investment in any functionality is worth the cost (a positive net present value.) With Scrum, the customer can decide when something is good enough, or even stop a project early if value is not being delivered (stopping the pushing good money after bad.) To me, that is a no brainer.

So, these various philosophical perspectives of agile were coalesced into the Agile Manifesto, which established that agile is not a process but a work philosophy and cultural guide. An organization cannot “do agile” but it can "be agile" and do its work in a manner that supports and is supported by the 4 values and 12 principles identified in the Manifesto. But, working in this way takes discipline, adjustment and acceptance of this philosophical foundation. You can’t just “talk agile” but you have to “walk agile” and we continue to have a helluva time with this.

The agile urban myths abound and it typically takes much more discipline and better engineering practices than the old linear methods. This puts pressure on the organization and its people. It requires change in thinking and challenges traditional ways and practices (e.g. using working software as the measure of progress, not the production of documentation and accepting change and modifying a plan rather than strictly adhering to it and making it difficult to change it through a rigorous and oppressive change control process.) Jeff Patton argues that agile is actually a culture not some kind of process in this blog post: Agile is More Culture than Process. Scott Ambler discussed the values and principles in detail in his essay Examining the Agile Manifesto.

I’ve harped enough, but the bottom line is that people need to learn about and understand agile. That means going out and googling it, read about it, and think critically about it. I firmly believe that agile isn’t going away here (despite the arguments that it isn't really here now); in fact, it is here to stay in my opinion. I do my best to dispel the myths to the folks I know such as Scrum projects don’t do documentation (all projects should documentation that is valuable to the team and to a servicing area, or required for compliance reasons – and that should be minimal.)

We typically don’t have coordinators, leads, etc. on Scrum projects because that adds to overhead and inhibits the notion of cross-functional, self-directed, self-organizing teams. We want to maximize the amount of “real work” that people do (e.g. coding, testing, etc.) IMHO, we have way too many of these coordinators, etc. and not enough carpenters (builders.) People who like carpentry (i.e. coding) and contribute to building products are told that they can’t be promoted to senior engineer unless they are willing to forego coding and get into coordination / lead positions. What nonsense!!

Our company would serve itself well to align with Deming when it comes to his 14 principles, especially as they relate to management (and agile supports these):

7. Adopt and institute leadership for the management of people, recognizing their different abilities, capabilities, and aspiration. The aim of leadership should be to help people…do a better job. Leadership of management is in need of overhaul, as well as leadership of workers.

8. Drive out fear and build trust so that everyone can work effectively.

11. Eliminate numerical goals, numerical quotas and management by objectives. Substitute leadership.

Well, now you know how I really feel and think, Tom. Thanks for letting me vent and get this out. By the way, you might appreciate Dilbert yesterday: http://www.dilbert.com/strips/comic/2010-09-20.

Josh

Pink Slip for Wheat Penny

My friend Betty is a contract worker. Like many, she is simply thankful for a job in this economy, even with the idiotic dysfunctionality that can come with the work. She does a fine job and she attended one of my Certified Scrum Master classes a few months back.

Betty, my friend, Wes, and I were talking about some of the absurd things companies do to enforce "rules" and while enforcement (and the rules themselves) often venture into the ridiculous, one instance she recalled caused us to laugh pretty well. She told us she received a pink slip for having a penny in the drawer of her desk. Wes and I gazed at her in disbelief. "Let me explain," she offered. By all means, we said.

It seems that a company she worked for had a rule (called a policy in company speak) that prohibited employees from leaving money in the unlocked middle drawer of their desks. Through some fortune, Betty had come across of "wheat penny" (produced circa 1909 to 1958) and intended to save it for one of her nieces. So, she put it in the middle drawer for "safe keeping." Bad timing; one of her company support people (we used to call them secretaries) did a "desk inspection" where they surreptitiously check to see if desk drawers are locked, that no contraband is in them, and that, heaven forebid, no money is in that unlocked middle drawer, which would surely tempt the local thieving office gremlin. But, lo and behold, there was that wheat penny - right up front and center - for all the world to see!

Well, for such a transgression, one receives a "pink slip" which Betty explained did not mean you were fired, but rather that you had violated (semi) sacred policy. Wes and I were extremely relieved. "How many of those pink slips can a person get before they get the other kind?" I asked curiously. "I don't know, thank goodness," she replied. "But if you accumulate 3 parking tickets in the company lots, you get to visit the head honcho in Chicago!"

"Wow, what a way to win a free trip to the big house in Chicago," I marveled. With that, we called it a week on a late Friday afternoon.