Re: 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 [email protected]
[SCRUMDEVELOPMENT] <[email protected]> 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 [email protected]
> [SCRUMDEVELOPMENT] <[email protected]> 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 [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
>>
>>
>>
>>
> 
>