Re: Coaching away from a waterfall requirements process

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



On 2 September 2016 at 04:31, Michael Wollin [email protected]
[SCRUMDEVELOPMENT] <[email protected]> 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 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
>
>
>
> 
>