Re: [scrumdevelopment] Re: Deviating from Scrum: The standup meeting
- I tend to agree with Peter (S) here on 'Inspect and Adapt'. Also, I have faced this scenario and I do consult teams of 3-4 members or usually start with bigger team size, say, 7 to 10 and than slowly gets to smaller team size depending on the context.
In one case, team said exactly what peterskeide wrote in his initial post. Some of the characteristics of this team were:
Team never used to skip updating burn-down chart otherwise they may miss the overall picture.
Team was updating sprint backlog as and when the story/task was completed.
Many times, whole team used to go for lunch together hence it can be considered that they had some kind of work related discussion during lunch itself and a separate meeting was quite redundant.
Some of the stories were also taking 3-4 days hence there were days when there was no progress with respect to done definition.
As an agile coach, my recommendation to team was that they may skip stand-up meeting on a day but not to skip for 2 consecutive days. This team tried the option of stand-up meetings on alternate day for some time and it worked in that context.
Hariprakash Agrawal (Hari),
Managing Director | Agile Coach | http://opcord.com | http://www.linkedin.com/in/hariprakash
Software Testing (QTP, Selenium, JMeter, AutoIT, Sahi, NUnit, VB/Java Script, Manual) || Consulting / Trainings (Agile, CMMi, Six Sigma, Project Management, Software Testing)
On Thu, Mar 3, 2011 at 2:50 PM, Peter Stevens (cal) <peterstev@...> wrote:
I believe the most fundamental principles of Scrum are 'Inspect and Adapt' and Emergence. So when you have a problem and don't know what the best solution is, you can propose alternative, try them out, and then reflect on them in the Retrospective.
What is the essential that you need to need to preserve on the daily scrum? Perhaps in your case, it's sufficient to move the daily scrum to the coffee machine and talk about the third question. Another alternative is dropping the Daily Scrum all together. So try it out for a sprint. The look at your results in the retro. Maybe try a different alternative in the next sprint. Maybe go back to doing the Daily Scrum in the third. Then make a more definitive decision.
I think by being open to the issues raised by your team that you will gain their respect.
Inspect and Adapt - keep true to this principle and you'll do fine!
On 02.03.11 21:19, Charles Bradley - Scrum Coach CSM PSM I wrote:
I think I understand now more why your team wants to ditch the Daily Scrum. The Scrum Guide says that Scrum is for teams of 5-9 developers. I count about 3.5 on your team. This *may* be an example of where the process overhead of a Daily Scrum is worthwhile for a team of 5-9 devs, but may not be worthwhile for a team of 3.5.
So, before we continue let's realize that we're operating outside of the recommended boundaries for Scrum, which may be some of the source of your pain. You may also experience other similar pains with other Scrum ceremony/rules for this reason as well.
Does your PO attend the Daily Scrum? I think it's generally a good practice. (Technically the PO would be attending as a Chicken, though, so while they would not be be allowed to talk in the meeting, they would certainly be allowed to follup with dev team members just after the meeting) If your PO has other duties and is located in a different room, I think they might benefit from the Daily Scrum, and in turn, the team would benefit.
Another thing most of my teams do right after the Daily Scrum is analyze the burndown a bit for possible scoping/workload issues. I generally coach them to use an "ideal (capacity=hrs capacity remaining) line", and we generally don't worry too much about a burndown number (hrs work remaining) that is within 20% of the ideal(capacity) number until the last 3 days of the (2 week)sprint or so. During the last 3 days, we generally always had a discussion(again, just after the Scrum) like "Do we need to take any action now that will help us have a more successful end of sprint?" Sometimes people would identify the burndown numbers as an obstacle in the Scrum, sometimes we wouldn't really notice or discuss until after the Scrum.
Technically, though, the person who ensures that the Daily Scrum happens is the ScrumMaster. So, since the SM, "owns the process", the SM can mandate the Daily Scrum regardless of what the team says. That may not be a fun position to be in, but it's justified IMO. I'd hope the SM would focus more on improving the Daily Scrum(like you are) than having to mandate it.
Charles Bradley, CSM, PSM I
Experienced Scrum Coach
My blog: http://scrumcrazy.wordpress.com/
From: peterskeide <peterskeide@...>
Sent: Wed, March 2, 2011 11:59:08 AM
Subject: [scrumdevelopment] Re: Deviating from Scrum: The standup meeting
--- In email@example.com, Charles Bradley - Scrum Coach CSM PSM I <chuck-lists2@...> wrote:
> I was wondering if you could share some more context with us about your
> How big is your Scrum team?
4, including me.
> Is the PO collocated with the dev team?
More or less (next door).
> What % of the PO's time does the PO spend working with the dev team?
He is available to us pretty much when we need it. He attends all the usual meetings, and we schedule regular backlog grooming sessions (working with him to get these sessions running smoothly).
> As the ScrumMaster, are you also a developer on the team?
Yes. And this can be a bit of a problem. Generally, I would prefer not to mix these two roles. As it is, one of our greates impediments is lack of capacity, and I feel I have to devote some time to development, sometimes more than I'm comfortable with while wearing both hats. The issue has been flagged and people are being hired, but this takes time. As it is, we have had to make the organization face some 'brutal' truths about what we are able to deliver.
> Does the PO wear more than one hat as well?
Yes. I'm working with him to help him understand what is required of a PO. As a Scrum Master, getting this role working well is a high priority. He is very motivated, skilled in the domain, and I have hopes :-). I'm also trying to ensure that upper management gives him the mandate he needs to fulfill this role. Changing his other responsibilities is a natural part of this as I see it.
> When does your dev team update the sprint backlog and sprint burndown?
Burndown at the end or beginning of each day. Sprint Backlog (story board) is updated continuously as people start and finish stories.
> Charles Bradley, CSM, PSM I
> Experienced Scrum Coach
> My blog: http://scrumcrazy.wordpress.com/
-- Peter Stevens, Partner DasScrumTeam GmbH direct: +41 44 586 6450 cell: +41 79 422 6722 skype: peterstev blog: http://scrum-breakfast.com My New Email Address: peter.stevens@... Please update your address book. Thanks!
- --- In firstname.lastname@example.org, Chuck B <chuck-lists2@...> wrote:
> > I'd say a format that is chosen by the team to give them value is a goodI interpreted the above as "the team uses standup meetings, but modified". I agree with you about teams that do not know Scrum well. For my current team, I made sure we ran several sprints as close to Scrum as we could manage before opening up for change. The standup was at that point a recurring theme in the retrospective meetings. We have not dropped or modified the other artifacts/ceremonies/roles.
> > fit.
> > - George
> I don't know about this. What if the team chooses the "no standup" format?
> What if they choose to just say what they are working on and that's it? I just
> don't know about entrusting the team to choose whatever format they want,
> especially not a team that is well versed in Scrum. You did say "chosen by the
> team to give them value " Who determines whether the format gives them value or
> The Daily Scrum is not a status meeting. It is not for anyone but theI'm definitely wary of removing it, but I'm also wary of disregarding context. On my previous project I worked for a customer where we as a team agreed to drop the standup meeting after a couple of sprints. We were a small team of 4 (colocated). We delivered a solid product on time and budget to a happy customer and with very little technical debt. We did it, by and large, without standup meetings.
> people transforming the Product Backlog items into an increment (the
> Team). The Team has committed to a Sprint Goal, and to these
> Product Backlog items. The Daily Scrum is an inspection of the
> progress toward that Sprint Goal (the three questions). Follow-on
> meetings usually occur to make adaptations to the upcoming work in
> the Sprint. The intent is to optimize the probability that the Team will
> meet its Goal. This is a key inspect and adapt meeting in the Scrum
> empirical process. "
> Note that last sentence. (Mostly to Peter)I'd be VERY wary of removing the
> Daily Scrum since it's a "...key inspect and adapt meeting..."
> Charles Bradley, CSM, PSM I
> Experienced Scrum Coach
> My blog: http://scrumcrazy.wordpress.com/
- --- In email@example.com, Adam Sroka <adam.sroka@...> wrote:
>This clicked with me. Yes, I think this is definitely a part of it.
> On Wed, Mar 2, 2011 at 6:05 AM, peterskeide <peterskeide@...> wrote:
> > The best argument I have heard so far in favor of dropping the standup is that it can be redundant in a small, colocated team. When you sit around the same table all day, pair program often and generally talk to each other a lot, it's a bit like gilding the lily.
> It's not so much that it is redundant as that the information is
> arriving at the wrong time. It is too late to for me to help you with
> what you were doing yesterday, and I am less interested in what you
> are doing now - while I am busy with something else - than I will be
> in what you are doing when I finish.
> > There are obvious downsides to dropping the standup: the visibility aspect of it lost. Granted, this only matters if people outside the team actually bothers to attend the meeting. Still, if there are no standup meetings, there will be nothing for potentially interested stakeholders to start attending.I encourage stakeholders to come down to where we sit and have a look at how we work. That way, they are exposed to our information radiators, and can easily view the progress of the current sprint. These radiators tell the truth about the current situation, because we update them continuously. I also feel that this is a great way of spreading information about Scrum to the organization. I don't mandate a strict "contribute or be silent" regime, but welcome questions. I have a feeling the team likes answering some questions about how they work, as it also gives them opportunities to reflect on what they do. I step in if someone appears at a bad time.
> I don't think so. What I like to do is open the room up to anyone who
> wants to be a fly on the wall, but if you want to ask questions you
> have to participate in whatever it is we are doing. That way customers
> can show up at whatever time is convenient for them, but their ability
> to interfere and "break the flow" is limited by their
> willingness/desire to directly contribute.
>I'm in favor of the inspect and adapt approach too, and I will discuss this option with team in next retrospective. However, if there is some way to keep the standup but in a way that adds value, I'd rather we do that.
> Some folks suggest switching up the format of the stand-up meeting to
> keep it fresh. Personally, I would say that if the team is not getting
> any value out of it then consider not holding the meeting for a Sprint
> or two to see what happens.