what does it mean "to do Scrum"?

Jane Prusakova's picture

A dictionary definition says: "Scrum is an agile software development model based on multiple small teams working in an intensive and interdependent manner", but what does it really mean?

Jim Shore in his recent post on the fall of agile points out that "[Scrum] also has a few mechanical things about a monthly Sprint and daily Scrum. Trivial stuff compared to the rest. But guess which part people adopt? That's right--Sprints and Scrums. Rapid cycles, but none of the good stuff that makes rapid cycles sustainable." That's been my experience too - every organization that claims to do Scrum has a daily meeting called Scrum, a few-weeks-long cycle called Sprint, and many have once-per-Sprint long meetings.

People who love meetings tend to like Scrum, probably because of the heavy meeting schedule. Those who prefer to get their work done, tend to hate it - the heavy meeting schedule disrupts the flexible workday arrangements, leaves less time for actual work, and a lot less time for thinking. Unfortunately, it's entirely possible to spend lots of time in meetings, and have poor communication. A bigger problem is that poor performers are usually better at adjusting to new and exciting management games, while high-performers usually have more options to go elsewhere.

However, the biggest problem with Scrum is the expectations of a Silver Bullet. Just because a group of people decided that they'll build something of value in the next few weeks does not make it so, regardless of how many meetings they hold. Scrum might be good (or at least better than the alternative Waterfall) at exposing problems early, but no amount of ceremony will solve real business and engineering problems.

Those teams that make Scrum work for them usually end up doing something different than Scrum-by-the-book - fewer and shorter meetings, more informal communication, retrospectives and planning sessions held on as-needed basis, rather than on schedule, more time and more respect for getting real work done.

Is it still Scrum? But, then, who cares - as long as it works.

Comments

softwarejanitor's picture

I hate meetings, so I've

I hate meetings, so I've never been a big fan of scrum.

SteveDonie's picture

I've been using Scrum and XP

I've been using Scrum and XP for two years now on a small team, and used it for 2 years before then. I have found it incredibly successful.

I haven't ever used it in larger teams, so I can't say that the meeting overload doesn't exist in that context. The way we work is that we have one short standup meeting every morning - 15 minutes max, and then 1 meeting per week to do iteration planning. We use 1 week iterations rather than 2 weeks or 30 days. Typically our iteration planning meetings take less than an hour. I do find that having a schedule is important - if you don't have a regular 'heartbeat' it is too easy to get into an endless slog.

One thing I think that many people miss when adopting any agile project management system is that one of the key aspects of each of them is reflection and feedback. If the team sees problems, it is their responsibility to point out the problems and adapt the system to try and fix them.

We (should) all know there are no silver bullets.

I'm curious - softwarejanitor, have you ever done scrum?

For anyone interested, I recently posted a blog entry showing the burndown from my most recent project. http://stevedonie.lostechies.com/

softwarejanitor's picture

No, I've never been directly

No, I've never been directly involved with Scrum, I've only read about it. The development group where I work now is so small that we are below the threshold where a formal methodology like that would help now. While we used to have 10-15 developers and occasionally did new development projects we now only have 4 developers and are pretty much only doing regulatory compliance and "keep the lights on" kind of maintenance work. And generally other than code reviews, we aren't working together on anything anymore, we each have systems we are maintaining until the services they provide are transitioned to another office and the office here in Austin is shut down.

Even when we had a big enough development group to warrant needing much formalized structure the management here was so enamored with detailed project specifications and time estimates that we were pretty much forced into a waterfall-ish methodology. At one point they brought in an architect from the outside who tried to bring in Agile RUP methodology, but before he could get very far with that he got caught in one of the rounds of layoffs here and since then we've had pretty much no leadership and no direction. Unfortunately none of the 4 of us who are left have any authority to do anything and we answer to a hands-off out-of-state manager who has too many direct reports (30+).