Freshen up your software development process to propel your product forward instead of getting stuck on repeated challenges.
Whether you choose to work with scrum, kanban, or another method, having an agile process should mean your team uses a certain set of values and principles in its decision making, that ultimately satisfy your customers through early and continuous delivery of valuable software.
But attempts to mimic how other teams “do agile” could backfire since not all agile processes fit all development teams. Consider how your team conducts retrospectives. Yes, you reflect on how to become more effective, examining what went well and what should change in the next sprint. But when it comes to actually adjusting behavior, it is very possible that your team, like many others, falls short.
The result is, at best, a subpar product at the end of your sprint, and at worst, a product that remains subpar across multiple sprints—a frustrating situation for teams and customers alike. What good is your agile process if you get stuck on the same hurdles every time?
Our new eBook is available!
Unleash the True Value of Collaboration
How to build a team that lifts its members up to constantly drive better results.
Your Retrospective is Missing Implementation
If the goal of agile development processes is to build better software, it stands to reason that teams would want to improve from one sprint to the next. The retrospective serves as a dedicated time for that. Megan Cook, Group Product Manager for Jira Software Cloud, says that the purpose of a scrum retrospective is to “evaluate how the last sprint went, create a shared understanding of the things that went well, and things that didn’t, and create a plan for improving the way that your team works.”
How can you optimize your retrospectives by not only taking stock of what worked well and what didn’t, but also—and this is the critical part—implementing what you learn? And, making sure that everyone involved in your product development learns from your lessons?
Let’s explore ways in which the learning from your retrospectives is limited when it comes to implementation, and how you can modify it to continuously improve your product.
1. Learning isn’t actionable
Capturing learning in a way that will actually serve team members in the next sprint is hard. A deeply valuable discussion that takes place in a retrospective may lack clear takeaways for what to concretely do differently the next day. Sometimes, the discussion itself is derailed, focusing too much on things that don’t matter, or that are out of developers’ control.
To address this, retrospective leaders need to understand how to steer the discussion toward topics that will move the product forward. This may mean focusing on a particular element of the last sprint that went great, or not so well. It could also mean spotlighting an issue from a previous sprint, a pivot in the business strategy, or any other topic that the discussion leader determines—based on agile principles—will yield the most critical action for product development.
Then, when discussion ends, regardless of how lofty it may seem, it is the discussion leader’s responsibility to summarize and make sure every person in the retrospective understands what they are going to do differently (or retain) the next morning. And—it’s the team members’ responsibility to hold their leader accountable.
2. Learning isn’t shared
A retrospective can raise rich insights worthy of sharing with those not present in the (physical or virtual) room. To not miss out on those insights, development team members can think more broadly about who should take part in the retrospective. Or, if that isn’t possible, they can create a mechanism for sharing learning across teams and departments.
This way, teams aren’t only getting the most out of their own retrospective by making sure that everyone involved is tuned into the reflection. They also unlock invaluable discussion topics for future retrospectives in other teams. A lesson that emerged in one team’s discussion could be directly relevant to a project taking place in an entirely different team. There is no reason why those two teams would participate in each other’s retrospectives. If they don’t share their takeaways with one another, they would never know what learning they’ve missed. By sharing learning, each retrospective can have far-reaching benefits across the company.
3. Learning isn’t there when developers actually need it
Even in the best case scenario, where learning from a retrospective is packaged with a precise action plan, what happens when the time comes to actually put that learning into practice? It’s easy in the event of a specific action with a clear start and finish and one person responsible. But some learning is more abstract.
Overlaying a briefing-debriefing cycle onto retrospectives can ensure that learning is incorporated into your team’s work process. Collaborative real-time learning platforms are technological solutions that automatically surface the most applicable takeaways at the moment of need—like once the next sprint has been set into motion. By delivering relevant learning at the optimal time, these tools empower team members to put knowledge into practice.
Never Miss an Opportunity to Improve
Is your development team operating on agile principles? If you’re not emphasizing implementation from one retrospective to the next, you may be falling short on your own values. Running from one sprint to the next without learning and adjusting in between is a missed opportunity; a chance to move toward more actionable learning, shared across your organization, that will come into play in your next sprint.
Moving toward that kind of learning is the surest way to reach your highest priority as an agile group: satisfying your customers through early and continuous delivery of valuable software.
Our new eBook is available!
Unleash the True Value of Collaboration
How to build a team that lifts its members up to constantly drive better results.