Posts Tagged ‘scrum’

My new course is out, teaching Scrum agile project management framework. Inside the course, you will earn:

• Artefacts: product backlogs, sprint backlogs and definition of done documents
• Ceremonies: Daily Scrum (stand-up), backlog refinement, sprint planning, retrospectives, ways of working meetings, wash-ups and sprint reviews
• Estimating points, velocity and agile poker
• Team roles including product owners, scrum masters and stakeholders
• Team psychology including psychological safety, coaching and best practice
• Agile requirement gathering, user stories, tech debt, prototyping and user labs
• Agile release management, continuous integration and continuous delivery
• Scaling scrum beyond a single team with product splitting and Scrum of Scrums

You can preview the course on Udemy.

What do you do if you need to scale your Scrum team? Ideally, have multiple teams and use one of the many fine methods for scaling with multiple teams. But what if you want to scale a single team? To say, 30 people?

This was the situation I ran into with a recent client. They had an important project and lots of money to throw at it, and they wanted it all to be one team.

You might think “but there is no way that could possibly work”. And you would be correct. It didn’t work that well. But, having no other option, we did find some hacks that made it easier. I’ll present these below.

Kim’s Corners

Doing a stand-up with 30 people is tough. You might think it took ages. But it didn’t. We got done in 15 minutes. There were so many people (in a special meeting room we had to book every day) that people kept it short and sweet. From that point of view, it was a good learning experience.

But it wasn’t useful. There was so much stuff going on that nobody could remember what everyone else has said. Most people did not even try. They just tuned out for most of it.

So, we moved to Kim’s Corners. Each workstream had a corner and we went around one corner at a time. The people in that corner listened to each other intently, while only taking a high-level overview of what the other corners said.

Goldfish Bowl

Having a retro was also challenging because there were so many people wanting to weight in. To solve this, we used the Goldfish Bowl technique.

This involves having five chairs in the middle of the room. Four people sit on them, with one empty chair. Everyone else sits around in a big circle. Only the people in the inner chairs are allowed to talk on the topic at hand, and the discussions are time-boxed to five minutes. The group can vote to allow another five minutes if required.

What if you are sat on the outside? You go into the circle and claim the empty chair. At which point, someone from the inner circle is obliged to get up and go back to the outer circle, freeing up a chair to be the new empty chair. Anyone who has a strong opinion can take a chair, but without too many people talking at once.

Refinement Lucky Dip

30 people were too many people to have sat around looking at a Jira board and pointing stories up. So, we used a lucky dip system in which five people were randomly selected to attend backlog refinement sessions.

Anyone else that particularly wanted to be involved, perhaps because they had the a specific knowledge or interest in a piece of work that was upcoming, was also welcome to attend. But they were not required or expected to attend otherwise.

If you are not familiar with a burndown chart, the idea is this: you pull so many points (bits of work) into a sprint (a period of time, typically two weeks) and your burndown chart shows you how far you are through said work. So, the red line on the chart (the amount of work done) should follow the grey line.

Or, at worst case scenario, the red line should stay flat because you have done literally nothing.

However, what it should never, ever do is go in the opposite direction to the grey line. Because that would mean you actually ended the sprint with more work to do than you had at the start of it. The point of a sprint is that you should not be bringing in extra tasks.

Safe to say then, that this was not a great sprint for us. But, it is at least comically bad.

To solve the problem of lots of different scrums wanting to release at the same time, we recently introduced a “release token” – some item that you had to have in your possession to allow you to release – and if you didn’t have it, you couldn’t release anything, thereby preventing conflicts.

Enter Gregory, the Release Bear.

Unfortunately, it was soon felt that tracking down a bear every time you wanted to do a release was too tiresome. So, after only a few days in the job, Gregory was retired in favour of a digital token. Unlucky, Gregory.