A retrospective is anytime your team reflects on the past to improve the future. Between technical and non-technical teams, you can retro on just about anything! Right now, we're hosting a public retrospective on agile software development. Help define the future of agile by adding some of your ideas to our board.
Join the #RetroOnAgile conversation
Reflect on your software development by tweeting with #RetroOnAgile. Tell us one thing you like with #ILike, one thing you wish you could improve with #IWish, and one thing you'd like to see in the future with #WhatIf. Use the hundreds of responses below as inspiration. Your feedback will show up here within 24 hours.
Pro Tip: ^^^ Replace the question with your answer, leave the hashtags ;-)
If nothing else, I feel like I waste less time, using the agile process. I know within a few weeks, I'll get feedback on the direction I'm headed with a project. #RetroOnAgile— Shaun Cave (@Yungdaht) April 13, 2018
#ILike companies and CEOs like @peax_ch which are not afraid, to trust and to have confidence in their employees - giving them the chances to establish an agile culture to improve the development process #RetroOnAgile— Ivan (@IvanAschwanden) April 12, 2018
#ILike that agile provides a means for saying "no" to the urgent, and empowers a team to focus on the important. We are an #agilemarketing team that runs scrum in #jira not a software dev team, for what that's worth. #RetroOnAgile— Bill Cushard (@billcush) February 14, 2018
#ILike it when my team doesn't finish the #Agile Sprint objectives and I make them demo broken shit to all the stakeholders anyway, because of course, public shaming is a powerful motivator. Wait, did I say that out loud? #RetroOnAgile— Dan Chuparkoff (@Chuparkoff) January 31, 2018
#ILike we pull up our Jira board during standups to make sure we stay on topic and talk about what we are actually working on. Makes it go faster as opposed to people trying to remember what they are working on #RetroOnAgile— Alex (@aortiz1989) January 24, 2018
I like how scrum turns agile back into a heavyweight process with lots and lots of meetings, even when those meetings take place in Jira itself.— Rob Lang (@robbytwitin) January 20, 2018
#Iwish to have more advance functions in jql.— Loshy Chandran (@loshyc) March 7, 2018
ADFS authenticatin - please release id-79 asap.
#IWish we could keep TLMs from degenerating into program managers. #RetroOnAgile— Juni Mukherjee (@JuniTweets) January 23, 2018
"When agile shops were first being established, an important consideration was to keep TLMs from having full visibility into any one agile team." https://t.co/32eiK5ih9a
#IWish Consensus would work always. Sadly, the voting environment could get polluted. #RetroOnAgile— Juni Mukherjee (@JuniTweets) January 23, 2018
"Even though agile rests on collaboration, the 'agreement by consensus' model has it’s share of flaws, depending on the who, the what, and the when." https://t.co/32eiK5ih9a pic.twitter.com/9X7dFon0RV
#IWish Teams won't declare agile victory prematurely by merely doing stand-ups.— Juni Mukherjee (@JuniTweets) January 23, 2018
Unless we invest in:
a) a single prioritized backlog
b) KPIs and a DoD that we can get behind, and
c) feel empowered,
standing up won't help. We might as well sit and do some work. #RetroOnAgile pic.twitter.com/3ou448YLbw
#IWish Jira was fast— Bastien Billey 🇫🇷 (@billey_b) January 24, 2018
#retroonagile I wish people played as a team. No aggressive jira Tix allowed— Sean Regan (@seanjregan) January 25, 2018
#WhatIf #agile teams wouldn't loose the big picture due to a flatened backlog, and be reminded how #UserStories are interrelated (e.g. from #UX point of view or from #BusinessProcess perspective) ? #RetroOnAgile— Christophe THIERRY (@chthierry) April 13, 2018
I’d replace the word software with product in the manifesto #RetroOnAgile— Matthew Evans (@matthewevansrec) April 13, 2018
#WhatIf we collectively decided that Sprints were, at most, one day from start to finish. #ContinuousAgile #YourStandupIsAlreadyYourPlanningMeetingAndYourDemo #RetroOnAgile— Dan Chuparkoff (@Chuparkoff) February 1, 2018
#Whatif we could say in 12 months from know that 2018 was the year when #agile was eventually applied to business at large – on all levels, beyond software projects? #RetroOnAgile https://t.co/lyylkPgNeV— swarmOS (@swarmOS_de) January 10, 2018
Why run a retrospective?
In 2001, with the stroke of a pen, the agile retrospective was born. The last of the twelve principles of agile development reads as follows:
"At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly."
The agile manifesto makes it clear: In order to best live the agile values, teams should meet reguarly to check in and make adjustments. Most commmonly, development teams apply this principle by hosting regular retrospective meetings, and while that meeting is the focus of much of this page, it's not the only way to retro.
More recently, the concept of retrospectives has made it's way out of development teams and into all facets of business and teamwork.
I know marketing teams that retro on campaigns, management teams that retro on large presentations, and above, Atlassian is hosting a retrospective on their entire industry. This openness to retrospecives, and their proliferation into all facets of business, is something to get incredibly excited about.
The reason to get excited about retrospectives is that they are where the agile rubber hits the road. So many of the core concepts in the agile manifesto are reinforced through retrospecitve meetings. Consider the following values:
- Individuals and interactions over processes and tools
- Responding to change over following a plan
At face value, this is what a retro is all about: Working with real people to make changes and improvements. Few things reinforce agile principles better. Now that we know why retrospectives are so important, read on and learn how to host a meeting on your own.
And don't forget, we do retrospectives to make things better, so if you're into agile, participate in our #RetroOnAgile and help define the future of software development.
Stay abreast of the #RetroOnAgile and other agile trends
The retrospective meeting
Retrospectives are an excellent opportunity for your agile team to evaluate itself and create a plan to address areas of improvement for the future. The retrospective embraces the ideal of continuous improvement - and protects against the pitfalls of complacency - by stepping outside the work cycle to reflect on the past:
The purpose of the retrospective meeting is to:
- Evaluate how the last sprint, iteration, or work item went, specifically around the team dynamic, processes, and tools.
- Articulate and stack rank the items that went well, and those items that did not.
- Create and implement a plan for improving the way the team does work.
The retrospective provides a safe place to focus on introspection and adaptation. In order for retrospectives to be successful, there needs to be a supportive atmosphere that encourages (but doesn’t force) all team members to contribute.
The retrospective should be a positive, energizing experience for your team. It helps team members share important feedback, let go of frustrations, and work together to come up with solutions. Facilitators can also get a lot from the retrospective, including a better understanding of how the team works together and what challenges (and successes) they experienced in the last sprint. A successful retrospective results in a list of improvements that team members take ownership of and work toward in the next sprint.
How to run your first retrospective
While it can be beneficial to vary the format of the retrospective (more on that below!), certain aspects like timing, attendees, and general format should remain as consistent as possible.
For agile teams working in the traditional two week sprint, the retrospective should take place at the end of every sprint. For teams running a more Kanban-esque style of work, a monthly or quarterly retrospective may make more sense. It's also healthy to engage members of the broader leadership after major initiatives have been rolled out; be careful to focus not on what was delivered, but rather on how the team worked together produce it.
Plan to spend at least thirty minutes, and up to an hour, depending on how long the sprint is and how much you have to cover.
Every team member should attend the retrospective, with a facilitator leading the discussion. The facilator can be the scrum master, product owner, or it can rotate throughout the team. Feel free to pull in designers, marketers, or anyone else who contributed to the current sprint or iteration.
There are several ways to mix up your retrospective (which we’ll discuss below), but here’s a basic template for retrospective meetings:
- Create a short list of things that worked well and things that could be improved. This list can be created on a whiteboard, on an Atlassian Confluence page, or maybe even sticky notes on the wall! No matter where you capture the initial feedback, be sure to memorialize it right after the meeting so it can be referenced down the road.
- Prioritize this list by importance as a team. You may discover common themes, which can be grouped together.
- Discuss ways and tactics to improve the top two items on the "room for improvement" list. Focus on outcomes, not actions or people, or the past.
- Create an action plan. By the end of the session, the team should have produced a few actionable ideas with clear owners and due dates to address the areas of improvement.
- Be disciplined about executing #4. Nothing is more frustrating than repeating the same roadblocks in every retro. Avoid stagnation (and frustration!) by making sure everyone walks away with clear next steps. Each action item identified in the retro should have a clear owner who follows it through to completion.
Because variety is the spice of life
Standardizing your retrospective is a good idea to create consistency and to build trust amongst the team over time. But there are a few "tweaks" facilitators can try that may help uncover additional insights, encourage participation from new team members, or simply keep it interesting.
Bring in an outside facilitator. Typically retrospectives are run by the scrum Master or project lead, but you may want to consider bringing in a guest to facilitate your next retro. The dynamic may shift in a positive way by having someone with no "skin in the game" lead the discussion. Moreover, this strategy enables someone else within the organization to observe how other agile teams are working and may pick up some best practices for his or her own team.
Vary the list prompts. At the end of the day, the retrospective is meant to uncover what's working and what's not. Consider these different prompts:
- Start / Stop / Continue: What the team should start doing, stop doing, and continue doing. Focus on ways to discontinue items in the "Stop" column.
- More / less: What the team needs to do more and less of. Create a plan around how to tackle the top items in the "do less" list.
- Glad / Sad / Mad: What made the team glad, sad, and mad. You guessed it, focus on the sad and mad lists and how to improve so there are only items in the glad column next time.
Engage leadership. After a major project has been rolled out, schedule an hour with a member of your leadership team and focus on how the team worked together (not particulars of how the initiative went).
There are plenty of ways to improve, so don’t hesitate to find some new tricks of your own. Whether you’re trying to engage a distributed team or improve a retro process that has stagnated, the key is to keep your team engaged and make the results actionable.
Join the conversation!
Now that you know the basics of running a retrospective, we'd love to hear from you about your team's retrospectives. Start your tweet with I like “I wish” or “What if” and you may just see your feedback on our virtual board above! Join the conversation →