The Importance of Project (Not Sprint!) Retrospectives
Project StrategyAs a product professional, it’s likely you’ve been a part of 10s if not 100s of sprint retrospectives (retros), but have you ever participated...
You’ve heard the buzz. You’ve heard agile this and agile that. You’ve done your research and you’re thinking that it’s finally time to make the move from your tried and true waterfall to the greener pastures of agile thinking.
There are myriad reasons your team or organization may switch from waterfall to agile. Perhaps you’re in the midst of a digital transformation. Or maybe you’re experiencing rapid growth and want to respond more proactively to the market. Or potentially, like many of our clients, you’re working with a vendor to launch a new digital product, and you’ve read that you should use agile to manage the backlog after handoff. We’ve coached many teams through the switch from waterfall to agile, and we’ve learned a few things along the way that may be helpful to you.
Change is hard, right? We’ve all been a part of challenging technology rollouts or process improvements that have been painful and impacted the day-to-day work. While it would be ideal to shift your entire business over the course of a week, you and I both know that’s impossible.
Instead choose one cross-functional team, a single department, or a single product to kick off the agile transformation. Slowly beta testing with this small group is less risky, allows for more insight into team sentiments, and means you can try small, incremental changes and quickly measure their effectiveness before the larger rollout.
As a part of that team, you want to be sure to have a Product Owner, a Scrum Master, and an Engineering Lead to guide the team, set priorities, and drive collaboration. While we’ve seen mature agile teams function well without these roles, it’s important to set a strong foundation for your new practice.
When kicking off with any team, I like to share the agile manifesto with them. This sets the foundation for a fruitful and robust discussion. Second, before you change any process, explain the pros of agile.
Some you may want to share are:
It’s also helpful to discuss the notion of “fast failure,” or the idea that they’ll quickly pivot based on user feedback instead of discovering weak points after full implementation.
There are plenty of agile tools out there and we’re not experts in all of them so we’ll leave it to you to decide what works best for your business. But here at the Ranch, we’re big fans of Atlassian. We use Jira and Confluence extensively across all of our projects. The out of the box (OOTB) setup in Jira works well for most teams, and you can always add columns for peer review, client review, or additional testing.
Confluence works well for project documentation like working agreements, retrospective notes, technical specs, and other details that relate to the entire product. Atlassian has an extensive training library you can put to use!
At Big Nerd Ranch, we typically start with two-week sprints and then adjust based on the needs of the team and the project. Within those two weeks, we’ll host all the standard sprint ceremonies.
It’s a good idea to check in with your team on their schedules. Do they like to have all their daily meetings back to back or spread out across the day? Do they have certain days that are more flexible than others? Do they prefer mornings or afternoons?
After we establish our sprint ceremonies, we also like to discuss ways of working and team agreements. This includes discussions around protected time (Do team members have certain days with childcare needs? Do they need time for prayer?), expectations for communication and meeting attendance, how we’ll set up our project tracking tool, how we’ll write user stories, etc. This is a lot to cover in one meeting so feel free to break it up over the course of a few weeks.
Sometimes it’s helpful to establish the basics first, go through a few sprints, then regroup to fill in gaps and discuss weak points. The beauty of agile is there’s always room for process changes based on team needs, product requirements, and the dynamics of your business.
We like to measure (team, not product) success for a few reasons. KPIs anchor the team to a unified vision. If everyone knows what’s being measured and why they can align their work accordingly.
Second, KPIs also support the story you are sharing with your leadership and/or your client. This will be especially critical as you are refining the new process in preparation for rolling out agile to the entire organization. Some KPIs you may want to consider are velocity, sprint burndown, and cycle times.
It’s especially great if you can demonstrate improvement from your previous waterfall efforts vs agile. Also, one note, consistently missing your KPIs may also be a sign that your team is ready for a change in process.
Once you’ve gone through several sprints with your beta team, take a step back and evaluate. What’s working? What’s falling flat? You may even consider hosting a project retrospective (instead of a sprint retrospective) to get team feedback. Use this input to refine your agile practice (be sure to document everything), so that you’re prepared to roll out to a larger group.
Once you’ve got a good process in place (and this may take a while), engage with other champions of agile who can support a larger rollout across the business. They can help with training, answering questions, and setting a good example of agile best practices.
You’ll always have some naysayers; it’s natural for there to be some resistance. For those people, we’d recommend revisiting the second step, where you explain Agile and highlight the pros, sharing the improvements you’ve seen via your KPIs.
No business or culture is exactly the same and it’s likely you’ll need to adjust some of the above steps to suit your needs. If you get stuck somewhere, Big Nerd Ranch is always here to help!
As a product professional, it’s likely you’ve been a part of 10s if not 100s of sprint retrospectives (retros), but have you ever participated...