Re: Coaching away from a waterfall requirements process

"George Dinwiddie [email protected] [SCRUMDEVELOPMENT]" <[email protected]> Thu, 1 Sep 2016 13:12:43 -0400
Newsgroups gmane.comp.programming.scrum.general
Organization iDIA Computing, LLC
Message-ID <[email protected]>
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

On 9/1/16 12:31 PM, Michael Wollin [email protected] 
[SCRUMDEVELOPMENT] 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
>
>
>
>
>
> 

-- 
  ----------------------------------------------------------------------
   * George Dinwiddie *                      http://blog.gdinwiddie.com
   Software Development                    http://www.idiacomputing.com
   Consultant and Coach                    http://www.agilemaryland.org
  ----------------------------------------------------------------------



------------------------------------
Posted by: George Dinwiddie <[email protected]>
------------------------------------

To Post a message, send it to:   [email protected]
To Unsubscribe, send a blank message to: [email protected]