Nailing the requirements and vision are key to any successful project. Throughout my career and in working with multiple clients, the review (aka playback or demo) has proven one of the most important practices for communication and demonstration of progress. I was taught this technique long before I practiced Scrum and it fits perfectly with process-related projects. In this blog, I hope to overview this agile practice and provide some benefits and risks to using it on your projects.
What is a Review / Playback?
In Scrum (the methodology we use here at AVIO), the goal of the sprint review is to demonstrate the working software that the team has built during the current sprint. Typically, I like to have teams recap their goals for the sprint, then dive into demos and discussion around the progress this sprint. If possible, the sprint should have a theme or story — recap that for the audience and then demo the tool or software. A clear story will help with communicating the sprint goals, but can also help with context when demonstrating more technical pieces of software like services or integrations. The meeting should be an informal and open discussion.
For example, if your sprint is two weeks long, this meeting will occur on the last Thursday or Friday of the sprint. A playback might also prove beneficial mid-sprint as well depending on the audience and where you are at in the project. If you are modeling a new business process, playbacks may occur daily with a smaller team to get things right before demo’ing a working systems to the main audience. In the Oracle BPM Process Composer, the playback feature is built in, including “running” an instance through the process and through UIs developed within Composer. The same is true in the new Process Cloud Service (PCS). This enables the business and technical teams to quickly model and understand the goals of the process together. I have seen more lightbulbs go off in these sessions as the shared vision for the project is communicated and progress better understood by the larger team.
Who Participates?
In addition to the core team, it is common to see the broader business community, subject matter experts and partners from other programs or projects that are related to the core team. Other stakeholders and financial supporters may attend to “check in” on the progress. I have found it most effective to have users actually demonstrate the tool, process or solution vs. having a technical staff deliver it. This often resonates more with the delivery team and the broader stakeholder community to see “one of their own” running the demo. Having more than one person demo is also good as the team builds the skills and experience on how to best run a review session.
What are the Benefits?
- Reviews allow the project community to see the project coming together in a tangible way (vs. a status report!)
- They communicate to a broader audience outside of the core team, broadening awareness and understanding.
- One of the major risks of larger projects or those in a waterfall methodology is going long periods of time without feedback from the broader project team. Reviews help reduce that risk.
- Reviews allow the team to incorporate changes faster and adjust with broader feedback
- Enable building a better project faster, including reprioritizing for the next sprint
Most of our solutions at AVIO involve processes or user interfaces of some type and this methodology works very well with these types of projects. Playbacks work especially well with business process model development and UI development. It allows the broader team to see the progress in a very visual way.
What are some Risks or Pitfalls?
- A lack of progress will be clearly display as there will be nothing to demo. This may indicate problems upstream in planning, development or testing.
- The team should not need to take significant time to prep for the meeting. The goal is a working system, so showing a working process or working set of integrations is key — even if you need to use curl or SoapUI to demo something. A powerpoint should not be used, unless it is critical to recap or tell the story.
- Lack of honest feedback or no feedback at all from the audience. This could either validate a bad direction or not provide key feedback to the team and foster a false sense of progress.
Coming out of a playback, the team should have good feedback and be re-energized for the next sprint! Are you using reviews or playbacks on your process or integration projects? What is working well for you?