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?
The Basics: parts of software development
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.
- During a demo, the software development team’s members introduce the new features and tasks accomplished to the Product Owner or the Project Manager.
- The sprint retrospective is to discover the good, the bad and create the action steps for improvement.
- Sprint planning is to gather the tasks that will fill each team member’ time and sufficient for implementing the subsequent features.
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.
Organizing a Sprint Retrospective
The invite I got came from Norbi, server side 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.)
The Rundown: How to Retro?
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.
First came the positives:
- ease of involving new dev team members
- nice time estimates for issues
- solving problems cooperatively
- daily standups were fast and effective
- awesome code reviews
- specification was great
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:
- undefined communication channels (however, communication itself was very effective, there was some tension when colleagues were approached with questions without prior notice)
- Code reviews’ their timing was not always properly organized (however code reviews themselves were stated as a success)
- Developers were easily involved, but their time schedules were not on point
Other issues that need improvements were:
- Making the KickOff more effective
- More detailed task descriptions in the time tracking and project management tool, Jira
- More details in the specifications
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.
- UserStory, Business, and TechSpec -related questions should go to the specific issue in Jira.
- Code-related questions should be addressed on HipChat or in person.
- If you’ve discussed something in person, make a note of it in Jira, so that the information doesn’t get lost in space.
- The default channel should be HipChat. If someone prefers something else, they should indicate it.
Code Reviews / Pull Requests
- Any review longer than 10 minutes should be logged on the issue that was reviewed.
- After your commit, check immediately whether there is a code review assigned to you. If there is, do it then and there.
Availability and schedules
- Include your hours in your personal wiki space, and make sure you notify your team’s members when you aren’t available.
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.
The Stuff We Learned
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!