Scrum replaces the Pointy Haired Boss with Scrum Master Jar Jar
Despite all the mystique, the “Scrum” meeting itself is nothing more than a Stand Up Weekly Staff Meeting. Except Daily.
And you thought being a Stormtrooper was hard. Let’s tune in now as the Scrum Master Jar Jar asks the 3 questions.
Scrum Master Jar Jar: “Meesah wanna know, What did yousa do yesterday?”
Hog: “I ran around in circles trying to accomplish a user story and then I gave up because the tests failed and the code smelled like a bantha.”
Scrum Master Jar Jar: “Meesah wanna know, What will yousa do tomorrow?”
Hog: “I will start fresh and try running a different direction this time and also try to pair with a more intelligent hog.”
Scrum Master Jar Jar: “Meesah say, Muy Muy Excellent! And is anything impeding yousa progress?”
Hog: “Well, the fact that I’m running around like a roomba, using XP seems like an impediment.
All of these Scrum meetings seem to be use a lot of valuable time, that I could use to discuss issues with my team members directly. I feel if we had more serious meetings to talk about the interfaces and dataflow that would be helpful.
Also I think having a concrete specification and tangible goals would be handy.
Why do we even have these Scrums in person? Any simple webform-protocol droid could ask us these questions and we could fill in the answers.
I don’t see why it takes a Scrum Master to do that. And it would save 2.5 hours per person per week! That’s 22.5 man hours among our 7 person team per week! Surely there is something more productive than listening to each person give 1 minute answers to 3 simple questions?
How much information can you really get in 1 minute of speech that you couldn’t get out of a 2 line email?
And for $1700 I think we could have gotten a ping pong table and a beer cooler. If we played pingpong 30 minutes a day, we’d be more effective programmers. ”
Scrum Master Jar Jar: “Meesah say, we too busy sprinting to discuss such things. Scrum is Hard. We appreciate yousa sacrifice. Stay the course.”
Hog: (kneels) “Yes, My Master.”
.
If you enjoyed this article please see the rest of my Scrum/XP articles
especially Agile as Communism and
Embracing Failure
The Practice and Art of Software Composition 
LMAO,
I enjoyed this thoroughly, whilst I do not quite agree with the sentiment behind some of the comments of your “headless chicken”.
The face-to-face of a scrum can yield insight that might not surface whilst talking to a “web-droid” a.k.a email/web form; yet I have found if all members of the scrum bring a Word document (printed!) with answers to the stock Jedi’s questions, they have already invested thought in what they have done, will do and what is keeping them from achieving their goals. Let them not play ping-pong.
My sincere thanks for a Sunday morning belly laugh.
Dan
Thanks a lot Dan; I did some slight “refactoring” the chickens are hogs now (so it’s more compatible with Scrumtoons and I won’t get the inveitable — WhyArentTheyHogsAndDontConfuseUs…)
also they aren’t (described as) headless anymore.
But he now explains how you can find lots of time for your team to play ping pong check it out.
Hrrm Printed Word Documents!!!…You must not be practicing Orthodox Scrum…. Yes… There is hope for this one… 🙂
SoftwareMaestro
Mee-sa happy to help!
The Word documents never get seen by anyone else other than the creator … unless I do a spot check … but it does enforce more than 2 seconds thought on the issues/achievements etc.
Keep the posts coming … experience shared ‘n all!
Kindness,
Dan
Pingback: JEDI » Blog Archive » links for 2007-07-02
Pingback: Funny anti-XP/Scrum blog - Jeremy D. Miller -- The Shade Tree Developer
Hundreds of people have read this post; many without commenting. Don’t be shy — say something!
SoftwareMaestro
Funny post, but I’d like to comment on a few things.
First, I think question two should be “Meesah wanna know, What will yousa do today?”
Quote: “All of these Scrum meetings seem to be use a lot of valuable time, that I could use to discuss issues with my team members directly”.
Standup meetings are not just for project manager to member communication. It’s also for communicating amongst the members of the team. The “And is anything impeding yousa progress?” can bring up issues that other team members know how to solve, but without the meeting they would not even have known about the problem.
Standup meetings each day further:
– push members on flexi time to at least be at work at the specific time
– makes it akward for a team member to say the same thing on each meetings and makes it embarrasing to not solve an issue (may cause people to stop spending their time on other things)
– spread knowledge about tasks around the team
erlandico:
You are indeed correct that he should say “What will yousa do today?” I noticed that myself a day or two ago and was wondering how long it would take for someone to notice.
I thought about fixing it, but, hey, it’s Jar Jar! It sort of fits his character.
Congratulations on being the first poster to notice that.
(There is another secret in the way the Hog phrases his questions poses a unique challenge for the Scrum Master: can you figure out what it is?)
As far as pushing members on flex time and making it awkward to say same thing — this seems like personnel control issues and not programming issues.
It seems on the one hand Scrum expects the team to “self organize”, yet at the same time, Scrum doesn’t trust the team and wants them present at the same time, these public confessions/whippings/promises, etc, as you describe.
If the employees are no good fire them don’t just treat them like children. Does that make sense?
The “don’t trust the team but let them self organize” is confusing to me about Scrum.
In the meantime please check out this article https://softwaremaestro.wordpress.com/2007/07/02/does-xpscrum-violate-the-agile-manifesto/ Which discusses the “social control” aspects of Scrum more.
Thanks for your comments 🙂
Software Maestro
Also what the Hog means by “use the time to discuss issues with my team members directly” he means that, instead of listening to everyone say their 3 minute piece, and have everyone there, that it’d be more productive to NOT be in the daily scrum and just (in a self organizing way) interact with THOSE TEAM MEMBERS directly that he needs to in order to accomplish his tasks.
Most companies have gotten away with weekly versions of these scrums for decades if not centuries and that frees up much time for the smaller, more focused meetings that the Hog proposes
Also, “if someone states a problem, then maybe someone else can fix it, but without the meeting they wouldn’t even know” (paraphrased) — I find this very hard to believe, that if someone has a problem, and they know someone else on the team has expertise in that area (and they SHOULD know given how often they pair, communicate, etc), that they can’t ask that team member directly and would have to wait until tomorrow’s scrum to bring up their issue and hope for a solution?
That is such a dichotomy about scrum; on the one hand, the team is supposed to be self organizing professionals, on the other hand they get the kindergarten treatment and let’s everyone hold hands….
Which is it? Are they professionals or do they need DAILY group meetings so they can say what is on their minds because they are unable to network with appropriate teammembers themselves?
If the team was organized into “squads” with each squad a module, then the squad members would only need to meet with themselves and occasionally the squad leaders would need to coordinate. This is far more scalable than the Scrum way which makes everyone horizontal even if their job functions are mostly unrelated. Eg, assuming there is a DB layer and teh GUI layer, and improvements are made to each (performance, eye candy) but the interface never changes, those groups really don’t need to talk to each other which is what the hog is pointing out.
Software Maestro
You can’t expect all team members to know all previous tasks and projects of the other team members. By flagging an issue in a scrum meeting, a team member can get help from someone he did not expect.
Of course there is nothing in scrum that prevents a team member from discussing issues directly with others outside the scrum meeting.
Also I don’t see organizing teams in squads as an alternative to Scrum. In 50 person team I would never use scrums with all persons present. I would organize the teams in squads, as you suggest, and then use daily scrums for each team (GUI team daily scrum, DB team daily scrum etc.).
I dont see why a 7 person scrum team WOULDN’t be working in squads.
What are these 7 people doing? If they are all working on the back end code, maybe they can be horizontal, but if they are working on gui, db, back end, middle tier… that sounds like squad time…
S.M.
Pingback: Top Posts « WordPress.com
Pingback: Agile Dogma « Mendelevium
Pingback: Musings of a Software Development Manager » Blog Archive » Jar Jar Standup Parody
Funny article but can’t say I agree. At my previous company, developers and business analysts did not speak to each other much – often the business analysts didn’t know which developers were developing their feature. I was a tester then and when I found discrepancies between my interpretation of the requirements and what was actually in the product, I would have to strong-arm the developer into the business analyst’s office. Lo and behold – progress was made when we spoke!
I find that the developers may communicate daily on design issues and such, but getting product development staff to speak across departments is tougher. Scrum makes you to do this.
Also, my previous company had product development offices in Boston and Vancouver so often the feature I was testing was being developed in the other office. A daily scrum meeting helped alot to make sure we remembered to communicate with the other office.
“I would have to strong-arm the developer into the business analyst’s office. Lo and behold – progress was made when we spoke!”
You can do that on a WEEKLY basis and not the Scrum DAILY crap basis, can’t you?
Hi Amanda… When you say “I find that the developers may communicate daily on design issues and such, but getting product development staff to speak across departments is tougher. Scrum makes you to do this.”
This seems like a baseless assertion. How does Scrum MAKE you do this? Scrum makes it possible, just like any meeting involving the team makes it possible, with or without scrum.
But Scrum “doesn’t make it happen” especially given that the team is supposed to self organize. If the teammembers don’t want to speak about something, they’ll need prodding, with or without Scrum.
If you needed to get the people together you could have done that with any methodology….
Why not try doing a few weeks with planning and organized meetings and see if you still need a daily Scrum or not.
Daily meetings are a little bit like crutches or training wheels; it might be handy for companies that have little to no organization, but the more organized and proactive the companies are, the less they tend to need the crutches and training wheels.
The only time I can see Daily Meetings being Standard Operating Procedure would be during the days or weeks leading up to a very critical release, and the team really is in crisis mode; however my opinion is that the team should not be in crisis mode all the time. But that’s for another blog entry!
Software Maestro
In response to your comment “The only time I can see Daily Meetings being Standard Operating Procedure would be during the days or weeks leading up to a very critical release, and the team really is in crisis mode; however my opinion is that the team should not be in crisis mode all the time.”
The first time (years ago) I explained Scrum to someone, she flinched and said, “It’s like crunch mode all the time.”
But it’s not. It’s a sustainable pace where you’re never in crunch time. I can say from real-life, firsthand experience, that it’s really nice.
Imagine a world in which you’re doing a critical (though aren’t they all?) release every few weeks. It’s not crisis mode, though, because you’re working in small iterations on high-priority, well understood things. You’ve got high-quality code so changes aren’t painful. You’ve got meaningful test automation at different levels of abstraction, so you aren’t afraid that you’re going to break everything. You’ve got real customer guidance, so you know you’re not building something pointless which nobody will use. You’re moving so quickly that you look forward to the daily team meeting because you want to discuss what you’ve accomplished and get guidance from the team on what to do next.
Granted, without high-quality code and meaningful test automation, it all goes to hell. It all goes to hell in traditional/waterfall/sequential development too, you just don’t see it earlier.
Martin:
Your comment can basically be summed up as:
“It’s not bad. It’s good. Imagine a world with the tooth fairy in it, and a lot of processes that come from XP and have nothing to do with Scrum.
However all these processes are working perfectly, your code is high quality, meaningful tests, etc…. And life is hunky dorey.”
There are no supporting arguments; these are baseless assertions and groundless fantasies dressed up as “the typical truth” that make up 99.99% of the “Agile literature”.
If you have some facts, feel free to post them, or if you have supporting reasoning, that’s fine too.
But the blanket statement, group backslap that makes up most of the “Agile literature” — and “Agile Websites” — “Oh aren’t we so great yuk yuk – Do agile and of course everything is perfect” is exactly what this website is about; there is no “there” there.
I’m SOOO glad to know that if I or anyone else does Agile they’ll get “real customer guidance” — as opposed to the fake kind they’d get with a non “Agile” process?
Roflmao. With all that goodness you’d think C3 would have been a success. It wasn’t. It’s all hype, and your post is typical amongst those who have drank the Kool Aid and blindly accepted a Faith Based Methodology.
It’s incredible to me that programmers, who of all people should value logic, throw it all to the wind when discussing Agile. If the code is as fluffy and logicless as the arguments in favor of Agile, no wonder the code needs constant refactoring.
Software Maestro
“It’s incredible to me that programmers, who of all people should value logic, throw it all to the wind when discussing Agile. If the code is as fluffy and logicless as the arguments in favor of Agile, no wonder the code needs constant refactoring.”
Now that one felt kind of like an ad-hominem attack. But I’m sure that a maestro such as yourself doesn’t need to stoop that low to make a point.
Re: Constant refactoring. Maybe I misunderstand the term refactoring, or maybe everyone else does. The code that I write isn’t so crappy that it “needs constant refactoring”. A lot of it (especially if I write tests for it) is good enough the first time. I do write my code in such a way that I can easily and safely change it, using well-understood techniques, if I need to change it.
Why would I need to change it? Either there’s a new feature that I need to support, or I have a better understanding of how to improve the quality of the code. By “quality” I don’t mean lack of defects, I mean highly cohesive, intentionally coupled, no reduendancy, human readable, etc.
And of course, I refeactor other people’s legacy code all the time. I don’t have the luxury of working in a vacuum.
@Cron
No it wasn’t an ad hom, at least not at you, it’s that I’m critiquing XP/Scrum/Agile AS PUBLISHED in books, etc.
Many people, yourself includeded, say “oh when I do agile/scrum/XP it’s not like…XYZ”.
That is Agile is like a virus and has morphed into many mutations, some more disease causing than others.
But I am refuting “canonical” XP etc which says “to refactor mercilessly”.
If you google for that phrase, “refactor mercilessly” you will see many Agile sites that espouse that.
They espouse that because they do so little up front design (none).
Of course if you “modify” Agile, and do more design up front, you’ll be doing less refactoring. That’s great.
A few more steps in that direction and you won’t need the Agile soup stone at all, you’ll be a full fledged programmer 🙂
Also, the Agilistas have hijacked the english language; yes refactor should mean combining similar methods, but when Agilists use it, it means any code change, from throwing out the entire code in the trash to minor tweaking..
This makes Agile much harder to refute, since it’s a virus/Jellyfish that morphs to avoid criticism, and why I stick to critiquing the “published” versions of XP/Agile/Scrum, since it’s harder for those versions to morph at internet speeds…
Also it is an Agile hallmark to make blanket statements: “Just do it”…”Agile is great…blah blah”… Why any programmer falls for that is beyond me.
I was merely pointing out that, I’m happy for pro Agile supporters to support whatever they want to, just on this particular blog, I’d like them to support the statements a bit, something that they don’t do at all on the pro Agile sites….
And if Agile wants people to take it on faith, and they seem to, I don’t see how that applies to programmers at all. The shocking thing is when people become Agile enthusiasts they start talking the same blanket statement no support to go along with it since it “feels normal” after reading all the Agilist propaganda…
It’s not personal at you, it just sounds like all the stuff that people hand out on the pro Agile sites with zero supporting facts.
I found the following quote from your blog most enlightening:
“I worry sometimes that by working at a lean-agile company, for a lean-agile company (I’m a consultant) getting training from a lean-agile company, and reading all of the blogs from the lean-agile thought-leaders, that I might succumb to groupthink. Especially when I read a perfectly good book (I’m reading Mike Cohn’s agile planning right now) and it feels like there’s no new ideas in it.”
You yourself seem to question the validity of the whole agile thing: that is a good sign! You’re right about Cohn, he has nothing much to say, along with the vast majority of the pro agile blogring that spouts the same platitudes over and over.
Perhaps you’re feeling disturbed because this website reinforces the notion that the Emporer has no clothes.
That’s a Good Thing 🙂 The first step in weaning yourself from the cult is recognizing the “group think” they attempt to impose on you, something you seem to be realizing.
Software Maestro
Pingback: Una de Scrum » Presión Blogosférica
Pingback: El Jefe de Proyecto tiene la culpa (o parte de ella) » Presión Blogosférica
Pingback: Jar Jar Binks knows nothing about Scrum | Lead, Follow, or Get Fired!
Please leavin messa out of tis, okee-day?
/Jar Jar
“Meesa wanna say yousa did a great job”
I see there are a lot of ways Jar Jar resembles the Scrum Masters I see around. Jar Jar from Naboo is honest in his ways, is not dominating at all, becomes a hero by chance and proves it, to say, fairly well. He is made a general, much like our scrum masters, and put in a role, he learns to serve well. He is saved by an Agile Coach looking Jedi warrior, is a representative in the Galactic Senate and gives a speech too. He appears to be motivating, has eyes on top of his head, which works good in most ceremonies.
Anything else is left to your imagination 🙂
Sharad:
That’s all true.
But if you continue with the rest of the story…
Jar Jar Gives a speech…exhorting the senate to elevate Palpatine with dictatorial powers….which he uses to destroy the Jedi and create the empire.
So, Jar Jar blows the whole universe by being a hapless, but well intentioned boob.
So yes quite apropros to the whole Jar Jar as ScrumMaster thing 🙂
Maestro
yep. agile – yet another job creation exercise for those individuals that cannot find a real job in I.T….
Pingback: My first impressions of…SCRUM | MarkjOwen's Blog
Pingback: Yes, Scrum Sucks, tell us your story | The Practice and Art of Software Composition
In my third week of trying to manage a QA group under scrum. In a meeting this morning, I found myself scribbling the word, “Scrumble” as in, they threw us all in this pit and left us to fight to the death for what we need to do our jobs. Meanwhile, the person who holds the key to the budget is screaming that she won’t pay for integration, end-to-end or business process testing even though it is clear she has no idea of what it is, nor what the risk and I’m not allowed to document the risks because this is “SCUM” and we don’t document in scrum. F this party-
Ha-ha! Freudian slip: SCRUM, not SCUM.
I love this site!
I’ve been a professional software developer for 20 years and have a degree in Mechanical Engineering. I’ve been working as a consultant with a group of totally dedicated (and very young) Agilistas who’ve clearly drunk the Kool-Aid. If I hear one more of these inexperienced boobs tell me that software requirements “can’t be known up-front” I think my head will explode! It’s as if they believe software development didn’t exist prior to Agile/Scrum.
Scrum is micro-management. In fact, the daily stand-up implies that you have either no trust in your developers or that they aren’t professional engineers who will raise issues without being constantly cajoled. I’m a professional. I know when I need something and whom I need to ask in order to get it. Leave me alone and let me do my job. Treating me like a child just demotivates me.