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. Saving Changes...
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 Saving Changes...
Drew CraigSr. Agile & Product Coach| VanguardPhiladelphia, Pa, United States
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. Saving Changes...
Wade HarshmanScrum Master| GDITIndianapolis, In, United States
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. Saving Changes...
Andrew SoswaTechnology leader| Leading global financial institutionElk Grove Village, Il, United States
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. Saving Changes...
Nils HyomaAgile Coach| Novatec Consulting GmbHHamburg, Hamburg, Germany
I was working closely with the workers council. It was pretty smooth working. Maybe a similar setup like this "problem".Here some key factors:
- The workers council attended the review, specially for the second part (!) of the review, the outlook for the next sprint.
- The workers council provided a list of goals or things which are a no gos. So everybody could check them while discussing requirements. You could call it part of definition of ready.
- In unclear situations the workers council was invited to the refinement session or asked directly. All requirement had a motivation, so the workers council could see that justification and gave input how to reach that goal with a different, better approach.
- Trust was builded between the team and the workers council based on transparency.
What you don't want:
Somebody who attends the review and tells the team the increment is not releasable. That would destroy all trust and motivation.
So involve stakeholder like legal or workers council in advance. They should be transparent too. That information should be at least in the Definition of Ready. Saving Changes...
"Humanity has advanced, when it has advanced, not because it has been sober, responsible and cautious, but because it has been playful, rebellious and immature."
