I m not quite seeing why having minutes is such a bad thing. From my perspective it enables people to check back to it over the course of the day. There areMessage 1 of 41 , Dec 7 12:34 PMView SourceI'm not quite seeing why having minutes is such a bad thing. From my perspective it enables people to check back to it over the course of the day.
There are plenty of times where items in the morning stand-up get mentioned and then need to be re-discussed later only to be forgotten about due to the fallibility of the human mind. Minutes give everyone the same information, that way only one person needs to be taking notes and can disseminate that information afterwards or post it on the wall.
I really don't see how this is an anti-scrum practice.
I work in an industry (DOD contracting) where documentation is a key part of the software delivery. You can t even bid on any reasonable size DOD contractMessage 41 of 41 , Jan 9View SourceI work in an industry (DOD contracting) where documentation is a key part of the software delivery. You can't even bid on any reasonable size DOD contract unless you are at least CMMI level 3 certified. The CMMI specification was designed in a heavy waterfall era. While there is technically nothing about CMMI that precludes an agile process, documentation is a sticking point when trying to mix the two. The DOD contracting environment is one of implicit mistrust. The government has so many regulations and procedures designed to limit fraud and waste (ah, the irony) that form a basis of mistrust. Contractors have policies and procedures designed to protect them from the government making major scope changes, especially scope creep, without changing the funding; also forming a basis of mistrust. It's not that the active players of a contract lack trust, but the process itself is untrusting.So, part of the process of any contract is to generate documentation that records progress and decisions as the contract is executed. We have to document design decisions (including essentially proving that we are actually thinking about design, interfaces, etc). We have to document progress so that the progress can be reported higher and higher up the contractor mgmt chain and then through the government mgmt chain.Even with all these documentation requirements, I STILL argue against taking minutes of the daily stand up. I'd agree to minutes in the planning session, in the sprint review, and even the grooming session. But the daily stand up is designed to be quick and free flowing. It's the thing that starts your day, and you shouldn't have to stick to the pace of someone taking notes. There's nothing at the stand up that you can't capture in some other way. If you need to report progress, then you can note changes to the sprint backlog for posterity after the fact (SM comes in later and notes which PBIs were completed, which have impediments, etc).On Tue, Jan 8, 2013 at 2:55 PM, Charles Bradley - Professional Scrum Trainer and Coach <chuck-lists2@...> wrote:
I will attempt to not beat you up, but I have some comments.
IMO, the "pattern" you suggested is really only possibly applicable in the contexts that you suggested it in. As such, I would now say that someone on this list has put forth a context(actually a couple of them) for when it might be useful to take meeting minutes at the Daily Scrum. I still stand by my statement that this is something like 1% of Scrum teams or less.
> why beat up on people in the community who may have valid reasons for their adaptions,While I don't agree with "beating people up," I do agree with professionals on this list who have seen situations like this and understand that ~99% of the time, it's not a good practice. Further, the OP never came forth with a "context" that justified taking meeting minutes. If he/she had done so, then I believe this conversation would have gone much differently.But your question is... Why?The answer: Because processes that used, encouraged, or even remotely implied a lot of written documentation in the past in our industry have proven over and over again to be unsuccessful on wide scale. You can get down on the weeds on the study, but the empirical evidence is that Agile is 3X more successful than Waterfall(and its derivatives).-------
From: Account <richardknaster@...>
Sent: Sunday, December 30, 2012 10:47 AM
Subject: [scrumdevelopment] Re: Meeting minutes for stand up meetings
I have a different observation and hopefully the "Monkey's" in our group will not beat me up for it. ;) I suspect the people negatively reacting to the idea of notes (or minutes) may not have experience working in a highly regulated environment or on highly distributed and dispersed teams, where there are no over-lapping work hours. I will briefly tackle the objective evidence piece at the end of the post.
Why Daily Scrum Notes (Minutes) can be a useful tool (Context Counts)!
I agree that "notes" (or minutes) are typically not taken during the Daily Scrum; the team must only log impediments. In most cases, "notes" would be unnecessary overhead. Notes are very useful for distributed teams when there are no over-lapping hours and when there are several team members whose primary language is not the same as what is being used on the call.
The Daily Scrum is an intense meeting with rapid communication. When a distributed team uses a language that is not the first language of all participants, communication becomes more difficult and typically delays the meeting. These communication issues can be caused by language, idioms, slang, or culture.
Having the notes available in a common location also allows those not able to attend the Daily Scrum to share their tasks with others and provides them with a way to learn about the tasks of other team members.
Taking notes for the Daily Scrum can also help distributed teams that are dealing with language difficulties. For those who are using their second language on the teleconference, having text prepared earlier can help them to state their responses. And, it can help others who are using the primary language of the meeting to understand what they are saying.
I also find that taking notes in real-time, using an electronic web conference tool (or Wiki), during the call helps with language difficulties as people can read what the speaker is saying while he/she is talking. I'm not suggesting creating a transcript, but recording the salient Speaker's points. By doing it this way, you reduce waste and by the time the meeting is done the minutes are completed and posted as well. It virtually adds no overhead and reduces the waste and time delays caused by translation, mus-understanding, e-mails back and forth etc.
Daily Scrum notes are especially important for teams working in a regulatory compliance environment (such as the FDA, HIPPA, or others), which about a third of agile teams claim to do.
Now what is Objective Evidence?
Objective evidence is information that proves
that something exists or is true. Objective evidence can
be collected by performing observations, measurements,
tests, or by using any other suitable method.
Auditors will vary greatly on what constitutes objective evidence. Some auditors will accept periodically attending Daily Scrums, or reviewing calendar invites, others will require meeting notes (minutes). Again context counts. In a large enterprise auditing Daily Scrum meetings and interviewing team members may not be practical way to provide objective evidence. For safety critical systems development, meeting minutes are an essential tool.
Scrum teams should do what makes sense in the context of their situation. If taking notes (minutes) provides value to the team or the business, then there should not be a stigma about doing so. All too often I hear people say "if you do this or that" then you are not agile, or are not doing scrum. Scrum is all about inspection and adaption, so why beat up on people in the community who may have valid reasons for their adaptions, especially when you may not be familiar with the regulatory domain?
On the other hand, doing things because we've always done it that way is not a good idea and we should periodically challenge things that the team considers waste.
If done right, notes can be taken and shared with all team members with minimal effort. If it doesn't provide value to the team or the business, then it's not a practice your team should adapt.
I hope people found this to a be a useful post.
--- In firstname.lastname@example.org, "avinap77" <avi.naparstek@...> wrote:
> Nice metaphor Mark,
> But I can't help feel that the monkey being beaten up in this thread is the OP.
> Makes one think...
> --- In email@example.com, "woynam" <woyna@> wrote:
> > I heard this one years ago. Source: http://wiki.answers.com/Q/Did_the_monkey_banana_and_water_spray_experiment_ever_take_place
> > The Experiment - Part 1
> > 5 monkeys are locked in a cage, a banana was hung from the ceiling and a ladder was placed right underneath it. As predicted, immediately, one of the monkeys would race towards the ladder, to grab the banana. However, as soon as he would start to climb, the researcher would spray the monkey with ice-cold water. In addition, he would also spray the other four monkeys…
> > When a second monkey tried to climb the ladder, the researcher would, again, spray the monkey with ice-cold water, as well the other four watching monkeys; This was repeated again and again until they learned their lesson: Climbing equals scary cold water for EVERYONE so No One Climbs the ladder.
> > The Experiment - Part 2
> > Once the 5 monkeys knew the drill, the researcher replaced one of the monkeys with a new inexperienced one. As predicted, the new monkey spots the banana, and goes for the ladder. BUT, the other four monkeys, knowing the drill, jumped on the new monkey and beat him up. The beat up new guy thus Learns- NO going for the ladder and No Banana Period- without even knowing why! and also without ever being sprayed with water!
> > These actions get repeated with 3 more times, with a new monkey each time and ASTONISHINGLY each new monkey- who had never received the cold-water Spray himself (and didn't even know anything about it), would Join the beating up of the New guy.
> > This is a classic example of Mob Mentality- bystanders and outsiders uninvolved with the fight- join in 'just because'.
> > When the researcher replaced a third monkey, the same thing happened; likewise for the fourth until, eventually, all the monkeys had been replaced and none of the original ones are left in the cage (that had been sprayed by water).
> > The Experiment - Part 3
> > Again, a new monkey was introduced into the cage. It ran toward the ladder only to get beaten up by the others. The monkey turns with a curious face asking "why do you beat me up when I try to get the banana?"
> > The other four monkeys stopped and looked at each other puzzled (None of them had been sprayed and so they really had no clue why the new guy can't get the banana) but it didn't matter, it was too late, the rules had been set. And So, although they didn't know WHY, they beat up the monkey just because " that's the way we do things around here"…
> > Why would we take minutes at a daily standup where all team members are present, and nobody outside the team has skin in the game? Because the organization has always taken minutes?!
> > Mark
> > --- In firstname.lastname@example.org>
> > > >To: email@example.com
> > > >Sent: Friday, December 28, 2012 8:32 AM
> > > >Subject: [scrumdevelopment] Re: Meeting minutes for stand up meetings
> > > >
> > > >
> > > >The basic foundation of Scrum is the self-organizing team. Any intra-iteration artifact is a waste of time and resources, and indicates that the organization does not actually trust the team (smell).
> > > >
> > > >The team certainly doesn't need minutes. If there's a question, they should be talking to each other, not referring to an interpretation of the meeting put together by some scribe.
> > > >
> > > >The only thing an organization needs is working software at the end of every Sprint, preferably containing the highest priority features. If this isn't delivered, the answer is not to produce more artifacts, but reduce the length of the feedback cycle, i.e. the Sprint length.
> > > >
> > > >Mark
> > > >
> > > >
> > > >--- In firstname.lastname@example.org>
> > > >> > *To:* email@example.com Groups Links
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
To Post a message, send it to: scrumdevelopment@...
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links
<*> To visit your group on the web, go to:
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
(Yahoo! ID required)
<*> To change settings via email:
<*> To unsubscribe from this group, send an email to:
<*> Your use of Yahoo! Groups is subject to: