Adapting agile ceremonies to a growing team
At CaptainContrat, we have worked in agile (Scrum) since the early days. The team reached a satisfying efficiency with the different ceremonies but while growing, we started to see pains emerging during some of them. Using the retrospectives and reorganizing the team in squads allowed us to tackle the growing issues. Here is a summary of our pains and corresponding solutions.
Disclaimer: as a more global solution we divided our development team into two groups of three to make things more manageable. We call them squads because we saw Spotify’s video. Although we divided our team in squads, our solutions do not necessarily revolve around squads and remain valuable for a different organization.
A strict daily standup to start the day
The daily standup is a key element of most agile frameworks. A lot of people tend to say that when a team declares daily standup inefficient, that is because it is not done properly (within the 15 minutes timeframe). With a team of 6 developers and 2 product owners (POs), we started having trouble communicating. We forced ourselves to maintain 15 minutes but we found out that the quality of information was poor, the call for help were less impactful, and some of us were starting to feel bored.
The issue was that we had to squeeze a lot of information in a short time and people had no time to give proper answer.
When the team is growing, the key elements for daily standups are:
- Be synthetic, but commit to privately discuss lengthy issues later right after the standup
- Be explicit about informing whether you need help or not, saying out loud “I am not blocked” or the opposite.
- Divide the team if possible (probably based on the epics different members are tackling) and parallelize the standup.
More inclusive retrospectives
Our retrospective started to have two issues. Listing complaints took too much time and the product members were frustrated because their issues were usually dropped by lack of time so we never took time to find solutions for those. A solution would have been to extend retrospective duration to match team size, but we prefered a more time efficient approach.
To ensure time efficiency, we decided that everyone should come with items already prepared. When listing them, we would avoid commenting on it (unless just to say I have the same topic and add it). We gained around 15 min worth of solution planning on that.
To limit product frustration, we decided that when voting for the most important issues to tackle first, product members which are in minority would get get more votes than developers to balance their numbers (respectively 3 and 2 in our case). We decided we might adjust that given the ratio of product/development participants, but keep a minimum of two votes. This works really well.
Lastly, since we divided ourselves in squads but are not fully set yet, we keep the whole team on the same ceremony, because some issues are related to the squad organization. So far, we have had time to find actions plan for 90% of voted issues which is satisfying. If we grow to 3 squads and we find out we lack time again, we will probably try to parallelize the ceremony (or at least a part of it).
A well prepared sprint planning
Along with team growth comes a higher velocity, meaning more stories which in turn lead sprint plannings to last longer. More questions were asked, stories were challenged and we quickly exceeded our 2 hours. After a careful analysis, we found various reasons and tried to have an answer for each of them:
- We took too much time presenting each User Story and asking basic questions about the featured functionalities. We decided to read and challenge User Stories beforehand and asynchronously as much as possible.
- We spent around 15 minutes looking back at the previous sprint completion, checking for holidays for the previous and next sprints and calculating how much complexity point we would take. We now prepare the engagement we want to take beforehand, so we do not lose this time during the sprint planning.
- Since it was not enough, we decided to parallelize effort estimation to the relevant group (in our case, the squad in charge of the epic). This also means that User Stories must be prepared with a pre-attributed group. Some of them are used as adjustment variables and dispatched during the sprint planning to complete the engagement of each group (our squads are not fully independent, tech tasks backlog and bugs are a shared responsibility).
Demo: focus on the most important
Our iteration review is a demo to the rest of the company. At first we had a presentation with one slide per story and live presentation for each story that was presentable. But the number of user stories was growing fast and it didn’t fit anymore within 30 minutes. So we switched to one slide per epic, presenting live the big picture and all stories at once for this epic.
That let time and made it easier for attendants to take a step back and brought very interesting feedbacks and discussions, while taking less time.
Wrapping up
The solutions we have set to solve our issues have some points in common. We tend to stick more to the rules, but also to prepare on our own each ceremony. When it is relevant, we also try to parallelize as much as we can.
More preparation beforehand could appear time consuming but it is not so much. We could argue that ceremonies virtually take more time because of that, but it is diluted in our daily work, furthermore, individual preparation tends to be more time efficient than discussing all together so I guess we end up winning precious time. Moreover, by reading and challenging before the ceremony, it enables people to take a step back and be more relevant.
Last but not least, we use the retrospective to fix the sprint on a high level. It is not only about how the sprint content went but also about how people felt about its structure. This is the more generic advice we can give but probably the more adapted to everyone, you are doing agile, do not hesitate to change what is not working, to adapt and try different solutions to find what is best for your team. Any frustration should be considered a bad smell and lead to an open discussion with the rest of the team. And do not forget that when the team is growing, the needs change, so try to adapt continually.
