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.
Monday, October 11, 2010
Tuesday, September 21, 2010
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
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
Friday, June 4, 2010
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.
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.
Thursday, May 13, 2010
I'm Gonna Write Me a Big Performance Review Bonus!!
My friend, Pete, works for a respected company and we talk about the travails at his company (mostly so he can vent his frustration and I can hone my emerging consulting skills and be amused simultaneously.) I like Pete - we don't see each other as much as we both might like, but we talk quite a bit (and exchange emails, texts, etc.) He visited with me about one of my favorite subjects – the performance review. His unadulterated opinion is that the performance review is one of the most despicable, morale degenerating, and hostile inventions ever concocted by that undignified management evil known as human resources (Pete holds little back when he gets fired up over something visceral to him.) His annual review had come and gone with the usual nondescript fanfare. It was typically painful for both him and his boss. Here's how our conversation unfolded:
PETE: There is absolutely no element of objectivity to any part of it! It is a charade and it politically possessed. But, there is nothing anyone can do about it. Our HR department gloats about how it fairly rewards people for their results. ( He let out a bit huff of air.) A co-worker of mine bragged about his high rating and then asked me what I got. We employees aren’t supposed to discuss these things among ourselves, but it happens fairly often. There’s always a curiosity about how someone was rated compared to you. When I told him what I received, he chuckled and told me what he received. I told him I felt we were pretty equal in skill and competency, so how was it he received a higher rating than me? Well, it turns out that he spent a month writing up his review!
ME: You mean you get to write your own review?? Everyone should get 5 stars in a system like that! This reminds me of the Dilbert cartoon where Pointy Hair Manager says he will pay $10 to people for every bug they find and fix and Wally proclaims "I'm going to write me a new minivan!"
PETE: Well, we don’t write the actual review, we just document the results we achieved during the year. We are supposed to use bullet points, but after I read this guy's performance evaluation it seems that a person gets more in return for not using bullet points. That’s when he told me that how you write up your results and how verbose you are can make the difference between an average rating and a high rating. His review was a perfect example, I guess…and so is mine, at least the other way.
ME: So a person is actually penalized for following instructions – putting their results in a list and keeping to brevity? That seems unfair.
PETE: Of course it is. But, this isn’t about fairness.
ME: It’s not? I thought that is what performance management systems were all about – being fair and applying an equitable process.
PETE: You've got to be kidding. For that to happen, they would need to apply actual objective criteria and have a credible scoring system. They would also need to eliminate human involvement because any human analysis and opinion injects bias and politics into the equation. It is as much about who they like as it is about results.
ME: Pete, how do you know that favoritism and cronyism are at work? It seems that your peers and others with whom you work provide feedback that is incorporated.
PETE: You bet they do. In fact, I suspect there is quite a bit of quid pro quo that goes on among people. Heck, even I do that. We ask each other to do feedback all the time with the implicit understanding that both people will give good marks to the other. Of course, it is supposedly anonymous, but we can usually figure out who said negative things. Of course, my supervisor really doesn’t know what I do and has never seen me actually work at my job, so she relies on this information.
ME: Your boss has never seen you work? That’s crazy. What does she do? Doesn’t she have influence over your career and work?
PETE: Well, she mostly goes to meetings of one sort or another. She has never actually coded software, so she doesn’t know what I do or how well I do it except from what she hears from others. She definitely has a say in my career and promotion options. I have to basically kiss her rear end and tell her how good she is and anything else she wants to hear. Heaven forbid if I said anything negative or critical of our company or her or just about anything else.
ME: Gee, Pete, I never realized your company was so draconian. Do you really want to stay there? It sounds like you are unhappy.
PETE: All in all, it is not a bad place to work. It has good benefits and pays reasonably well. I just think it could be much better. I read in Crucial Conversations that the authors found many highly performing companies that had no formal performance management system in place. Their primary rewards were team-based. Of course, we aren’t that progressive, I guess. I just think it can be better.
ME: Of course, all companies can strive to be better. And, I have read articles like Get Rid of the Performance Review that was in the written by Samuel Culbert in the Wall Street Journal back in 2008. There is even a book by the same name and author. Many respected people acknowledge that performance management systems are detrimental to morale and highly unfair, but companies seem to be at a loss to substitute anything else. I don’t disagree with the contentions Culbert has made about the PR:
- Performance reviews focus on finding faults and placing blame.
- Performance reviews focus on deviations from some ideal as weaknesses.
- Performance reviews are about comparing employees.
- Performance reviews create a competition between boss and subordinate.
- Performance reviews are one-side-accountable and boss-dominated monologues.
- Performance reviews are thunderbolt from on high, with the boss speaking for the company.
- Performance reviews mean that if the subordinate screws up, then the subordinate suffers.
- Performance reviews allow the big boss to go on autopilot.
- The performance review is a scheduled event.
- Performance reviews give HR people too much power.
- Performance reviews don't lead to anything of substance.
- Performance reviews are hated, and managers and subordinates avoid doing them until they have to.
I just wonder what replacement or substitute companies might have in place of it? Perhaps they would ascribe to Deming’s thoughts about it.
PETE: You have good questions, Tom. I’m not sure what I will do, but I do know that something so unfair cannot sustain without having long-term impacts to morale here. And there seems to be mounting criticisms surrounding inequities of such a systems.
ME: Well, keep me informed and I wish you well, Pete. You have quite a Quixotic challenge ahead of you.
Helping Pigs Fly
I think an appropriate first entry in Helping Pigs Fly is some type of explanation (rationalization??) of the title. To get to that, let's explore a bit about the blog owner (me.) I've been living on the earth for a bit over 50 years now. In dog years, that's a lot, but in human years, it's not so much anymore (depending, of course, where on the earth a person lives.) I teach, coach and live agile as in agile software development. I admittedly do not have much (any??) technical development experience. I came to the IT world from the business world about 10 years ago as a business analyst. I enjoyed the business world - but I tired of some aspects of it.
So, at the invitation of a friend, I ventured over to the software side initially in staffing. What a change! The vernacular, the styles and types of work (i.e. projects) and the people were much different (refreshingly so) than the business world. However, the bust of 2001 put an end to any ambitions I had to continue in IT staffing (not to mention my rather fervent dislike of the intensity and frequent frustration of having to continuously "source for talent' - aka head hunt.)
Another friend suggested that I actually give IT work a try, and though I had no technical background I did have a strong business background that made me a reasonably strong business analyst candidate. I was hired and moved to a rather small, sleepy Midwest city from the bustle of Seattle to work in a large IT shop. Within 18 months (in March 2003), I found myself ordained as a project manager (I had functioned or perhaps malfunctioned as a business manager for several years, so I think the people reasonably thought I could manage IT projects.)
Within a few months of experiencing the nuances and peculiarities of project management, I realized that much about it was rather illogical and assuming. I learned from an older, grizzled PM about the “PM bag of tricks” that provided remedies to the project maladies that every PM seemed to constantly endure – budget overruns, schedule delays, unreliable estimates provided by supposedly expert “resources,” poor quality product, etc. For example, I learned the trick of keeping 2 schedules (similar to keeping 2 sets of books) – the one that was viewable publicly and was always on time and on budget and the “real one” that reflected the actual state of the project – often running late and over budget. When I asked how a PM might bring the public schedule and real schedule to coincide near the end of the project, I learned of the death march and schedule crashing and many other evil PM tricks.
Thankfully, I soon tired of the charade, but rather than quit as a PM (something that is done more than I realized), I began to explore for alternatives to the “traditional” approach that depended upon being able to predict a project schedule from beginning to end. It was December 2003 when I stumbled upon an article in a software development magazine that described an agile process called, mysteriously, Scrum. The more I read, the more I realized that this approach made much more sense than anything I was doing at the time. Thus began my journey to Agile Oz on the Scrum Yellow Brick Road. What a trip it has been! (More about that in future posts.)
So, Helping Pigs Fly refers to my campaign to help people in organizations do work in a better way. That doesn’t mean simply adopting Scrum and agile, but thinking about things in a most different way and understanding how little control we actually have in this self-organizing world in which we live and work. I still see many pigs who could fly if they wanted and I see pigs who fly with the grace and elegance of the eagle and the determination of the migrating goose. So, this blog will be full of all kinds of stories, vignettes, and experiences with lessons gained or not. I hope people find the content enjoyable, entertaining and even worthwhile.
Subscribe to:
Posts (Atom)