RE: Coaching away from a waterfall requirements process

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: [email protected] [mailto:[email protected]]
Sent: Thursday, September 01, 2016 9:31 AM
To: [email protected]
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