Feb 8th, 2021
Lessons From the Field
Part 7: What Is Your True North?
Written by: Craig Vosper, Chief Delivery Officer
In my opinion, retrospectives have always been the most important ceremony within the agile framework. They represent the one time in which the entire team focuses solely on getting better. Part of my infatuation with this step comes from my experience in the Army. Every operation we executed, whether training or real, ended only after we had completed our After-Action Review (AAR). This activity mimics the one found at the end of each sprint in agile.
During my time as an agile coach, I quickly found that I could identify how well a team was performing just by sitting in on one retrospective discussion. Teams that left these retros with a list of action items would often be the highest performers, while teams not holding retros (or putting very little focus on them) tended to be the ones needing the most improvement. Retros are like practice for a sport. If all you do is play games, it’s difficult to get better!
At Clientek, we’ve found that retros start off well with new teams. The team is excited about the work they’re doing, and they provide significant input for ways to improve. Over time, however, teams start to get into a groove and their retros can get quiet and feedback becomes scarcer.
In order to combat this lack of participation we focus our teams on what we call True North - a state of nirvana that the team would like to achieve. This allows our teams to focus their retrospectives on achieving that nirvana and identifying ways to get closer to that state. At times, these goals might even describe a state you don’t believe is attainable, and in many cases, those can be the best kind!
Take some time with your team and define how your perfect team would perform, then focus your improvements on achieving that goal. To get you moving in the right direction, I’ve provided our “starting point” for teams to define their nirvana. Add and subtract items as necessary until you feel like you’ve identified that ideal state.
- Culture
- Team members feel comfortable disagreeing with each other and leaders.
- Team members do not fear failing.
- Team members own their commitments.
- Planning
- Objectives well defined and understood by all team members (stakeholders to developers)
- Releasable Features defined with agreed upon impacts on Objectives.
- Features sized and prioritized to create a release plan for 6 sprints out.
- Sprint Execution
- Requirements are clearly defined to show how PO will accept stories.
- Sprint tasks planned for and dependencies/handoffs identified during sprint planning.
- Test cases for each requirement are reviewed by development team and PO.
- Requirements are demonstrated as soon as completed within the sprint.
- PO accepts that all requirements have been met within the sprint.
- All activities required to move requirement to production have been completed.
- Development
- All code is reviewed via automated/manual processes and meets agreed upon standards.
- All code checked in using defined process.
- All check-ins/merges are built using continuous integration.
- All deployments are made using automated pipelines.
- All environment and build definitions are maintained in source control.
- Releases
- Regression tests identified are automated and run with every deployment.
- Production release done via automated pipeline.
- Go/No-Go performed 3 days prior to release.
- Post Release Smoke tests identified and automated.