At Made we host regular client showcases, this is an opportunity to sit down with the client to discuss how the iteration and the project as a whole are progressing.
Who should be involved with a showcase?
The most important people to be involved in a showcase are the developers working on the iteration and the key stakeholders on the clients side. A showcase cannot happen without these people. Additionally, any members of the client’s business whose lives will be improved by the work carried out ought to be involved, such as a customer service representative or an e-commerce manager. These people will have valuable, on the ground insights into existing problems it should solve and potential challenges the work may introduce before it’s too late.
An alternative showcase can be one made internally, to educate other teams in your organisation on things you’ve learned, the project you’ve been working on, any reusable software you’ve built and practices you’d like others to adopt. It’s important to do this formally as a showcase, because it allows people the opportunity to comment and give feedback. You don’t get this kind of honest technical feedback from clients, so it can be more than a chance to share, it can be invaluable peer review.
Why do good software teams showcase?
A showcase is a prime time to get your work in front of all key stakeholders to demonstrate how your work is progressing, and how this impacts the project and their business. It is extremely important to have these regularly, to ensure client and developer expectations are kept in sync. Without this regular contact point, delivered work may fall short in some areas and over-deliver in other areas, both of which are a waste of developer time and the clients resources. By instead ensuring you and your client are on the same page, everybody will be happy with the delivered iteration, and any potential problems will surface before it’s too late, again saving time and money.
Additionally, by involving people in the showcase who will actually personally benefit from the work being done, this gives you an opportunity to demonstrate and teach processes and functionality to these end users. We notice this in particular when building new tools for businesses. Overall it reduces the time spent up-skilling these people later on, and gives them a good opportunity to recommend improvements.
Furthermore, a showcase is an excellent forum to openly discuss any feedback the client may have on the past iteration and the shape of the project in general, and to line up the goals of the next iteration if relevant.
We’ve found it useful to give internal showcases to people outside of the project team, so that we can update everyone across the company on what the team have achieved, what they’ve learned, any practices the wider team should adopt or avoid, and any technical achievements that could be co-opted into other projects.
Introducing better showcases into your team
Things which are important to consider when introducing showcases in a project are structure and frequency. Enforcing good structure in your showcases will ensure the time is well spent for all parties. Make sure the first and most important part of the showcase is demonstrating what you’ve been up to, discussing any problems you faced and solved and any problems you still have, whilst not allowing interruptions or tangents to take place until the end. The benefit of this is clients have time to consider, condense and prioritise feedback, and those leading the showcase are able to make all of their points undistracted.
Additionally, showcases provide a personal growth opportunity for developers. We believe showcases should be led by developers. This puts a certain amount of pressure on them, but we think it’s beneficial pressure to have, because they are the people with the best understanding of the work, the people who can most easily gauge and accept feedback and the people who will have to carry out the rest of the work. Additionally, it encourages their best work as they know they will have to stand up and be accountable for it in front of clients. We’ve found this kind of growth is often best achieved by pushing people in at the deep end and providing them with a float, rather than wading them in gently. This sink or swim approach sounds brutal, but encourages autonomy and personal confidence in the individual.
Preparation
During an iteration we find it useful to keep note of all the wins and challenges we’ve had, on top of the tasks we’ve completed. This enables us to easily prepare a run down of the iteration. These run down documents then get stored inside the project, similar to a changelog to provide a contextual history of a project.
After the run down has been prepared it is often valuable to run through it with other members of the project team to ensure smooth delivery, and catch any shortcomings, complexity, and omissions. This is particularly important when finishing an iteration where it is important to put your best foot forward and deliver a slick demo.
Additionally, a practiced showcase enables you to efficiently time-box the demonstration, as an ideal showcase lasts a maximum of 10-15 minutes. If you find your showcases are longer than this, consider shortening your iteration times and focusing on smaller chunks of work. Keeping it concise also means you also allow time for questions, feedback, and thoughtful discussions about the work presented.
Mid point showcases
A mid point showcase is an opportunity to present work in progress and ensure the client’s expectations are being met before the end of the iteration, where it may be too late to change, and certainly more costly. Having frequent showcases allows them more opportunity to give feedback and have more of a say in the way a feature is developed. Developers may also discover areas of improvement over the original specification of the feature, having built and used it. Features are often not built exactly to specification; UX and UI changes are made throughout the build and, as web professionals, we’re well placed to make this kind of feedback to our clients.
Secondly, as this is work in progress, it’s important you make this clear to the client beforehand, so they’re confident you’ll be able to work on the fine details together, and focus on whether the high priority, wider feature is being completed correctly. For example, frontend tweaks can be made, but the backend logic is coming together as they wanted. If you do receive any feedback, it is important to keep it focused on the demonstrated functionality, not inflate the scope of the iteration, and to do your best to only capture top level information as more detailed discussions should be made with the client when you come to address it. You want enough to be able to triage it later, but not so much that the showcase goes on too long or anybody loses focus.
It’s also an excellent opportunity to set expectations early if you feel you won’t complete the piece of work by the end of the iteration, and give clear honest reasons behind this, for example if a “quick win” task which we didn’t expect to take long ended up taking a day. This will prevent the team from having to break bad news at the end of the iteration when work is incomplete, when the client was expecting fully featured work. Being honest about these problems builds a better relationship with the client and ensures they understand that you faced an unforeseen problem, and not that the team were slacking off. It’s positive to build this relationship of trust, and that comes from openness.
Additionally, bringing up adversity early gives the client an opportunity to back out early rather than wasting further time. For example, if the team was to discover the work would take twice as long as expected, the client should have an opportunity to re-evaluate their business priorities if they have other high priority features that may now be considered more valuable. Furthermore in this situation they may want to park the other work if they were depending on the time staying fixed, as they have other time sensitive work upcoming.
End of iteration showcases
The primary purpose of the end of iteration showcase is for the team to present all the work they’ve agreed to deliver, excluding any work previously removed from the scope of the iteration, which should have happened at the mid point showcase. Not to mention, a perfect time to show off.
During the showcase you should make a point to highlight unseen wins, for example shining a light on complexity within the iteration where it existed. This builds your client’s confidence in your teams ability to deliver technical work and solve problems. Also point out areas where the team have gone above and beyond to deliver unexpected value. You can often find easy opportunities to improve a feature by chance, that is a quick win to implement, and highlighting these value adds delights the client. This promotes a more trusting “Adult to Adult” relationship. It will be beneficial to the ongoing project if you are seen as partners rather than contractors.
If you’ve taken the time to implement additional functionality to help an end user, which you believe will save the client time and money in the long run, you should take the time to point these out as well.
Although ideally the work your team has delivered will be as expected by the client, often additional requirements fall out of new features, which should be captured at the end of your showcase. If they are minor tweaks, these new requirements should be stored in your project backlog and then prioritised by the client. However you will sometimes begin to pad out the next iteration off the back of a final showcase.
Post Showcase
The time after a showcase, before the next iteration begins, is a good chance to reflect on the iteration. It’s worth congratulating everybody on a job well done by highlighting things individuals, and the team as a whole, did well, and which you’d like to see happen more. You should also take the time to evaluate areas of the delivery and development of the iteration which didn’t go so well, which should be learned from for all future iterations. To name a few examples, if the iteration was slowed by interactions with a third party which could have been mitigated beforehand by starting conversations earlier, if you began work before the design was finalised, or if you waited too long to get code into a production environment. These are all lessons we’ve learned from over the years.
Furthermore, when celebrating triumphs and learning from shortcomings, it is important to share this with your wider organisation. For example, if you’ve solved a recurring or complex technical problem and produced a reusable solution which other teams could use, or discovered a flaw in a company process which you’d like to evolve together. Keeping these learnings to yourself can cause fragmentation in the knowledge of different teams, and prevent you from raising everybody up together. A rising tide lifts all boats.
Conclusion
To reiterate, hosting frequent structured showcases, is an excellent way to keep lines of communication open, and ensure client expectations always meet your own. Having developers run these makes them accountable, promotes autonomy, and boosts confidence. You should use them to share your work, capture constructive feedback, and backlog new requirements.
Don’t be timid when you encounter adversity, and involve the customer when you do. This ensures they are able to make informed, timely business decisions. After your showcase learn from your strides, and miss-steps, and take the time to spread this knowledge amongst the wider organisation.
A perfect showcase involves a minimal number of people for brevity, but these need to be the right people. You should invite key stakeholders along, like the project manager, as well as a relevant end user. Most importantly keep your client happy, and keep the work flowing!
About the Author
Seb Ashton
Lead Software Engineer at Made Tech
