Thoughts on Scrum

I’ve been involved in a few projects that were using Scrum.

I don’t know about you, but I don’t have velocity all the time when I work. My working style is more like: Fidget for a while, noodling with things until they appear to work, re-writing and re-designing and throwing stuff away as the real problems become clear. I don’t appear to make progress for a while, then stuff comes together and starts working.

So I’ve been stuck in a scrum every morning. What have I done in the last 24 hours? I make something up: “I oprimanded the access code in the Glorok module, and got maybe half of the Schnorketic logging written.” In reality I’ve been mucking about with interfaces and playing with some sample code, or staring into space and taking notes and drawing boxes in my notebooks. Drawing cartoons, if things are really fuzzy; space-ships crashing into each other could be B-Tree nodes if you didn’t really know. Put my laser-eyed fighting robots in your fucking UML, I dare you. This works for me.

But I’ve never felt very good about the humiliation of scrum, every single stupid morning.

Things are different the fourth or fifth time you do something. The fourth or fifth take, you generally know what you’re doing — you’re on a Mission from God and on a good day you’re unstoppable. Lock the door and delete all that crap from your calendar. Get things done.

Scrum seems pretty good for doing things that you’ve done before, that is, when you have a pretty good idea of what you know you have to do. Scrum is a lousy fit when you’re doing exploratory programming, or debugging, or when you’re dependending on miracles [1] or anything else profoundly unfit for scheduling.


[1] A miracle is when you have a bunch of contingency plans, and A through maybe E didn’t work, then you wake up in the middle of the night and realize that F is going to get to you G which will, by gum, work. But you won’t get to this realization until you pay the dues.

Author: landon

My mom thinks I'm in high tech.

37 thoughts on “Thoughts on Scrum”

  1. During the short time I was involved in Scrum project, I always resented those meetings and just said whatever I thought would keep them off my back, too. The times I did mention that I wasn’t quite sure about something or other, they perceived it as a “roadblock” and shifted my tasks around. Very, very annoying.

    I can see why managers would want it, but if they can’t trust me to let them know when a project is in serious trouble at the appropriate time, I’d prefer they just fire me.

  2. Yeah…I work the same way. The worst was burn down. I’d have a 40 hour task and like clock work each day I’d tick off between 2 and 4 hours when in reality I didn’t do anything but try out some different ideas. By the time I was down to 10 hours of time left on the task, I would usually know what I want to build and go from there.

    But I’d work this way even if the task is something I’d done before just because I’d want to try out one of the other N ways that I’d thought of in the past for pure learning purposes 🙂 My PMs hated me.

  3. Is there some rule against saying that you’ve just been doodling or reading or whatever in your scrum huddle? The chances are that everybody else has been doing the same thing…

  4. I think you’re missing the point of the scrum meeting. Either that or your Project Manager is a right cock about maintaining velocity at all times. By now I’d hope that most companies recognise that programmers work can happen sporadically. The important thing is that everyone involved in the scrum understands that the timeframes that you should have established for each task at the beginning of the Agile process are still under control. It’s not about talking about how much work you’ve done – it’s about making sure the items you have checked out are still on target.
    Scrum is just one small part of Agile – if you’re not using all the fundamental parts your scrum meetings are obviously going to be lacking.

  5. @Sam: How do you know something is on target if you’ve never done it before?

    Customer: “I want a Frogswongle.”

    Team: “Okay. What’s a Frogswongle?”

    Customer: “It’s a framistan made of hoogers, vermifrob soffits and yaddayas. Now, go start . . . doing stuff. You know, all that typing of curly-braces and semicolons. Do that.”

    (three scrums later)

    Scrum member 1: “I have great velocity on this yaddaya. But every time I consult the verbal documentation, all I hear is laughter.”

    Scrum member 2: “I, too, have excellent progress made on the Hooger module. Yet, it feels like there is something missing. Some critical spark that will make the whole. Make it even compile. You could say that I am blocked. Conceptually.”

    Scrum member 3: “I spent most of yesterday trying to open a vein with a spork. I am blocked by these sporks of lousy quality.”

    Now, you’re going to say, “The team should never have signed up for doing a Frogswongle with no documentation, no planning, and no way to know whether any progress they were making was really progress or not.”

    And I’d say: “Yup.”

    A good team can probably do a “Frogswongle” if they are given proper support and a process whose core attribute does not require them to daily admit that they don’t know WTF they are doing yet.  Because on the burn-down chart, lack of velocity coldly translates to “Joe is just scribbling dinosaurs and someone needs to take over.”

    Scrum seems a fine fit for things-you-have-done-already.  It seems lousy for things-you-don’t-know-how-to-do-yet.  That’s all.

  6. It sounds like your team is doing Scrum wrong. We do Scrum where I work, and we do a lot of exploratory programming, debugging, and other things that are difficult to schedule. But the thing is, our management trusts our coders.

    When I don’t get anything done, I let them know:

    “Me? I did Jack-all. I THOUGHT I was making some progress on that weird user-save bug, but I haven’t tracked it down.”

    “Need help?”

    “Probably not. I just haven’t run across it yet.”

    “Okay, next.”

    And if, after a couple of days of that, I still haven’t run across it, the bug might be shelved for a bit for something that provides a better utility/time ratio. But you shouldn’t feel shame over saying that you didn’t really accomplish anything yet, and management shouldn’t make you feel shame. If they are, leave the Mythical Man Month laying around as a not-so-subtle hint.

  7. @Landon
    In the example you gave the team is making mistakes that have nothing to do with Scrum. Your example is the definition of a poorly prepared team and project. Can you name a single methodology which *would* be useful to them in that situation? No, you can’t. The problem isn’t with scrum – it’s with a disorganised company.
    There’s absolutely nothing wrong with standing up in a scrum meeting and saying: I have no idea what I’m doing yet – from my current progress I’d say that my initial guesstimate of two days to learn this API is way out and I’ll need to revise that figure to a week.
    If your Project Manager has a problem with you doing/saying that then the problem still isn’t scrum, it’s with your PM.

  8. The goal of the scrum isn’t to report to management what you did yesterday, scrum is a tool to report to your team members (which in the true spirit of scrum that is all that matters to you).

    Sounds like you might not have been working in a true scrum environment.

    1. I think everyone sharing opinions on the value of Scrum should state whether they are a manager or developer. Any developer who is excited about scrum and enjoys being micro-managed is probably not a high creativity output. Just a personal reflection on it.

      I am a programmer – for 28 years.

  9. “In the example you gave the team is making mistakes that have nothing to do with Scrum.”

    I think this is a prime example of a fallacy which should be called the “Explanation of Agile” fallacy. It seems like any time anybody says “I think scrum has issues here or there as a methodology” the comeback is: “You must be doing it wrong.”

    The truth is, no human created process is gonna be a perfect fit for every situation. It’s okay, scrum-heads, to admit that your process isn’t perfect all the time. That’s okay.
    Really! It is! It doesn’t make scrum or Agile or whatever you want to call your methods bad. It just means that they’re rough on some contact points.

    Landon, I have the same problem with scrum as a methodology: I think it’s generally a bad fit for startup-ish things; I think it’s really fine-tuned for entrenched corporate software products. That’s the scrum sweet spot. That’s where half the ideas came from for that whole camp, the Chrysler time monitoring program blah blah or whatever, right?

    It doesn’t really help when you’ve got a code base that you nor nobody else knows anything about and has to maintain, or when you’re doing completely new, unknown stuff. You have to make adaptations to it to get it to work. I, too, feel really dumb right now going to meetings and being like, “I estimated 2 hours for this task. It turns out it’s gonna take 6 days. Sorry.”

  10. Yeah, I always get the “Well, you must be doing it wrong” counter-argument. If you’re failing, you must not be doing Real Scrum.

    But I’ve never seen it done right. _Never_. Maybe all the people Ive seen try it have sucked at it — I guess it’s possible that the “certified scrum master training” that the scrum masters went to was worthless, or the surrounding management structure poisoned things

    The best response I got was from a former boss of mine who said, “Scrum is supposed to be a really light-weight process, and everyone seems to blow it out of proportion.”

    No silver bullets.

  11. “Scrum is supposed to be a really light-weight process, and everyone seems to blow it out of proportion.”
    Seems to be about right.
    I have no problem with picking apart issues with scrum/agile that are actual issues, but I do have a problem with the expectation that it’s going to be a solution to poor planning and preparation.
    People who get an undocumented project comprising technology they’ve never used before and immediately leap into the programming for it are going to FAIL. End of story. There is not a single project management methodology that will save you when you’re starting from such a gigantically poor first step.
    For the record, all our projects are completely new, unknown stuff and we make sure that we include the time required to document and learn what we need to before we ever sit down and write a line of code.
    1/3rd planning.
    1/3rd writing.
    1/3rd testing.
    If you’re not assigning appropriate time frames to the appropriate tasks then you need to take a step back and re-evaluate your own process.

  12. During our scrum training, management fixated on the published productivity increases of Paired programming. I’m fine with that, but now we do it %100 of the time. Time to look for a new gig.

    1. Face it – Scrum is for managers. Managers generally have a propensity towards meetings. No veteran coder is going to vote for daily meetings and say say it is more productive, regardless of the framework.

  13. @landon: Most people do scrum wrong at one time or another. In my organisation we’ve variously:

    * reported to the project manager/scrum master (instead, report to each other how you’re doing and if you need help);
    * tracked the number of hours we “spent” on a problem (instead, tell each other how much time you think you have left, and if you need help);
    * and various other problems.

    In my experience, the only time that velocity really matters is at planning time; you shouldn’t be measuring your velocity during a sprint, but should instead be seeing “are we going to make that commitment we made as a team?”

    It’s hard, especially when management doesn’t really get the concept, as has happened for far too long in my organisation. The key point is that, even if you don’t know what you’re doing to reach a longer-term goal, you should be able to say on a short-term basis (ranging from one week to a maximum of one month) what you can show your customer that has value to them. It’s not going to be their frobnicator, but it might be what frobnication files look like when saved to disk. It’s definitely not going to be their frobsync server, even if it might be a read-only view of a frobnitz.

    Scrum is, in my experience, about the team collaborating to solve the software development problem at hand. If the team doesn’t have some level of control over their intra-team collaboration, then they’re not practicing Scrum.

    I had a situation this past week where I said “I’m looking at XYZ technology” one day, reported research progress for the next two days, and then said “XYZ is too hard to do in the time we have. I’m punting and doing DEF instead. We may want to revisit XYZ when we have time, because it’s still the right approach.” It’s honest, and no one thought less of me for it.

  14. What does this have to do with Scrum, exactly?

    It seems to me that the core of this discussion is this:

    1. Do you believe that a developer should provide estimates for work, even if they’ve never done it before?

    2. Do you believe that a developer should provide status updates to his/her teammates on a regular basis?

    If that answer to those questions is “no”, then I submit you have larger problems than just Scrum. Scrum simply exposes those problems, that’s all.

  15. Grrr…

    This “…then you’re not doing it right…” “Oh, you always say that” argument is really getting old.

    Here is my experience: I’ve done agile right, and I’ve done it wrong. When it’s done right it works really well – it bridges gaping chasms that traditional approaches leave…wel…gaping.

    I’ve also worked on projects that successfully used tradtional approaches.

    Thing is, it was _a lot_ harder to be successful using the tradtional methods. That said, it was even harder to be successful on the projects with incorrect agile implementations.

    The problem is _it’s really difficult to do agile properly_. This mostly has to do with:

    a) people’s misconception that because it _sounds_ simple to do, it _is_ simple to do. This is incorrect. Agile methods require more diligence, rigor, and discipline than other approaches.
    b) it’s not about the actual practices as much as it is about keeping the right things in mind. Read the Agile Manifesto ( Tie everything back to that, and it’ll make sense and (likely) work.
    c) because it’s hard to do, there aren’t a lot of people who’ve actually been on a successfully implemented agile project. If you have, then you know it works. Trouble is, it’s hard to see _why_ it works, so subsequent attempts may fail.

    Think about it this way: if you’ve only ever heard AM radio, and someone tells you “there’s this thing I heard once, called FM and it’s awesome!” but then you can’t manage to find an FM radio, and even when you do you can’t find a clear station, you’re not going to have a particularly good perspective on FM. Is the sound quality of FM better? Absolutely. Is _FM_ better? No, because it’s inaccessible.

    _That’s_ what I believe the problem is here – Agile remains inaccessible.

  16. Hey, I’ll admit Scrum has issues as soon as I run into a developer who even admits the possibility that it might be their habits and expectations that are the problem. Never seen that yet in all the rants I’ve read. Funny.

    Seriously, Scrum is a process that involves humans. Of course it can fail. That’s not the question. The question is: does it fail less frequently, or earlier, or more visibly than other processes? It sounds as if you’ve already learned that the leaders of your current project value following the plan over adapting to change. That’s valuable information.

    I’m not sure why a developer would feel embarrassed about reporting that their estimate of the work has changed. Would you feel embarrassed if you discovered that a task originally estimated as a week was only going to take 1 day? Then why be when the opposite occurs? The improved estimate comes from increased knowledge about the problem AND THAT’S A GOOD THING. If your Scrum Master can’t deal with that, that’s his problem but, be sure, Scrum isn’t telling him to do that.

  17. I work for a very small software company here in Bellevue Wa. We are too small to be able to use a tool like that effectively. So currently I’m Scrumless Near Seattle.

  18. Doing scrum wrong is ok, and it’s taken into account in the actual scrum framework itself. The one major underlying foundation of scrum is that it’s ok to make mistakes as long as you learn from them and don’t repeat them.

  19. I hate scrums. They are the most excruciatingly boring 20 minutes of my day. My company doesn’t know how a scrum is supposed to be run. Everyone just sits around and tells everyone else what they are doing that day. It doesn’t affect my job at all and I could care less what everyone else is doing.

  20. @Bruce: 20 minutes is too long. Five minutes, tops.

    Also, if you truly don’t care what other people on the project are doing, then you should probably find another project to work on.

    My algorithm for truly boring, useless meetings is to ignore them. If they are really, really bad, I’ll just quietly walk out. Another possibility: Find someone else to go in your stead (that’s what Program Managers are for at Microsoft — they go to meetings for me. Seriously. If they need really technical backing I’ll go).

  21. While I haven’t done Scrum, in a previous job we used some XP concepts – especially test-driven design, XP-style planning and pair programming (although they stopped that soon after us interns finished our 6-month stint almost simultaneously and left a coder-vacuum).

    One of the best parts of XP to me was that our planning and scheduling was a process which adapted to us as much as we adapted to it. By roughly measuring and learning from the discrepancies between our estimations (ideal hours) and actual time spent on tasks (actual hours) we not only got better at estimating (i.e. guessing), even with quite exploratory code, but perhaps more importantly our weekly Big Visible Charts were a realistic description of how much we were managing to get done.
    We didn’t allow them to be turned against us (to demand or bully us into promising more output or work) – instead, we used last week’s chart and ideal hours count (which did get closer to our 40-hour week as time went by) to plan the next week, cutting back on tasks as need be so we’re only taking on the same expected workload as we accomplished last week. Also, some of our other graphs were able to make it apparent when our schedule slipped due to late requirements changes from client/boss.

    So, really it’s about planning through honesty and openness. If we got shag all work done this week, then it’d be unrealistic to expect double the output next week. Sure, if we’re really falling behind it might be brought up at the daily stand-up meetings, but that was never an issue. Pair programming helped keep a decent level of output too – if one guy is tired or needs to space out, his partner takes the keys for a while and vice versa.
    Also, at those meetings I had no trouble saying things like “we didn’t get much done yesterday because I got confused by some mystery slowdowns so we played around with the code to see how Hibernate deals with sets that have been serialised and reconstructed. That took a couple of hours because, it emerged, Hibernate can be a bitch”.

    But we were a very small team (maybe 8 coders) and openly experimenting with XP, rather than taking anything as gospel. Maybe it can get silly in bigger groups.

  22. This is kinda familiar to me, too. The Scrums weren’t daily affairs though, but occurred once or twice a week (except on some pretty hard crunches, when they were indeed daily annoyance).

    Just “fooling around” (ie. doing stuff that doesn’t _seem_ to have much to relate with the work at hand) until my subconsciousness works the problems out is also my modus operandi. Alas, it can be quite incompatible with the management types. In this particular job (the one with the Scrums) the managers actually wanted to sack me after about six months, until they mentioned this to my team leader, who informed them, that I was in fact their “best” developer (not necessarily the most productive, but the one with the most compact code (important in coding mobile software in early 2000s) with the least bugs). The managers were apparently quite astonished by this 😛

    Left the place after a year. The managers were so obsessed with nitpicking and unnecessary details, that for coders it wasn’t a particularly nice job (in fact, about half of the coding team left within half a year). The company folded a couple years later.

  23. DadHacker’s thoughts on scrum are right on target. I’ve been on a couple of scrum teams at my current job. Some of them worked pretty well. But I wouldn’t say that they worked well because of Scrum, they worked because we had some really, really good developers (and no, I’m not putting myself in that class). The reason Scrum worked on the teams I was on was that each had an “alpha wolf” developer who was pretty happy to set the agenda for 2 weeks.

    Theoretically, Scrum is supposed to be this lightweight management process that frees up developers to get work done. Well, reporting status every day, estimating the next two weeks in 2-4 hour increments, and planning out what the next couple of months will cover for backlog items is FAR more managment heavy than anything I’ve ever done before.

    I’ve heard that if you are doing standup as a status meeting, you are doing it wrong. But telling people what you have done, what you are doing, and whether you are held up is exactly what I would do in status meeting. Or to put it another way, what would be different about a status meeting? If the answer is that status meetings involve management, then I’d say you don’t understand status meetings.

    The thing that really bugs me about the daily standup is that it’s redundant, because I DO talk to people as necessary. If I make a change that I think will impact the team, I mail everyone. Muttering about it at standup is rarely productive.

    And, for all the people who say “if Scrum doesn’t work, you aren’t doing it right”, that’s got to be the most circular argument in existence.

  24. Scrum is Anarcho-Syndicalism in action.

    Might work if you have a factory in place, and factory staff that have more cognitive ability than an assembly line automaton, but isn’t too good at entrepreneurial factory creation.

  25. I am a Project Management Consultant, and SCRUM is becomming a nightmare i agree with you it is the biggest pain in existence. Wrapped in esoteric nonsense, pigs chickens and strict rules that don’t work in all environments, teams that adopt it stick to the letter of the law even in stupid circumstances.

    It will come a cropper, I am just waiting for when

  26. I thinking of adding a twist to the daily stand-ups. One day I’ll have it in the mens toilets around the urinal the next day I’ll have it at a bus stop, etc, etc.

    It is a pain, the whole thing.

  27. I hate scrum.
    I find it increasingly hard to fake enthusiasm for stickers on coloured cards. The chicken pig story makes me weep inside. I had THREE stand ups this morning + one meeting to define what “done” means (we agreed that a good session to define what a “task” is was the natural next step) . There are 2 PM breathing down our necks for us to shuffle our coloured cards in the right order on the wall.
    So maybe it’s not scrum, maybe it is any methodology that sucks when implemented by morons, but seriously ?
    I used to love my job, but I’ve been scrummed.

    PS: I’ll reuse as soon as I can the “soviet union wasn’t really communism” one.

  28. I’m totally new to Agile/Scrum, so reading and preparing to help my team transition due to a mandate from on high to do so. A few observations:

    – The idea of mandating a Daily Scrum seems to fly in the face of Agile (or perhaps Lean) philosophy. Agile is quick to say, for example, “document as little as possible” and only document what’s absolutely necessary (which I partially agree with), but then turns around and mandates a daily Scrum meeting regardless of whether or not the team feels it is necessary? That seems absurd.

    – The stereotype of the overly defensive “Agilista” is well-earned. There’s a persistent snarky tone to nearly every defense I see on blogs, etc.

    – I’m tired of comparisons between “Agile” and “Waterfall”. Like there’s no in-between? Besides: why is the argument that “you are not doing it right” always applied in defense of Agile but never in more sequentially structured methodologies?

    – Agile should never be defended merely because “the industry is moving this way”, etc. Trends don’t mean much. How about the trend in OTC Derivatives that has now brought various countries to the brink of sovereign debt default? BIS valued the pool at over a Quadrillion dollars at one point. That’s a pretty big trend, wouldn’t you say?

    – The Chicken and Pig language is disturbing. What does it say about the underlying psychology of a movement when it thinks referring to fellow human beings as farm animals is cute? I think it’s sick.

    – I agree with the contention that – at least in some circumstances – the idea of placing a Product Manager in the role of “Product Owner” is a recipe for disaster. That opens up a can of worms.

    – I don’t like the word “Scrum”. There’s just something about saying it… like it gels with the whole Chicken/Pig thing. Like the “Daily Scrum” is where you must kiss the Ring Of Scrum and confess out loud to everyone, “Here am I – merely a pig in a team of replaceable pigs. I happily Scrum away. Thus I was born, and thus I shall stay. The world has become Scrum, and Scrum is become the world. Now send me to my duty and label me again as thou wilt, for I am but thy bacon factory.” I don’t know. Feels weird, dude.

    Seems to me there are huge philosophical questions around the whole approach, but I need to study more about it all to try to articulate.

    All this said, I am endeavoring to learn about this approach and will give it my best effort.

  29. I love agile, but hate scrum. Agile is a little like object oriented design: once you get your head wrapped around it, it makes all the sense in the world. But I’d say it has a harder to acquire revelation than OO. Agile works because it tries mimic reality as closely as possible. That is, it recognizes that a bunch of documentation is no substitute for communication; it recognizes that over-design is just as bad or worse than under-design, and it tries to incorporate the customers’ needs into those judgment calls.

    Scrum on the other hand, like traditional methods, dilutes reality. For example, the. rigidity of not changing the goal of an iteration during the iteration, the ‘story points’ and of course we can’t leave out the pigs and the chickens. It’s frankly, a little ‘Mickey Mouse’. Further, it clings to things like user stories, back logs, and acceptance – hence elevating documentation above communication and what the product needs- again ignoring the reality that a user story is only as good as it’s writer’s thoughts at the time and story acceptance is is an abstraction the customer couldn’t care less about that does nothing to sell the product.

  30. I really appreciate the programmer’s dilemma described in your post. You can never replace solid engineering chops with rigorous process. You just end up with process-driven robots that will eventually grind out all motivation from your project. I posted my own thoughts earlier today and I’d love to hear about Scrum projects that translate to really wonderful products that people love to use made by teams that love what they do. I personally haven’t sen that in any Scrum project.

Leave a Reply

Your email address will not be published. Required fields are marked *