Scrum Scrum Scrum

Scrum can be easy. Scrum can be hard. Scrum can be perfect. Scrum can be so wrong. Scrum can change everything. Scrum can change nothing.

Is it because of Scrum or the way we use it?

Is it just the pessimist stating that Scrum doesn’t work, or doesn’t add any value? Is there any truth to it? Is there truth to the optimist stating that Scrum revolutionized “our” business improving our performance with X percent? Was it because of Scrum or something else?

Personally I think Scrum is one of, or perhaps “the”, best model for team-work out there at the moment. But that’s also it.

I’ve worked for small organizations where Scrum actually might not be needed; it all depends on mindset of the people working together. But I can also see how it would have helped us become more efficient and focused on doing what counts.

For larger organizations though I think that Scrum as the team framework makes, almost, immediate sense. I’ve seen plenty of teams destructively working on unimportant tasks just to generate “heat”. To be stressed out for deliveries even though it is unclear what to deliver and why. To be bogged down by tasks from other teams without the quantity of extra work ever being visible. To be part of a team but completely unaware of what the other guys and girls are filling their days with. What they are actually filling their days with.

But!

To use Scrum in a larger organization is far different from adopting it in the little “SW-shop” with 10 or so developers. During Scrum trainings and seminars I’ve been getting answers implying that as long as you stick to SCRUM you are doing the right thing and that Scrum will point out where your problems are; irrespective if you are 100 or 10 people.

The problem is though that many of these problems can’t be solved by following the rationale of Scrum. Because for large organizations the team-work aspect makes sense but other straight lines in Scrum might need some bending. Or you will at least need to add things to deal with issues you have simply because you are a large amount of people with a lot of interfaces.

Scrum doesn’t have roles (besides the golden 3) and traditionalist state that everyone in the team should able to do any task… is that really practical, cost-efficient, or even possible? How do you put together your teams with this in mind?

Scrum appraises the retrospective but does that really mean you are working towards constant improvement? Does it really?

How do you Scrum when your organization are both assigned with product development and product maintenance? Can you time-box maintenance?

How do you fit testing into it all? Unit-testing sure, how about integration test?

How do you deal with geographical spread?

What do you do if the DoD depend on other teams?

How do you deal with extensive documentation that can be required due to legal or safety aspects?

How long should a sprint be when our cycle-times are long? To short and we add too much overhead, too long and we aren’t Scrumming anymore. Or?

There are a lot of questions around this that I find interesting, for some I think I have the (or at least one) answer and for some I’m still doing some soul-searching.