Tracking change and innovation in the enterprise software development community
Create REST
-enabled Web Apps
with Project Zero
from IBM.
Terracotta:
Scale your
Apps w/ease
Offload the DB:
Learn More!
IBM WebSphere
Virtualize apps
to lower costs,
Increase agility
Learn more!
QCon San Francisco
Nov 19-21:
+ 80 sessions & tracks
Register now
and Save $400!
Posted by Amr Elssamadisy on May 20, 2008 04:53 PM
One of the most simple and yet most talked-about agile practices is the Daily Stand Up Meeting (a.k.a. Scrum).
On the scrumdevelopment mailing list, Jeff Martin asked the group:
I have searched and can't seem to find what I'm looking for. I'm sure I'm just not using the right terms. Does anyone have a script of an example daily scrum? We are having several issues with our scrum and some team members are wanting to do away with it or change it to a twice a week thing.
That question elicited varied remarks. Marcie Jones suggests that many problems occur from (lack of) meeting facilitation techniques:
1) Don't be late yourself (duh). As a ScrumMaster, this sets a
bad example and sends the message that you don't value the
team's time, or the daily Scrum. If they don't think you value
it, why should they?
2) The meeting needs to start on time. "I'm in the middle of
something, can we wait 5 more minutes" does not respect the
team's time. If you delay routinely for these, again you are
sending the message that this session is not important, when
really it should be one of the most important parts of the day.
3) If #1 and #2 really can't happen, experiment with different
meeting times. Changing the time though will not fix the
underlying attitude issues.
4) Cut off inappropriate discussions. As ScrumMaster you get to
be the facilitator of this session, even if you are just "team
member" the rest of the day. You are allowed to ask people to
take the discussion offline, or hold it until after the general
group is finished. This can be tough at times, but be firm.
5) If the updates are too vague, ask questions. Don't just tell
them "updates need to be at the task level" or that they're
"doing it wrong". If you've been talking with them throughout
the day, ask leading questions during the Scrum, "What happened
with...", "How did you decide to handle...", "Did you ever get
such-and-such from so-and-so". The team will figure out what is
the appropriate level of detail to give over time, partly based
on what questions people ask them, or the opposite problem at
times, when eyes start to glaze over.
6) Ask your team permission to keep trying it daily for say, one
more iteration while you try to fix these problems. Promise
them that if it's not any better after that, you'll switch to
twice a week, and do it. Go from there. If you're having
retrospectives, you can always decide to switch back.
Artem Marchenko suggested that the rules of the Daily Stand Up are so simple that they won't be much help:
Minimal daily scrums are that simple that concrete script won't
probably be of much help. What you are asking for is probably more
about gestures, looks, tone and feeling of trust in that Scrum Master
(and team members) will actually help when help is needed. These
things are difficult to reflect in a script.
Scott Weber suggested a script that looks something like this (by the way, many did not agree with Scott and thought this suggestion was too much on the command-and-control side):
Scrum Master: Scot, what did you accomplish yesterday?
Scot: I finished tasks X and Y, but had a problem with Z. I think I
need Jon's help.
<< presuming Jon's availability is NOT a problem >>
Scrum Master: Scot, what are you planning to do today?
Scot: Get with Jon and complete Z, and start on AA.
[[ cycle through to the next person on the team ]]and later Scott notes:
One of the hoped for artifacts of Scrum is the self organizing team,
meaning the development team members (not all are necessarily
engineers) find their capacity for effective participation and
engagement in the team.
Along the way, several good articles discussing Daily Stand Ups were referenced. Simon Baker gives an overview of Daily Stand Ups (including the chicken and pig joke), Mishkin Bertig tells us about its dysfunctions, and Jason Yip tells us about them in pattern format.
A Daily Stand Up Meeting seems so simple in concept, but is not easy for many teams to adopt. If we were to apply our own Agile principles to Stand Ups (meta-Agile), we should be explicit about the goal of a Stand Up meeting to be able to "test" the success or failure of any particular instance of Stand Up meeting. Unfortunately, the clarity of a goal is lacking in many conversations. In this entire thread, the goals of the meeting were only brought up in passing and never discussed directly.
What are your thoughts on the goals of a Stand Up meeting? Do the implementations above all meet your goals or not?
Software Quality Survival Guide
IBM software architect eKit: Grady Booch podcast, whitepapers, articles
Scaling Agile on large teams & Being Agile every day Tracks @ QCon SF Nov 19-21
IBM Agile Development eKit: Free Articles, Expert Q&A, Educational Resources
Sometimes, what's good about a Standup meeting is just that it is daily. It's a safety net. The summary for a week of standup meetings might go like this: Monday: normal Tuesday: normal Wednesday: normal (this is getting boring) Thursday: OH MY GOSH! THE ROOF IS FALLING! THE CODEBASE IS FULL OF ALIEN LIFEFORMS! The team decided what steps to take, and discussed with the product owner which story they could remove from the iteration to compensate. Friday: normal. It's the fact that there is a daily check in that let Thursday's problem be fixed on Thursday, so the team could go back to normal on Friday. If the standup were only on M-W-F and Friday was the sprint's end, this could have derailed a whole sprint. Let's admit it: on a team with no crises, few interruptions, stable requirements (um, do you know many teams like that?) the standup turns into a wax-on/wax-off** exercise. The question is: what risk does a day's (or a week's) delay and confusion carry for this team? How important is is that they keep their promises? (Or, perhaps, why is an "all normal" standup taking more than 7 minutes?) ** reference from The Karate Kid film.
Standups are those crucial 15 minutes or less which help you get a quick health check of how the team is progressing. Do it in a wrong way and you would get less than half the benefit that was expected out of it. I tried to summarize list of 15 points for those crucial 15 minutes here. Standup Commitments
Maybe it's the developer in me, or maybe it's that I just don't trust lists of things to do because my context is always unique (just like everybody else). So - instead of telling my why they are important, or what I have to do to get them right, I'd rather know what I should expect from a StandUp.
As far as I understand StandUps they are meant to do the following:
1) Provide visibility - both pigs and chickens can see things inching along.
2) Provide visibility - the (self organizing) team members are informed of roadblocks so they can remove them
and
3) Provide visibility - the team can know what to expect for tomorrow.
If some other thing meets that criterion then I'm fine with it. The scrums I participate in usually pass those tests. Are there more tests that need to be passed for a good scrum?
(by the way, I've also been part of teams that had such great communication that these meetings were dropped without any negative effects. Small teams of 3-4 in one room talking all day. We passed all three tests without the need for the meeting.)
Small teams of 3-4 in one room talking all day. We passed all three tests without the need for the meeting.
This is very interesting. Sometimes I tend to feel the same that when we are working in smaller teams (2-4) people then we might not need to do the "official" standup. The communication throughout the day takes care of it.
That being said I have to try skipping the standup in my small team and see the results ;)
Three great things to remember for a great stand up:
I've posted actual practice that we do during our stand-up meetings. Here's some detail about it - Finding Value in Stand-up Meetings
Thin client paradigm characterized by web applications is a kludge that needs to be repudiated. Old compromises are no longer needed and it's time to move the presentation tier to where it belongs.
In this presentation filmed during QCon 2007, Jeff Sutherland, the creator of Scrum, talks about his visit at Google to do an analysis of Google's first implementation of Scrum.
In this article, Bryon Jacob and Chris Berry introduce AtomServer, their implementation of a full-fledged Atom Store based on Apache Abdera, which is now available as open source.
It is easy to think that virtualization applies only to servers. In reality the recent resurgence of the concept is also being applied to networking, storage, and application infrastructure.
In this article, Stefan Tilkov explains some of the most common anti-patterns found in applications that claim to follow a "RESTful" design and suggests ways to avoid them.
In this article, Adrien Louis and Marc Dutoo discuss the differences and relative merits of using orchestration vs. routing in a typical ESB setup, and discuss various implementation options.
Wayne Lund discusses batch processing, Spring Batch objectives and features, scenarios for usage, Spring Batch architecture, scaling, example code, failures and retrying, and the future roadmap.
Developer Jay Fields draws on his experiences as a ThoughtWorks consultant to describe effective user story estimation techniques.
6 comments
Reply