Finding the right way to “show off”
You’ve heard Matt and our organization leads talk about the importance of milestones, goals, and recognition. I want to drill down into the team level, because wherever you are in an organization, your success and failure is entirely dependent on the output of your team(s). So let’s talk about team-level celebrations.
Agile ceremonies worked well at first
Our team has been an agile shop for some time now, so we’re no stranger to the ceremonies and celebrations. We may hold a record for having a sprint showcase every 2 weeks for the last 4 years. However, we’re now comfortable enough to break some of those practices to fit our evolving team needs, structure, and workflow.
Most notably, we have reduced the spotlight on grandiose celebrations like sprint showcases. They had grown to a point where the pressures to present smoothly in front of a growing audience overshadowed any gratifying sense of accomplishment. As our team grew in size and complexity, we noticed the following issues:
- Showcases and demo sessions were too large in population, crossing squads and leadership levels.
- There was always too much to cover in too little time.
- Any important topic worth showcasing almost always blossomed into a feedback or brainstorming session.
- There were too many to-do’s to “follow up on offline”.
Our new and improved ceremonies
We knew we had to change how to spotlight and celebrate the work we were doing without the pressure of doing a formal showcase. We evolved our practices and implemented the following activities to celebrate milestones:
- The team moved to holding ad-hoc showcases, reviews, and demos that include the most relevant parties. These can span across squads if necessary. This is a time reserved for in-depth review sessions, questions, and even brainstorming if needed. The outcome of a session like this may be to either continue building, take a couple steps back and course correct, or deploy as is — all of those outcomes are worthy of a celebration with the group involved. Closing this session with positive feedback shows appreciation of everyone’s time and attention.
- Release notes are published publicly in a place where our stakeholders can respond immediately (in Slack). There are few things in life that are as satisfying as watching emoji reactions fly in on a post that summarizes a new release. Trust me on this one.
- Lastly, we incorporated community calls for larger showcases, where we cover recent releases and upcoming topics. These sessions are open to stakeholders, colleagues, leadership, and any other interested parties. But most importantly, this gives team members the opportunity to present work they’ve taken ownership of rather than always having a manager present. This builds a strong relationship between engineers and the direct consumers of their hard work.
Peer-to-peer recognition is just as important
Every technical managers’ dream is to have their team enforce effective practices like architecture design sessions, rigorous code reviews, and coding to a style guide. Remind your team to acknowledge cases where teammates have embraced those practices. You’ll find that engineers often complement each other on things otherwise overlooked, like using nicely designed architecture icons or well documented API specs. We’ve found that to be the most effective way to keep ourselves on top of these processes, rather than enforcing it from a management perspective.
I hope this summary of our experiences provides clear experiments you can try with your team. Consider scheduling a large community call and having your engineers present their work. Or maybe run a sprint that consists of three mini-showcases, instead of one large one at the end. Best of luck.
Albert Avetisian is a Delivery Manager for our Hybrid Cloud Platform team within CIO Hybrid Cloud Platforms at IBM based in Armonk, NY. The above article is personal and does not necessarily represent IBM’s positions, strategies or opinions.
