Tighten Your Feedback Loops
Communication and transparency are cornerstones in Agile, but there’s always opportunity to improve.
When is the last time you took a look at your team’s feedback loops and the frequency at which they take place? I bet you’re just going through the motions, and maybe in some regards have become complacent with how the team operates. We’ve all been there, and when this happens, we need to revaluate and strive to change things for the better. Delivery may be slow, requirements may be missing, and as a result team morale may suffer. These are my thoughts on how to combat this, and how your team can tighten those feedback loops.
Iterate
One downside to leveraging cloud-based platforms like AWS and GCP is the additional effort engineers need to exert to delivering software products. Sure, we can codify our infrastructure, run apps in containers, and use CloudFormation Templates to expedite resource creation, but this all comes at a cost up front. Teams seem to build their entire ecosystem upfront, which requires little to no product owner involvement, and thus provides limited feedback to the team. As a result, teams need to be challenged now, more than ever, to think of ways they can iterate on the products they deliver, specifically when they’re net new.
Daily Sell
Daily what? A daily sell was first introduced to me in 2017 as a means for teams to demo (i.e. sell) the work they’ve completed that day and get feedback on it. Teams can deliver faster than ever and, as I mentioned in my last post, the strict release cadences and 2-week sprints have fallen to the wayside. Teams can push products to production with the click of a button, daily if they choose, so just in time feedback is critical. Run similarly to that of a Sprint Demo, the Daily Sell is typically a quick 15-30 minute session for the engineers to share what they’ve done with their product manager or stakeholders. It’s meant to be brief to ensure the best use of time, and can result in valuable feedback before calling development done, or before a release. These sells are even useful for engineers, who often use them for code reviews as a means to get feedback from everyone, or share their solutions with the rest of the team.
No more sprints + no more sprint demos = hello Daily Sell!
Service Delivery Review
Last but not least, as many organizations and teams make the shift to Kanban, an often forgotten about tool is the Service Delivery Review. For an in depth post about this, check this out, but in short these SDRs help teams evaluate their fitness for purpose and ability to meet their customer’s needs. Unlike Retrospectives that take an internal or inside-out view at the team and how things are trending, the SDR looks at the team from the outside in. Within this meeting, we can take a quantitative look at the team’s ability to deliver, due date performance, work-type mix, and product performance overall. For my implementation of SDRs, we use it as a means to discuss the explicit policies that go hand in hand with Kanban and our ability to deliver, too.
Automate!
While not exactly a secret or a meeting you should be having, we all know that automation can go a long way in making things easier for us! Don’t rely on your team to remind you, or for you to remind yourself to schedule feedback-based meetings. Whether it’s a SDR, Daily Sell, or Retrospective, sit down with your team, setup some norms or policies that include a cadence for these feedback-based meetings, and get recurring meetings on the calendar! You’ll be more likely to hold these sessions if they’re already scheduled; you can thank me later.
As always, if you made it this far, thank you for reading! Let me know if you try any of these in the comments, or if anything in particular resonates with you. That’s all for today!