- Consulting / Coaching
- Jeff’s Blog
On the scrumdevelopment Yahoo! group, a discussion revolves around user group concerns over the trademarking of the phrase “Sc*um User Group.” (Note that I’ve starred the name in order to avoid trademark violations.) A few inquiries resulted in an official response from a Sc*umAlliance representative.
I find it odd that (a) no one belonging to the “Sc*umAlliance” (whoever they really are–I’m suspecting maybe Mars, but given their legal nature, maybe Uranus) frequents the scrumdevelopment group, (b) none of them chose to respond directly on the group once apprised of the concerns, and (c) Ken Schwaber didn’t have an immediate answer (regardless of his affiliation with the Sc*umAlliance). I suppose there must be people (lawyers, no doubt) who don’t have to be at all interested in the product they support, but it just seems wrong somehow.
Agile requires lots of communication and continual negotiation. Bits of command and control have their value at times, but in most cases C&C begins to eat away at the trust relationship required for continual negotiation. I suggest people considering or doing Sc*um dispense with the trappings of a trademarked process and look instead to understanding what agile is really about.
The progenitors of agile–i.e. the agile manifesto signatories–rightly eschewed “heavyweight” processes–processes centered around lots of documentation and meetings. I think there’s a new category of “heavy” that should be spurned, and that includes processes controlled by people so heavily wrapped up in legal and licensing protections that they can’t bother discussing changes with the community who would be affected.
I try to keep up with all of the various agile “Yahoo! Group” lists: extremeprogramming, scrumdevelopment, refactoring, testdrivendevelopment, agile-testing, and so on. I post once in a while when I see a topic I feel qualified to respond to or that I’m passionate about. Lately I’ve been getting a lot less value out of these lists, some of which I’ve been following for ten years.
Many of the lists degrade into passionate statements of position, i.e. advocacy. Inevitably, people get burnt. Tempers flare, people get upset, some stomp their feet, some simply withdraw. I myself have gotten burnt on this same list, feeling that someone (probably not coincidentally, the same person who is withdrawing now) was looking to simply piece apart every single word written to find as much fault as possible with it.
I withdrew completely from that discussion. I’ve also withdrawn from perhaps a couple other difficult discussions (out of the hundreds I’ve engaged in over the years). Sometimes it’s because I felt the environment was too hostile, and I justified it to myself by thinking that the individuals involved were being immature or offensive or whatever. But that’s not courage speaking. I looked back at my most recent example and regretted how I handled it. Withdrawing didn’t solve anything.
Sometimes a simple statement, meant to be innocuous by who wrote it, is taken as a stab and affront. We can pout and take our toys and go home, but that’s not at all useful or commendable. Courage can help us find a way to face the challenge and learn how to get past the issue. We don’t have to agree with everyone or get along with them, but sometimes a sour incident can lead to a valuable relationship.
So how is this at all relevant to anything? Well, if we are to succeed, agile software development requires that we face challenges and not bury them in isolated cubes. Similar clashes occur not only on email lists, but in real life, and we’re particularly going to see such clashes more frequently in highly collaborative teams. Conflicts that are not handled properly will detract from a team’s ability to deliver. The XP value of courage is still essential to learning how to regularly deliver quality software.
In Scrum, those “not accountable for deliverables” (emphasis added; see Jeff Sutherland’s article) do not get to talk during certain meetings. Pigs (product owners, ScrumMasters, and “the team”) are accountable for the success of the project. Everyone else is a chicken, because they’re not accountable for the project. Their opinions are distracting and thus damaging to the project.
Thus customers–people who ask for and pay for the product–are not part of the team, nor are the people who manage humans on the team. In Scrum, these people are absolutely not part of what we’re trying to accomplish, and they are to be silenced during parts of the development process.
Of course I understand why the rule exists. There’s always a loquacious manager or sponsor who wants to hear their own voice, or worse, insist that the team work “their” way. Understandably, we should want to minimize such distractions.
Unfortunately, the remedy goes too far, substituting command and control for the core agile value of communication. The rule is borne out of excessive personal bias: In the above-linked blog post, Sutherland says, “Whatever we call them it should have a negative connotation because they tend to sap productivity. They are really suckers or parasites that live off the work of others.”
Gee, how do you really feel?
Some distaste between management and development is normal, but this stance isn’t at all helpful. Knowing that deeply caustic bile is part of the foundation of pigs and chickens only affirms my belief that it’s a damaging practice.
XP embraces the wonderful value of courage. The simple XP solution would seem to be: Ask the disruptive people to stop. Talk about it. If you can’t figure out how to do that, you have more serious problems that a contrived rule is not going to solve.
People are not chickens. Calling them such is demeaning, even if you have a cute, cloying story to back up your attempts to control. A simple statement or two can make things clear: “This meeting is intended to help ensure continual progress on our commitments to delivery. Discussions around that are welcome, no matter who you are. Attempts to be a back-seat driver should be taken offline to our Scrum Master ™. We’ll let you know if you’re detracting from our goals.”
Ultimately, it should be obvious that any rule that silences a whole class of people is not in the spirit of agile. We should welcome contributions from those even remotely involved in our efforts. If they come at the wrong time, we can gently ask them to talk about it later. Sometimes the best ideas come from those who are not accountable.
This posting won’t keep people from insisting on the rule of pigs & chickens. That’s ok. The next time someone calls you a chicken, let them know that there is a new animal in agile. It’s the ass. The ass is the person who dictates how things must be. They are stubborn, controlling animals. Perhaps the best thing to do with an ass is to give it a good swift kick.
Jeff, I agree with you and applaud this article; however, I think we do need a Novice Rule to follow while we tend to the larger issue of “why does Tony insist on hijacking our Daily Scrum three times a week?” I think “Only these people may talk, and those other people must wait until the meeting is over to raise their concerns” constitutes a valuable Novice Rule for groups in disarray to try to follow when they start trying to put Daily Scrum to practice.
The “chickens” and “pigs” thing is just too often hurtful to be widely useful. The irony is that to get away with calling each other “chickens” and “pigs” generally requires a level of trust that groups use the Novice Rule to try to attain: trust that everyone will have a chance to speak, trust that everyone will honestly discuss how their work is going, that kind of thing. Calling each other “chickens” and “pigs” early on sours the development of that trust relationship.
I’m glad “chickens” and “pigs” works for some, but after I told that story twice and saw the looks on people’s faces, I stopped.
Just got referred to this post Kevin Schlabach, he left the note on the extremely similar themed message I blogged yesterday.
In summary, my post says (not literally of course) “I agree with you!”
The “ass” is a great, and appropriately lighthearted addition to the story. Love it.
Of course, I’m glad to have the opportunity to also see J.B.’s [as usual] insightful counter-point on the topic. And to think, the irony, I basically first learned XP from JB! 😉
While it is fair to say it might help in some ways, as a Novice Rule, the real punch-line of my entry is sorta the counter-counter-point that it injects too much of a largely irreversible negative “us vs them” undertone into the culture to be worth the possible benefits.
Anyway, just wanted to say great article!
ps// in case you’re interested, my posting.
The Scrum Yahoo! group is again undergoing some minor turbulence about proper use of the list. Someone from the Scrum Alliance laid out the law with a number of rules about what could and could not be posted to the list. Many people reacted poorly–supposedly this is the poster’s first post, and he’s not even a Certified Scrum Master (CSM). (gasp!)
Oddly, a year or so ago when there was similar agonizing over the use of the list, it appeared as if L. Ken Schwaber “owned” the Yahoo! group and thus controlled(an important word in the Scrum community) appropriate content. Not that there’s anything wrong with that. For those who like command & control, with the additional potential of being part of a good multi-level marketing machine, the Scrum system provides a wonderful starting point.
The nice thing is that you can still do Scrum and talk about Scrum without succumbing to the controlled community that is S©rum. As far as I know, there’s no licensing scheme required to be able to say, “I’m doing Scrum.” And that’s exactly what I’d recommend. No annual maintenance fee required! No required trainer tiering! Yes, you need a Scrum Master in order to successfully execute Scrum. But I don’t believe they must be “certified.” (I could be wrong–perhaps I need a lawyer here!)
Where might you find a good Scrum Master? Well, you should probably read L. Ken Schwaber’s book, Agile Project Management With Scrum (that link is my piece of the Scrum machine’s gravy train, by the way). You’ll quickly discover, through a number of case studies that L. relates, that Scrum and S©rum are mostly a matter of executing to common sense, best done by someone with good experience in people-oriented problem solving and leadership. Find someone who can do that well, and hire them. It really doesn’t matter if they’re a CSM.
Today, I received the following post on a few of my Yahoo group lists (refactoring, scrumdevelopment, etc.):
I apologize for the spam, but I wanted to share with you a new initiative on the web to help large organizations make the transition to agile. I have been working with several customers over the past few years, and their biggest complaint to me has been about scaling up their agile transition when it’s so expensive to find genuine agile experts. So many people have jumped on the bandwagon last year!
So we have joined forces with some large organizations, many of which you’d recognize, to take that first important step towards solving this problem. In the spirit of being agile, our first presence is small, but we’re growing it incrementaly, so I hope you will show us your support.
Please visit http://www.agilecertificationnow.com to become certified and spread the word. It’s easy!
I highly recommend clicking through the certification links. You’ll also find a good letter from Tom DeMarco (which looks to be written in 1998) that talks about the value of certification.
Anyone who knows me knows that I have a good sense of humor. I’m usually the one in the back of the meeting room, making wisecracks and trying to keep a spirit of levity.
The Scrum(TM) development list this weekend has been rife with accusations about other people’s senses of humor. This is in response to Ken Schwaber, one of the Scrum founders, having promoted a secret handshake (which apparently is supposed to be accompanied by wolf howls).
Almost everyone has a sense of humor. What’s also true is that almost everyone has something for which they don’t have a sense of humor. In other words, they find offense in attempts at humor around these elements.
The best we can do is accommodate these peoples’ sensitivities. It doesn’t mean that we should stop doing the things that these people find offensive. If that were the case, half of human conversation would need to cease. Some people are just touchy about everything.
No, what “accommodate” means is that we don’t go out of our way to force our “senses of humor” on others. Telling dirty jokes in front of a religious person, when we already know better, is doing likewise. Making everyone howl like a wolf or touch one another in some potentially inappropriate manner is forcing our sense of humor. Simply put, it’s about showing appropriate respect. (Some people don’t find humor in anything–we best show these people respect by avoiding them, I suppose.)
I’m not offended by the whole thing, but I do find the whole “great loyalty oath” aspect of Scrum embarrassing. Not necessarily for the participants, but the for the whole of the “agile movement” (no, it’s not that kind of “movement”–that’s probably inappropriate humor, isn’t it?).
One thing that agile gets criticized for is the fanaticism of its proponents. I know, because I’ve been accused of being a fanatic. It’s an odd accusation, because anyone who has ever listened to me has heard me temper my statements, and suggest that these agile things we find valuable aren’t for everyone.
In any case, I have a hard enough time defending agile concepts to people who view them as childish and unworkable. This sort of unnecessary posturing just makes it all that much more difficult.
I do need to pause here and give credit to Mike Cohn. In his posting, referenced above, he explains it as “If we do something silly and a few people woof along with me, everyone remembers it”. I think that’s the right attitude. Unfortunately other peoples’ fascist tendencies (such as the other poster referenced above) lead them to look upon with disdain people who don’t feel like participating. We are branded as humorless and ostracized from the group.
I guess I don’t have the “right” sense of humor. My response, guaranteed to offend at least a few people, is at http://groups.yahoo.com/group/scrumdevelopment/message/19947.
We can do better. Instead of being indignant because someone dared resist the tide, we should look to find out what is turning them away. Instead of adding things to agile methods that are divisive and exclusive, what if we just concentrated on how to get teams to work together well? It’s really how great software gets produced.
“The important thing is to keep them pledging,” he explained to his cohorts. “It doesn’t matter whether they mean it or not. That’s why they make little kids pledge allegiance even before they know what ‘pledge’ and ‘allegiance’ mean.” – Catch-22