Skip to content

Instantly share code, notes, and snippets.

@AnthonyBriggs

AnthonyBriggs/scrum.md

Last active July 30, 2017 06:46
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 1 You must be signed in to fork a gist
  • Save AnthonyBriggs/a22d96f816abb446efd5 to your computer and use it in GitHub Desktop.
Save AnthonyBriggs/a22d96f816abb446efd5 to your computer and use it in GitHub Desktop.
Download ZIP
Detailed rebuttal / explanation of Giles' "take down" of Scrum
Raw
scrum.md

Story Points

20 point stories:

So, for example, a project manager might say "integrating our login system with OpenAuth and Bitcoin," and you might put up the number 20, because it's the maximum allowable value.

That's one option. You might also say:

  • "Bitcoin? WTF? Why do you need bitcoin for login? How did this story make it through backlog grooming?"
  • "That story's far too big to estimate accurately, we need to break it down." (OpenAuth and Bitcoin are two separate things, etc. Again, how did it make it through grooming?)
  • "20? That's too high - we integrated system X, which is similar, and it was only really 5 points." "Ah, but to do Bitcoin properly we need..."
  • If you're the lone holdout at 20, you might go with the flow, but ask to record your opposition. This comes in handy at review time if/when the story blows out.
  • I've also used planning poker decks which went higher (50, 100 points) and had infinity symbols and question marks. I don't think they were used very much, but it helped [UPDATE: the picture on the blog post even shows these cards]

Disagreements in Planning Poker

I have literally never seen Planning Poker performed in a way which fails to undermine this goal. Literally always, as soon as every engineer has put up a particular number, a different, informal game begins. If it had a name, this informal game would be called something like "the person with the highest status tells everybody else what the number is going to be." If you're lucky, you get a variant called "the person with the highest status on the dev team tells everybody else what the number is going to be," but that's as good as it gets.

A nontechnical participant has, at any point, the option to pull out an egg timer and tell technical participants "thirty seconds or shut the fuck up."

[Note that I think you're being harsh with the egg timer. The point is to keep the discussion rolling, and to see whether the discussion has had any effect on people's estimates, not to limit conversation ]

So... the first question here is "Where the fuck is your Scrum Master*?" Because this is exactly the sort of bullshit they should be jumping on... hard. There are plenty of options open if a story is generating too much hostility:

  • The most critical: If you don't have a Scrum Master with the power to tell the PM to STFU, you're not doing Scrum :)
  • The second most critical: If a project manager is leaning on devs to produce lower numbers, they should be warned and/or ejected. Estimation is one of the critical communication paths between the dev and management camps, and if you scuttle that, management are blind and you're back to "rolling around in the mud".
  • If the discussion is heated, you should be relying on previous stories to give you some idea of the weight of this one, or using some other evidence somehow.
  • Leave the story to simmer and come back to it later on in estimation.
  • Pull an average, or tiebreaker it somehow, but RECORD THE SCORES and the arguments for the retrospective.
  • Push the story back to the Product Owner for clarification, or to break it up.
  • The "Put up or shut up" approach. If the vote is split, or agreement can't be reached, the story is earmarked for one of the devs who thinks it's easy :)

[* Scrum Master is a bit of a silly term; Scrum Coach or Process Coach might be better and more accurate ]

Broader Point

I think, however, that there's a broader point to be made, which is that one of the key principles/effects of Scrum is to surface problems in the development process really early, so they can be dealt with. Even in your case, which several people have already agreed is thoroughly broken to the point of being pathological [ha ha ScrumBut(tm)], it's working -- just by making everyone sit around and play a "stupid" Planning Poker game.

It sounds like the PM or lead dev is leaning on people to give nice low estimates. That's a problem (not one specific to Scrum), but now it's surfaced and everyone can see it. You can document it, and you'll find out who's right at the end of the next sprint. In a normal dev environment, management might not figure out that estimates are total bullshit until the whole project's 12 months over schedule -- if they even do, and don't just fire everyone and start over with a new team and a new $million.

Stand ups

Giles' problem with stand ups is that they tend to go for longer than 15 minutes. Fair point, but a known problem. There are a couple of "house rules" which help.

  1. Three pieces of information:
    • What did you do yesterday
    • What are you planning to do today
    • Are you having trouble with anything? (or likely to have trouble?)
  2. Anything more than that, punt until after the meeting (the parking lot). Except that where I've been involved, the "parking lot" is small, targeted meetings with just the people involved (usually "I need help understanding module Y" or "What's the backstory behind story X?") And those sub-meetings don't have to be in the scrum office (and usually weren't - they'd be while looking at code on someone's screen, or over a notepad).

At one company, a ponderous, overcomplicated web app formed the centerpiece of the company's Scrum implementation.

Web app not working? Kill it with fire. Or have the scrum master / management take notes during the standup and update the behemoth afterwards. Not a huge deal - Scrum is supposed to be an agile process.

Sprints, backlog and other dodgy names

Yeah, bad names. Giles and everybody else who doesn't like Scrum jumps on the names of things, but it's just a name. "Iteration" works just as well as sprint. I can remember sprints at one place being referred to as "our glorious one week plan" (complete vit dodgy russian accent, comrade). "Wish list" vs. "Backlog" vs. whatever other name you can come up with? Who cares?

Velocity

This is one of the better parts of Scrum, IMO. Standard procedure in most places is management badgering developers as to whether they're going to meet the deadline, and developers going "Gee, I sure hope so!" and being pressured to work overtime. Neither party has any idea whether they're going to hit the deadline until it's really close and the programming is either done or it isn't. Even then, trouble building the damn thing, or QA suddenly realising that a major sub-system is wrong, can blow your deadline out of the water.

Instead, you build a bit at a time, test it and make sure it's done-done, ie. tested and ready to ship. Rather than develop for 6 months and try to build it/test it/get it accepted/delivered right at the end, you do a little bit of it (1/24th or so if you're doing weekly sprints) and get that accepted.

Decent (small, accurate, concise) user stories, estimating with points and using previous work to estimate is one of the most accurate, low-stress, risk free ways of estimating that I've seen, mainly because it takes the developer out of the frame.

Issues with points, velocity, etc.

Is this perfect? No, there are all sorts of things that will crop up. Developers tend to low ball estimates, or react badly and overestimate, problems crop up that mean that you can't finish a story, stories being estimated might be crap, the team might have a bad week. But scrum also has short term iterations. Worst case, you have a few weeks of wild up and down estimates before you start being more consistent. Better stories, more accurate estimates, consistent velocity.

Again, Scrum brings issues with your development out into the open:

  • if you have trouble hitting x/24 points worth of stories in a week, it means you may not meet your deadlines. Great! You know this four months out and can adjust -- rather than 3 weeks out, when you can't
  • your manager who's jumping up and down about people leaving early will probably calm down once he can see solid, concrete progress being made, demo the product to clients without rehearsing for three weeks, and has some confidence that it'll ship on time.
  • you discover that one of your developers on the team is producing half the story points that the others are. Great! You can figure out why that is and help them out.

Think of it as an attempt to drag developers and management halfway to reality.

with the exception of a few Heisenbugs, engineering work is already inherently more accountable than almost any other kind of work. If you ask for a feature, your team will either deliver it, or fail to deliver it, and you will know fairly rapidly.

This is incredibly detached from reality. Firstly, programming is not engineering in any real sense. (If it is, you have a far more scrupulous and detailed process to deal with than Scrum). Secondly, software projects have overruns all the time. Millions of dollars worth of development -- canned, because the team wrote something that doesn't compile, or there are so many bugs that it'll never ship, or the team burns out and quits en masse, or the company wrote the wrong thing and customers hate it, or the initial estimation was never revised, or the marketing director cut the estimates in half to meet an arbitrary deadline.

Ranting

And about this point, there seems to have been enough explaining, and the ranting starts. So there's not much structure to this bit, sorry, blame Giles :)

  • Using velocity on a "rescue engagement" is pretty much the worst thing you can do. Development in terms of stories may actually go down, you'll have no confidence in the estimates (since the code will likely be buggy), developers will usually be demoralised and burned out and not want to have Scrum lumped on them (although if you get buy-in from them and some leeway from management it could work really well).

  • Accountability. Programming is rarely accountable. If you screw up a project, it's relatively easy for a programmer to just jump ship to a new job. For management, unless they're technical, it's a nightmare. See above - programming projects crash and burn all the time. Accountability is built into many fields - Accounting for example, the home of double-entry bookkeeping, spreadsheets, reconciliation, and laws where you can go to jail for fraud or fucking things up.

    Here's a fun game - go read http://www.geotechconsultant.com/lawsuits.pdf and replace "engineer" with "software engineer", "structure" with "program". Sounds ludicrous, but that's how "software engineering" works. You couldn't screw up a $100M bridge and get away with it, but for a software project? No problem.

  • Ads, blah blah - not sure what the point is here, other than Giles needs an editor. Oh, and online advertising actually screwed a lot of marketers, since click-through ads are trackable and accountable. Part of the reason that newspaper and TV ads are declining is that the internet showed that a lot of ads don't work.

  • Scrum is a "demeaning ritual to dumb down your work so that people who will never understand it can pretend to understand it." Gee, arrogant much? "Meanwhile, work which is genuinely difficult to track doesn't have to deal with this shit." Which work is this? Marketing? They have targets just like everyone else.

  • "business people and developers must work together." Why are we supposed to think developers are not business people? Er, because they're usually not? Typically they'll be siloed - biz throws a wishlist over the partition, dev grinds on it and management find out a few weeks from the deadline whether dev will hit it or not. With a bunch of psychosocial stress thrown in for good measure.

  • Oh look, Giles joined a startup, wrote some code, joined a dysfunctional team, had some people fired, etc. Not sure how this is a relevant point either

  • Face to face communication is still the most important means of communication. For example, your customers do not give two shits about git log, and will make their purchase decisions based on who they like the most. If you sell to developers or people who are technical, great, a nerdy blog post will probably do (hint: Look at the blurb on the front page of pandastrike.com) - otherwise yeah, you'll probably need to at least pick up the phone.

    Developers are not immune to this either. If you have a disagreement about something and you do everything via text, you'll get a lot of shitty emails and hurt feelings. Distributed teams (at least, the ones that I've worked with) use chats, Skype and hangouts with webcams with wild abandon.

  • "Github was built without face-to-face communication" Utter crap, go read http://tom.preston-werner.com/2008/10/18/how-i-turned-down-300k.html and look at how much face-to-face time they have. Ditto for Linux and OSS - sprints (as in, lots of devs in a room, usu. at a conference) are a very popular part of OSS culture. It's a piece of cake to tell whether someone's in trouble on their part of the code by just talking to them; it's much harder over email.

  • Designers should be included in sprints, ditto sysadmins, DBAs, etc. Also see above, accountants are absolutely kept tabs on. Trust, but verify, etc.

  • Trust is ultimately earned, not given. One of the great ways to earn trust is to be frank and open with people, be accountable and ready to own your mistakes. That's pretty much what Scrum does, AFAICT.

Some bits of Agile that Giles missed

  1. It's not meant to be onerous. The main idea behind Agile is that it's agile. 15 minute standups, simple stories for specs, tracked with index cards and sticky notes, simple burn downs and points to measure progress. If you're spending lots of time doing paperwork or meetings, it's a red flag.

  2. The retrospective. At the end of each sprint, the team gets together and works through what went wrong, what went right, etc. Things which are demonstrably crappy go out the window, new promising processes get brought in. Heavyweight web agile tool not working? Can it, or use index cards and someone can enter the stuff later. BUT give the process a fair shake first, since there are aspects of it that fit into each other well.

  3. Scrum masters and process. Any new thing is going to be hard to do at first - people will fall back into their old habits unless they're pulled up on it. That's where the Scrum master comes in. They seem to be a bridge between dev and management, also a shepherd of the scrum process. If your process goes off the rails, it's probably that you didn't have a Scrum master, or they weren't fully across scrum, or they didn't have enough power within the organisation.

  4. Scrum is not a silver bullet. It can't deal with truly pathological people or organisations. Neither should you use it in every situation (eg. a nuclear power plant). Where it does excel is in developing business software - which might change halfway through, or need to be delivered relatively rapidly.

I'm not going to deal with Giles' second post

It's ranty ad-hominem, mostly incorrect and he should have slept on it before hitting post.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment