Karmængine

So, I have been thinking. Scrum is an excellent methodology, without doubt. It’s perhaps not suitable for all software development projects, but I reckon that a majority would benefit from adopting scrum.

Yet scrum has weaknesses.

I can talk about what I have perceived from being involved in Scrum for eleven months as a product owner. I am sure there’s more than one ‘opponent’ of this development method, but I am certainly not of that ilk, nor do I wish to be. I just want to share my experiences.

Firstly, scrum pays entirely no attention to product maintenance and technical support. If you have a small company, with only a handful of developers working on a new release of a product, there’s nobody to maintain the old versions while a sprint is in progress.

The obvious workaround is to reduce the number of developers involved in the sprint, and stick them on maintenance and support handling. Aha- but for a small team pushed to make a new release, this is a disaster. Firstly, a reduced team equals a reduced output, an extended release date, and, let’s face it, less revenue.

Secondly, reducing the team reduces the skill of the team. With less knowledge available to developers, the code quality will suffer tremendously.

With less knowledge, there’s also less knowledge-sharing. If four men can’t change a light-bulb, but five can, then it’s a single man which makes the difference. The same with scrum. Remove a man from the team and the rest of the team will struggle.

Possibly, the team can remain the same size, but with a reduced velocity. Personally, I find that reducing velocity has some kind of negative mental effect on the developer. Reduced velocity translates to – more tasks. More variation in tasks in turn translates into less ability to cope with the tasks. Why? Because it’s difficult for a programmer to switch from task to task. Not only does it take time, but it also requires changing gears in the brain and doing this often leads to increased stress, and lower performance.

A classic case: Artyom (used his real name) used to be a part of my team for the new product release. Then, due to lack of available skill in the maintenance of another product, he was moved to that. That product is developed and supported in an entirely different country. Artyom faced a constant battle with himself to find time to do actual work – he was constantly bombarded on Skype by users and other developers. He would start a task, halt due to a Skype interruption, reset his brain and work on the emergency task thrown at him, receive yet another task in a similar fashion, spend hours explaining parts of the system to other developers via chat, and in the end, he was one very unhappy and underachieving developer.

Artyom said to me that it was not the interruptions affecting him, nor even the explaining which he was doing every day, it was the changing between tasks, which sometimes took him half an hour of saving, deploying, documenting, downloading, merging, opening, understanding, and reading code to understand where to begin, which created the stress and anger.

The same effect can be achieved by reducing sprint velocity. Other, non-sprint tasks will leak in, that’s one of the points of reducing velocity. When the tasks do leak in, there’s a long process required to get the developer to actually start working on it. Then the same process to continue on the previous task. This means that hours can be lost each day, not due to actual development, but due to.. overhead.

Now, the second (or first?) major problem I have found with scrum comes from task planning.

Different teams plan the sprints in different ways, but here’s how we do it:

1. Stories are explained to developers.
2. Developers consider, ponder, think, and divide the story into real tasks.
3. Real tasks are discussed, understanding is reached, and the tasks are estimated, one-by-one.
4. Estimating involves each developer holding up a card to display the number of hours they think the task will take to develop, test, and document.
5. If the differences between estimates are not too great, I take an average and assign this amount of hours to the task.

So, what happens when Mr Estimated Thirteen Hours ends up on a task with eight hours planned? Well, he struggles, he overspends his time, and essentially, spends thirteen hours on it. Well, that’s five hours lost from the sprint backlog. But, that’s the point, it’s not lost, it’s still in there, still estimated to some task, and someone has to pick up the slack.

Not only does Mr Estimated Thirteen Hours end up blowing his workload on red hours (hours spent on tasks outside planned hours), but he pushes to work faster, and his code becomes messy, his tests fail, and he doesn’t care because he has another task, failed tasks, and testing to juggle.

Before I continue I want to quickly point out one more flaw with the way we’re running scrum. Sometimes there’s one or two team members who simply cannot estimate, either due to mental deficiency, or due to lack of understanding of the task. As product owner, I can’t pick up on this. I don’t know if the developer truly knows how to write the appropriate code. If he says he understands what needs to be done, then I have to trust him. The only thing I can do is watch his eyes during estimation. He will be trying to see other people’s estimations before selecting his own.

Estimating.

Yes, estimating is one of the main problems we’re having. We strictly plan the sprint based on the developer’s estimates. With a small team, this can be a fatal mistake. We’ve had several failed sprints which have failed because the team was not large enough to provide enough intelligent estimations.

Essentially the entire release date depends on the developer estimations. If they can’t get it right, you’re boned.

Back to Mr Estimated Thirteen Hours.

He has 56 hours of work to do during the sprint. But he always, always spends 30% more time on his tasks.

He works 56 hours on only 40 hours of sprint tasks. That means at the end of the sprint, assuming other developers stick perfectly to the plan, there’s 16 hours of unfinished work. Scrum has no real way to manage this. And neither do we. We sit scratching our heads in the retrospective, wondering what went wrong.

The only solution: lower the velocity for this developer by 30%.

Now we have a mixed-velocity team. This is against the scrum guidelines. But it is the only solution I can see.

In conclusion, scrum is probably still evolving, you can learn a lot from the first year of it’s implementation at your company, and you have to be prepared to smooth-out the rules a bit, if you want this much-kneaded methodology to fit in your pie tin.