bookmark_borderWhat happens when the scrum team gets too big?

Participating in an overgrown scrum team is a fascinating experience. It allows us to observe how the framework collapses under its own weight.

Basically, scrum consists of meetings. Daily stand-ups, backlog refinements, sprint planning, review, and retrospective. These meetings, in theory, can consume even 22.5% of developers’ time. That’s a lot. But as always – it depends.

Image result for office sleep

Observation 1 – meetings get longer

Let’s start with a daily scrum. It should last no longer than 15 minutes. As long as the team is just a few developers big – it’s easy. But when we have 15 devs we can give everyone only one minute to speak. It’s pretty impossible. Either we will destroy the idea of the daily meeting – where the team members can properly describe what they worked on and ask for help (by forcing them to speak extremely short) either we’ll extend the time. In the team of 14 developers, I’ve seen daily scrum to grow up to 25 minutes.

Exactly the same is the situation with every other meeting. But in case of refinements or sprint review, it’s getting even worse because these meetings are naturally longer than daily scrum.

Observation 2 – meetings become full of things you don’t need to hear

As the team grows, the scope of work grows. Naturally – as in any big enough group – the subgroups form up. It can be any kind of division – front-end and back-end devs; people who work on feature A, and another group working on feature B; Java, and JavaScript programmers. When they work on the everyday tasks they almost don’t talk to each other unless they need to discuss some API or contract which is necessary for the parts of the system to communicate. But if the scrum team doesn’t split they’re forced to participate in the meetings together.

Then you find yourself in a meeting where half of the time is spent on discussing the things you don’t need to hear. You’re let’s say a JavaScript developer and last 30 minutes of a meeting was a discussion about back-end, or you’re developing database structure while implementation of the UI of the system is estimated.

Observation 3 – productivity plummets

You want to code. That’s why you became a software engineer. You like to focus, you love to create lines of instructions. This is also why, all in all, you’re getting paid. You automate processes, therefore, people don’t need to be employed to make them manually and the company is more effective. The money saved on automation goes to your pocket. Everybody is happy.

Unless you can’t code.

When the length of scrum meetings get longer it consumes your coding time. When the meetings get boring it consumes your mental energy. You become less productive. Not cool.

That’s why Scrum guide recommends a scrum team to be between 3 and 9 developers. Even if it seems difficult to divide – it’s necessary. The alternative is a small crowd of unhappy, ineffective developers.

Please follow and like us:

bookmark_borderModified agile

I can’t remember how many times have I heard a word Agile during recent years. We’re agile. We’re doing agile. We’re introducing agile.

It sounds like people dialogues in the kitchen. Yes, I’m going to the gym. Sure, I do cardio. Yeah, I do Crossfit. Of course, I consume supplements. Aero? Every week.

But somehow I can’t see the muscle grow.

The results of this supposed agility I can’t see as well. There used to be chaos and it still is. Estimations have been poor and they still are. The technical debt balance looks like the credit card of a young adult after the summer weekend. Deadlines are scary like cancer and deployments as painful as colonoscopy. And last but not least – the scope is still not flexible at all. But we’re agile!

Are we?

The worst failure of Agile is I believe its promise it can be modified and adjusted. Therefore let’s come back to the analogy of a gym. We are growing muscles. But we don’t take care of the diet because we like to eat. We don’t train our legs because on Fridays we go to the party. We don’t go to the gym when we have a headache.

Then we visit a gym for two years and we still are somehow ashamed owners of a beer belly instead of rock-solid ABS.

Can we be agile if we have a fixed scope? Can we deploy at the end of each sprint if we don’t have the whole organization prepared for it? Can we build better software without showing the client a new version at each iteration? Can we be agile if there’s no client yet, only the budget?

Maybe yes, maybe no.

But for sure if we will modify or remove half of the rules from Agile recommendations we will achieve mess, not benefits. So let’s be serious, responsible developers and not be tempted to eat a cookie when we’re on diet. We can’t eat a cookie and still have it.

Please follow and like us: