Why SCRUM Fails the Artist

shakespeareContributed by Nicole Reineke

I find myself struggling with the recommendations of extremist SCRUM practitioners. The idea of paring everything down to a minimum set of customer-value features, then continually iterating those down to their bare bones (as an extremist view of the SCRUM methodology might suggest) is interesting, but not always the best way to create great software.

After some real soul searching, I have come to the conclusion that it’s the artist in me that is frustrated by the SCRUM extremists.  And, as Jobs would have told you, great software products are like art (you know it’s great when you see it).

To illustrate my struggle, let’s take a nice extreme view of what would happen to great writing if we forced it into SCRUM.  Imagine Shakespeare’s Romeo and Juliet written by a SCRUM team. The Epic is the original work, and what follows are the stories (let’s just pretend Romeo is our primary customer, we know Juliet is a business value and Tybalt is a primary conflict for the sake of brevity.

SCRUM PM NOTE: I took a quick look at the Epic, and got rid of the families as requested, they are incidental and add way too much development work to the story. The audience will be OK with an action/adventure love story.  Here is the minimum set of stories:

  • STORY 1: As Romeo, I want to fall in love so that I am no longer depressed.  I will know this is done when I attend a ball with my cousin and meet Juliet.
  • STORY 2: As Romeo, I want to meet Juliet so that I can find the love of my life. I will know this is done when Juliet is my wife.
  • STORY 3: As Romeo, I need to fight Tybalt so that I can protect my honor.  I will know this is done when I duel and kill Tybalt.
  • STORY 4: As Romeo, I want to return from exile so that I can marry Juliet.  I will know this is done when we make a commitment and I spend the night in her chamber.
  • STORY 5: As Romeo, I want to kill myself when I think Juliet is dead (while she is in a coma) so that I can be with Juliet in death.  I will know this is done when I am not breathing.

SCRUM PM NOTE:  The PM concedes.  The customer does not need all of those things to enjoy Romeo and Juliet. I suppose we can do without the ball, and the dueling. The audience will be OK with just a love story.  Here is the minimum set of stories:

  • STORY 2: As Romeo, I want to meet Juliet so that I can find the love of my life. I will know this is done when Juliet is my wife.
  • STORY 5: As Romeo, I want to kill myself when I think Juliet is dead (while she is in a coma) so that I can be with Juliet in death.  I will know this is done when I am not breathing.

SCRUM PM NOTE: Really, Juliet is a big job. Does it have to be Juliet? That seems oddly specific. And, the whole coma thing, do you really care HOW she gets on the slab? And, do you really care how Romeo dies for that matter?  Here is the minimum set of stories:

  • STORY 2 Revised: As Romeo, I want to meet a female human so that I can find the love of my life. I will know this is done when a female human is my wife
  • STORY 5 Revised: As Romeo, I want to kill myself when I find a female appearing dead so that I can be with the female woman in death.  I will know this is done when I am not breathing.

SCRUM PM NOTE: OK. I give. I need to get this out. Release 1 can just ship with the death scene.  Here is the new story:

  • STORY 5 Revised: As Romeo, I want to kill myself so that I am no longer depressed.  I will know this is done when I am no longer breathing.

SCRUM PM NOTE: Let’s release it. I now have a book to sell, some set of people will buy it. Will they LOVE it? No.

Bringing software from good to great requires providing customers with the little things that make their job easier, giving them that extra thing that makes them LOVE you.  I am being extreme, but I feel strongly that the details, the finishing touches matter.

And sometimes, that is contrary to SCRUM’s minimalist view.

Image from Flickr


NicoleReinekeNicole Reineke  has spent the last 15 years as a Product Manager building and designing business continuity solutions for the IT industry.  At Stratus Technologies, she was Senior Manager of Cloud Solutions and Agile Product Owner, where she defined and has patents pending for the first Fault Tolerant OpenStack software solution for enterprise clouds,  she was a founding team member and Director of Product Management at Unidesk, designing and delivering centralized virtualization management solutions, and at Connected Corporation, now part of HP,  she managed engineering teams delivering solutions to the Fortune 500.  Nicole is currently  co-founder and VP of Product Management and Marketing at Nerdkin designing and building cloud-enabled apps for service professionals.

One thought on “Why SCRUM Fails the Artist

  1. Great point about working with “extremist SCRUM practitioners.” I agree that it’s a constant battle to fight back their urge to eliminate the little things. While it can be frustrating, it can also force important critical thinking about why those little things are important. Not necessarily because they aren’t, but to focus their purpose.

    For Romeo and Juliet, why are the families critical to the story? Perhaps to establish a sense of hopeless longing early on that makes it even more rewarding when they marry, or to make their love more exciting for the reader by elevating it to an act of defiance, etc.

    For finishing touches on software, perhaps the little things, while little in practical purpose relative to the whole, are important for other reasons E.g. to elicit an emotional response of surprised delight in the user, to engender good will for the app/brand/service, or because the correct frame of reference is not “This feature makes us 2% better so therefore it’s pretty unimportant,” but rather “This is a feature all of our major competitors have so if we don’t we’ll look outdated.”

    I’ve also found that the degree of release-related marketing efforts is a useful consideration as well. Often the hypothetical SCRUM practitioner of which you speak will argue that any small things can be saved for a later release and can be re-evaluated against everything else after some data starts coming in on the first release.

    But if significant efforts and money are going into driving traffic for a specific release, you don’t get a second chance with those new potential users. So the “overbuilding” that some may say you’re trying to do is sometimes justifiable as you have a limited number of chances to spend big on user acquisition and retaining as many as possible the first time may be worth an extra week or two of dev time.

    Good post!

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s