In this post I will explain what a sprint and a sprint retrospective are because they’re important parts of software development, but there are always questions arising when we introduce these concepts to our clients.
So, this morning I got invited to a sprint retrospective to take pictures for our social media outlets. I did my job, then I thought, how could I share these without explaining what they are for?
So first of all, what is a sprint? (If you’re familiar with the concept, you can skip this paragraph.) At Wanari, we employ agile methods. For the purposes of this post this means that our clients (if they want) can get daily reports on the work we do and can review new developments and features at the end of each sprint. This is called a daily stand-up; every member of the team gets together and states in one minute what s/he’s accomplished yesterday and is working on today OR what s/he’s working on today and will be working on tomorrow. And every member states if they have trouble completing a task or if they’re waiting for another member. At the end of each sprint is a sprint closing, often including a demo, a retrospective and a plan-creation for the next sprint.
A sprint then is just a pre-set time interval, carefully planned so that developers can achieve the development of certain functionalities within it. It can be one or two weeks long. However, when they are set, development is done within these intervals on an ongoing basis, sprint after sprint.
The invite I got came from Norbi, CTO at Wanari, to me and a team that has been working on an enterprise solution of ours. It stated that the meeting was to look back on the sprint that has just ended. He asked the invitees to collect their thoughts before the meeting, regarding 3 questions he attached:
What was good during the sprint?
What did not go well during the sprint?
How could we improve so that the next sprint will be better?
He also sketched a plan for the meeting; everyone would have 5 minutes to write their answers on a post-it, then everyone would get a chance to post their notes while explaining their contents. He warned not to write short stories, but only a few words to indicate the statement that was stated with those words. After all the posting, there would be a discussion on what should be done for improvements, hence creating an action plan for the sprint starting the following week. Naturally, everything would be kept neatly in notes for future reference. (For these purposes we use Atlassian software, keeping our meeting notes in Confluence.)
So the time came and we all gathered in the now creatively named “green room”… picture below. The developers got to work and started writing their opinions on the post-its. The different colors indicated the different stages of the process, answering the 3 original questions.
Note-taking took place on a shared wiki page and was projected the whole time, so immediate feedback could take place.
Then the negatives were posted. The developers organized them in such a manner that connected issues could be seen clearly. For example, room for improvement here was stated as:
Other issues that need improvements were:
When the good & the bad were defined, it was time for everyone to get up and cast their vote on the most pressing problems, which were hence selected as grounds for actual action steps.
Then came the discussion and defining the to-dos:
These aren’t usually posted on the wall, rather kept in the detailed and accessible meeting notes. However, I asked the team members to post them for the purposes of this post, you can see that there are a few, succinct actions steps in hopes of making subtle but effective improvements for this project’s outcomes.
Our action steps involved the three most pressing issues (as voted by the team), complete with newly defined rules for each.
The retrospective was concluded with clearly defined steps for the next sprint and as far as I could see the team was happy with the outcomes.
Now you see, retrospectives are often neglected and dismissed as unnecessary. And we were also guilty of this here at Wanari. Now in our efforts to become better and more effective developers, we consciously searched for our weaker points. One of them was neglecting retrospectives, since we delivered on time, we thought everything was going well (enough). Every development project is different and every client has their own needs and expectations. We’ve learned that our ongoing retrospectives truly help us not just save frustrations for ourselves, but also help us save time for our clients on the long run.
I hope you enjoyed this post and might be able to take some tangible strategies with you!
Do you do it differently? Did I miss something out? Leave a comment!