6. Endless Refinement
Impossible with a group
of 12 people!
Ended up in:
- Refinement in focus
groups
- Intake meetings
Goal of refinement session: understand the problem and the goal to achieve
10. Sprint review:
internal knowledge sharing?
It became the moment where team members shared the work/solutions to
each other for the first time.
Goal sprint review: Demo the work to PO and stakeholders
11. How we re-structured the new teams
Team Shipsters - Build Distribution and SaaS
Team ECI - Custom Enterprise projects
Team Gardeneers - Market Open Social
www.getopensocial.com
Responsible
Team 1 Team 2
Responsible
Hi everyone, My name is Evelien. I am working for Goalgorilla for almost 4 years now, and since then I am part of the Drupal community.
We are an agency who work mostly according to scrum, and in those projects I act as a Scrum Master.
When speaking about multi-disciplinaire teams at DrupalCon Dublin, the question “What is the ideal Scrum team size” was raised by a number of people.
While I know Scrum prescribes an ideal team size of 6 to 9 people, November of last year we experienced that our Open Social team was becoming too big and decided to see what would happen if we split it up. In this blog I will explain the cons we ran into with a bigger team size and why this led to the decision to split our original team up in two separate teams.
Before Open Social I have been work
While I know Scrum prescribes an ideal team size of 6 to 9 people, November of last year we experienced that our Open Social team was becoming too big and decided to see what would happen if we split it up. In this blog I will explain the cons we ran into with a bigger team size and why this led to the decision to split our original team up in two separate teams.
NIce that this is an internal project,and you can really get to know scrum, test methodoly
We are building Open Social since January 2016. We started with 7 people.
Because we wanted to move faster, we added more development capacity to the team.
In October 2016 our Scrum team had grown to 12 people. Our team consisted of:
1 Project Owner
1 Scrum Master
6 Back-end Developers
1 Front-end Developer
3 Designers and User Testing Experts
You can probably imagine that the size of our sprints where huge. Our velocity was +/- 300 points per 3 week sprint. The amount of issues that were listed in the sprint felt endless!!
This resulted in the following problems….
Everyone has to know every item in the sprint.
To make sure enough work had been refined for the coming sprint we had to plan extremely long refinement sessions. While under normal circumstances the entire team should be present for these meetings, so everyone has a clear understanding of the ‘Why?’, we weren’t able to include all 12 people in these sessions because that would mean the meetings would be even longer still. That we all have very strong opinions of course meant the meetings would never be short to begin with. :P
We all agreed that splitting the attendees was not the way to go, but 12 people in the meeting was also a definite ‘no go’ for us. Additionally: during the sprint we’d schedule intake meetings with the people who would be working on a specific story.
We had a hard time discussing the stories that would meet our sprint goals. So we started to discuss them in smaller groups to create workable items. Unfortunately this (once again) resulted in not every team member having workable knowledge of every story in the sprint.
Goal of sprint planning: PO explains sprint goals, team asks questions, create workable items and give commitment.
Impossible with such a huge sprint
PO had no overview
Started to do sprint planning in sub-groups
We were working on 4 different projects in 1 sprint:
The Open Social Distribution
The commercial/ marketing site where you’re reading this
2 Enterprise projects where the distribution was implemented including a number of custom features
Since it’s hard to focus when switching from one project to another, we started to assign specific projects to the same pool of people within the team.
Additionally, having multiple projects in 1 sprint makes it hard to create (and meet) the sprint goals, since Enterprise projects almost always have the highest prio.
It was impossible for the team to answer the question in the Daily Stand-up, “Are there any impediments”. For the Scrum Master it basically turned into a day-job to track progress and try to spot impediments, since the team members were neither a 100% aware of the progress of the rest of the team or of the amount of open tickets.
The burndown chart had somehow become useless. We still haven’t figured out why exactly, but it had something to do with too many issues in progress and starting new ones without finishing others first. Or not even being able to start every ticket, since we had spread our knowledge between 4 different projects. My best guess is that it came down to planning, which was impossible to do with that many issues on the board.
The sprint demo (or review) should be held for the Project Owner and stakeholders to demonstrate the (potentially) shippable product. But with our team size the meetings turned into knowledge sharing sessions where we showed each other the work we’d done and the solution we picked. Some of the solutions were even presented and discussed for the first time!! This is of course not the way sprint demos should work.
Since not every discipline was represented twice, we had to add some more people to be able to make the split:
1 Designer
1 Front-end Developer
1 part-time Developer (who would be handling support)
In order to regain our focus, we decided to split the team up on a project basis:
Team Shipsters - Distribution and SaaS
Team ECI - Enterprise projects
Team Gardeneers - getopensocial.com (commercial site for ordering
While Team ECI works on our Enterprise projects, the teams still have to collaborate, this way ECI contributes a lot of these features back to the distribution. This has given us a huge benefit: the distribution is still a product of both teams, meaning it benefits from knowledge and input from both teams and resulting in a higher quality end-product.
I guess when you read about our problems, it’s pretty clear that the team was too big. We worked with this big team for 4-5 sprints before we decided to split it up. We would have probably split the team up sooner if we didn’t need additional time to add more disciplines to be able to facilitate a healthy split.
So when does a Scrum team become to big?
I gues you naturally run in to these problems, and especially the focus part will give you reasons to split it
“The moment you start creating sub-groups within your sprint/ Scrum team, your team is too big”
If the team is too big, you will run into several problems. But what happens when your team is too small? What would be the smallest acceptable team size?
In my opinion you can’t really talk about a Scrum team if the people are all working on their own little islands. The team should at least work together on (preferably all) stories. Ideally, a healthy Scrum team will also be able to handle setbacks such as illness and holidays, so I would always aim to have every discipline represented twice in one team.
Of course, I don’t want to preach that this is a must. There’s never just one answer to these types of question, there are a lot of dependencies per project and organisation which can give you different insights and needs. What’s your ideal Scrum size? How did you first notice your team was either too big or too small? And how did you resolve this? We would love to hear from you in the comments. :)
Be sure to attende the Friday sprints.
And please give us your feedback on our talk through the event page of drupal.org
