If run well, project retrospectives result in a wealth of insights into opportunities for growth and can be a powerful tool in building team rapport and expertise. We’ve seen great ideas come from these broader retros like splitting larger teams into feature/requirement squads, how to ensure we’re budgeting for the right roles during the sales pitch, and improving our load testing process.

Needless to say, we’re big fans of project retrospectives and wanted to share what’s worked for us.

Have an objective facilitator

Generally, the team scrum master will host your sprint retrospectives. While they are the most objective person on the scrum team, it’s challenging for them to participate AND facilitate even though they may have great insights to share. Including an outside party means that every person on the team can engage in the discussion without also owning the retro board and taking notes. An objective facilitator will also provide a new outside perspective to refresh the way the team has been thinking and working. Unsure of where to find someone? See if there’s a scrum master from another team who can jump in. Or even a project, program, or account manager. It’s a great upskilling opportunity for them and your team gets the benefit of their observations and wisdom.

Choose an intuitive tool and method

We can’t give away all our secrets, but we will share a few tools that we like to use. My personal favorite is stickies.io. It’s free, super-fast to create an account, and the UX is intuitive. It is a bit limiting on the questions/themes you can use, but we haven’t found that to be a deterrent to valuable meetings. Another useful tool is FunRetrospectives. This one is also free, doesn’t require an account, and has a few options for full, prepackaged retros including fun activities. It’s also quite intuitive and easy to use although the design may feel a bit dated. Lastly, we like Miro. This one is much more freeform so you can structure your retro the way you want. If you’ve got your own personal favorite process that doesn’t line up well with the other two, this is the tool to use! You can set up a free account with limited access to get you started, but if you plan on using it regularly you’ll need to spring for a paid version.

Make it fun!

While retros are often serious, action-oriented discussions, it’s a good idea to let everyone loosen up a little and offer opportunities for laughter and joy. When the team is at ease, they are more likely to share their inputs, collaborate, and build rapport with their colleagues. Since we’re a very geographically dispersed company, we host all of our meetings virtually and have a handful of remote activities that we use. Some of my favorites are themed zoom backgrounds, playing music during quiet times (you can even take requests in advance), using emojis or gifs for voting or other activities, and games like Two Truths and a Lie or Would You Rather. You’ll probably run into some (hopefully) productive tension throughout the retro, but making time for the fun stuff will make it that much easier to collaborate.

Schedule enough time

This will ultimately be driven by the number of attendees but we’d recommend at least 90 minutes to two hours to ensure a dynamic discussion where everyone is heard and action items are thoroughly discussed and documented. We know long meetings aren’t everyone’s favorite, but if you can get all attendees engaged, the time will fly by. There’s nothing worse than cutting people off in the middle of a great conversation because everyone needs to leave. To keep things running smoothly, be sure you have an agenda and stick to it (within reason of course; don’t derail fruitful discussions).

Document and share your results

I know I mentioned that learnings can be shared across the organization but it’s worth reiterating. I can’t count how many times I’ve left meetings with great action items or ideas that are never discussed again. What documentation and sharing look like will depend on your company. Do you have an intranet? Playbooks? Regular cross-functional leadership meetings? Or has communication and tracking of institutional knowledge always been a challenge? You may find that an outcome from the retro is a desire for better documentation and communication. What better way to start than with the retro itself! 

With these five tips for conducting a project retrospective, you can easily gather and implement some high value-added process changes like starting a project with a solid but flexible Jira framework or implementing a comprehensive QA testing process. We encourage you to try hosting your very own project retrospective to witness what value can be delivered to your organization!

The post The Importance of Project (Not Sprint!) Retrospectives appeared first on Big Nerd Ranch.

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.

Beta Test and Take it Slow

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. 

Explain Agile and Highlight the Pros

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 flexible
• The product will get to market faster
• It allows for better communication and transparency across the team

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.

Learn the Tools and Train the Team

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!

Establish Your Sprint Cadence and Ways of Working

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.

Establish KPIs for Success

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.

Refine, Refine, Refine

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! 

The post How to Transition Your Team from Waterfall to Agile appeared first on Big Nerd Ranch.