This morning in scrum we did three things: confirm that all of our tickets were ready to deploy (that is, we reviewed the work we had done and made sure everything was tested and prepared for this weekend’s rollout), conduct a retrospective on this sprint (that is, we talked together about what went well, what was problematic, and what we can do differently going forward), and plan for next sprint by reviewing our sprint and product backlogs.  If this sounds familiar, that’s because it is exactly what I wrote about two weeks ago when I started this ‘sprint in the life’ mini-series of blog posts.  At the end of each sprint we both look back on what we have accomplished and look forward to plan what comes next.

The backward look comes out of another key principle of Agile: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”  At the heart of Agile is this iterative feedback loop, in which both the software product and the team itself get better over time through quick responses and incremental changes.  We have ‘mini retrospectives’ when we encounter issues like we did this sprint, taking time for a mid-course reflection and correction as we attempt to improve our team process.  And we end every sprint with a more structured retrospective in which we take notes and make concrete plans to take clear steps toward further developing what works on our team and improving what did not go well.

For our sprint team, communication is a regular topic for our retrospectives.  Scattered as we are across different offices and time zones, on top of the fact that all of us are busy with multiple responsibilities, we have learned that we must pay particular attention to communicating well.  Whether writing up tickets, user stories, or emails to the team we strive to make our written communication as clear as we can.  We spend a fair amount of time each day talking face-to-face or over video conferencing, and I encourage everyone on the development team to ask questions whenever they don’t understand or aren’t clear about what I am after as a product owner.  Early in our work together the topic of how we communicate often showed up on the ‘what went wrong’ or ‘what to improve’ lists in our retrospective; now it usually hits high on the ‘what went well’ list.  That’s a great sign that these sprint-ending retrospectives are in fact helping us to ‘tune and adjust’ our behavior.

We also talk regularly about how well articulated our user stories were at the start of the sprint.  If you’ve been reading this series then you know we hit a problem in this area in the past two weeks.  We’ll need to look for ways to improve as we continue developing complex software products for a sophisticated market.  At the same time, part of what went well this sprint is our Agile-enabled ability to catch this issue when we did and to make rapid adjustments in our development to fill in the holes we identified.

Part of why we employ a retrospective in Agile is because we know that software development is a process in which we can always improve.  We aren’t just following static steps in a mechanized methodology; we are living out principles that offer both guidelines and flexibility in our quest to improve both our products and our teams.  We are passionate about working together to develop outstanding products and solutions that thrill our clients and even impact the wider market in which we work.  Agile offers a very helpful framework for us in pursuing that goal.  I hope this ‘a sprint in the life’ blog series has given you a picture of how Agile is being applied in our firm and specifically on the team I work with as a product owner.  If you can learn from what we are doing to help you get better, that would be great and I would love to hear about it.  And if you have comments on things you think I’m missing then please let me know that too.  Because in truth, it’s not that simple.