This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2006/10/chickens-pigs-and-really-inappropriate-terminology.html
The only way to change something in a a workplace is to get organized. Go on a strike and demand that the derogatory naming scheme is removed.
The problem is that you seem to accept just about any stupid thing from you “bosses” over there.
I can’t ever imagine anyone over here accepting to be called pigs and chickens on the morning meetings.
I am sure you are able to see the essence of the matter, please get familiarity with the context for the words, you can use whichever words work best for your project context, as soon as the essence of the original context remain, you are taking value from Scrum.
I’ve been working with scrum for the last 6 months or so, and really like it.
I have wondered though if the “inappropriate” names are done intentionally - agile methods are not supposed to be taken as law, they should be adapted to fit the needs of the group using them. As such, maybe this is an indirect way of forcing the adopters to think of the process in their own context as opposed to using it word for word?
Or maybe I’m just reading too much into it
It would be great if you could devote a blog entry to this:
“I have a deep respect for project managers* who nobly throw themselves on meeting grenades so the team can actually get work done. The number one goal of any competent PM is to shield their team from as much of this organizational overhead as possible.”
What the heck? This is one of those things where I just shake my head and question whether or not I should even attempt to understand why people do the things they do in this world. I’m afraid I wouldn’t last long at your company, Jeff, because during one of your ‘daily scrums’ I’d stand up and say, “look, dude, I’m not chicken, you’re not a pig. This is a company, we’re making a product, and if I need to put on a funny hat, or face paint, or change my name for the sake of some ridiculous concept then please allow me to make my way towards the nearest exit!” I mean, come on, why this need for ultra-labeling, ultra-defining, ultra-structure? Yes, software development is hard, it’s complex and there is a known history of failure, but, the same goes for the concept of democracy and that doesn’t mean that socialism or communism is the answer. I have now finished my rant.
I’ve always said that semantic analysis should be a required course for anyone in IT. Not only can the words used identify the conceptual context of the speaker, but selecting terms creatively can evoke a conceptual context for the listener.
For instance … want to make sure your extensible application never gets extended beyond its intended scope? Make sure all your terms imply a context in which the correct scope is required for them to make any sense whatsoever.
And it’s useful to be able to identify when other people are using language in order to manipulate your own state of mind. The pigs/chickens dichotomy just sounds like yet another technique “those who must lead from behind with a whip” must use to make sure their 35-year-old bachelor developers with no hobbies or home life continue to put in 100 hours a week in order to save an understaffed, underallocated project.
It seems the “chicken” are the most offended by the terms “pig” and “chicken”! ;o)
the browser i have used for the last six years now is the best multi-tab browser in the world. it is called ‘crazy browser’ and thanks to that stupid stupid name i have never convinced anyone else to use it. and yet it’s the best.
names matter. like what if instead of jeff your name was janice. i for one would think of you differently.
Relax folks… It’s just a name, and when I was involved in Scrum, we didn’t use any of that.
The real difference for us was having monthly (approx) shoft term deliverables, and the daily standup meetings that set the tone.
and maybe I’m lucky/unlucky in that I’ve rarely gone to a meeting with ‘spectators/chickens’. Usually our meetings were with the small team, or sometimes included outside help, or even the customers.
Have you ever tried to lay an egg? It’s actually pretty hard work.
This is a company, we’re making a product, and if I need to put on a funny hat, or face paint, or change my name for the sake of some ridiculous concept then please allow me to make my way towards the nearest exit!
In other words:
This is a company, we’re making a product, and if I need to put on a suit, or tie, or use a professional title, for the sake of some ridiculous concept then please allow me to make my way towards the nearest exit!
Really - what is the logical difference other than the fact that one set of concepts is new and the other is old?
So let me get this straight:
If I’m not willing to give up my life or health for the project, I’m excess overhead.
My day starts when I’m done work. I’m not going to work 50-60+ hours a week to satisfy the ego of a sociopathic homewrecker. If he knew how to allocate resources, then nobody would have to work overtime.
We’ve all read how you’re just not productive after a certain number of hours. You go to more meetings, you read more /. and CH, and your work is always - without exception - piss poor.
“People who are not committed to the project and are not accountable for deliverables at the meeting do not get to talk [at the daily meeting]. They are excess overhead for the meeting.”
Then why are they there? Seriously, this has got to be the most ridiculous thing I’ve ever heard!
Some of these comments show an impressive capacity for overreaction.
“If I’m not willing to give up my life or health for the project, I’m excess overhead.”
That’s not what “committed” means in terms of these meetings. “Committed” means “I am one of the people who is producing something that is being discussed”. The opposite is “I am at this meeting to hear about what is being discussed because it may affect me indirectly.”
For example, say you’re having a cross-functional review of a design for an upcoming feature. The “pigs” are the designers and implementors; the “chickens” are people like QA (who need to know what’s coming down the pike so they can get their test plans ready), the Tech Pubs people (who will eventually need to document the feature), etc.
In a test plan review, the “pigs” are the QA folks who have written the test plan or will be carrying out the work; the “chickens” might include the developers whose software is being tested.
Both have a reason to be there; Scrum tries to make sure that their roles in the meeting are understood ahead of time.
@ Matt V
Really - what is the logical difference other
than the fact that one set of concepts is new
and the other is old?
Limiting the involvement of people who 1) Don’t have enough information to make useful contributions or 2) Aren’t tied to the success or failure of the project, is not a new idea. And there’s already a decent name for people who are involved: stakeholders.
The logical difference between the two sets you point out is that one (suit, tie, titles) were designed to promote professionalism within the workplace. Something that slang derogatory names based on (inside?) jokes hardly makes an effort in doing.
The effectiveness of suite+tie+titles in promoting professionalism is an entirely other discussion.
And I wonder: how do you diplomatically break
the news to a chicken that thinks it’s a pig?
Bingo. It’s easy when the chickens know and accept that they’re chickens. This is where assigning names to projects (and roles within those projects) can make a difference. There’s nothing like a good old fashioned org chart to tell you in a very impersonal way that you’re better off not attending a meeting.
Tim Lesher writes:
“If I’m not willing to give up my life or health for the project, I’m excess overhead” [is] not what “committed” means in terms of these meetings. “Committed” means “I am one of the people who is producing something that is being discussed”. The opposite is “I am at this meeting to hear about what is being discussed because it may affect me indirectly.”
This has an accountability problem. I am on the hook for a project coming online sometime soon enough that I am feeling pressure. If the guy who works on ‘service I intend to use’ or ‘service that my project replaces’ comes to one of our planning meetings, I damn well expect him to tell me if we have wandered into the weeds. I would really like to know sooner rather than later.
“For example, say you’re having a cross-functional review of a design for an upcoming feature. The “pigs” are the designers and implementors; the “chickens” are people like QA (who need to know what’s coming down the pike so they can get their test plans ready), the Tech Pubs people (who will eventually need to document the feature), etc.”
If the design for the feature adds something that is impossible to test, or that will not be documented in time for shipment, wouldn’t you rather know early enough to make the change? Sure, it might be nice to wait until the Test Plan Meeting, but if the test plan guy has a real, substantive objection, then that creating that test plan meeting might just have become his action item.
We have all sat in meetings with too many people, or people wandering off the agenda. A good meeting facilitator can judge, on the fly, whether an interruption indicates an off-line discussion, a ‘schedule a meeting’ action item, or an addition to the agenda. That is what they are there for.
And if someone belongs in a meeting, then they should be paying attention, and should contribute as needed, even if they are not delivering anything. If they do not belong there, then someone in authority should talk over why they do not belong there.
Insulting terminology, especially that which encourages a ‘Death before Delay’ mindset does not help us act professionally.
Aside from the chicken and pig argument, I don’t agree that meeting ‘spectators’ are overhead. If they’re there, and they can keep their freaking mouth shut, it can provide a desired depth to their experience in the company.
For instance, I used to abandon my desk in the IT department and attend a “production team” meeting; I never spoke up in the meeting, but I was listening for ways that my department could help theirs.
Of course, this was a stand-up, every day, 10 minute meeting, so it was heavily ‘facilitated.’ I’ve had to sit in on the other kind of meeting too :S
I’m regularly involved in meetings (and have been over the past five or so years that I’ve been a dev lead) in which the “eavesdroppers” outnumbered those doing actual work by eight to one. It wouldn’t be so bad if they were just evesdroppers, but just about any random meeting attendee can derail a meeting, and those with no vested interest in a productive meeting seem to love to derail it just to “make their mark”.
I think Jon’s experience cuts to the heart of the debate. The role of the PM (or ScrumMaster) is to protect the team-- and that means keeping (and enforcing) observers silence during this period.
This effect is particularly dangerous for a Daily Scrum meeting, which is supposed to be a tight, daily 15 minute affair. You can imagine the effect on a team if the “daily” meeting balloons to 45 minutes or an hour. So the timeboxing has to be strict.
As Sutherland points out, these people are welcome at the (roughly monthly) sprint retrospective meetings, where they can speak and provide input for the upcoming work.
But still, we can get rid of the ridiculous pig/chicken nomenclature. It just gets in the way.
I wonder what Steve Yeggi would say about this