[SCRUMDEVELOPMENT] Coaching away from a waterfall requirements process

[Michael Wollin [e-mail] [SCRUMDEVELOPMENT]]

Am I on solid ground? This is hand-offy to me. It has four extra meetings for Dev, not including the backlog grooming meeting. I could be wrong though. What do you think?

Susan is a PMP ACP charged by V&V (QA) to streamline process. Steve is a highly experienced PO. I am the department’s agile coach consultant. I don’t know who Jon is. :)
[not their real names]

Begin forwarded message:

From: Susan
Date: Wednesday, August 31, 2016 at 5:16 PM
To: Michael Wollin, Steve
Subject: RE: Thursday's Meeting for Project X

One of the key takeaways I am looking for is the agreement of the flow through the system and creation of tasks in JIRA by both Dev and Test – get agreement on what the JIRA tool is used for. I am also looking to have agreement regarding what the Rational tool is used for (and what it is not used for).

From: Michael Wollin,
Date: Wednesday, August 31, 2016 at 5:37 PM
To: Susan , Steve,
Subject: Re: Thursday's Meeting for Project X

This may be a tall order. It may also be premature. People not well trained in agile or not bought into it might force a “compromise” that in the final analysis doesn’t serve the department or the company and that thwarts agility.

From: Steve,
Date: Thursday, September 1, 2016 at 7:31 AM
To: Michael Wollin, Susan ,
Subject: Re: Thursday's Meeting for Project X

Good morning.

We have an agreement on this flow now. I don’t mind sharing it. Jon can speak to how he is feeling about the current process meeting V&V needs.

In a nutshell:
1. Product Owner first gathers user needs/use cases from stakeholders
2. A Feature Page is created in Confluence to start sharing Goals, Business Intent, Assumptions, Risks, and User Needs for each feature (Example:[link to requirements spec form removed])
3. Dev and V&V participate in the review of these needs with UX and HF teams
4. JIRA stories based on the agreed user needs are created in the backlog, assigned to an Epic and a Version
5. UX presents designs to support the user needs. Dev and V&V participate in the review.
6. UX presents final designs with “callouts” (the implementation details). All stakeholders (Marketing, PO, Dev, HF, and V&V) review and approve.
7. We need to come up with a long-term plan, but for now the PO, V&V, Dev, and UX create the entries in Doors to support the agree functionality.
8. The team then meets to approve the Doors entries. For items that are shared between projects, this can take longer as we have to get approval from all teams working on affected products.
9. The Dev and V&V teams Groom the stories to ensure the JIRA story and the designs with callouts give a clear picture of the story.
a. Story points are assigned during Grooming.
b. Dev and V&V have to agree on points. Sometimes small development tasks can require significant V&V, so points reflect the total effort.
10. During the Planning session for each sprint a common set of tasks needed to achieve a “Done” Status is added to each story (see list below)
11. Sprint Begins
12. Dev and V&V must be complete for a story to be DONE


Project X Sub-Tasks Needed to Ensure Each Story is DONE:
· Design in Confluence Complete
· Requirements in Doors Complete
· Dev Complete
· Unit Tests Complete
· Test Cases & Scripts Traced to Requirements Complete
· Screen Crawler Complete



From: Michael Wollin,
Date: Thursday, September 1, 2016 at 8:42 AM
To: Steve, Susan ,
Subject: Re: Thursday's Meeting for Project X

You can take this approach if you so choose, but it is completely waterfall.

From: Steve,
Subject: Re: Thursday's Meeting for Project X
Date: September 1, 2016 at 8:59:44 AM PDT
To: Michael Wollin, Susan ,

I disagree that this is “completely” waterfall. I’m happy to discuss with you. We do Agile within Waterfall in compliance with the AAMI TIR45 process. I see the steps below as Completely Agile per feature.

To Michael’s point, what is the intended purpose of the meeting? Are we evaluating the whole process, or just looking to improve efficiencies for V&V? I think both are worthwhile; I’m just looking for expectations. Glad to participate in both.

Thanks,
Steve

[Adam Sroka [e-mail] [SCRUMDEVELOPMENT]]

I would have to know more about the context to be sure, but I don’t see any
indication that these folks understand Agile. I see an awful lot of stuff
about processes, tools, comprehensive documentation, following a plan,
“sign offs,” etc and essentially nothing about any of the stuff on the left
side of the manifesto. In fact, I would go as far as to say that this is
the kind of stuff the manifesto authors were arguing against explicitly.

Post by Michael Wollin ***@mercurysw.com [SCRUMDEVELOPMENT]
Am I on solid ground? This is hand-offy to me. It has four extra meetings
for Dev, not including the backlog grooming meeting. I could be wrong
though. What do you think?
Susan is a PMP ACP charged by V&V (QA) to streamline process. Steve is a
highly experienced PO. I am the department’s agile coach consultant. I
don’t know who Jon is. :)
[not their real names]
*From: *Susan
*Date: *Wednesday, August 31, 2016 at 5:16 PM
*To: *Michael Wollin, Steve
*Subject: *RE: Thursday's Meeting for Project X
One of the key takeaways I am looking for is the agreement of the flow
through the system and creation of tasks in JIRA by both Dev and Test – get
agreement on what the JIRA tool is used for. I am also looking to have
agreement regarding what the Rational tool is used for (and what it is not
used for).
*From: *Michael Wollin,
*Date: *Wednesday, August 31, 2016 at 5:37 PM
*To: *Susan , Steve,
*Subject: *Re: Thursday's Meeting for Project X
This may be a tall order. It may also be premature. People not well
trained in agile or not bought into it might force a “compromise” that in
the final analysis doesn’t serve the department or the company and that
thwarts agility.
*From: *Steve,
*Date: *Thursday, September 1, 2016 at 7:31 AM
*To: *Michael Wollin, Susan ,
*Subject: *Re: Thursday's Meeting for Project X
Good morning.
We have an agreement on this flow now. I don’t mind sharing it. Jon can
speak to how he is feeling about the current process meeting V&V needs.
1. Product Owner first gathers user needs/use cases from stakeholders
2. A Feature Page is created in Confluence to start sharing Goals,
Business Intent, Assumptions, Risks, and User Needs for each feature
(Example:*[link to requirements spec form removed*])
3. Dev and V&V participate in the review of these needs with UX and HF teams
4. JIRA stories based on the agreed user needs are created in the
backlog, assigned to an Epic and a Version
5. UX presents designs to support the user needs. Dev and V&V
participate in the review.
6. UX presents final designs with “callouts” (the implementation
details). All stakeholders (Marketing, PO, Dev, HF, and V&V) review and
approve.
7. We need to come up with a long-term plan, but for now the PO,
V&V, Dev, and UX create the entries in Doors to support the agree
functionality.
8. The team then meets to approve the Doors entries. For items that
are shared between projects, this can take longer as we have to get
approval from all teams working on affected products.
9. The Dev and V&V teams Groom the stories to ensure the JIRA story
and the designs with callouts give a clear picture of the story.
a. Story points are assigned during Grooming.
b. Dev and V&V have to agree on points. Sometimes small development
tasks can require significant V&V, so points reflect the total effort.
10. During the Planning session for each sprint a common set of tasks
needed to achieve a “Done” Status is added to each story (see list below)
11. Sprint Begins
12. Dev and V&V must be complete for a story to be DONE
· Design in Confluence Complete
· Requirements in Doors Complete
· Dev Complete
· Unit Tests Complete
· Test Cases & Scripts Traced to Requirements Complete
· Screen Crawler Complete
*From: *Michael Wollin,
*Date: *Thursday, September 1, 2016 at 8:42 AM
*To: *Steve, Susan ,
*Subject: *Re: Thursday's Meeting for Project X
You can take this approach if you so choose, but it is completely waterfall.
*From: *Steve,
*Subject: **Re: Thursday's Meeting for **Project X*
*Date: *September 1, 2016 at 8:59:44 AM PDT
*To: *Michael Wollin, Susan ,
I disagree that this is “completely” waterfall. I’m happy to discuss with
you. We do Agile within Waterfall in compliance with the AAMI TIR45
process. I see the steps below as Completely Agile per feature.
To Michael’s point, what is the intended purpose of the meeting? Are we
evaluating the whole process, or just looking to improve efficiencies for
V&V? I think both are worthwhile; I’m just looking for expectations. Glad
to participate in both.
Thanks,
Steve

[Michael Wollin [e-mail] [SCRUMDEVELOPMENT]]

Yeah. I know.

I'm looking for a powerful way to say what needs to be said that will make a difference. That conversation is deeper than agile coaching. Inside of their concerns in their occurring world that has them want to do agile, there is a way to reach them.

On Sep 1, 2016, at 12:37 PM, Adam Sroka ***@gmail.com [SCRUMDEVELOPMENT] <***@yahoogroups.com> wrote:

I would have to know more about the context to be sure, but I don’t see any indication that these folks understand Agile. I see an awful lot of stuff about processes, tools, comprehensive documentation, following a plan, “sign offs,” etc and essentially nothing about any of the stuff on the left side of the manifesto. In fact, I would go as far as to say that this is the kind of stuff the manifesto authors were arguing against explicitly.

Post by Michael Wollin ***@mercurysw.com [SCRUMDEVELOPMENT]
Am I on solid ground? This is hand-offy to me. It has four extra meetings for Dev, not including the backlog grooming meeting. I could be wrong though. What do you think?
Susan is a PMP ACP charged by V&V (QA) to streamline process. Steve is a highly experienced PO. I am the department’s agile coach consultant. I don’t know who Jon is. :)
[not their real names]
From: Susan
Date: Wednesday, August 31, 2016 at 5:16 PM
To: Michael Wollin, Steve
Subject: RE: Thursday's Meeting for Project X
One of the key takeaways I am looking for is the agreement of the flow through the system and creation of tasks in JIRA by both Dev and Test – get agreement on what the JIRA tool is used for. I am also looking to have agreement regarding what the Rational tool is used for (and what it is not used for).
From: Michael Wollin,
Date: Wednesday, August 31, 2016 at 5:37 PM
To: Susan , Steve,
Subject: Re: Thursday's Meeting for Project X
This may be a tall order. It may also be premature. People not well trained in agile or not bought into it might force a “compromise” that in the final analysis doesn’t serve the department or the company and that thwarts agility.
From: Steve,
Date: Thursday, September 1, 2016 at 7:31 AM
To: Michael Wollin, Susan ,
Subject: Re: Thursday's Meeting for Project X
Good morning.
We have an agreement on this flow now. I don’t mind sharing it. Jon can speak to how he is feeling about the current process meeting V&V needs.
1. Product Owner first gathers user needs/use cases from stakeholders
2. A Feature Page is created in Confluence to start sharing Goals, Business Intent, Assumptions, Risks, and User Needs for each feature (Example:[link to requirements spec form removed])
3. Dev and V&V participate in the review of these needs with UX and HF teams
4. JIRA stories based on the agreed user needs are created in the backlog, assigned to an Epic and a Version
5. UX presents designs to support the user needs. Dev and V&V participate in the review.
6. UX presents final designs with “callouts” (the implementation details). All stakeholders (Marketing, PO, Dev, HF, and V&V) review and approve.
7. We need to come up with a long-term plan, but for now the PO, V&V, Dev, and UX create the entries in Doors to support the agree functionality.
8. The team then meets to approve the Doors entries. For items that are shared between projects, this can take longer as we have to get approval from all teams working on affected products.
9. The Dev and V&V teams Groom the stories to ensure the JIRA story and the designs with callouts give a clear picture of the story.
a. Story points are assigned during Grooming.
b. Dev and V&V have to agree on points. Sometimes small development tasks can require significant V&V, so points reflect the total effort.
10. During the Planning session for each sprint a common set of tasks needed to achieve a “Done” Status is added to each story (see list below)
11. Sprint Begins
12. Dev and V&V must be complete for a story to be DONE
· Design in Confluence Complete
· Requirements in Doors Complete
· Dev Complete
· Unit Tests Complete
· Test Cases & Scripts Traced to Requirements Complete
· Screen Crawler Complete
From: Michael Wollin,
Date: Thursday, September 1, 2016 at 8:42 AM
To: Steve, Susan ,
Subject: Re: Thursday's Meeting for Project X
You can take this approach if you so choose, but it is completely waterfall.
From: Steve,
Subject: Re: Thursday's Meeting for Project X
Date: September 1, 2016 at 8:59:44 AM PDT
To: Michael Wollin, Susan ,
I disagree that this is “completely” waterfall. I’m happy to discuss with you. We do Agile within Waterfall in compliance with the AAMI TIR45 process. I see the steps below as Completely Agile per feature.
To Michael’s point, what is the intended purpose of the meeting? Are we evaluating the whole process, or just looking to improve efficiencies for V&V? I think both are worthwhile; I’m just looking for expectations. Glad to participate in both.
Thanks,
Steve

[Adam Sroka [e-mail] [SCRUMDEVELOPMENT]]

I would have an ongoing conversation with them where I brought it back to
the manifesto values and principles. Challenge them to truly live them,
while giving them some room to do stupid process stuff and then learn from
the mistake. Measuring the system would be a good idea, because then you
have ammunition when a bad idea slows productivity. That can be a
double-edged sword, though.

Good luck. I have been in similar situations and not enjoyed them.

Post by Michael Wollin ***@mercurysw.com [SCRUMDEVELOPMENT]
Yeah. I know.
I'm looking for a powerful way to say what needs to be said that will make
a difference. That conversation is deeper than agile coaching. Inside of
their concerns in their occurring world that has them want to do agile,
there is a way to reach them.
I would have to know more about the context to be sure, but I don’t see
any indication that these folks understand Agile. I see an awful lot of
stuff about processes, tools, comprehensive documentation, following a
plan, “sign offs,” etc and essentially nothing about any of the stuff on
the left side of the manifesto. In fact, I would go as far as to say that
this is the kind of stuff the manifesto authors were arguing against
explicitly.

Post by Michael Wollin ***@mercurysw.com [SCRUMDEVELOPMENT]
Am I on solid ground? This is hand-offy to me. It has four extra meetings
for Dev, not including the backlog grooming meeting. I could be wrong
though. What do you think?
Susan is a PMP ACP charged by V&V (QA) to streamline process. Steve is a
highly experienced PO. I am the department’s agile coach consultant. I
don’t know who Jon is. :)
[not their real names]
*From: *Susan
*Date: *Wednesday, August 31, 2016 at 5:16 PM
*To: *Michael Wollin, Steve
*Subject: *RE: Thursday's Meeting for Project X
One of the key takeaways I am looking for is the agreement of the flow
through the system and creation of tasks in JIRA by both Dev and Test – get
agreement on what the JIRA tool is used for. I am also looking to have
agreement regarding what the Rational tool is used for (and what it is not
used for).
*From: *Michael Wollin,
*Date: *Wednesday, August 31, 2016 at 5:37 PM
*To: *Susan , Steve,
*Subject: *Re: Thursday's Meeting for Project X
This may be a tall order. It may also be premature. People not well
trained in agile or not bought into it might force a “compromise” that in
the final analysis doesn’t serve the department or the company and that
thwarts agility.
*From: *Steve,
*Date: *Thursday, September 1, 2016 at 7:31 AM
*To: *Michael Wollin, Susan ,
*Subject: *Re: Thursday's Meeting for Project X
Good morning.
We have an agreement on this flow now. I don’t mind sharing it. Jon can
speak to how he is feeling about the current process meeting V&V needs.
1. Product Owner first gathers user needs/use cases from
stakeholders
2. A Feature Page is created in Confluence to start sharing Goals,
Business Intent, Assumptions, Risks, and User Needs for each feature
(Example:*[link to requirements spec form removed*])
3. Dev and V&V participate in the review of these needs with UX and HF teams
4. JIRA stories based on the agreed user needs are created in the
backlog, assigned to an Epic and a Version
5. UX presents designs to support the user needs. Dev and V&V
participate in the review.
6. UX presents final designs with “callouts” (the implementation
details). All stakeholders (Marketing, PO, Dev, HF, and V&V) review and
approve.
7. We need to come up with a long-term plan, but for now the PO,
V&V, Dev, and UX create the entries in Doors to support the agree
functionality.
8. The team then meets to approve the Doors entries. For items
that are shared between projects, this can take longer as we have to get
approval from all teams working on affected products.
9. The Dev and V&V teams Groom the stories to ensure the JIRA story
and the designs with callouts give a clear picture of the story.
a. Story points are assigned during Grooming.
b. Dev and V&V have to agree on points. Sometimes small
development tasks can require significant V&V, so points reflect the total
effort.
10. During the Planning session for each sprint a common set of tasks
needed to achieve a “Done” Status is added to each story (see list below)
11. Sprint Begins
12. Dev and V&V must be complete for a story to be DONE
· Design in Confluence Complete
· Requirements in Doors Complete
· Dev Complete
· Unit Tests Complete
· Test Cases & Scripts Traced to Requirements Complete
· Screen Crawler Complete
*From: *Michael Wollin,
*Date: *Thursday, September 1, 2016 at 8:42 AM
*To: *Steve, Susan ,
*Subject: *Re: Thursday's Meeting for Project X
You can take this approach if you so choose, but it is completely waterfall.
*From: *Steve,
*Subject: **Re: Thursday's Meeting for **Project X*
*Date: *September 1, 2016 at 8:59:44 AM PDT
*To: *Michael Wollin, Susan ,
I disagree that this is “completely” waterfall. I’m happy to discuss
with you. We do Agile within Waterfall in compliance with the AAMI TIR45
process. I see the steps below as Completely Agile per feature.
To Michael’s point, what is the intended purpose of the meeting? Are we
evaluating the whole process, or just looking to improve efficiencies for
V&V? I think both are worthwhile; I’m just looking for expectations. Glad
to participate in both.
Thanks,
Steve

[Silvana Wasitova [e-mail] [SCRUMDEVELOPMENT]]

They may be new to agile, or have been doing "scrumbut" for a while -in which case what they need is guidance to what agile is, and a modeling behaviour for how to do it.
E.g. the phrase "I am looking for is the agreement of the flow through the system"can mean any of these:  1. I want the team to understand and follow the existing "standard flow"  2. THere is an existing flow, and the team can tweak t  3. The team can define its own flow, and tools (is jira optional?)
Is there understanding and appreciation for a light-weight process? I'd start with those questions, and help the team improve in future sprints :) Silvana Wasitova Skype: wasitova | LinkedIn: http://www.linkedin.com/in/wasitova

From: "Adam Sroka ***@gmail.com [SCRUMDEVELOPMENT]" <***@yahoogroups.com>
To: ***@yahoogroups.com
Sent: Friday, September 2, 2016 3:35 AM
Subject: Re: [SCRUMDEVELOPMENT] Coaching away from a waterfall requirements process

  I would have an ongoing conversation with them where I brought it back to the manifesto values and principles. Challenge them to truly live them, while giving them some room to do stupid process stuff and then learn from the mistake. Measuring the system would be a good idea, because then you have ammunition when a bad idea slows productivity. That can be a double-edged sword, though. 
Good luck. I have been in similar situations and not enjoyed them. 

On Thu, Sep 1, 2016 at 1:44 PM, Michael Wollin ***@mercurysw.com [SCRUMDEVELOPMENT] <***@yahoogroups.com> wrote:

  Yeah. I know. 
I'm looking for a powerful way to say what needs to be said that will make a difference. That conversation is deeper than agile coaching. Inside of their concerns in their occurring world that has them want to do agile, there is a way to reach them. 
On Sep 1, 2016, at 12:37 PM, Adam Sroka ***@gmail.com [SCRUMDEVELOPMENT] <***@yahoogroups. com> wrote:

  I would have to know more about the context to be sure, but I don’t see any indication that these folks understand Agile. I see an awful lot of stuff about processes, tools, comprehensive documentation, following a plan, “sign offs,” etc and essentially nothing about any of the stuff on the left side of the manifesto. In fact, I would go as far as to say that this is the kind of stuff the manifesto authors were arguing against explicitly. 

On Thu, Sep 1, 2016 at 9:31 AM, Michael Wollin ***@mercurysw.com [SCRUMDEVELOPMENT] <***@yahoogroups. com> wrote:

  Am I on solid ground? This is hand-offy to me. It has four extra meetings for Dev, not including the backlog grooming meeting. I could be wrong though. What do you think?
Susan is a PMP ACP charged by V&V (QA) to streamline process. Steve is a highly experienced PO. I am the department’s agile coach consultant. I don’t know who Jon is. :)[not their real names]

Begin forwarded message:
From: Susan 
Date: Wednesday, August 31, 2016 at 5:16 PM
To: Michael Wollin, Steve 
Subject: RE: Thursday's Meeting for Project X One of the key takeaways I am looking for is the agreement of the flow through the system and creation of tasks in JIRA by both Dev and Test – get agreement on what the JIRA tool is used for. I am also looking to have agreement regarding what the Rational tool is used for (and what it is not used for). From: Michael Wollin,
Date: Wednesday, August 31, 2016 at 5:37 PM
To: Susan , Steve,
Subject: Re: Thursday's Meeting for Project X This may be a tall order. It may also be premature. People not well trained in agile or not bought into it might force a “compromise” that in the final analysis doesn’t serve the department or the company and that thwarts agility.  From: Steve,
Date: Thursday, September 1, 2016 at 7:31 AM
To: Michael Wollin, Susan ,
Subject: Re: Thursday's Meeting for Project X Good morning. We have an agreement on this flow now. I don’t mind sharing it.  Jon can speak to how he is feeling about the current process meeting V&V needs.  In a nutshell:1.      Product Owner first gathers user needs/use cases from stakeholders2.      A Feature Page is created in Confluence to start sharing Goals, Business Intent, Assumptions, Risks, and User Needs for each feature (Example:[link to requirements spec form removed])3.      Dev and V&V participate in the review of these needs with UX and HF teams4.      JIRA stories based on the agreed user needs are created in the backlog, assigned to an Epic and a Version5.      UX presents designs to support the user needs.  Dev and V&V participate in the review.6.      UX presents final designs with “callouts” (the implementation details).  All stakeholders (Marketing, PO, Dev, HF, and V&V) review and approve.7.      We need to come up with a long-term plan, but for now the PO, V&V, Dev, and UX create the entries in Doors to support the agree functionality.8.      The team then meets to approve the Doors entries.  For items that are shared between projects, this can take longer as we have to get approval from all teams working on affected products.9.      The Dev and V&V teams Groom the stories to ensure the JIRA story and the designs with callouts give a clear picture of the story. a.       Story points are assigned during Grooming.b.      Dev and V&V have to agree on points.  Sometimes small development tasks can require significant V&V, so points reflect the total effort.10.  During the Planning session for each sprint a common set of tasks needed to achieve a “Done” Status is added to each story (see list below)11.  Sprint Begins12.  Dev and V&V must be complete for a story to be DONE  Project X Sub-Tasks Needed to Ensure Each Story is DONE:·         Design in Confluence Complete·         Requirements in Doors Complete·         Dev Complete·         Unit Tests Complete·         Test Cases & Scripts Traced to Requirements Complete·         Screen Crawler Complete

 From: Michael Wollin,
Date: Thursday, September 1, 2016 at 8:42 AM
To: Steve, Susan ,
Subject: Re: Thursday's Meeting for Project X You can take this approach if you so choose, but it is completely waterfall.   From: Steve,Subject: Re: Thursday's Meeting for Project XDate: September 1, 2016 at 8:59:44 AM PDT
To: Michael Wollin, Susan ,
I disagree that this is “completely” waterfall.  I’m happy to discuss with you.  We do Agile within Waterfall in compliance with the AAMI TIR45 process.  I see the steps below as Completely Agile per feature. To Michael’s point, what is the intended purpose of the meeting? Are we evaluating the whole process, or just looking to improve efficiencies for V&V?  I think both are worthwhile; I’m just looking for expectations.  Glad to participate in both. Thanks,Steve  




#yiv5719034788 #yiv5719034788 -- #yiv5719034788ygrp-mkp {border:1px solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv5719034788 #yiv5719034788ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv5719034788 #yiv5719034788ygrp-mkp #yiv5719034788hd {color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 0;}#yiv5719034788 #yiv5719034788ygrp-mkp #yiv5719034788ads {margin-bottom:10px;}#yiv5719034788 #yiv5719034788ygrp-mkp .yiv5719034788ad {padding:0 0;}#yiv5719034788 #yiv5719034788ygrp-mkp .yiv5719034788ad p {margin:0;}#yiv5719034788 #yiv5719034788ygrp-mkp .yiv5719034788ad a {color:#0000ff;text-decoration:none;}#yiv5719034788 #yiv5719034788ygrp-sponsor #yiv5719034788ygrp-lc {font-family:Arial;}#yiv5719034788 #yiv5719034788ygrp-sponsor #yiv5719034788ygrp-lc #yiv5719034788hd {margin:10px 0px;font-weight:700;font-size:78%;line-height:122%;}#yiv5719034788 #yiv5719034788ygrp-sponsor #yiv5719034788ygrp-lc .yiv5719034788ad {margin-bottom:10px;padding:0 0;}#yiv5719034788 #yiv5719034788actions {font-family:Verdana;font-size:11px;padding:10px 0;}#yiv5719034788 #yiv5719034788activity {background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv5719034788 #yiv5719034788activity span {font-weight:700;}#yiv5719034788 #yiv5719034788activity span:first-child {text-transform:uppercase;}#yiv5719034788 #yiv5719034788activity span a {color:#5085b6;text-decoration:none;}#yiv5719034788 #yiv5719034788activity span span {color:#ff7900;}#yiv5719034788 #yiv5719034788activity span .yiv5719034788underline {text-decoration:underline;}#yiv5719034788 .yiv5719034788attach {clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 0;width:400px;}#yiv5719034788 .yiv5719034788attach div a {text-decoration:none;}#yiv5719034788 .yiv5719034788attach img {border:none;padding-right:5px;}#yiv5719034788 .yiv5719034788attach label {display:block;margin-bottom:5px;}#yiv5719034788 .yiv5719034788attach label a {text-decoration:none;}#yiv5719034788 blockquote {margin:0 0 0 4px;}#yiv5719034788 .yiv5719034788bold {font-family:Arial;font-size:13px;font-weight:700;}#yiv5719034788 .yiv5719034788bold a {text-decoration:none;}#yiv5719034788 dd.yiv5719034788last p a {font-family:Verdana;font-weight:700;}#yiv5719034788 dd.yiv5719034788last p span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv5719034788 dd.yiv5719034788last p span.yiv5719034788yshortcuts {margin-right:0;}#yiv5719034788 div.yiv5719034788attach-table div div a {text-decoration:none;}#yiv5719034788 div.yiv5719034788attach-table {width:400px;}#yiv5719034788 div.yiv5719034788file-title a, #yiv5719034788 div.yiv5719034788file-title a:active, #yiv5719034788 div.yiv5719034788file-title a:hover, #yiv5719034788 div.yiv5719034788file-title a:visited {text-decoration:none;}#yiv5719034788 div.yiv5719034788photo-title a, #yiv5719034788 div.yiv5719034788photo-title a:active, #yiv5719034788 div.yiv5719034788photo-title a:hover, #yiv5719034788 div.yiv5719034788photo-title a:visited {text-decoration:none;}#yiv5719034788 div#yiv5719034788ygrp-mlmsg #yiv5719034788ygrp-msg p a span.yiv5719034788yshortcuts {font-family:Verdana;font-size:10px;font-weight:normal;}#yiv5719034788 .yiv5719034788green {color:#628c2a;}#yiv5719034788 .yiv5719034788MsoNormal {margin:0 0 0 0;}#yiv5719034788 o {font-size:0;}#yiv5719034788 #yiv5719034788photos div {float:left;width:72px;}#yiv5719034788 #yiv5719034788photos div div {border:1px solid #666666;min-height:62px;overflow:hidden;width:62px;}#yiv5719034788 #yiv5719034788photos div label {color:#666666;font-size:10px;overflow:hidden;text-align:center;white-space:nowrap;width:64px;}#yiv5719034788 #yiv5719034788reco-category {font-size:77%;}#yiv5719034788 #yiv5719034788reco-desc {font-size:77%;}#yiv5719034788 .yiv5719034788replbq {margin:4px;}#yiv5719034788 #yiv5719034788ygrp-actbar div a:first-child {margin-right:2px;padding-right:5px;}#yiv5719034788 #yiv5719034788ygrp-mlmsg {font-size:13px;font-family:Arial, helvetica, clean, sans-serif;}#yiv5719034788 #yiv5719034788ygrp-mlmsg table {font-size:inherit;font:100%;}#yiv5719034788 #yiv5719034788ygrp-mlmsg select, #yiv5719034788 input, #yiv5719034788 textarea {font:99% Arial, Helvetica, clean, sans-serif;}#yiv5719034788 #yiv5719034788ygrp-mlmsg pre, #yiv5719034788 code {font:115% monospace;}#yiv5719034788 #yiv5719034788ygrp-mlmsg * {line-height:1.22em;}#yiv5719034788 #yiv5719034788ygrp-mlmsg #yiv5719034788logo {padding-bottom:10px;}#yiv5719034788 #yiv5719034788ygrp-msg p a {font-family:Verdana;}#yiv5719034788 #yiv5719034788ygrp-msg p#yiv5719034788attach-count span {color:#1E66AE;font-weight:700;}#yiv5719034788 #yiv5719034788ygrp-reco #yiv5719034788reco-head {color:#ff7900;font-weight:700;}#yiv5719034788 #yiv5719034788ygrp-reco {margin-bottom:20px;padding:0px;}#yiv5719034788 #yiv5719034788ygrp-sponsor #yiv5719034788ov li a {font-size:130%;text-decoration:none;}#yiv5719034788 #yiv5719034788ygrp-sponsor #yiv5719034788ov li {font-size:77%;list-style-type:square;padding:6px 0;}#yiv5719034788 #yiv5719034788ygrp-sponsor #yiv5719034788ov ul {margin:0;padding:0 0 0 8px;}#yiv5719034788 #yiv5719034788ygrp-text {font-family:Georgia;}#yiv5719034788 #yiv5719034788ygrp-text p {margin:0 0 1em 0;}#yiv5719034788 #yiv5719034788ygrp-text tt {font-size:120%;}#yiv5719034788 #yiv5719034788ygrp-vital ul li:last-child {border-right:none !important;}#yiv5719034788

[Tim Wright [e-mail] [SCRUMDEVELOPMENT]]

Hey, that process does seem to lean toward "processes and tools" rather
than "people and interactions". However, I've got a couple of questions
that might illuminate:


* What is the minimum lead-time for a story from conception to development
start? ie: if a new story was identified that was 'ultra high urgency',
then how many days does it take before the dev team can start work?


* How easy is it for the story to change once it's in a sprint? I've found
often that once development starts, unexpected things are found that
require conversations and change. The process below doesn't seem to mention
this.


Tim




--
Tim
021 251 5593
http://www.linkedin.com/in/drtimwright

Post by Michael Wollin ***@mercurysw.com [SCRUMDEVELOPMENT]
Am I on solid ground? This is hand-offy to me. It has four extra meetings
for Dev, not including the backlog grooming meeting. I could be wrong
though. What do you think?
Susan is a PMP ACP charged by V&V (QA) to streamline process. Steve is a
highly experienced PO. I am the department’s agile coach consultant. I
don’t know who Jon is. :)
[not their real names]
*From: *Susan
*Date: *Wednesday, August 31, 2016 at 5:16 PM
*To: *Michael Wollin, Steve
*Subject: *RE: Thursday's Meeting for Project X
One of the key takeaways I am looking for is the agreement of the flow
through the system and creation of tasks in JIRA by both Dev and Test – get
agreement on what the JIRA tool is used for. I am also looking to have
agreement regarding what the Rational tool is used for (and what it is not
used for).
*From: *Michael Wollin,
*Date: *Wednesday, August 31, 2016 at 5:37 PM
*To: *Susan , Steve,
*Subject: *Re: Thursday's Meeting for Project X
This may be a tall order. It may also be premature. People not well
trained in agile or not bought into it might force a “compromise” that in
the final analysis doesn’t serve the department or the company and that
thwarts agility.
*From: *Steve,
*Date: *Thursday, September 1, 2016 at 7:31 AM
*To: *Michael Wollin, Susan ,
*Subject: *Re: Thursday's Meeting for Project X
Good morning.
We have an agreement on this flow now. I don’t mind sharing it. Jon can
speak to how he is feeling about the current process meeting V&V needs.
1. Product Owner first gathers user needs/use cases from stakeholders
2. A Feature Page is created in Confluence to start sharing Goals,
Business Intent, Assumptions, Risks, and User Needs for each feature
(Example:*[link to requirements spec form removed*])
3. Dev and V&V participate in the review of these needs with UX and HF teams
4. JIRA stories based on the agreed user needs are created in the
backlog, assigned to an Epic and a Version
5. UX presents designs to support the user needs. Dev and V&V
participate in the review.
6. UX presents final designs with “callouts” (the implementation
details). All stakeholders (Marketing, PO, Dev, HF, and V&V) review and
approve.
7. We need to come up with a long-term plan, but for now the PO,
V&V, Dev, and UX create the entries in Doors to support the agree
functionality.
8. The team then meets to approve the Doors entries. For items that
are shared between projects, this can take longer as we have to get
approval from all teams working on affected products.
9. The Dev and V&V teams Groom the stories to ensure the JIRA story
and the designs with callouts give a clear picture of the story.
a. Story points are assigned during Grooming.
b. Dev and V&V have to agree on points. Sometimes small development
tasks can require significant V&V, so points reflect the total effort.
10. During the Planning session for each sprint a common set of tasks
needed to achieve a “Done” Status is added to each story (see list below)
11. Sprint Begins
12. Dev and V&V must be complete for a story to be DONE
· Design in Confluence Complete
· Requirements in Doors Complete
· Dev Complete
· Unit Tests Complete
· Test Cases & Scripts Traced to Requirements Complete
· Screen Crawler Complete
*From: *Michael Wollin,
*Date: *Thursday, September 1, 2016 at 8:42 AM
*To: *Steve, Susan ,
*Subject: *Re: Thursday's Meeting for Project X
You can take this approach if you so choose, but it is completely
waterfall.
*From: *Steve,
*Subject: **Re: Thursday's Meeting for **Project X*
*Date: *September 1, 2016 at 8:59:44 AM PDT
*To: *Michael Wollin, Susan ,
I disagree that this is “completely” waterfall. I’m happy to discuss with
you. We do Agile within Waterfall in compliance with the AAMI TIR45
process. I see the steps below as Completely Agile per feature.
To Michael’s point, what is the intended purpose of the meeting? Are we
evaluating the whole process, or just looking to improve efficiencies for
V&V? I think both are worthwhile; I’m just looking for expectations. Glad
to participate in both.
Thanks,
Steve

[Eric Gunnerson [e-mail] [SCRUMDEVELOPMENT]]

That is a lot of process.

My best advice is to try to subdivide the process into separate processes, with backlogs between them.

There is a “figure out what our feature backlog is” process, which is the first part of the list. That requires some input from dev, but it shouldn’t need more than a t-shirt size estimate.

There is a “What does this feature really mean?” process, which is about fleshing out a feature so that there is enough detail to start implementation. I think that probably includes UI design in this environment, though my experience is that if you can do UI design directly with the dev team when you do development, everybody will be a lot happier. But, baby steps


Finally, there is the “build this feature” process, which is all about taking those fully-defined features and implementing them.

If you can break those apart, that gives you process decoupling, and you should see migration of stakeholders towards the areas they care the most about. With a single process, everybody has to be involved. This can also give you a way to talk about inventories and queues - “in our current state we have 45 features in the ‘ready to implement’” state, which represents 4 years of projected work. I expect there will be a lot of changes in the details in the next few months, so it would be better if we focused only on the features that are up for the next 6 months.

Eric
From: ***@yahoogroups.com [mailto:***@yahoogroups.com]
Sent: Thursday, September 01, 2016 9:31 AM
To: ***@yahoogroups.com
Subject: [SCRUMDEVELOPMENT] Coaching away from a waterfall requirements process



Am I on solid ground? This is hand-offy to me. It has four extra meetings for Dev, not including the backlog grooming meeting. I could be wrong though. What do you think?

Susan is a PMP ACP charged by V&V (QA) to streamline process. Steve is a highly experienced PO. I am the department’s agile coach consultant. I don’t know who Jon is. :)
[not their real names]

Begin forwarded message:

From: Susan
Date: Wednesday, August 31, 2016 at 5:16 PM
To: Michael Wollin, Steve
Subject: RE: Thursday's Meeting for Project X

One of the key takeaways I am looking for is the agreement of the flow through the system and creation of tasks in JIRA by both Dev and Test – get agreement on what the JIRA tool is used for. I am also looking to have agreement regarding what the Rational tool is used for (and what it is not used for).

From: Michael Wollin,
Date: Wednesday, August 31, 2016 at 5:37 PM
To: Susan , Steve,
Subject: Re: Thursday's Meeting for Project X

This may be a tall order. It may also be premature. People not well trained in agile or not bought into it might force a “compromise” that in the final analysis doesn’t serve the department or the company and that thwarts agility.

From: Steve,
Date: Thursday, September 1, 2016 at 7:31 AM
To: Michael Wollin, Susan ,
Subject: Re: Thursday's Meeting for Project X

Good morning.

We have an agreement on this flow now. I don’t mind sharing it. Jon can speak to how he is feeling about the current process meeting V&V needs.

In a nutshell:
1. Product Owner first gathers user needs/use cases from stakeholders
2. A Feature Page is created in Confluence to start sharing Goals, Business Intent, Assumptions, Risks, and User Needs for each feature (Example:[link to requirements spec form removed])
3. Dev and V&V participate in the review of these needs with UX and HF teams
4. JIRA stories based on the agreed user needs are created in the backlog, assigned to an Epic and a Version
5. UX presents designs to support the user needs. Dev and V&V participate in the review.
6. UX presents final designs with “callouts” (the implementation details). All stakeholders (Marketing, PO, Dev, HF, and V&V) review and approve.
7. We need to come up with a long-term plan, but for now the PO, V&V, Dev, and UX create the entries in Doors to support the agree functionality.
8. The team then meets to approve the Doors entries. For items that are shared between projects, this can take longer as we have to get approval from all teams working on affected products.
9. The Dev and V&V teams Groom the stories to ensure the JIRA story and the designs with callouts give a clear picture of the story.
a. Story points are assigned during Grooming.
b. Dev and V&V have to agree on points. Sometimes small development tasks can require significant V&V, so points reflect the total effort.
10. During the Planning session for each sprint a common set of tasks needed to achieve a “Done” Status is added to each story (see list below)
11. Sprint Begins
12. Dev and V&V must be complete for a story to be DONE


Project X Sub-Tasks Needed to Ensure Each Story is DONE:
• Design in Confluence Complete
• Requirements in Doors Complete
• Dev Complete
• Unit Tests Complete
• Test Cases & Scripts Traced to Requirements Complete
• Screen Crawler Complete




From: Michael Wollin,
Date: Thursday, September 1, 2016 at 8:42 AM
To: Steve, Susan ,
Subject: Re: Thursday's Meeting for Project X

You can take this approach if you so choose, but it is completely waterfall.

From: Steve,
Subject: Re: Thursday's Meeting for Project X
Date: September 1, 2016 at 8:59:44 AM PDT
To: Michael Wollin, Susan ,

I disagree that this is “completely” waterfall. I’m happy to discuss with you. We do Agile within Waterfall in compliance with the AAMI TIR45 process. I see the steps below as Completely Agile per feature.

To Michael’s point, what is the intended purpose of the meeting? Are we evaluating the whole process, or just looking to improve efficiencies for V&V? I think both are worthwhile; I’m just looking for expectations. Glad to participate in both.

Thanks,
Steve

[George Dinwiddie [e-mail] [SCRUMDEVELOPMENT]]

Michael,

I think it would be interesting do a value stream mapping of the
proposed process and measure the time (including wait time between
steps) it takes to get from ideation to production.

As you say, this is a serial process, i.e. completely waterfall, but
arguing waterfall vs Agile isn't the point. What do Susan, Steve and Jon
want to accomplish?

- George

Post by Michael Wollin ***@mercurysw.com [SCRUMDEVELOPMENT]
Am I on solid ground? This is hand-offy to me. It has four extra
meetings for Dev, not including the backlog grooming meeting. I could be
wrong though. What do you think?
Susan is a PMP ACP charged by V&V (QA) to streamline process. Steve is a
highly experienced PO. I am the department’s agile coach consultant. I
don’t know who Jon is. :)
[not their real names]
*From: *Susan
*Date: *Wednesday, August 31, 2016 at 5:16 PM
*To: *Michael Wollin, Steve
*Subject: *RE: Thursday's Meeting for Project X
One of the key takeaways I am looking for is the agreement of the flow
through the system and creation of tasks in JIRA by both Dev and Test –
get agreement on what the JIRA tool is used for. I am also looking to
have agreement regarding what the Rational tool is used for (and what it
is not used for).
*From: *Michael Wollin,
*Date: *Wednesday, August 31, 2016 at 5:37 PM
*To: *Susan , Steve,
*Subject: *Re: Thursday's Meeting for Project X
This may be a tall order. It may also be premature. People not well
trained in agile or not bought into it might force a “compromise” that
in the final analysis doesn’t serve the department or the company and
that thwarts agility.
*From: *Steve,
*Date: *Thursday, September 1, 2016 at 7:31 AM
*To: *Michael Wollin, Susan ,
*Subject: *Re: Thursday's Meeting for Project X
Good morning.
We have an agreement on this flow now. I don’t mind sharing it. Jon can
speak to how he is feeling about the current process meeting V&V needs.
1. Product Owner first gathers user needs/use cases from stakeholders
2. A Feature Page is created in Confluence to start sharing Goals,
Business Intent, Assumptions, Risks, and User Needs for each feature
(Example:/[link to requirements spec form removed/])
3. Dev and V&V participate in the review of these needs with UX and HF teams
4. JIRA stories based on the agreed user needs are created in the
backlog, assigned to an Epic and a Version
5. UX presents designs to support the user needs. Dev and V&V
participate in the review.
6. UX presents final designs with “callouts” (the implementation
details). All stakeholders (Marketing, PO, Dev, HF, and V&V) review and
approve.
7. We need to come up with a long-term plan, but for now the PO,
V&V, Dev, and UX create the entries in Doors to support the agree
functionality.
8. The team then meets to approve the Doors entries. For items
that are shared between projects, this can take longer as we have to get
approval from all teams working on affected products.
9. The Dev and V&V teams Groom the stories to ensure the JIRA story
and the designs with callouts give a clear picture of the story.
a. Story points are assigned during Grooming.
b. Dev and V&V have to agree on points. Sometimes small
development tasks can require significant V&V, so points reflect the
total effort.
10. During the Planning session for each sprint a common set of tasks
needed to achieve a “Done” Status is added to each story (see list below)
11. Sprint Begins
12. Dev and V&V must be complete for a story to be DONE
· Design in Confluence Complete
· Requirements in Doors Complete
· Dev Complete
· Unit Tests Complete
· Test Cases & Scripts Traced to Requirements Complete
· Screen Crawler Complete
*From: *Michael Wollin,
*Date: *Thursday, September 1, 2016 at 8:42 AM
*To: *Steve, Susan ,
*Subject: *Re: Thursday's Meeting for Project X
You can take this approach if you so choose, but it is completely waterfall.
*From: *Steve,
*Subject: **Re: Thursday's Meeting for **Project X*
*Date: *September 1, 2016 at 8:59:44 AM PDT
*To: *Michael Wollin, Susan ,
I disagree that this is “completely” waterfall. I’m happy to discuss
with you. We do Agile within Waterfall in compliance with the AAMI
TIR45 process. I see the steps below as Completely Agile per feature.
To Michael’s point, what is the intended purpose of the meeting? Are we
evaluating the whole process, or just looking to improve efficiencies
for V&V? I think both are worthwhile; I’m just looking for
expectations. Glad to participate in both.
Thanks,
Steve