Upsides of Scrum

In many team sports, players are selected by teams through a draft system. If you’re a bit of a sports nerd and you follow these drafts closely (as the team you root for is always in the dumps and therefore higher in the draft order), you’ll hear a lot about players’ “upsides”. Upsides are the opposite of downsides. They’re seen as a set of potential benefits as opposed to possibly risky deficiencies.

Scrum is a bit of the same. It has the potential, in some scenarios, to work really well. Potential isn’t certainty, however, and that amazing athlete in the college ranks may crash and burn in the pros. Although the warning signs were there, the athlete’s upsides often warrant a high selection.

Scrum does have its upsides:

  • Forces iterative development
  • Forces regular feedback
  • Forces business participation
  • Forces a single voice of direction (product owner)

In some situations, especially large IT organizations, I’ve seen Scrum work really well. These are scenarios where you might have disparate organizations with no common authority in their HR hierarchy. We could measure our success on participation of other business units by their distance away from us on the org chart, following chains of command. In fact, there’s probably a PhD thesis out there talking about effectiveness of teams given their distance as plotted on a directed graph.

Organizations and divisions that don’t have a common goal or have competing interests and conflicting schedules can benefit from an outside force to ensure that regular delivery happens. Often, I’ve seen places where constraints are lifted on regular delivery through sprints and measured productivity and delivery drops precipitously. Sprints tended to force apparent dysfunction into some level of stasis and a modicum of collaboration.

While not always fun or ideal, these externally forced heartbeats act as sort of a pacemaker to the value delivery system. Remove the pacemaker, and the patient suffers or potentially dies. Apply the pacemaker, and although the patient isn’t going to run a marathon, they can lead much more normal life. The team might not ever get any better at delivery until they break the bonds of Scrum’s ceremony, but in some cases, Scrum is as good as it’s ever going to get.

About Jimmy Bogard

I'm a technical architect with Headspring in Austin, TX. I focus on DDD, distributed systems, and any other acronym-centric design/architecture/methodology. I created AutoMapper and am a co-author of the ASP.NET MVC in Action books.
This entry was posted in Agile. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • I’m in  a situation where there are competing product owners who will try anything to get to a developer and have him/her work on the product owners piece.  I am working agile/scrum into the mix and it seems to be well received so far. It does have challenges such as the cultural change of having the product owners decide what the priorities should be as we move all items into a single product backlog.  

    It really is  a suite of software that the team maintains, and the priorities should not be set by who can put the most pressure on a developer at any given point in time. I like how we are able to provide more visibility into our work and empower the product owners with information needed to make decisions. The common goal is an important piece here and the product owners are requiring some coaching on how we all move together to row the boat in the same direction.

    It uncovers the blemishes in the system, but just using that information to direct healthy change is very helpful.  I have enjoyed the challenge so far and hope the positives far outweigh the negatives in the long run.

  • Anonymous

    The places where I’ve seen it used best is when the weekly planning and retro meetings play a crucial part in communicating with people outside of the dev team.  In this situation, I would not consider these meetings waste, but important communication tools.

    I scenarios where the team is functioning well and there are no barriers to communication, then a lean / pull model works really well.  Plus you get the added bonus of removing the marathon planning meetings.