Open Practice Library basics: Showcasing and improving

The Open Practice Library is a repository of open practices and principles used during engagements by Red Hat's Open Innovation Labs. In the previous post in this series, we discussed how to plan and execute a sprint/iteration. In this post, we will talk about showcasing our work and continuously improving. 

End-of-Sprint Demo

An end-of-sprint demo, or showcase, is the team’s chance to show off all of its hard work. 

Many teams may feel skittish about presenting an incomplete product to stakeholders and management. However, this is an important part of the feedback loop for the team and can often be a much-needed reality check for stakeholders and management.

Demonstrations can be facilitated in-person or remotely and do not need to be very formal. In fact, they should be relaxing and fun. This is the chance for the team to show off and gather feedback from its stakeholders, to describe any difficulties it may have had, and most importantly, to celebrate successes, no matter how small.

It is important to note that a demo applying all of these tips may very well require one hour or more of everyone’s time to complete, especially for larger teams or larger groups of stakeholders. This is not always possible to accommodate. The team should make every effort to apply what makes sense for it and its stakeholders to convey the desired information, receive feedback, and respect the time of participants and attendees.

Naturally we have some tips for maximizing the gains possible when facilitating a remote or in-person demo.

Show and talk about each completed story

Even stories such as writing documentation could be demonstrated by walking through the created or updated document. Even though project managers and executives favor more business-critical functionality over documentation, audiences tend to enjoy seeing just how much documentation was written—especially when it includes diagrams—and appreciate the “bird’s eye view” of the content.

Other examples of things to showcase:

• Wireframes and mock-ups.

• Working and “broken” code.

• User interaction.

• Backend processes.

• Meeting minutes.

Always have an agenda

Always make sure that everyone who completed a story or helped complete one gets a turn to speak about what they did (if they want).

At a minimum, a showcase or demo should include an agenda containing:

• Welcome/Introductions.

• Description of the Sprint/Iteration goal.

• A transition to team members presenting what they completed.

• Dedicated time in the end for Q&A, open discussion, and or feedback from the audience.

Make this the first slide so that everybody can see each member’s name on the big screen, or in the video conference. This is a huge morale booster and can often help quieter team members get noticed by managers and stakeholders who may not fully grasp the impact those team members have on the product.

Also, be sure to add the agenda to the calendar invitation you send potential attendees so that they can know ahead of time what to expect and prioritize their schedules accordingly, especially in the case of a long demo session.

Timebox your demo

Give everyone five to eight minutes to present their portion of the work completed. 

This has two benefits: 

1. It respects everyone’s time, and 
2. For the space of that time, only the speaker “has the floor” and can present without distraction.

Showcase what didn’t get finished

This is important because you’re showing what was accomplished, and even an incomplete story has merit. 

Perhaps that incomplete story presented could be helped by a stakeholder who didn’t realize what they were asking for required additional thought or time to complete. 

Maybe after seeing what was incomplete, the definition of that feature needs to be changed. Or maybe there was a blocker that someone attending the demo could assist with.

Dedicate at least 10 minutes of scheduled Q&A time

This is where the team can receive feedback and discuss the project’s direction, additional needs (if any), assumptions that were challenged or confirmed, and expectations with stakeholders. This is arguably the most important part of the demo and should be given everyone’s full attention.

Invite everybody

The most important participants for a demo to take place might be the team and its immediate stakeholders. However, the team should not discount inviting any external team whose work is impacted—and should consider inviting everyone. This includes executives, security, support, accounting, everyone. Everyone!

When a team invites as many people as possible to its demo, it opens itself up to a lot of scrutiny and a lot of praise. Many companies struggle with “silos” or the feeling of “the left hand not knowing what the right hand is doing.” A team’s end-of-sprint demo is the perfect opportunity to create a culture that reduces those problems. 

Perhaps a member of the security organization sees what the team is doing and can offer advice, expertise, or already completed research that unblocks future work. Maybe someone in support has a customer question that the team can answer. 

Or maybe an executive who typically is stuck travelling worldwide for meetings gains some perspective on your product, netting your team additional funding to expand operations. 

If the team limits the demo, the successes are limited—or worse, never recognized, allowing misconceptions to persist. When a team invites everyone, it invites the company’s full weight and support to participate in and celebrate its success. 

Invite everyone!

Sprint Retrospective

Sprint Retrospectives are where continuous team improvement truly happens. 

After the sprint and end-of-sprint demo are complete, the team discusses how things went. Importantly, a retrospective is not the place for a “blame game.” As we mentioned in the previous post, the team should offer a safe environment for all members to speak up, so a retrospective session should not end with team members feeling attacked or belittled. 

Real-time retrospectives are a great tool to check in with your team members individually to get their thoughts on how the retrospective went for them. If there are concerns, address them as a team so that everyone can feel comfortable sharing their thoughts. 

There are many different retrospective formats available, and all of them are useful. Ideally, the retrospective allows the team to focus on actionable ideas based on the lessons learned from the positive and not-so-positive observations during the sprint and demo. 

This is an important activity, and if the team is committed to improving its delivery capability and addressing the top one or two actionable ideas for each sprint/iteration, this practice will pay dividends many times over.

A simple retrospective format that directly addresses the key types of topics to be raised is “HHH”: “Helped,” “Hindered,” “Hold Up!”

Make three columns on a shared document or board with the titles “Helped,” “Hindered,” “Hold Up!”. Taking turns, the team should fill out each column with what “Helped” the sprint and demo, what “Hindered” the sprint and demo, and what made someone say “Hold Up!” or left questions unanswered. 

Once everyone has had a chance to add their points (don’t worry if you do not come up with a point that fits each column!), the team addresses each item raised. This is where the team builds a shared perspective on what happened, intending to improve upon for the future. Once the initial discussion is complete, it’s time to come up with action items. 

Generally, things that “Helped” the sprint and demo should be continued and don’t require additional action. 

Things that “Hindered” the sprint and demo should be addressed. Ask yourselves, “What can we do to improve this?” then begin crafting a story around it for inclusion in the backlog. 

Next, address questions in the “Hold Up!” column. If they can be answered during the session, great! If not, write stories with the express purpose of getting those questions answered and place them in the backlog.

The resulting stories should have someone on the team as an owner. That isn’t to say that one person owns all of those stories, but each person on the team should pick one to care for and resolve. 

Many of these action item stories may very well require asking stakeholders, management, or support teams for assistance. Sometimes they may need meetings scheduled to address them. 

These situations are all valid and should be tracked like any other story in the backlog: They should conform to the Definition of Ready and Definition of Done as closely as possible, have a points value assigned via Relative Sizing, and should be prioritized for inclusion in an upcoming sprint. They should also be showcased in an End-of-Sprint Demo.

Conclusion

In this article, we discussed showcasing the team’s work via an End-of-Sprint Demo and conducting a simple Retrospective that can be acted upon to improve continuously. 

Do not be alarmed if your team’s first attempts at applying these practices seem rough and unrefined. It’s a learning experience, and what is important is that the team grows together. Also, do not worry yourself with trying to apply every tip in this or the previous articles. When in doubt, err on the side of simplicity and work your way up based on the needs of your team and organization.

The core practices described in this article and others in this Open Practice Library Basics series can help your team go a long way toward delighting your customers and adding value to your organization. 

In various combinations, the practices we’ve described are currently being taught to Red Hat customers via myriad services offerings, from Red Hat OpenShift 4 engagements to Red Hat Open Innovation Labs Residencies, Red Hat Open Transformation Engagement offerings and beyond. 

If your team or company is looking for new ways of working to drive a culture of innovation, a reduction in time to market for your products, or to solidify your place as a leader in your industry, schedule a discovery session to find out how Red Hat can help you accomplish your company’s goals.