The Cycle Review session which occurs at the end of every Agile cycle or sprint is a wonderful opportunity to re-connect the Team to the Product Owners or Clients.  Yet often this meeting loses value over time because of how poorly it is conducted, and rarely realizes its full potential.  This article is aimed mostly at people who facilitate this process, like account people or project/production management, and its content derived from our Cycle Operations Training curriculum that is part of our Agile-inspired project management methods.

Cycle Review: Purpose and Challenges

The Cycle Review meeting is intended to show the Product Owners the work that the Team has completed during the current (now ending) cycle or sprint.  This meeting is usually held on the last day of the cycle prior to the Cycle Retrospective meeting.  Since our methods focus on implementing self-empowered teams, one of the key objectives of the Cycle Review meeting is fostering a deeper conversation between the Team (people who create stuff) and the Product Owners (aka Clients).

In our methods, as in traditional Agile, the Team has  conversations with the Product Owners as part of planning and other review activities.  So on one level, they are familiar with speaking with Product Owners, but only in terms of requirements.  This presents a challenge in that the Team now has to explain implemented features/stories in a language and style different than that used internally between themselves during the Cycle.

If we consider as an example the walk-thru of a section or several pages of a website, the Team Member likely thinks of these pages in terms of the challenges faced during the development, and the areas that are most interesting to the Team.  Having spent several days looking at the pages (maybe 200+ page views) they will forget what it feels like to see the page for the first time, as will be the case for the Product Owners.  Non-obvious aspects of what has been done will feel obvious to the Team because of this repetition.  For example, that the nav (menu structure) has been completely reorganized will feel somewhat trivial and “old news” to the Team Member — it was likely easy to implement, and probably happened earlier in the process.  We call this type of focus a “Project” focus, reflecting “how” things are being done, versus the “Product” focus, which covers “why” it exists. what (business) purpose it serves.

This same challenge holds for pretty much any other kind of deliverable, like creative concepts, campaigns, etc.  This “blindness” is a key component in what account people mean when they say that a given person on the Team is not really “client-facing”.  These same account people (your author was one) always seem to forget that at some point in the past they had this challenge as well.  Avoiding this blindness is not hard to learn, it just takes some repetitions.  That’s what our Cycle Review method helps Teams do.  Here are a few key guidelines and an effective process for reviewing a web page (as an example).

Have the Team Pass the Ball

  • Make sure your team understands that everyone should get a chance to show off the work.
  • Ask them to design the sequence of things that will be gone through and evenly divide up the responsibilities.
  • Have them prep a list of what they are going to review.  If you’re using a Kanban already, then just use that.

A Simple Process for Reviewing a Page:

  1. Explain the purpose of the page BEFORE it is shown on the screen.  The minute you show the page people will not be able to hear a single word you say, because people’s brains process visual input over auditory.  “The page I’m going to show you has the new customer login widget which adds the capability to login with Facebook.”
  2. Explain the work that was done.  Start with the functionality and finish with the visual description.  “We changed the layout to accommodate the need to have the FB button showing, and because of that you’ll notice that the actual widget is now a reveal instead of open by default.”
  3. Show the page.  DO NOT SCROLL.  Let people look at the page for a few seconds.  Remember, they can’t listen and look at the same time.
  4. Transition to talking by describing what they are seeing. “What you’re seeing here is the top of our normal home page with no changes except in the upper right”.  DO NOT SCROLL.
  5. Describe the feature and every action you do, BEFORE YOU PERFORM THAT ACTION.
    • “As you can see the login widget is only partially revealed” [hover your mouse near it, but do not move the mouse excessively].
    • I’m going to mouse-over the widget and you’ll see it pop open [pause, and then mouse over, pause again].
    • Explain the obvious (to you): “As you can see the widget is pretty much the same as before, except we added the FB login button.”
    • Pause.  Really do pause. Don’t assume everything is obvious.
    • Tell them what you’re about to do: “I’m going to click on the FB button now, and when I do that, you’ll see a popup from Facebook.”
    • Click and pause for a few seconds after the popup appears.
    • Repeat this sort of transition (say-do-pause) every time you perform as action.
  6. Let them know that you’re at the end: “That’s pretty much everything that we did.”
  7. Ask for feedback and questions: “We would love to know your thoughts on what we have done or if you have any questions”.

Pass the Ball, Part Deux

Once the Team Member finishes, have them pass the ball to the next Team Member.

As an account person or project manager, resist the urge to moderate.  Between the Team and the Product Owner, they can run the whole thing…they just need a chance to do it.

Have the last Team Member ask for feedback from the Client/Product Owner on how the Team did in terms of presentation and if there are anythings that the Product Owner would like done differently this time.