Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling
 
PerlMonks  

Comment on

( #3333=superdoc: print w/ replies, xml ) Need Help??

Chairman: I’d like to call this meeting to some sort of order, if that is at all possible.

Ford: Look! C’mon please! I mean everybody! There is some important news: we’ve made a discovery.

Management Consultant: Is it on the agenda?

Ford: Oh don't give me that!

Management Consultant: Well I’m sorry, but speaking as a fully trained management consultant, I must insist on the importance of observing the committee structure...

Chairman: Listen! I would like to call to order the five-hundred-and-seventy-third meeting of the colonization committee of the planet of Fintlewoodlewix. And furthermore...

Ford: Oh this is futile! Five-hundred-and-seventy-three committee meetings and you haven’t even discovered fire yet!

Management Consultant: If you would care to look at the agenda sheet ... you will see that we are about to have a report from the hairdressers fire development subcommittee today.

Hairdresser: That's me.

Ford: Yeah, well you know what they’ve done don’t you? You gave them a couple of sticks and they’ve gone and developed them into a pair of bloody scissors!

Marketing girl: When you have been in marketing as long as I have, you’ll know that before any new product can be developed, it has to be properly researched. I mean yes, yes we’ve got to find out what people want from fire, I mean how do they relate to it, the image...

Ford: Oh, stick it up your nose.

Marketing girl: Yes, which is precisely the sort of thing we need to know, I mean do people want fire that can be fitted nasally?

Chairman: Yes, and, and, and the wheel. What about this wheel thingy? Sounds a terribly interesting project to me.

Marketing Girl: Er, yeah, well we’re having a little, er, difficulty here...

Ford: Difficulty?! It’s the single simplest machine in the entire universe!

Marketing Girl: Well alright mister wise guy, if you’re so clever you tell us what colour it should be!

-- from Hitchhikers's Guide to the Galaxy (Prehistoric planet, scene 7)

Meetings. Bloody meetings. There's no avoiding them. I've attended all sorts of meetings over the years. Some good, some bad. Many companies decree that an agenda be circulated to all attendees well in advance of any meeting and that minutes be sent to all partipicants promptly following the meeting. Others are less strict. How does your company do meetings?

The Scrum Daily Meeting

Scrum prescribes a fifteen minute daily meeting. The rules for my first Scrum daily meeting seemed simple enough:

  • The meeting happens at the same location and the same time every day.
  • The meeting must start precisely on time.
  • The meeting is timeboxed to 15 minutes.
  • Anyone is welcome to attend, but only "pigs" may speak.
The (strict) meeting agenda is for each team member to speak in turn, answering three questions only:
  • What did you do yesterday?
  • What do you plan to do today?
  • Do you have any impediments?
The ScrumMaster ensures the meeting runs according to the above rules, and is further responsible for ensuring that impediments are removed. Sounded simple enough. However, I soon discovered that running an effective daily meeting is surprisingly tricky, there being many "subtleties" to consider.

Subtlety No. 1: When to hold the Daily Meeting?

The first subtlety was that my team was instructed to hold their daily meeting at an allotted (early) time slot, so as "to start the day with an energizing meeting" and not clash with the daily meetings of other teams, thus allowing high level managers to attend all the daily meetings. We were less than thrilled with our "early bird" time slot, most of us being "night owls". On principle, I felt we should schedule our daily meeting at a time and place that suited us. After all, the daily meeting is primarily for the (empowered, self-organizing) team, not the managers.

Good Stress, Bad Stress

As you might expect, the early meeting time slot was causing some unwelcome stress within my team. Sometimes a train was late or cancelled. On other occasions, family duties, such as taking a child to school, caused team members to be late or even to miss the daily meeting. And this stress was not reduced when agile coaches proposed the imposition of humiliating punishments or fines for being late to the daily meeting.

On one occasion, an overweight team member (let's call him Taffy) with a family history of heart disease just made it to our daily meeting in the nick of time -- but only by sprinting from the train station. Taffy was red in the face, puffing excessively, and looked quite unwell to me. I thought he might even suffer a heart attack. Now he's a lovely guy and a first-rate programmer and it upset me to see him being subjected to such unnecessary stress. Like cholesterol, there is good stress and bad stress. This was definitely bad stress. This is an office job, not the army. After seeing my good friend suffering like this after his train was delayed, I got pretty worked up. This was insane! It's not worth endangering your health to arrive at work five minutes earlier. I lost the plot a bit at the daily meeting and our team was thereafter allowed to choose our own time slot. We chose just before lunch. This worked very well; it eliminated the bad stress, and it became very rare for anyone to be late to our daily meeting again. Moreover, holding the meeting just before lunch minimized harmful context switching because we broke for lunch as soon as it ended.

Subtlety No. 2: Is it a Meeting or a Ceremony?

The second "subtlety" arises when senior managers, with the power both to fire and grant generous pay rises, attend the daily meeting. When that happens, in my experience, instead of honest and direct team communication, you get a surreal form of theatre, with each performer on the stand-up stage trying to look good (or at least not foolish) in front of the (intimidating) bigwig audience.

To mitigate this less than totally honest communication, most of our teams took to holding a second "team only" daily meeting where they could communicate more openly and without fear.

Dogmatic Pigs and Chickens

I'm reluctant to assert this was anyone's fault. After all, it's only natural to want to look good in front of someone powerful enough to fire you or grant you a pay rise. All the senior managers behaved admirably, following the standard Scrum daily meeting rules, namely:

Team members should address the Team. This is not a "Reporting to the ScrumMaster" meeting... Chickens (non Team members) are welcome to attend the Daily Scrum Meetings but they are not allowed to talk, make observations, make faces or otherwise make their presence in the meeting obtrusive.

-- from Daily Scrum Meeting Rules

Very rarely, a manager "chicken" couldn't stand those damned rules any longer and spoke up, offering well-intentioned (and often helpful) advice to the team. Generally, I feel that Scrum contains too much dogma -- which often leads to heated and divisive argument, in my experience. Accordingly, I doubt any great harm would come from relaxing the dogmatic "pigs and chickens" rules. Certainly, I didn't mind when "chickens" had something to say at our daily meetings. On the contrary, it was often useful and insightful, helping more than harming, IMHO.

It's advised by Scrum that during the Daily Stand-up (or "Daily Scrum") only pigs are allowed to speak, chickens can listen in but can't speak. While I understand, and even support, the intention of this - I really despise it.

Unfortunately, what commonly happens in many instances is that the team sees themselves as the "pig" and all of management as their "chickens". The team "goes scrum" and all of a sudden Chicken/Pig cards are flying left and right. "You can't speak at our stand-up!"..."You can't come to our retrospective!"..."You can't tell us how to organize our cards!" ..."You can't... go away... you can't...leave us alone...you can't you can't you can't...". Essentially, the team tells their managers to take a hike. Now, while a renegade team shunning their manager may in the luckiest cases represent an improvement over Command and Control, it's a far cry from what we mean by Empower and Support. In a nutshell, a "chickens & pigs" attitude ultimately begets nothing more than an "Us versus Them" culture. Uggg. What we really want is simply an "Us" culture, no "Them". Remember "People & Interactions"?

-- Don't like Green Eggs and Ham Mike Bria blog

Update: The Scrum Update (July 2011) has removed all references to Pigs and Chickens. The reasons behind this decision are discussed in the "Chickens and Pigs" section of the Scrum Guide Updates where Steve Porter further elaborated that:

The labels were being used to create barriers between the Scrum team and individuals in the organization who potentially could assist the team in meeting its goals.

Subtlety No. 3: The Importance of a Good ScrumMaster

You will have, if you use Scrum, someone on each team whose name is, it's called the ScrumMaster, also known as "The Prick". And this person's job is to make sure that you don't cut quality. D'oh. And they have no authority but they, what they can do is if we've defined that an increment has a certain level of quality for it to be demonstrated to our product management, their job is to make sure that quality's there. And if the quality isn't, not to let you demonstrate it, but instead to say to the product manager, "Hmph, we lost our heads, we're not done, it's gonna take us another month to finish this".

This person is probably the least loved person in the world because they stand right at the nexus between product management believing that any amount of stuff can be done and our willingness to help them cut quality to support that belief.

The burnout rate on these people is usually, like, 13 to 14 months. Throw 'em away. We often get them from hopeless, professional areas like QA. People in QA are used to doing incredible things with no authority, no respect, and no hope of success, so that's where we take these people.

-- Ken Schwaber, Google tech talk on Scrum, Sep 5, 2006 (46:34)

As indicated above, the ScrumMaster is a tough role. Some ScrumMasters are good. Others clueless. Yet they all attend the same two-day course to become a "certified ScrumMaster".

I see the ScrumMaster role as a chronic weakness of Scrum; you either get effective ScrumMasters who burn out in "13 to 14 months" (Schwaber) or ineffective ones who just go with the flow and never push back on quality. It's a great marketing and money-making device though, with certified ScrumMaster courses that can only be run by certified ScrumMasters.

Rather than a dedicated specialist ScrumMaster, I suggest that the daily meeting be run by the team, with each team member, in turn, running the daily meeting. This mitigates the (single point of failure) risk of an incompetent ScrumMaster while creating a vibe of inclusiveness and making it less likely for an individual personality to dominate.

Subtlety No. 4: Using the Daily Meeting as a Control Mechanism

What made the meetings most painful was my boss (I'll call him Wally) ... For Wally, the stand-up meeting (like the 7 a.m. Monday meeting and the 5 p.m. Friday meeting) was a loyalty test designed to reinforce the employer-employee relationship.

Restricting team interaction to 10- to 15-minute snippets is artificial and suggests disconnection and coldness. The 15-minute meeting conveys an explicit message: “Let’s keep it short and to the point”. But there is another, more subtle, message: “We can’t waste time socializing; just deliver the facts.”

I think there is something wrong with a meeting held standing up. Standing is inherently onerous. It is used for punishment in schools and in the military: “Stand in the corner,” “Stand at attention,” etc. Standing has an implicit element of authoritarianism and theory X control (which asserts that people will respond only to threats).

The point is, in the hands of an authoritarian manager or in a hierarchical, command-and-control environment, the stand-up meeting can become a weapon.

-- Why I Hate Stand-up Meetings by Phillip A Laplante, Penn University

Three simple rules can help alleviate Laplante's authoritarian concerns:

  1. Call it a daily meeting, not a "standup" meeting. By all means, time-box it, but don't demand that everyone stand. Apart from the undesirable authoritarian overtones pointed out by Laplante, demanding that everyone stand discriminates against those with specific medical conditions. Moreover, strictly demanding a process in which "all people must stand" violates the agile principle of "individuals and interactions over processes and tools".
  2. The time and place of the daily meeting should be decided (without coercion) by the whole team, not by a command-and-control manager (see "Subtlety No. 1" above).
  3. The daily meeting should be run by each team member in turn (see "Subtlety No. 3" above).

Daily Meetings: "Add Value" or "Coordination Cost"?

I have discovered that many people have trouble identifying wasteful activities. I have seen, for example, Agile advocates argue that daily standup meetings are value-added. I do not subscribe to this view. I cannot fathom that a customer cares whether a team holds standup meetings or not. What the customer wants is functionality that enables their goals, delivered in a timely manner with high quality. Whether or not a team needs to hold daily standup meetings to enable such delivery is neither here nor there from their perspective.

When you ask Scrum advocates who vehemently argue that daily meetings are value-added, whether they would hold the standup twice daily or whether they would lengthen it from 15 minutes to 30 minutes, they will surely reply, "No!". "Well, if standup meetings are truly value-added", I reply, "then surely doing more of them would be a good thing!". This is really the acid test that demonstrates the difference between a truly value-added activity and a transaction or coordination cost. Developing more customer requirements is clearly value-adding. You would do more of it if you could and the customer would gladly pay for it. Planning is clearly not value-added. The customer would not pay for more planning if he could avoid doing so.

-- Kanban book by David Anderson (p.215)

At the risk of taking this to a pointless Room 12A battle between Agile and Lean advocates, I agree with Anderson that daily meetings are indeed a "coordination cost". Accordingly, following Lean principles, each team should reflect on how to minimize the time and energy spent on them and how they might make them more effective. While I personally feel that team daily meetings are well worth the cost for most teams, there are many pitfalls for the unwary, as indicated above.

Other Articles in This Series

References


In reply to Nobody Expects the Agile Imposition (Part V): Meetings by eyepopslikeamosquito

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":



  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • Outside of code tags, you may need to use entities for some characters:
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.
  • Log In?
    Username:
    Password:

    What's my password?
    Create A New User
    Chatterbox?
    and the web crawler heard nothing...

    How do I use this? | Other CB clients
    Other Users?
    Others lurking in the Monastery: (6)
    As of 2014-09-21 06:09 GMT
    Sections?
    Information?
    Find Nodes?
    Leftovers?
      Voting Booth?

      How do you remember the number of days in each month?











      Results (166 votes), past polls