Project Management

Project Management Central

Please login or join to subscribe to this thread

Topics: Agile, Scrum, Stakeholder Management
Incorporating Legal Reviews in the Agile Process (Scrum)
Anonymous
If you are a team using scrum as your agile methodology, how do you engage and plan around work product reviews (before product release) that must be conducted by parties that are not members of the development team nor who attend the sprint planning and sprint review? For example, a lawyer who must review the final as-built implementation of a product before release to customers.

The following parameters apply:

- The reviewer is unable to provide prescriptive acceptance requirements and insists upon reviewing the as-built product, thus the team cannot simply collect better requirements and "build to specification" to avoid the review altogether.
- Reviews often result in (minor) changes to the product, so this review must be part of the definition of done. Performing this review after the sprint concludes would mean that the product increment is not releasable at the end of the sprint.
- Limiting the sprint goal to only that which can be designed, built, and reviewed by the reviewer within the sprint results in a sprint goal that accomplishes much less than the capacity of the development team.
- Reviews may take a variable amount of time ranging from a half day to a week, depending on the workload of the reviewer.
Sort By:
This is obviously not an ideal situation. As much as possible, you'd want the reviewers to:

a) provide their acceptance criteria at the time when the team is having their conversations with other stakeholders about work items leading up to a sprint

b) review the completed work items either as they are done during the sprint, during the sprint review, or delegate their review process to someone like the product owner

Failing this, you are accepting a constraint which will slow down the pace of delivery and potentially result in batching of multiple sprints worth of work with the resulting increased risk of rework.

Things which are within the team's control are breaking down the work items small enough so the individual item review time is minimized.

The SM or PM should then work with the legal team to explore options for accelerating delivery.

Kiron
A few points. One is inclusivity. Change the pattern of 'review' to 'partnership'. This will require a change in mindset and culture for the legal review team, spreading Agile ways of working further into the organization. Second, work to create a framework of regular touch points with the legal team and scrum team to for the scrum team to share work and elicit feedback. Third, within the team, rethink what stages of value the deliverable goes through, think of the MVP depiction using Mona Lisa. For instance, for a given effort, a story will get the team to the meeting with legal. The next story will take it further by incorporating feedback. And so on...

This makes the legal group part of the process from the beginning as a team partner. and not an afterthought with completed work handed off.

There are many inherent [potential] advantages that can be capitalized in this paradigm, such as an increase in quality and innovation.
I had a product that required a lot of legal reviews. We handled it in two ways.

First, the PO worked with legal upfront and captured their requirements before the Dev team started the work.

Second, when legal was concerned about a specific increment, they attended the sprint review.

I never had to go this far, but we could have also incorporated legal into our release pattern. If you're working with software and have any sort of pre-release review (user/feature/environmental), make them a part of that.
I would love Andrew's reply, but I also worked with stakeholders that (for various reasons) don't bend to Agile. A bit of upward education might be possible. Most likely, you have a situation where Agile was implemented for rapid product (i.e., software) delivery rather than reason d'etre in your business and you cannot manage up.

Why do Agile Scrum? You have two competing methodologies. Top-down (i.e. "I tell you when to do something.") vs. iterative, phase-based Agile Scrum (i.e., "we work together toward a common goal on an established cadence"). Since top-down is your management method - it will always win. The cadence of sprints is comforting and gives a sense of steady workflow but maybe it is not what you should do. My recommendations (no priority or order)
# 1. Try to remove Scrum-imposed same length iterations (i.e., two weeks sprints) and experiment with various sprint's length. Sure, your velocity will not be usable but velocity is used for long-term planning and your planning depends on acceptance of work by stakeholders.
# 2. Complete the same length sprints but create a separate cadence of demos. As you noted, the team has enough back-end work and only demoes a front-end to your stakeholders. You'll optimize your team's time and decrease the possibility that stakeholders will not approve the demo.
# 3. Complete smaller demos of MVP products. I bet that your stakeholders want fully-completed products, but if you slice it to MVP and reveal to them one part at a time (MVP of the working module and mockup how it fits into the whole product), you'll achieve incremental acceptance and higher customer satisfaction.

Please login or join to reply

Content ID:
ADVERTISEMENTS

"Always do right. This will gratify some people and astonish the rest."

- Mark Twain

ADVERTISEMENT

Sponsors