Agile2022 wrapped last Friday. Thank you Agile Alliance and Nashville! It had been a long time between in-person conferences for our amazing community of agilists, and we were thrilled to be part of it, as attendees, sponsors, and a speaker – our very own Colleen Johnson. The entire ScatterSpoke crew loved seeing so many new and familiar faces (and cool masks!) in-person after so long!
The fixed time interval between cadenced events can be a blessing and curse. Regular cadences bring consistency to our lives and make it easy for us to plan our days, weeks, and months. But, it’s easy to get comfortable with your cadence and miss opportunities to change it up and get new results. The COVID pandemic has taught us that we have to be adaptable and that cadences get disrupted in response to the events of the day. We used this lesson at Agile2022 and chose to adapt our retrospective practices with intentionality around our improvement goals.
We normally retro every two weeks, like so many other teams do. With only six dedicated sponsor events totalling a mere 20 hours over four days, we knew we had limited opportunities to connect with attendees, talk about ScatterSpoke, and learn from them. We have clear improvement goals for our team and we wanted to maximize our learning in this fast-paced, time-limited event, so we reduced the interval for our retrospective cadence to daily. Yes, you read that right. Daily retrospectives!
We held our retro each day after our booth closed at 3:45 PM. Our retros typically happened over a snack and beverage … as you do. We talked about:
- The events of the day - booth traffic, our best conversations, our worst conversations, the badges we didn’t scan.
- Our new elevator pitch - Is it working the way we expect? What’s working best after the pitch?
- Objections and blockers - You’re not FedRAMP authorized. We can’t use a cloud-hosted solution. We’re on Azure DevOps not Jira.
- Why we ordered so many koozies - How to give away more of the roughly one billion amazing, custom, Agile2022 koozies we brought! (Oops.)
To some those may sound like things we could or should have figured out before we landed in Nashville. But, for our small, young startup this is new for some of us. Our daily retros made a real impact on our approach, our shared understanding, our team, and our improvement goals. We made several refinements and went home with roughly one billion amazing, custom, Agile2022 koozies. (Some things are hard to solve.)
We can choose to disrupt ourselves when warranted to boost and enable our improvement too. The conditions that warrant changing your cadence will be specific to your teams and your context. You should consider changing your cadence when:
- The pace of your work significantly increases or decreases.
- The time constraint on your work changes. Shorter = more frequent. Longer = less frequent (...or does it?)
- You have a new improvement goal and you want to make sure it is clear, you’re putting the right amount of focus towards it, and you’re validating your initial results.
- You are a new team or have significant changes to your team.
Like so many things, there’s no one-size-fits-all answer here. Your context should drive your decision on this. In addition to the factors listed above, the quality of your retros and the maturity of your team and your practices are major factors to consider. Your context will lead you to a variety of answers and you might even wind up considering Just-in-Time retrospectives!
What can you actually do to make effective retro a reality? The good news is, it’s not as difficult as you might think. We’ve broken it down into 5 elements to make it as easy as possible to massively improve your sprint retrospectives.
Most engineering managers instinctively think of productivity as complex processes like workflows, solutions, and deliverables expressed in purely quantitative terms. The result is a dynamic that’s usually counterproductive. But there is another way.
Often that dynamic plays out in metrics and misguided attempts at fostering engineer productivity, usually by measuring the wrong things and offering the wrong incentives. Fortunately, there are better ways to use metrics to genuinely empower engineers to accomplish more.