Scrum: A Framework for (Finding) Failure

Hacker News LinkedIn Facebook Twitter by Abby Fichtner

Scrumbut!Ken Schwaber, co-developer of Scrum, just gave an interesting talk at the Agile Project Leaders Network. Scrum, he explained, is not a methodology, but a framework for developing complex products.

The thing about complexity is that the more of it we have, the less likely it is that an external entity can dictate our way to success. There are just way too many variables and too many unknowns. Instead, what we need is a safe, supportive environment in which the team can generate ideas to dynamically deal with this complexity.

Scrum serves as a container for this environment. It’s not a methodology, it doesn’t tell us what to do (we still have to figure that part out). Instead, it exposes the weaknesses and, dare I say, failures in how we’re doing it.

Scrum is not going to solve your problems, it’s just going to make them in-your-face obvious, every day.

“Do you have a mother-in-law?” Ken asks one of the men at the session.

“Of course,” the man laughs. “Now imagine that your mother-in-law believed her daughter could do better,” Ken proposes. “And then imagine that she moved in with you. That’s what Scrum is like.”

You see, the other thing about complexity is that it’s really hard (as a customer of mine recently reminded me). No matter how smart we are, we’re still going to get some things wrong – either because we misunderstood, or the conditions of success changed, or just because that’s what it means to be human rather than a machine. And so which is more helpful? A process that pats us on the back and tells us everything is going to be just fine (see, it says so right here in the plan!)? Or one that provides us with immediate feedback when we get something wrong?

Think of the red x‘s in our IDEs that show us errors before we even request a compile. Or, the squiggly red underlines letting us know that “squigly” is misspelled (it has 2 g’s). It may sound counterintuitive, but if we can be notified of what’s wrong before we even think to ask; in a simple, non-intrusive manner, it allows us to to correct problems so easily that we hardly have to stop and think about them. Before those errors can domino out to impact other, larger things that are harder to fix. Before incorrect assumptions can kick off a trail of bad decisions. Before they grow to be complex problems in and of themselves that require massive amounts of rework and frustration.

Our goal is not to avoid all errors in software development (the mere act of creating new things requires a process of trial & error). But rather to spot them as quickly as possible, before they become a problem. Scrum is not as automated as our IDEs or text editors. But then, building software is a lot more complex then just banging out code or documentation. It requires really hard things like understanding what the customer wants. Which, of course, is never the same as what they say they want. So, there’s a bit of mind reading involved, which can be rather challenging. And then there’s making sure our code works. Not just on its own, but also with other people’s code, which of course is never as good as our own, so that’s a challenge as well.

So, we have these really hard parts in software development – and they’re mostly the parts that involve other people. And since we can’t just pull out our red sharpies and go around marking red X’s on people’s foreheads when they do things we don’t like, we have to find a different approach.RugbyScrum In Scrum, we do this by putting a framework into place that makes detection of errors as automatic as possible:

1. Scrum forces us all to work on the same pieces at the same time until each piece is completed to everyone’s satisfaction. This is done quickly and efficiently – the pieces are time boxed to fit into sprints that are, at most, 30 days in length. So, if there is an error or misunderstanding (you wanted the software to do what?!), it will be caught while we are working on the item. Each sprint produces production ready software, so we can move forward with confidence, knowing that we can reliably build upon what’s already in place.

2. We can’t automate error detection in human communication and understanding, so Scrum builds in human inspections at regular intervals that are designed to catch these types of errors as quickly & non-intrusively as possible:

  • Each day, we inspect our progress towards meeting our commitments in the Daily Scrum.
  • Each sprint, our customers inspect what we’ve developed against the product they want at the Sprint Reviews.

I say non-intrusively because in Scrum, these inspections are done as such a natural part of the process that they become second nature, like those red squiggly underlines (hey, something is wrong here if you’d like to fix it

And so, Scrum’s benefit is not that it tells us how to do things. But, rather, that it recognizes that only the team is in position to adapt and respond quickly enough to the unknowns and changing variables in order to drive the product to success. Scrum instead focuses on ensuring that feedback is always available to keep the team on track; moving in the right direction, closer and closer to their target.

Ken says when people do Scrumbut (We’re using Scrum, but… we don’t do X), the “but” often removes the parts of Scrum that expose problems (we’re doing Scrum, but… we don’t do Daily Scrums every day), thus defeating the purpose of Scrum. Does your project do Scrumbut? Does your but negate your Scrum?

  • Pingback: Kanban is the New Scrum « The Hacker Chick Blog()

  • Pingback: mercubuana()

  • Pingback: smash bros. wii u()

  • Pingback: Discover How I Made $770.41 with Just 3 Hours Work with 1 simple video!!! (which I didn't even make)()

  • Pingback: Agen Judi Terpercaya()

  • Pingback: Agen Judi Casino()

  • Pingback: Agen Judi Casino()

  • Pingback: best free porn()

  • Pingback: free online porn videos()

  • Pingback: best sex videos()

  • Pingback: แทงบอลออนไลน์()

  • Pingback: แทงบอลออนไลน์()

  • Steve Carter

    Good readable article thanks! I like Scrumbut particularly and will be watching out for that. We do scrumbut we tend to assign individual developers to individual tasks, for example.

  • Abby Fichtner

    Abhijeet – yes! I agree. I think even if we talk all day every day, the benefit is taking some time specifically to check in with how we’re doing at meeting the iteration’s goals.

    I like your idea of shortening it down if it’s a small, well connected group. If you’re talking all day every day anyway, how could it really be a problem to take 5 minutes to focus on “are we on track? do we need help with anything?”

  • I would see that many of us don’t believe in daily scrums, but then it’s like “I know what you doing anyways, so why to meet in the morning and say the same thing”. It happens for one day, then two days, and then eventually we meet once a week. Will that be beneficial to you? I don’t think so. I agree sometimes Scrum meetings feel like we know all this, but we still discuss it. Make the meetings short then! Bring it down from 15 min to 5 min, get it quickly done and go back to whatever you were doing, whether it was software development or training.

  • Ken is both right and wrong about ‘Scrumbut’.

    I have seen many cases where people did just that – removed the parts of scrum that exposed a problem. One has to be very careful when introducing changes to a system that works, because what one gets is an untested system that may not work as well.

    That said, some in the Scrum community are too inflexible in following the ‘book of Scrum’.

    One clear example is – if daily stand-ups do not work (e.g. people out of the office or working flex hours on some days), the Daily Scrum not being daily is A-OK. Insisting on a specific ritual over other important aspects (e.g. “respect for people”) is… not the way.

    Just my $0.02

  • Mary

    Hi Abby,
    Sure I am following this blog. Great replies! Thank you all.

    Again we are not coding / delivering software. Perhaps i have to explain for what purpose we use scrum (or Agile. We are developing other business valuables like training, howto apply XML, JMS, BPEL etc., howto migrate en help in that proces, we gather requirements, help envisioning, identify strategic goals, develop architecture and more. We work in iterations of 4 and 2 wk sprints, we have a internal pr. backlog and customers backlog prioritized and tasks estimated on sprint backlog. We appoint our own product owner for internal developing and know who our procuctowner is at customer’s site. Tests are reviews, we evaluate on what went well and what could be better and do check our solutions. We do have contact on a nearly daily basis through email, telephone (conference), google talk and wiki. We use a wiki scrumboard. We show estimates and progress in planning. We do not pass the nokia test by the ‘book’. If we fail this are we to be excluded?

    So scrum or scrumbut(t)and does this matter?

    Be well

  • I do get a little confused when SCRUM advocates from various places bang on about how you must use all of SCRUM to gain advantage from SCRUM. One of the foundation principles of SCRUM is to “Inspect & Adapt” – that must mean that if an aspect of SCRUM isn’t working for you then you should be able to adapt it to fit your environment… However – i do believe that the daily SCRUM meeting can’t be dropped as surely it them isn’t SCRUM at all. I have to disgree with Mary too – the burndown chart is seen as a valuable artifact by our developers – they like the visual representation of progress…and keen on both sprint and release burndowns tbh…

  • Abby Fichtner

    Abbot, I think that’s a good point on it having a different focus, even if we’re sitting in the same room communicating all day. We can get so in the weeds with what we’re working on, the Daily Scrum allows us to step back and make sure we’re still progressing as expected towards our sprint goals.

    I’ve seen some suggestions like making sure at least 1/3rd of the stories are “done done done” by the sprint’s half way point – to make this check in more explicit (sure we all did a bunch of stuff yesterday, but are we actually bringing any of the stories to completion?).

    I think a daily drink would be nice.

    Mmmm, now what would that do to our velocity? :-)

  • If you’re on a team that is in the same room all day constantly communicating, I think I can see the lure of dropping the daily scrum, but even then I think it’s important for the entire team to stop and talk about short and mid-term goals every day — it should be a different kind of conversation than the task driven communication throughout the day. The scrum meeting is a meta-meeting.

    I think a daily drink would be nice.

  • Abby Fichtner

    Paul & Abbot, Thank you!

    @Paul – I agree on the burndown charts, and I almost wonder (if Mary is still reading?) if their usefullness may have shrank from more scrumbut activities, such as lack of a product backlog (if we don’t know where we’re going, we can’t show very meaningful progress towards it). Or if there was another reason…?

    @Abbot – here, here for failure! :-) I agree on the daily somethings. If we’re working as a close knit team on iterations of only a week or so, don’t we need to at least check in with each other once a day? But, that’s interesting, maybe it doesn’t have to be the daily scrum, just something that is at least equally adept at helping us “inspect and adapt”… hmm. What else could we do?

  • I vote for daily something. I’m not sure how the framework be scrum without a regular scrum. Sure, it could still be agile, but I think cadence is important, both for the demo and the synchronization point. The planning moment has to keep re-occurring throughout the project.

    I also like failure. I’m a big fan! Just after reading this the other day, I went to a movie and saw an advertisement for Honda talking about starting with failure. Weird when that synchronicity happens.

  • Hi, here’s a vote for daily scrums, part of the “inspect and adapt” mantra. I don’t agree with the comment about burndown charts being useless, as they also imho provide the team important feedback on its ability to deliver (“velocity”), thereby also helping the team to “inspect and adapt”. Best regards, Paul

  • Abby Fichtner

    Hi, Jurgen,

    Interesting, thanks for commenting.

    Well, that’s 2 against feeling Daily Scrums are essential to Scrum… anyone for them?

  • Hi Abby, I would agree with Ken on that, up to some point. Though I think the daily scrums are not needed in some kind of environments. The planning moment is the most essential, I think.

  • Abby Fichtner

    Hi, Mary,

    Thanks for commenting! Very cool that you’re using scrum (with or without the but) on non-software projects. I find myself doing this too at times. And I agree, agile should be about being flexible, which means figuring out what works for us rather than getting all religious about it.

    I think there’s an interesting warning for us when we do so – about taking care not to just throw out the hard/uncomfortable parts that point out our weaknesses… in fact, now this has just given me an idea for one of those non-software projects that hasn’t been working so well for me. Hmmmm….

  • Mary Beijleveld

    Thank you for pointing me to the interview. I must say that Ken Schwaber is starting to get a bit biblical / mythical about scrum. As if the framework, or methodology, or whatever name you give it, didn’t change over the years. It really did. I am a really big fan of scrum and I use, what he calls, scrumbut for other purposes than developing software. We use it for ‘common’ projectmanagement and for knowledgemanagement aspects and actions. Do we meet regularly? Yes. Do we need a daily scrum meeting? No. Do we use a backlog? Yes. Do we need a burndown chart to know what our progress is? No, this artifact /document is useless. Do we evolve? Yes. Do we face problems? Yes, and solve them together…
    The way Ken is positioning scrum it is solely adressing software development, I can’t use scrum for other things and thus may not use the name. Like swearing in church? Very exclusive imho.