Here's a description of the daily Scrum meeting in the Scrum process:
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
Here's a description of the daily Scrum meeting in the Scrum process:
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.
-E
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.
Riiight.
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.
@Jeff
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.
Quoting again:
ā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.
Scott
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