Re: Feature-Focused Daily Scrum - New Scrum Extension Proposed

Thanks for all the feedback, folks. I have simplified the structure of our template as per the feedback here and I believe we re better for it. Now that this

Message 1 of 19
, Apr 10, 2012

0 Attachment

Thanks for all the feedback, folks.

I have simplified the structure of our template as per the feedback here and I believe we're better for it. Now that this template is improved we'll try and release a few more extension proposals that use this simplified template.

Check it out, all.

--- In scrumdevelopment@yahoogroups.com, David Starr <david@...> wrote:
>
> This thread is the community conversation thread for a proposal to extend
> Scrum, the Feature-Focused Daily Scrum.
>
>
> Read the proposed extension
> here<http://www.scrum.org/storage/scrumguides/extension/Feature-Focused%20Daily%20Scrum.pdf>
> .
>
>
> As you may know, Scrum.org hosts the Scrum Guide, which defines the Scrum
> framework. Scrum Extensions are prescriptive guidance that goes beyond the
> Scrum framework to offer suggestions for how Scrum Teams can improve their
> practice within specific contexts.
>
>
> Scrum Extensions are authored and submitted by Scrum practitioners and
> published for consideration by the Scrum community in an open forum. Anyone
> may propose an extension.
>
> Please provide the extension author with feedback via this thread, or
> directly via email. All conversation is encouraged to occur in public and
> in the open. We all want the vetting process for Scrum Extensions to be
> transparent.
>
>
> Read the Scrum Guide <http://www.scrum.org/scrumguides/> | Read about Scrum
> Extensions <http://www.scrum.org/scrum-extensions/?SSScrollPosition=56>
>
>
> *David Starr
> **Scrum.org, Chief Craftsman* - *Improving the Profession of Software
> Development*
> elegantcode.com | @elegantcoder | scrum.org | @scrumdotorg
>

Charles Bradley - Scrum Coach CSM PSM I

Apparently I m not the only person that has this same concern about a Feature Focused Daily Scrum:

Message 2 of 19
, Apr 17, 2012

0 Attachment

Apparently I'm not the only person that has this same concern about a Feature Focused Daily Scrum:

"...I don’t know if story focus helps with improvement. I don’t think it
will but I will say that most teams miss the opportunity to use the
daily scrum for noticing and suggesting improvements. It’s a shame that a
lot of teams try to do all process improvement in the retrospective. A
lot could be accemplished mid-sprint...." -- Mike Cohn

They said it better than I could... I remain in my position that I think this should be documented as a concern to watch out for when applying the extension.

I apologize if I wasn't clear before, and I think I was unclear. My point is not that the Features and Goals(F&G) section would be overshadowed by the EE
section. Let me try again.

In summary, I think it is possible, with some teams, that the transparency of the current DS content could be reduced by using the new extension, mostly in the EE content part of the meeting. Further, I think there is often really good "empirical data" (inappropriate work, interesting tips from fellow team members about stuff that is not *directly* related to a PBI, mentioning a previously solved problem not directly related to a PBI, etc) on which to "inspect and adapt" in the EE
content. Said another way, I think some teams might be losing transparency on things that can be improved, in large part because recalling one's day chronologically (the current DS approach) vs. recalling/sorting the content into categories off the cuff(the extension appraoch) might cause some people to forget the EE content.

If one breaks the current DS content conceptually into 2 category(not time-wise, but content wise), one with F&G, and one with EE. The extension will probably increase the transparency on the F&G side, but I think it could decrease transparency on the EE side because developers have to recall and/or come up with the material in different ways.

In the current DS (what is referred to as the "1-2-3 technique" in the extension), a team member simply has to recall events in rough chronological order,
something that is pretty easy for humans to do. I consider it a "high level bullet points" of what I did yesterday and what I plan to do today.

In the extended DS, a team member has to remember to filter out EE in the F&G part (something that is not terribly hard for humans to do), and has something to use as a "memory peg (the PBI)" for what they need to say. This is the huge benefit of the extension, IMO, focusing on the F&G part with a memory peg.

During the EE part the human then has to recall the EE(remembering to leave out the F&G part which has already been done) from yesterday. As such, remembering this chronologically is one strategy, but again, you have to subtract F&G content from your yesterday. Then, for your "today", you have to again recall your plan, subtract the F&G content, and then speak
that part. I guess people might fall into a habit of having content ready for both and separate, but I doubt it.

Further, the SM, during the EE part, has to investigate to draw out interesting EE content, where in the traditional DS it comes out naturally as part of a chronological recall, something humans do often. I guess I'm saying for some people it might be much easier to do a full chronological recall than to add and subtract content categories(F&G vs. EE) on the fly in a meeting.

I'm not saying I dislike the extension/pattern. What I am suggesting is that this possible risk of loss of information in the EE part should be documented in the extension as part of the context, somehow, IMHO.

Good points, Charles. I want to let this thread thrive a bit longer before responding.... but I can't help myself :-)

I think you are right that the EE section could overshadow the feature discussion. In fact, we know that it will grow to fit its container, right? So, does that mean we should just make it really small and be strict on the timebox, or does it mean we shouldn't do it?

I do think every Daily Scrum should visit the features (the goal, the software, the progress, etc.) and any other items the team is working on. Whatever little framework one constructs for the Daily Scrum needs to provide a mechanism for uncovering hidden work while focusing the team as a group.

Let's see what advice others may have.

David StarrScrum.org, Chief Craftsman - Improving the Profession of Software Development

I'm hypothetically putting myself in the Dev Team member role. "I've noticed over recent Daily Scrums that the information in the 'Everything Else'(EE) section of the DS gets a lot more attention and scrutiny from the SM. As such, I've decided that, so long as I can claim work on a feature, I will generally not add anything more to the EE section of the DS.

I'm sure a similar argument can be made for the traditional last meeting/next meeting/obstacle format, but I think a Developer would be more likely to reveal the EE info while recounting a basically chronological account of yesterday vs. the "feature based" approach with the EE
section separated out.

It's sort of like the difference between asking someone directly if they committed a crime vs. having them "tell their story," then investigating inconsistencies in the story.

As you may know, Scrum.org hosts the Scrum Guide, which
defines the Scrum framework. Scrum Extensions are prescriptive guidance that
goes beyond the Scrum framework to offer suggestions for how Scrum Teams can
improve their practice within specific contexts.

Scrum Extensions are authored and submitted by Scrum practitioners
and published for consideration by the Scrum community in an open forum. Anyone
may propose an extension.

Please provide the extension author with feedback via this
thread, or directly via email. All conversation is encouraged to occur in
public and in the open. We all want the
vetting process for Scrum Extensions to be transparent.

I agree it should be noted as a potential downfall. We ve been using this technique here at Scrum.org for awhile and the dynamics are interesting. Overall, I

Message 3 of 19
, Apr 18, 2012

0 Attachment

I agree it should be noted as a potential downfall.

We've been using this technique here at Scrum.org for awhile and the dynamics are interesting. Overall, I think we all prefer it to a simple 3-question Daily Scrum. I can see how it could go off track.

David StarrScrum.org, Chief Craftsman - Improving the Profession of Software Development

"...I don’t know if story focus helps with improvement. I don’t think it
will but I will say that most teams miss the opportunity to use the
daily scrum for noticing and suggesting improvements. It’s a shame that a
lot of teams try to do all process improvement in the retrospective. A
lot could be accemplished mid-sprint...." -- Mike Cohn

They said it better than I could... I remain in my position that I think this should be documented as a concern to watch out for when applying the extension.

I apologize if I wasn't clear before, and I think I was unclear. My point is not that the Features and Goals(F&G) section would be overshadowed by the EE
section. Let me try again.

In summary, I think it is possible, with some teams, that the transparency of the current DS content could be reduced by using the new extension, mostly in the EE content part of the meeting. Further, I think there is often really good "empirical data" (inappropriate work, interesting tips from fellow team members about stuff that is not *directly* related to a PBI, mentioning a previously solved problem not directly related to a PBI, etc) on which to "inspect and adapt" in the EE
content. Said another way, I think some teams might be losing transparency on things that can be improved, in large part because recalling one's day chronologically (the current DS approach) vs. recalling/sorting the content into categories off the cuff(the extension appraoch) might cause some people to forget the EE content.

If one breaks the current DS content conceptually into 2 category(not time-wise, but content wise), one with F&G, and one with EE. The extension will probably increase the transparency on the F&G side, but I think it could decrease transparency on the EE side because developers have to recall and/or come up with the material in different ways.

In the current DS (what is referred to as the "1-2-3 technique" in the extension), a team member simply has to recall events in rough chronological order,
something that is pretty easy for humans to do. I consider it a "high level bullet points" of what I did yesterday and what I plan to do today.

In the extended DS, a team member has to remember to filter out EE in the F&G part (something that is not terribly hard for humans to do), and has something to use as a "memory peg (the PBI)" for what they need to say. This is the huge benefit of the extension, IMO, focusing on the F&G part with a memory peg.

During the EE part the human then has to recall the EE(remembering to leave out the F&G part which has already been done) from yesterday. As such, remembering this chronologically is one strategy, but again, you have to subtract F&G content from your yesterday. Then, for your "today", you have to again recall your plan, subtract the F&G content, and then speak
that part. I guess people might fall into a habit of having content ready for both and separate, but I doubt it.

Further, the SM, during the EE part, has to investigate to draw out interesting EE content, where in the traditional DS it comes out naturally as part of a chronological recall, something humans do often. I guess I'm saying for some people it might be much easier to do a full chronological recall than to add and subtract content categories(F&G vs. EE) on the fly in a meeting.

I'm not saying I dislike the extension/pattern. What I am suggesting is that this possible risk of loss of information in the EE part should be documented in the extension as part of the context, somehow, IMHO.

Good points, Charles. I want to let this thread thrive a bit longer before responding.... but I can't help myself :-)

I think you are right that the EE section could overshadow the feature discussion. In fact, we know that it will grow to fit its container, right? So, does that mean we should just make it really small and be strict on the timebox, or does it mean we shouldn't do it?

I do think every Daily Scrum should visit the features (the goal, the software, the progress, etc.) and any other items the team is working on. Whatever little framework one constructs for the Daily Scrum needs to provide a mechanism for uncovering hidden work while focusing the team as a group.

Let's see what advice others may have.

David StarrScrum.org, Chief Craftsman - Improving the Profession of Software Development

I'm hypothetically putting myself in the Dev Team member role. "I've noticed over recent Daily Scrums that the information in the 'Everything Else'(EE) section of the DS gets a lot more attention and scrutiny from the SM. As such, I've decided that, so long as I can claim work on a feature, I will generally not add anything more to the EE section of the DS.

I'm sure a similar argument can be made for the traditional last meeting/next meeting/obstacle format, but I think a Developer would be more likely to reveal the EE info while recounting a basically chronological account of yesterday vs. the "feature based" approach with the EE
section separated out.

It's sort of like the difference between asking someone directly if they committed a crime vs. having them "tell their story," then investigating inconsistencies in the story.

As you may know, Scrum.org hosts the Scrum Guide, which
defines the Scrum framework. Scrum Extensions are prescriptive guidance that
goes beyond the Scrum framework to offer suggestions for how Scrum Teams can
improve their practice within specific contexts.

Scrum Extensions are authored and submitted by Scrum practitioners
and published for consideration by the Scrum community in an open forum. Anyone
may propose an extension.

Please provide the extension author with feedback via this
thread, or directly via email. All conversation is encouraged to occur in
public and in the open. We all want the
vetting process for Scrum Extensions to be transparent.