Uncharted Waters

Oct 5 2015   10:46AM GMT

Why Is Scrum Valuable

Justin Rohrman Justin Rohrman Profile: Justin Rohrman

Tags:
Agile
Scrum

Companies have a hard time putting out software, and an even harder time doing it on time. There are lots of different things that can go wrong from veering way off course from what the customer wants to never ending problems in implementations to having no clue how far you are from the beginning or how close to the end.

For the past 20 years or so whenever people are having these problems, a new process framework has been the answer. There is XP which puts 2 programmers working on one problem, lean tries to remove all the cruft so that all you are left with is value, and then there is scrum.

Scrum is often one of the first things people try when they want to shake up their development process and hopefully fix a lingering problem or two at the same time.

Why Scrum though? What is the value in this practice?

Jeff Sutherland presented Scrum to the world formally at OOPSLA 95. He had spent years developing the framework and using it in real software development companies prior to that. Each company had a similar problem. There was a team of programmers working on building a project that was way over budget and way past its due date. If team members were asked when they thought they would be done, they’d give a date, inevitable encounter unanticipated problems, and that new date would fly on past just like the others.

The team members weren’t talking to each other and didn’t understand why they were having problems.

Enter Scrum

Scrum introduced a framework into what was otherwise the wild west. Instead of taking the next requirement off of the stack, writing some code, and committing to the code repository in isolation, Scrum forces people to talk to and listen to each other at least once a day. Once a day doesn’t sounds like much at all, but for people that were used to working alone for weeks or months without course correction it is huge.

2000px-Scrum_process.svg

So everyday, the group now gets together to talk about what they are working on, and what is preventing them from moving forward. The rest of the team hears that and now knows that this person has dependencies with code I’m working on. The product manager hears descriptions of work and now knows there is a bug in the specification before code has been written. Testers hear developers carefully talk about parts of their code and now have ideas about where they should focus their work.

The theme here is problems. Scrum has a tendency to throw them right in your face everyday where before they were either unnoticed or quietly swept away till we try to push a build and things fall over.

A few simple questions expose that to the world.

Seeing all of that is tough. Before scrum, you see code getting quietly committed every day, and after you hear about how someone can’t work and how another person keeps changing code from underneath someone else. Figuring out what to do with all of this new information is what makes the process useful for some, and causes others to abandon the problem exposing process, and go back to what they were doing before.

For some, Scrum is just a beginning. A tool that gets introduced and eventually goes away because people no longer need it. And for others, it is a burden that needs a support group and life support.

Scrum is deceptively simple, and people have a lot of problems finding the value. My colleagues, Matt Heusser and Markus Gärtner wrote a book on this very topic called Save Our Scrum. Next week, I’ll give some of my thoughts on that book and dig deeper into the question of value.

3  Comments on this Post

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.
  • techietubby

    Scrum may work for software development but it certainly does not for anything where the work is varied or unpredictable such as support. On a typical day you waste more than an hour whilst the members of the team with the strongest personalities drone on about how wonderful they are, whilst the others look on in mock adoration.

    I find the idea that you don't document anything maybe fine when you are producing code (fragments) however good documentation is vital for support. We deal with complex problems that rely upon solid research and thus having the daily interruption ios simply a massive distraction that I can do without.

    The dictionary defines a scrum as a place of great noise and confusion. Need I say more?

    160 pointsBadges:
    report
  • Justin Rohrman
    @techietubby

    I find software work to be varied, and occasionally unpredictable. If it were predictable, we would discover bugs and testing wouldn't be important.

    Also, I'm not sure that there is any edict to not document anything. There is certainly a focus on not documenting to the degree of detail we used to think was necessary.

    It sounds like you may have had some bad experiences. I can appreciate your anecdote, I've had similar experiences. I've also had experiences where it was a valuable tool.Group dynamics matter. 
    2,130 pointsBadges:
    report
  • ACowan

    Justin,

    I can see how it helps with software because you are dealing with "known unknowns" whereas we are dealing with "complete unknowns" e.g. you know what your software should do/isn't doing whereas in security we have both false positives and false negatives that can mean you sometimes have to work out what you are actually looking at/for, and SCRUM tries to over simplify this by saying you can slice-up things.

    In some instances you can slice, however more often than not you either know something or you don't, you can't slice that, and half-know something.

    40 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

Share this item with your network: