It's Showtime!

Time to show what you've got

Showcases are part of the regular Agile development cadence. However I’ve worked at organisations that are ‘Agile’ yet don’t do them. Despite its name, showcases can have greater benefits than simply showing work.

Henrik Axelsson

Benefits of putting on a Show(case)

I’ve found regular showcases one of the most effective tools in the Agile bag of tricks.

Here are some of the things I’ve used showcases for:

Sharing your work

Well this one is pretty obvious. However sometimes teams don’t think the work they do is showcaseable, or that only ‘customer facing’ applications should be showcased. I believe that if you are taking a product based approach to your work (which you should be! see my other blog post [here](/devops/2017/09/26/productise_me.html)) showcases should definitely be part of your team’s rituals.

A product has customers. The best way to engage with those customers is to show them what you are building.

Keeping the team focused

One issue I’ve commonly come across in development teams is the ‘but in the future’ argument. Anytime a decision is about to be made someone says ‘but in the future we might need X’. This can often come from the best of intentions, but can impede progress toward a working product.

Having a regular showcase means the team must focus on getting something built for that week. Otherwise you have a showcase with nothing to show (seriously, still do the showcase!).

No matter how much requirements analysis you do, nothing clears up expectations quicker than by getting working software in front of people.

Keeping the team motivated

Showing off work to others and getting feedback on it, good or bad, can be a great way to keep the team motivated. Even not so good feedback means that someone actually cares about what you’re building enough to comment on it!

Knowledge sharing

Showcases don’t just have to be about the working software (although working software must be there!). Just as important can be sharing some of the pain, frustration, and joy behind developing that software.

For example, maybe your team tried adopting pair programming and found it really helped reduce the amount of defects in testing. Or perhaps you spent more time doing UI wire frame walk throughs with users which reduced the amount of rework necessary on the UI each sprint.

The story behind the software can sometime make people appreciate what they are seeing on screen.

Remove the fear of building the wrong thing

Getting a shared understanding of the “right” thing to build can be very very difficult. Some teams are petrified of building the wrong thing and being seen as a “bad” team. I found that convincing a team to show their work every week, and not worrying about the finer details of rightness, removed this fear.

At worst, if people don’t like what’s on display you lost a week of work. At best, you just saved hours and hours of meetings to come to the same conclusion. I’ve found that most people don’t really know what they want anyway until they see something in front of them and working.

Go forth and show!

Hopefully this has given you some food for thought on the different ways that showcases can benefit your team.