26 ms·

Why I'm done with Scrum

194 points by hkarthik 14y ago

leothekim 14y ago
The author is right that, with scrum you end up focusing more on process and not delivery. There are nice things about scrum, but I think scrum followers are too doctrinaire. It has some well-defined practices and is associated with that agile "manifesto" that you are compelled to buy into if you adopt scrum. Being doctrinaire about anything is guaranteed to distance you from reality - you give project managers a weapon to coerce you into worrying about how to break down your work into a velocity and stories and tasks. Any time you enforce a process like that, you are disengaging yourself from the reality of having to ship something.
- vannevar 14y ago
  Scrum is focused almost exclusively on delivery. Every sprint, you should be delivering working features. It's not that hard: every sprint, you commit to a set of stories to finish before the next sprint. Every day you meet briefly to tell everyone how you're progressing and to air out any impediments. That's about it. To me, scrum is stripping process down to the bare minimum you need to be effective.
  - barrkel 14y ago
    And it's fantastic when you're on a tight schedule! Instead of running fast all the time, you just sprint, then sprint, then sprint, etc! Works like magic. No one burns out at all.
    - MartinCron 14y ago
      I don't know if you meant that in a sarcastic way, but this does touch on a pet peeve of mine with Scrum, the word "sprint" is, by definition, not a sustainable pace.
      - anthonyb 14y ago
        So call it something else, like "an iteration".
      - Evbn 14y ago
        You rest, reflect, and recompose between sprints.
    - vannevar 14y ago
      Not quite. You sprint, then you take time to review and reflect on what you've done. Then you take time to plan what you're going to do next. Then you sprint again.
      - barrkel 14y ago
        IME the "review, reflect and plan" is a one-hour meeting on a Friday, every two or three weeks.
        Evbn 14y ago
        Change it to two days. When do you squeeze in your retrospective? Your presentation of the deliverable to stakholders? Negotiating next sprint commitments? Researching before you do estimation?
    - baconner 14y ago
      Well... yeah! if you get some other core parts of scrum right then nobody should be burning out. Time boxing and point estimation are about figuring out what your team's sustainable pace is and using that to avoid burnout. Scrum isn't about developing faster its about working toward more sustainable and predictable development. If your management doesn't understand that and respect it no methodology will fix your problem. I admit as someone else mentioned that sprint was a poor choice of words. So say iteration instead. Problem solved.
  - dasil003 14y ago
    I've never done formal scrum, but I've worked on a lot of teams, and I just don't see how there is a single bare minimum you need to be effective. In my experience, even with excellent teams, this depends on the project and the talents of the contributors.
    - vannevar 14y ago
      To me, the bare minimum for success in software development is clear direction, continuous communication, and continuous verification of the product. Scrum is a simple process to ensure that all three actually occur and aren't merely good intentions left up to individual discretion. I guess you could come up with alternatives, but it would be tough to make it much simpler and still cover all three.
      - leothekim 14y ago
        I've done formal scrum before, and I can see where you're coming from, but my experience scrum didn't ensure continuous communication. The company where I worked actually actively prevented cross-team communication. They did this because the scrum masters and director of engineering claimed it would generate work that couldn't be captured by stories, so velocity couldn't be accurately tracked and people's time could be spent on the "wrong" things. I took as project managers not trusting the engineers to do their jobs. Again, I don't think scrum is all bad, nor do I think it's hard to grok or follow. It's how people adhere to it, and in my experience, people really adhere to it in a way that's detrimental to productivity. For me, it's kind of like religion - I like some of the ideas, but I don't like the fan club.
        vannevar 14y ago
        Not sure I understand the communication policy you guys were dealing with. If a team is meeting briefly every day and sharing their progress, it ensures that there's at least that much communication. But the daily standup should be a floor on communicating, not a ceiling.
  - MartinCron 14y ago
    You can, however, strip it down even further and still be effective. Scrum encourages bundling stories into sets and delivering them all at once. I've been moving away from that, and continuously delivering discrete stories/features/changes/fixes/whatever as they are ready. Decoupling incrementalism from iterations has been a huge change for me.
    - aaronblohowiak 14y ago
      What does QA look like with continuous delivery?
      - MartinCron 14y ago
        Different continuous delivery teams do it differently. I don't like having a dedicated QA team/department. QA is an effort, not a role. The key part of continuous delivery is that the safest change to make to a stable system is the smallest change possible. So instead of batching up lots and lots of stuff and throwing it over the wall to QA, you make one change, have humans and robots test it, and deploy that change. The mindset shifts from "features per release" to "releases per feature" so with truly friction-less automated deployments, you can release very small changes individually. You don't have to test everything in order to change anything. As you may expect, multiple layers of test automation are necessary. Each change runs a gauntlet of different kinds of tests before release. A set of "safe to run in production" tests immediately after release. Rollbacks are trivial, but exceedingly rare. Obviously, this only works in some contexts. If you're pressing things onto gold master DVDs and shipping them in boxes, the QA effort will be more traditional.
      - bwindels 14y ago
        Your automatic (unit, functional, system) tests assure stuff doesn't break (too much), and manual QA happens after deploying. If something is broken, you can fix it very fast, since you are deploying continuously. Stuff might sometimes be broken on production, but you could argue this makes people think twice before pushing to master. Also, you can deploy to production with a delay (e.g. 1h) and deploy to a QA server first to give the QA people some time to check before stuff goes to production.
  - programminggeek 14y ago
    Haha, that is only true for a certain type of person. For other people Scrum becomes about "the rules" and if you break one of the rules, you're doing it wrong, even if that might be the best decision at the time. Agile is a philosophy, Scrum is meant to be more of a framework to implement that philosophy, but many people treat it as a set of rules on how to do things, which tends to violate the philosophy of Agile process in the first place.
    - Evbn 14y ago
      In that regard, how is scrum different from anything ever? Anyone can be process obsessed in any system. And, dare I say it, giving a process to Asperger, socially tone-deaf, shoe-staring programmers may help them contribute more effectively to a larger organization.
vannevar 14y ago
FTA: Scrum forces iterations, forces feedback, forces smaller iterations. These are all good things, which I loved about Scrum. And yet the author spends most of the article denying that these aspects of scrum are useful at all. Planning sessions are "highly inefficient," a "quick meeting between the architect and the developer" is better. What if someone else has an important piece of information that the dev and the architect don't? Maybe another dev on the team has done something similar in the past, and could have warned that the estimate was low? He won't be in that meeting, to avoid being "bored to tears" with a story he isn't working on. So how do you know if Scrum isn’t right for you? If it’s hard. If it’s easy, then it will work for you. Obviously, if something is hard, there can't be any possible benefit to it. It's so much easier to get rid of all that process stuff and just churn out code as fast as you can. What could possibly go wrong?
- pherk 14y ago
  > What if someone else has an important piece of information that the dev and the architect don't? That isn't good enough justification. You are too much erring on the side of caution.
  - vannevar 14y ago
    But it's not costing me much. My devs still need to be in on planning their own work, and if they're all on the same scrum there should be a lot of overlap. Listening in on the planning for work entirely unrelated to their own should be pretty rare.
- gutnor 14y ago
  The author has a point. Scrum is costly. Obviously it is more productive to silo specific knowledge to specific people, generally the expert (or more motivated) in that field. At least it is in the beginning. People leave, experts become expert teams, silos widen and it soon become the good old planning nightmare we have all learned to "love" in enterprise development.
  - adrianhoward 14y ago
fingerprinter 14y ago
When I took over development of a extremely dysfunctional engeering team at an established startup with 100 people, the first thing I did (after watching for a bit to learn) was put in scrum. It worked. And it worked really, really well. 2 years later, it didn't work anymore. The team had matured, the organization itself had adapted to the leaner processes and mindset and, in time, the actual scrum process was too much. It was time to change again... And that is something I think most agile advocates don't realize. Agile should be viewed as an organizational tool that has prescripted and prescribed rules that work in general, but maybe don't work in the specific. It is great if you need something forceful with books or documentation in the beginning, but in time, the organization should mature to the point where agile/scrum/whatever is actually too much. One last thought. I highly recommend people look at agile for the times when you need a drop in process....but there is absolutely no subsitute for hiring quality people capable of making good decisions. Agile will get more out of bad developers, IMO, but having nothing and good developers you trust is always going to be more productive.
- m_st 14y ago
  I fully agree with your post. But do mind sharing what process you changed to then? Did it and does it still work?
- sandGorgon 14y ago
  That was an excellent observation. I like to explain the phenomenon you observed using queuing theory - As time went on, each of you (and you yourself) were able to estimate tasks very, very accurately. I'd like to think that this was a period of low attrition.. but even if it was not, you were able to model the behavior of a 100 employees (a large enough set) to come up with good estimates. An agile/scrum process is designed to work with tasks of inaccurate estimates - the whole business of story points is designed around that fact. Since your underlying phenomenon changed, the process was no longer optimal. I'm not sure if you experimented with your own "lean" inventions beyond agile - single queues, multiple queues, queues with an artificial stop signal to reduce variance, etc. - but it would have been interesting.
- debacle 14y ago
  I think your last point is key. You can't use process to turn a bad programmer into a mediocre one - any process that does will also turn a great programmer into just a mediocre one.
snarfy 14y ago
The effectiveness of scrum really depends on the team size. The larger the team, the more bureaucracy is needed to manage it.
- genwin 14y ago
  True. My last project started each day with 2 hours of scrum.
  - SideburnsOfDoom 14y ago
    > started each day with 2 hours of scrum. What? Was your 15-minute stand-up 2 hours long? If so, are you sure you were doing it right? Were you scrum-master, and doing 2 hours of admin per day? What were you doing for the rest of the working day? I'm not really sure what you are describing here.
    - genwin 14y ago
      I wish it was a stand-up! If standing would've forced it to be only 15 minutes, that is.
    - stonemetal 14y ago
      OP mentions larger teams, so a 20-40 person team nets you around 22-45 seconds per person in a 15 min scrum. If we give each person 3 min that is a 1-2 hour scrum.
      - SideburnsOfDoom 14y ago
        > a 20-40 person team nets you around 22-45 seconds per person in a 15 min scrum Which is just one reason why you do not have 20-40 person teams in scrum. The team size top out at around 12, and yes, at that size you have to keep what you say at stand-up short and to the point. If you find a 20-40 person team, for scrum you will have to break it up into sub-teams. Was he doing some variation of scrum? Some kind of scrumbut? I won't claim that scrumbut always fails, but it's not hard to spot where this went wrong.
cocojumbo123 14y ago
Actually what the author describes is a natural path of evolution for that team. Scrum (as a process) contains the possibility of changing the scrum rules themselves - although it is strongly recommended one does that only after they get experienced (e.g. they actually manage to get shippable product each iteration). When the focus is on the process itself and not on delivery there is something rotten in Amsterdam. Scrum can be a micro-manager's dream (think of the visibility on who is doing what at almost hourly level) - case in which one can end up with focus on the process not on result.
michaelt 14y ago
Iteration planning meetings are seriously expensive. Group discussion around design, group estimation, group acceptance, all highly inefficient. [...] I remember just getting bored to tears listening to discussions around stories I wasn’t developing on to begin with. That's quite team size dependent. In a scrum team with 4 people this isn't a problem - but when the team's twice as large it doubles both the amount of work to plan and the hourly cost to assemble the entire team, quadrupling planning costs. If a team is structured in such a way that a developer knows they won't be working on a story, that seems like a logical line for splitting into two scrum teams.
debacle 14y ago
> With Scrum, there is an explicit commitment ... on what stories are going to be delivered within the sprint, No, there isn't. You adhere to your burn-down, not to your feature set. Scrum is time driven, not task driven. The whole idea is to become better at estimation so that Scrum appears task driven, when really it's just because your team is that good at estimating. > Iteration planning meetings are seriously expensive. Then you're doing it wrong (god, I feel awful for saying that). If you're spending that much time in pre-sprint planning, people aren't bringing enough to the table and you're not defining your problems well enough before trying to solve them. > I hate the term “scrum-but”. Ironic that that sounds like exactly what the environment you were working in sounds like. > This might be a bit controversial, but the big difference between Scrum and things like Lean Software Development for me were the difference of focusing on process versus delivery. I think this is a "forest for the trees" issue. Scrum is about abstracting the process into a rigid and lightweight framework so you only have to think about it, at most, fifteen minutes a day (unless you have the misfortune of being the Scrum master/cat wrangler) > It can’t, and it’s not a problem with your organization if it doesn’t. It’s a problem with Scrum. That's a non-sequitur. It's a problem with neither. If my company can't implement a waterfall methodology because our clients require faster iteration, that doesn't mean there's a problem with either - it's just not a good fit. But if your company tries to implement Scrum and throws it out six weeks or six months later because it's "too hard" or "bad," my assumption is that real Scrum probably wasn't happening. Will Scrum work for everyone? Fuck no. Scrum is hard. It requires the kind of buy in that, if you've got it, you probably don't need Scrum anyway. Can Scrum work for everyone? Probably. Scrum is only hard when you've got conflicting goals. If you have a smart enough team, you can tweak your sprint lengths from as little as a few days to as long as six to eight weeks, and after you've been on Scrum for a few sprints your planning meetings should take an hour or two, tops.
- sethg 14y ago
  In my experience (six months at a job that does Scrum and, I think, does it very well), the thing that slows down iteration planning meetings is when the product manager hands down a one-sentence feature description, the engineers say “we can’t size that, it’s too vague”, and then you need a five-to-fifteen-minute discussion in order to expand that one sentence into something resembling a spec.
g123g 14y ago
The #1 point mentioned in the article was my experience as well. For a tight deadline project if we decided to do everything based on the complexity points and team velocity it would take 6 sprints and a total of 3 months. But we just decided to ditch it and sit around a table and finished the whole thing in 2 weeks straight. So my experience is that if you are working with a dedicated team it is better to finish the work based on the best of your ability rather than time boxing into some artificial time limits.
- kevingadd 14y ago
  How would Scrum turn a 2 week project into 3 months? Are you just saying you were terrible at estimation, or what? I don't understand what you ditched, specifically, and how that produced an improvement.
  - SoftwareMaven 14y ago
    In timeboxed iterations, you have to be very careful that work doesn't expand to fill all available time. If you are a little conservative with your estimates, its easy to double the time the necessary aspects of development would take. Little, unnecessary tweaks becomes more important than putting four hours into the stretch goal that is going to spill into the next sprint. Six times is a bit much, though. That sounds like they haven't worked out their estimations yet.
- knighthacker 14y ago
  Having a dedicated team is definitely important. I had a similar experience to yours and I am not entirely sure why. I think a big part of it is that once you dig into complexity points and time estimates and all that other stuff, people tend to be on the safe side and add a lot of buffer. But when the whole team is in the hacking mentality and just wants to get sh*t done, you don't need to have everything in sprints. You just need a highly motivated and a dedicated team.
- skMed 14y ago
  Are you trying to say the overhead of SCRUM would increase the time to 3 months? SCRUM is a lightweight framework, so I am struggling to see how this could happen. Alternatively, do you think the estimation with points was the main problem and you couldn't get a correct feel for doing it without resulting in a conservative estimate?
michaelt 14y ago
Iteration planning meetings are seriously expensive. Group discussion around design, group estimation, group acceptance, all highly inefficient. [...] I remember just getting bored to tears listening to discussions around stories I wasn’t developing on to begin with. That's quite team size dependent. In a scrum team with 4 people this isn't a problem - but when the team's twice as large it doubles both the amount of work to plan and the hourly cost to assemble the entire team, quadrupling planning costs. If a team is structured in such a way that a developer knows they won't be working on a story, that seems like a logical line for splitting into two scrum teams.
MartinCron 14y ago
The fundamental thing I've realized while looking for "the optimal end-state process" is that it doesn't actually exist. Scrum is, for many development organizations, an incremental improvement over what they are doing now. The biggest problem that I have with Scrum (and all prescriptive methodologies) is that it's presented as a vision for the right end-state instead of a set of tools that you can use to help find the right process for your immediate context.
- mongol 14y ago
  I so agree with this. If there was such a ting as "100% scrum compliant" it would be a bad goal to strive for. Not because it is bad in itself, but because the process should be adjusted to the situation.
the1 14y ago
just code. code well.
- sethg 14y ago
  You can code, code well, and then discover that the feature you just implemented was something that the upper management actually didn’t consider to be very important, or that they wanted something completely different from what you thought they wanted. That’s the sort of failure mode that Scrum and other development methodologies are trying to protect you against.
  - pnathan 14y ago
    This is an incredibly big deal. If the customer didn't order it, it doesn't matter how well you coded.
  - the1 14y ago
    I tend to think bringing in agile specialists and installing scrum process to save the project is a bit dogmatic. If you worked on a project for sometime and wrote/rewrote a lot, you probably know what's needed to be written. It's fairly unlikely the scrum process actually helps at that point. What keeps you going at it is probably "faith" you built through out the year since the onset of scrum installment... and, just a habit. If you are afraid of writing unneeded, unimportant, and unpopular things enough to label them as a "failure", your focus may be to find needed and important things for your audiences. Your focus may be to read the draft to a select sample audiences everyday, every week, continuously, and apply various analytical techniques to different statistical models you built from the feedbacks to overcome your fear of rejection, and "manage" direction, completion, and shipment of your writing. Or just write. A lot. And read. A lot. You'll "get" trends. You'll "get" what works and what doesn't. Of course you need feedbacks. Of course you need plans and management especially if you are co-writing with many authors. But my focus is still to write.
- brazzy 14y ago
  That's kinda like saying that all you have to do to win the Superbowl is "just play. play well."
mmanfrin 14y ago
Minor counterpoint to the bit about meetings being boring: As a QA person, it is incredibly valuable to us to all be together so we can discuss things with the devs that are otherwise getting overlooked in bugtracking software or even in our chat. It makes it so that those orphaned problems can find a home. But our meetings are short. 5 or 10 minutes max. If you're getting bored than, to quote another commenter here, you're doing it wrong. Quick summaries, major problems, then get out the door.
base698 14y ago
You haven't really jumped the shark with scrum until you have in place a scrum of scrums, and a scrum of scrum of scrums taking up half the day for all the key players.
at-fates-hands 14y ago
> Iteration planning meetings are seriously expensive. I completely agree on this one. I've worked in several corporate environments utilizing Srum and the planning meetings were always a huge waste of time. I would rather light my hair on fire than sit around a bunch of PM's trying to figure out what features to include/exclude. Also, most of the people (PM's,Dev's,IA's) I talk to always say, "Nobody does Scrum/Agile right anyways." Which made me wonder if there is indeed a right and wrong way to do these.
- skMed 14y ago
  Perhaps it is the environment or Product Owners that are causing this slow down? Product Owners (PMs, etc.) should stack rank items in their backlog before a sprint planning meeting. This should make it fairly easy to allocate items for a sprint and identify features which either need to be 1. clarified, 2. split/scoped down. My sprint planning sessions have typically always gone smoothly as long as everyone came prepared and ready to contribute.
- jt2190 14y ago
  In my experience most teams do planning completely wrong. The goals of the planning meeting are simply: 1. Do a relative-size estimate the top n stories in the backlog. (Where n is some number slightly larger than the number of stories that usually fit in an iteration.) 2. Pick the stories to complete in the iteration. That's it. I often see teams: * doing one-by-one story estimation, and debating over how many points to assign. (The statistical method completely fails when it's done this way.) * getting into long discussions over the spec. (That's between the dev and product owner, to be figured out during the iteration.) * worrying too much about accurate estimates * worrying too much about how much work to take on
  - smhinsey 14y ago
    I think the reason this happens is because no matter what people say, the idea that if you can't finish a story within a sprint it will simply slide into the next one is anathema. People spend more time on estimation when the consequences of mistakes are higher. If you can't realize that a story is larger than you thought and reprioritize mid-sprint without it being equivalent to missing a deadline in your old model, it's not going to work. In my experience this is the key failure mode of scrum.
dpham 14y ago
I work at Webs and we also recently abandoned scrum for a more kanban approach. While all points in the article resonated with our company, the biggest problem we had was not delivering projects on time. We focused too much on fitting as much work into a sprint as possible for maximized throughput. The problem with that, especially when you have alot of projects going on at the same time, is that alot of work was being burned across the board, but the needle for each individual projects didn't move forward fast enough and we ended up missing deadlines. Another problem with scrum is that it turns creative developers into code monkeys, and this in turn lowers code quality. Developers are constantly worried about trying to meet deadlines for the next two weeks rather than taking the time to do things correctly. This ultimately creates technical debts and hurts the team in the end. (also, if you're a manager and you use the developer points burned in order to rate performance and distribute bonus, then fuck you)
- pherk 14y ago
  I very much agree with the last point. Objective evaluation of a developer is much more than burned down points. I worked at Amazon and could see evidently that Scrum was turning good developers into mediocre ones. But not many raised a finger against it as Scrum was seen as the norm. And there was no scientific way to establish this fact.
njharman 14y ago
Excellent observations based on actual experience. A refreshing change from the usual "I don't understand what agile is but I did something I called agile and it sucked so I'm now blogging about how agile is broken".
gleiva 14y ago
We started doing Scrum around a year ago and it has worked well for us. I feel some of the points described in the article about Scrum are not because of the framework itself but because there could have been a lack of a Scrum Master, which is an important piece in the puzzle, to ensure Scrum effectiveness.
tosh 14y ago
The problem with SCRUM is that it is not agile. That's why we see most of the pragmatic companies adopting a kanban or scrumban approach and they see good results. I would argue that just having a kanban board during stand-up meetings and "walking the board" instead of interrogation-like status reporting is going to do wonders to team collaboration atmosphere, morale and actual productivity. You start to see and talk about the flow of value, what's next, what's in the moment ("what can we do right now?). You see context. All of that is missing with SCRUM or only possible with a highly motivated and responsible team that communicates a lot automatically. I'm not yet saying that kanban is solving the software crisis [1] but it turned around quite a few teams that I've seen and been part of. DISCLAIMER: I'm working on https://www.blossom.io https://www.blossom.io which is a lightweight kanban board. 1: http://en.wikipedia.org/wiki/Software_crisis http://en.wikipedia.org/wiki/Software_crisis
- manmal 14y ago
  Can you elaborate on why Scrum is not agile? You are the first I read claiming this.
  - tosh 14y ago
    Great question. I might have a harsh tone in my previous comment but I've got really frustrated with scrum (or implementations of it) over the last few years. Scrum in my eyes is a process and from what I've seen it makes teams very process oriented. The whole idea of scrum master certification and the success it had in enterprise adoption might have something to do with that. It incentivises teams (at least all the teams I've seen) to work for the process as good as possible. They focus on complying to the process, getting estimates right (or working in a way that makes the estimates right), they focus on the backlog instead of throughput or frequent re-prioritization … If you can free yourself from viewing the 'process' as fundamental religion it's easier to apply agile & lean principles like focusing on delivering value and improving the framework, changing things, changing the process so it fits your needs, etc. In a nutshell: I see scrum incentivising people to work in a way that is not agile but pseudo-agile/feel-good-agile. I see no feedback loop for the process itself (at least I see no one doing that, except teams that adopt kanban and scrumban or do scrum but …). But I'm interested in learning from people who've made other experiences. It's an exciting topic.
martincmartin 14y ago
I've done a bunch of reading about Scrum. If you read between the lines, you realize that Scrum was created and popularized by consultants who go into dysfunctional teams/organizations, and tries to fix the worse problems. For example, the idea of a sprint is for a team to be able to work for at least a couple weeks on a single thing, without people being asked to work on other "small" projects, or without the entire direction of development changing every week. Once the team is functioning well, you can usefully relax a lot of the aspects of Scrum.
- sjtgraham 14y ago
  This is a really interesting insight. I have seen so many instances of prescriptive Scrum with no explanation as to why that it's appropriate, i.e. Cargo Culting.
  - luriel 14y ago
    Most of the software industry is built on cargo cult.
- mizhi 14y ago
  After a bit of experience with scrum, one of the things I"ve come to appreciate is that it's not a one-size-fits-all methodology. I think the spirit of scrum (break work into chunks, have working code at each stake in the ground, define a project in terms of user stories, etc) is more important than the letter of the law, and being able to tailor the process to your current reality is more valuable than dogmatic adherence to some prescription.
  - rockyj 14y ago
    Excellent point!
- deleted 14y ago
  [deleted]
- ams6110 14y ago
  I think you're being a bit generous. The consultants who sell "Agile" to dysfunctional organizations are the same ones who sold every fad methodology that preceded it to those same dysfunctional organizations.
deleted 14y ago
[deleted]
vpeters25 14y ago
Every time I come across "why scrum sucks" articles like these I can quickly point the problem: the ScrumMaster. #1 - Iterations are less efficient than pull-based approaches: A good ScrumMaster keeps an eye on the burndown chart and negotiates with the stakeholders and team to either add or remove tasks from a sprint. My first sprint ever as ScrumMaster, we estimated a 3 months project, we did everything in 2 sprints (1 month) #2 – Iteration planning meetings were wasteful: You are doing them wrong. A good scrum master keeps everybody focus on one user story at a time and keeps the meeting moving. I use a 3 min stopwatch in my phone. The whole meeting should not take more than 1 hr (I do 30-45 mins estimate new stories, the rest to plan and commit team to next sprint) #3 – Scrum is highly disruptive in established organizations: A good scrum master servers as a bridge between traditional management and keeps them out of the team's backs. This one is the reason I don't like being ScrumMaster anymore. A good ScrumMaster needs great people skills, I rather write code.
- erichocean 14y ago
  So scrum has a single-point-of-failure that organizations, more often than not, see high failure rates with? And we're still recommending companies adopt this, when the failure rates are both known to be high, and catastrophic when they occur?
  - vannevar 14y ago
    Companies still do project management, and the project manager is a single point of failure. The reason the failure rate is high is that scrum is relatively new and companies still think they can get away without having a scrum master, while they know from long experience that they need good project managers.
gstober 14y ago
I read through the first bunch of these comments and scanned the rest...you guys, you guys... I might have missed it but I didn't see anything about client delivery that is viable...or do you have other reasons for being in the software game? Who really cares what process you use? As a client I want to be involved, I want to see how you're doing on an on-going basis, I want stuff that works well, I want stuff I can use and I want to alter by vision as you deliver because my business can change...
ajsharp 14y ago
In my experience, Scrum / Agile / XP tend to be more about the process than the results. I find these methodologies to be particularly useful for contractors and consultants, primarily because the value proposition for a consultant is much different than it is for an employee. A consultant comes in and typically some sort of statement of work or master services agreement is agreed to by both parties, which outlines roughly the work that will be performed over the course of the engagement. Once work begins, some Agile hoops will be jumped through (storyboarding, etc) in order to further establish and agree upon the work that will be performed. This way, at the end of the engagement, when the consultant has been paid for 3/6/9 months of work, they can point back to what was agreed upon each step of the way and say, "See, we're delivering what was agreed upon way back when." Employees at most software companies, and certainly at early-staging companies, don't work like this, nor should they. As a product engineer, your job is, in a nutshell, to figure out through software how to make the business work. There might be a high-level strategy laid out for you, there might not be. Either way, you're engaged in an inherently creative activity in order to devise and implement a solution to make users happy, and hopefully make money. Whether or not the employee delivered upon what was agreed to three months ago, or whatever the timeframe, is irrelevant (at least it should be). The question should be, "Is your work having a positive impact on the business?". There is an inherent necessity to quantify "positive impact" when working with consultants, partly because they cost a lot more in the short-term, and partly because the nature of their work is generally less creative and more controlled. So, if you trust the people you work with, and the company communicates it's vision well, IMO Scrum and Agile are too much procedural overhead. Of course, you have to meet those two conditions :)
leothekim 14y ago
Also, obligatory: http://programming-motherfucker.com/ http://programming-motherfucker.com/
cpenner461 14y ago
Several comments about the notion that at some point you outgrow Scrum. For those who have reached this point, I'm curious what you've switched to? Or has it been more of simply relaxing some of the constraints/procedures? Asking because I've recently started to wonder if/when we'll need to modify our mostly-Scrum process.
- adrianhoward 14y ago
  The most common (productive) change I've seen is a move to something that's closer to the pull/kanban/lean approaches. For example a pattern I've seen a few times goes something like this: * Teams get good at breaking down and estimating backlog items, they tend to all become the same "size" and need about the same amount of "work" * Product Owners get good at prioritising the work so that the most valuable stories are at the top of the queue * Dev team and product owner turn have a collaborative relationship rather than a boss-minions relationship. * The combination of those three factors means that the planning meeting basically turns into "we do the next N stories" where N is the number of stories you get done every sprint. So the utility of this meeting disappears. * The process of work flowing through the team starts resembling single-piece flow. Everybody works on the next most important thing. * People start continually delivering, rather that just being able to deliver at the end of the sprint. * The last two points mean the utility of breaking work into sprints kind of vanishes. * Everybody notices that they're doing flow-ish things rather than batch sprint-ish things and starts looking to the lean / kanban world for ways to optimise the process further.
wballard 14y ago
Interesting points, but I feel that the root cause of these process debates is one un-natural act: estimation. Personal opinion is that far too much energy is put into processes to generate predictability, which is only practical when you have done it before, repeatedly. All this focus on estimation, points, timing -- it just doesn't create what is needed to both do a great job and go fast: clarity. This is why I don't run my shop with deadlines. I have no experience that deadlines/sprints/iterations make things faster, or create better ideas -- the things I'm actually interested in.
jpatil 14y ago
What people fail to realize is that Scrum is a specific process. There are actual guidelines on how it should be implemented and what the team make up should be. People think they can take Scrum and tweak it to meet their needs (even if it hurts the process) and have it still be effective. People believe that they can "scale" Scrum to teams of 100s of people, in different locations, across time zones and with people who speak different languages and expect it to work the same. It wont and was not designed to. Additionally, Scrum is not designed to handle unanticipated work. How many times will a team be working on a sprint when a fire happens, especially at a large company? The team needs to disrupt the sprint and handle whatever unplanned work it is, from a defect a major customer change request or whatever. The whole sprint gets thrown out of wack and what was defined as the ship requirements needs to be redefined on the fly. However, Scrum allows partially done work and if a new work item is injected at the end of sprint, the Q&A team may not be able to meet the new ship requirements of either the new work item or the rest of the sprint work. With that said, Kanban was designed to not be a prescriptive process. Kanban is all about making small incremental improvements in WHATEVER YOU ARE DOING NOW. By visualizing work you are able to see where you are becoming overloaded and where blockages are occurring. By adding WIP limits and through pull instead of push you are helping to even out the flow of work and ensure that work is getting completed to 100% at a relatively constant speed. There are other aspects of Kanban that help, specifically metrics, the CFD, and swim lanes, but really with these two aspects, you can constantly visualize what is going on and figure out how to improve your work process on demand and in your own way. While I am a big proponent of Kanban for countless reasons, many organizations cannot simply change overnight. Many organizations cannot grasp the concept of no time box and continuous deployment. Putting faith in the work ethic and self organizing capability of the developers doesn't jive with many companies (even though the studies show teams are much more productive when self-organizing). Other people, like the author, like the idea of iterations. In addition, many teams see great value in doing the retrospective. Lastly, the teams in the organization may have been trained in Scrum and been doing it for years. To all of a sudden change to something new can cause major disruptions in work and full on rejection and revolt. For these types of organizations, I tell people to try Scrumban or Kanban with Iterations, whatever you want to call it. Teams can use Scrumban as a stepping stone to becoming more Lean or then can just use it going forward to improve and scale Scrum. Using Scrumban, teams can move slowly to self-organization and from estimating to prediction. They can handle injected work more easily and move to continuous deployment. Moreover, they reduce multi-tasking/ task switching and ensure a even flow of work. For anyone wanting to learn about Scrumban, I send them to this video -> http://www.youtube.com/watch?v=0EIMxyFw9T8 http://www.youtube.com/watch?v=0EIMxyFw9T8 It's an awesome video that is just over 6 min long. I don't know who these guys who made it are and am not promoting them but the video does the job well.
demian 14y ago
We need to drop the idea that there is THE methodology to organize software development. I like the approach of this post, but I would had prefered a little more context on the type of projects he manages. A professional software manager should be able to identify the key aspects of a project, and with that define the methodology (borrowing from different aproaches and using different tools). Some projects require centralized design with a top-down approach, and more of a "programming workforce" self-coordinated with some progress metric. Other projects require more sophisticated engineering design, technical expertise imbued in a creative enviroment by a relatively small team of engineers/developers. In my opinion, iteration is all about exploration. Scrum basically discards the role of a "designer" for the systems. But sometimes you need a designer.
JoelMarsh 14y ago
There seems to be some very scrum-savvy people here. I have used it many times, but I am interested in your thoughts about how designers typically work within that framework. In my experience design and scrum don't play very nicely together. Thoughts?
- adrianhoward 14y ago
  There are a bunch of folk (me included) who spend a lot of time thinking about getting UX and Agile folk to play nice together. You can find some of my rantings via lanyrd http://lanyrd.com/profile/adrianh/ http://lanyrd.com/profile/adrianh/. You'll likely find Jeff Patton's work of interest - this might be a good starting point http://agileproductdesign.com/blog/emerging_best_agile_ux_practice.html http://agileproductdesign.com/blog/emerging_best_agile_ux_pr.... There's a stack of stuff under https://pinboard.in/u:adrianh/t:agile/t:ux https://pinboard.in/u:adrianh/t:agile/t:ux that you may find interesting. Some of it may need filtering through my brain before you see the agile/ux connection though :-) The UX track at Agile 2012 had a bunch of great sessions around getting UX and agile running well together (bias warning - I produced the track :-) http://agile2012.sched.org/overview/type/user+experience http://agile2012.sched.org/overview/type/user+experience - I think all the sessions have slides now. Nag me if not. There are also the sessions from Agile UX NYC earlier this year http://agileuxnyc.com/presentations/ http://agileuxnyc.com/presentations/ Personally I'm finding UX works better outside of an iteration context with a more lean/kanban approach. The stuff Janice Fraser is doing at LUXr for example http://www.slideshare.net/clevergirl/ http://www.slideshare.net/clevergirl/. Google around the "Lean UX" topic. Ignore the folk who talk about it as if it's just about less deliverables. It's more than that. Finally the agile usability mailing list http://tech.groups.yahoo.com/group/agile-usability/ http://tech.groups.yahoo.com/group/agile-usability/ is a useful place to chat about this sort of stuff.
  - JoelMarsh 14y ago
    Amazing. I'm glad I asked. Thanks!

194 points by hkarthik 14y ago

The author is right that, with scrum you end up focusing more on process and not delivery. There are nice things about scrum, but I think scrum followers are too doctrinaire. It has some well-defined practices and is associated with that agile "manifesto" that you are compelled to buy into if you adopt scrum. Being doctrinaire about anything is guaranteed to distance you from reality - you give project managers a weapon to coerce you into worrying about how to break down your work into a velocity and stories and tasks. Any time you enforce a process like that, you are disengaging yourself from the reality of having to ship something.

vannevar 14y ago
Scrum is focused almost exclusively on delivery. Every sprint, you should be delivering working features. It's not that hard: every sprint, you commit to a set of stories to finish before the next sprint. Every day you meet briefly to tell everyone how you're progressing and to air out any impediments. That's about it. To me, scrum is stripping process down to the bare minimum you need to be effective.
- barrkel 14y ago
  And it's fantastic when you're on a tight schedule! Instead of running fast all the time, you just sprint, then sprint, then sprint, etc! Works like magic. No one burns out at all.
  - MartinCron 14y ago
    I don't know if you meant that in a sarcastic way, but this does touch on a pet peeve of mine with Scrum, the word "sprint" is, by definition, not a sustainable pace.
    - anthonyb 14y ago
      So call it something else, like "an iteration".
    - Evbn 14y ago
      You rest, reflect, and recompose between sprints.
  - vannevar 14y ago
    Not quite. You sprint, then you take time to review and reflect on what you've done. Then you take time to plan what you're going to do next. Then you sprint again.
    - barrkel 14y ago
      IME the "review, reflect and plan" is a one-hour meeting on a Friday, every two or three weeks.
      - Evbn 14y ago
        Change it to two days. When do you squeeze in your retrospective? Your presentation of the deliverable to stakholders? Negotiating next sprint commitments? Researching before you do estimation?
  - baconner 14y ago
    Well... yeah! if you get some other core parts of scrum right then nobody should be burning out. Time boxing and point estimation are about figuring out what your team's sustainable pace is and using that to avoid burnout. Scrum isn't about developing faster its about working toward more sustainable and predictable development. If your management doesn't understand that and respect it no methodology will fix your problem. I admit as someone else mentioned that sprint was a poor choice of words. So say iteration instead. Problem solved.
- dasil003 14y ago
  I've never done formal scrum, but I've worked on a lot of teams, and I just don't see how there is a single bare minimum you need to be effective. In my experience, even with excellent teams, this depends on the project and the talents of the contributors.
  - vannevar 14y ago
    To me, the bare minimum for success in software development is clear direction, continuous communication, and continuous verification of the product. Scrum is a simple process to ensure that all three actually occur and aren't merely good intentions left up to individual discretion. I guess you could come up with alternatives, but it would be tough to make it much simpler and still cover all three.
    - leothekim 14y ago
      I've done formal scrum before, and I can see where you're coming from, but my experience scrum didn't ensure continuous communication. The company where I worked actually actively prevented cross-team communication. They did this because the scrum masters and director of engineering claimed it would generate work that couldn't be captured by stories, so velocity couldn't be accurately tracked and people's time could be spent on the "wrong" things. I took as project managers not trusting the engineers to do their jobs. Again, I don't think scrum is all bad, nor do I think it's hard to grok or follow. It's how people adhere to it, and in my experience, people really adhere to it in a way that's detrimental to productivity. For me, it's kind of like religion - I like some of the ideas, but I don't like the fan club.
      - vannevar 14y ago
        Not sure I understand the communication policy you guys were dealing with. If a team is meeting briefly every day and sharing their progress, it ensures that there's at least that much communication. But the daily standup should be a floor on communicating, not a ceiling.
- MartinCron 14y ago
  You can, however, strip it down even further and still be effective. Scrum encourages bundling stories into sets and delivering them all at once. I've been moving away from that, and continuously delivering discrete stories/features/changes/fixes/whatever as they are ready. Decoupling incrementalism from iterations has been a huge change for me.
  - aaronblohowiak 14y ago
    What does QA look like with continuous delivery?
    - MartinCron 14y ago
      Different continuous delivery teams do it differently. I don't like having a dedicated QA team/department. QA is an effort, not a role. The key part of continuous delivery is that the safest change to make to a stable system is the smallest change possible. So instead of batching up lots and lots of stuff and throwing it over the wall to QA, you make one change, have humans and robots test it, and deploy that change. The mindset shifts from "features per release" to "releases per feature" so with truly friction-less automated deployments, you can release very small changes individually. You don't have to test everything in order to change anything. As you may expect, multiple layers of test automation are necessary. Each change runs a gauntlet of different kinds of tests before release. A set of "safe to run in production" tests immediately after release. Rollbacks are trivial, but exceedingly rare. Obviously, this only works in some contexts. If you're pressing things onto gold master DVDs and shipping them in boxes, the QA effort will be more traditional.
    - bwindels 14y ago
      Your automatic (unit, functional, system) tests assure stuff doesn't break (too much), and manual QA happens after deploying. If something is broken, you can fix it very fast, since you are deploying continuously. Stuff might sometimes be broken on production, but you could argue this makes people think twice before pushing to master. Also, you can deploy to production with a delay (e.g. 1h) and deploy to a QA server first to give the QA people some time to check before stuff goes to production.
- programminggeek 14y ago
  Haha, that is only true for a certain type of person. For other people Scrum becomes about "the rules" and if you break one of the rules, you're doing it wrong, even if that might be the best decision at the time. Agile is a philosophy, Scrum is meant to be more of a framework to implement that philosophy, but many people treat it as a set of rules on how to do things, which tends to violate the philosophy of Agile process in the first place.
  - Evbn 14y ago
    In that regard, how is scrum different from anything ever? Anyone can be process obsessed in any system. And, dare I say it, giving a process to Asperger, socially tone-deaf, shoe-staring programmers may help them contribute more effectively to a larger organization.

vannevar 14y ago

FTA: Scrum forces iterations, forces feedback, forces smaller iterations. These are all good things, which I loved about Scrum. And yet the author spends most of the article denying that these aspects of scrum are useful at all. Planning sessions are "highly inefficient," a "quick meeting between the architect and the developer" is better. What if someone else has an important piece of information that the dev and the architect don't? Maybe another dev on the team has done something similar in the past, and could have warned that the estimate was low? He won't be in that meeting, to avoid being "bored to tears" with a story he isn't working on. So how do you know if Scrum isn’t right for you? If it’s hard. If it’s easy, then it will work for you. Obviously, if something is hard, there can't be any possible benefit to it. It's so much easier to get rid of all that process stuff and just churn out code as fast as you can. What could possibly go wrong?

pherk 14y ago
> What if someone else has an important piece of information that the dev and the architect don't? That isn't good enough justification. You are too much erring on the side of caution.
- vannevar 14y ago
  But it's not costing me much. My devs still need to be in on planning their own work, and if they're all on the same scrum there should be a lot of overlap. Listening in on the planning for work entirely unrelated to their own should be pretty rare.
gutnor 14y ago
The author has a point. Scrum is costly. Obviously it is more productive to silo specific knowledge to specific people, generally the expert (or more motivated) in that field. At least it is in the beginning. People leave, experts become expert teams, silos widen and it soon become the good old planning nightmare we have all learned to "love" in enterprise development.
- adrianhoward 14y ago

fingerprinter 14y ago

When I took over development of a extremely dysfunctional engeering team at an established startup with 100 people, the first thing I did (after watching for a bit to learn) was put in scrum. It worked. And it worked really, really well. 2 years later, it didn't work anymore. The team had matured, the organization itself had adapted to the leaner processes and mindset and, in time, the actual scrum process was too much. It was time to change again... And that is something I think most agile advocates don't realize. Agile should be viewed as an organizational tool that has prescripted and prescribed rules that work in general, but maybe don't work in the specific. It is great if you need something forceful with books or documentation in the beginning, but in time, the organization should mature to the point where agile/scrum/whatever is actually too much. One last thought. I highly recommend people look at agile for the times when you need a drop in process....but there is absolutely no subsitute for hiring quality people capable of making good decisions. Agile will get more out of bad developers, IMO, but having nothing and good developers you trust is always going to be more productive.

m_st 14y ago
I fully agree with your post. But do mind sharing what process you changed to then? Did it and does it still work?
sandGorgon 14y ago
That was an excellent observation. I like to explain the phenomenon you observed using queuing theory - As time went on, each of you (and you yourself) were able to estimate tasks very, very accurately. I'd like to think that this was a period of low attrition.. but even if it was not, you were able to model the behavior of a 100 employees (a large enough set) to come up with good estimates. An agile/scrum process is designed to work with tasks of inaccurate estimates - the whole business of story points is designed around that fact. Since your underlying phenomenon changed, the process was no longer optimal. I'm not sure if you experimented with your own "lean" inventions beyond agile - single queues, multiple queues, queues with an artificial stop signal to reduce variance, etc. - but it would have been interesting.
debacle 14y ago
I think your last point is key. You can't use process to turn a bad programmer into a mediocre one - any process that does will also turn a great programmer into just a mediocre one.

snarfy 14y ago

The effectiveness of scrum really depends on the team size. The larger the team, the more bureaucracy is needed to manage it.

genwin 14y ago
True. My last project started each day with 2 hours of scrum.
- SideburnsOfDoom 14y ago
  > started each day with 2 hours of scrum. What? Was your 15-minute stand-up 2 hours long? If so, are you sure you were doing it right? Were you scrum-master, and doing 2 hours of admin per day? What were you doing for the rest of the working day? I'm not really sure what you are describing here.
  - genwin 14y ago
    I wish it was a stand-up! If standing would've forced it to be only 15 minutes, that is.
  - stonemetal 14y ago
    OP mentions larger teams, so a 20-40 person team nets you around 22-45 seconds per person in a 15 min scrum. If we give each person 3 min that is a 1-2 hour scrum.
    - SideburnsOfDoom 14y ago
      > a 20-40 person team nets you around 22-45 seconds per person in a 15 min scrum Which is just one reason why you do not have 20-40 person teams in scrum. The team size top out at around 12, and yes, at that size you have to keep what you say at stand-up short and to the point. If you find a 20-40 person team, for scrum you will have to break it up into sub-teams. Was he doing some variation of scrum? Some kind of scrumbut? I won't claim that scrumbut always fails, but it's not hard to spot where this went wrong.

cocojumbo123 14y ago

Actually what the author describes is a natural path of evolution for that team. Scrum (as a process) contains the possibility of changing the scrum rules themselves - although it is strongly recommended one does that only after they get experienced (e.g. they actually manage to get shippable product each iteration). When the focus is on the process itself and not on delivery there is something rotten in Amsterdam. Scrum can be a micro-manager's dream (think of the visibility on who is doing what at almost hourly level) - case in which one can end up with focus on the process not on result.

michaelt 14y ago

Iteration planning meetings are seriously expensive. Group discussion around design, group estimation, group acceptance, all highly inefficient. [...] I remember just getting bored to tears listening to discussions around stories I wasn’t developing on to begin with. That's quite team size dependent. In a scrum team with 4 people this isn't a problem - but when the team's twice as large it doubles both the amount of work to plan and the hourly cost to assemble the entire team, quadrupling planning costs. If a team is structured in such a way that a developer knows they won't be working on a story, that seems like a logical line for splitting into two scrum teams.

debacle 14y ago

> With Scrum, there is an explicit commitment ... on what stories are going to be delivered within the sprint, No, there isn't. You adhere to your burn-down, not to your feature set. Scrum is time driven, not task driven. The whole idea is to become better at estimation so that Scrum appears task driven, when really it's just because your team is that good at estimating. > Iteration planning meetings are seriously expensive. Then you're doing it wrong (god, I feel awful for saying that). If you're spending that much time in pre-sprint planning, people aren't bringing enough to the table and you're not defining your problems well enough before trying to solve them. > I hate the term “scrum-but”. Ironic that that sounds like exactly what the environment you were working in sounds like. > This might be a bit controversial, but the big difference between Scrum and things like Lean Software Development for me were the difference of focusing on process versus delivery. I think this is a "forest for the trees" issue. Scrum is about abstracting the process into a rigid and lightweight framework so you only have to think about it, at most, fifteen minutes a day (unless you have the misfortune of being the Scrum master/cat wrangler) > It can’t, and it’s not a problem with your organization if it doesn’t. It’s a problem with Scrum. That's a non-sequitur. It's a problem with neither. If my company can't implement a waterfall methodology because our clients require faster iteration, that doesn't mean there's a problem with either - it's just not a good fit. But if your company tries to implement Scrum and throws it out six weeks or six months later because it's "too hard" or "bad," my assumption is that real Scrum probably wasn't happening. Will Scrum work for everyone? Fuck no. Scrum is hard. It requires the kind of buy in that, if you've got it, you probably don't need Scrum anyway. Can Scrum work for everyone? Probably. Scrum is only hard when you've got conflicting goals. If you have a smart enough team, you can tweak your sprint lengths from as little as a few days to as long as six to eight weeks, and after you've been on Scrum for a few sprints your planning meetings should take an hour or two, tops.

sethg 14y ago
In my experience (six months at a job that does Scrum and, I think, does it very well), the thing that slows down iteration planning meetings is when the product manager hands down a one-sentence feature description, the engineers say “we can’t size that, it’s too vague”, and then you need a five-to-fifteen-minute discussion in order to expand that one sentence into something resembling a spec.

g123g 14y ago

The #1 point mentioned in the article was my experience as well. For a tight deadline project if we decided to do everything based on the complexity points and team velocity it would take 6 sprints and a total of 3 months. But we just decided to ditch it and sit around a table and finished the whole thing in 2 weeks straight. So my experience is that if you are working with a dedicated team it is better to finish the work based on the best of your ability rather than time boxing into some artificial time limits.

kevingadd 14y ago
How would Scrum turn a 2 week project into 3 months? Are you just saying you were terrible at estimation, or what? I don't understand what you ditched, specifically, and how that produced an improvement.
- SoftwareMaven 14y ago
  In timeboxed iterations, you have to be very careful that work doesn't expand to fill all available time. If you are a little conservative with your estimates, its easy to double the time the necessary aspects of development would take. Little, unnecessary tweaks becomes more important than putting four hours into the stretch goal that is going to spill into the next sprint. Six times is a bit much, though. That sounds like they haven't worked out their estimations yet.
knighthacker 14y ago
Having a dedicated team is definitely important. I had a similar experience to yours and I am not entirely sure why. I think a big part of it is that once you dig into complexity points and time estimates and all that other stuff, people tend to be on the safe side and add a lot of buffer. But when the whole team is in the hacking mentality and just wants to get sh*t done, you don't need to have everything in sprints. You just need a highly motivated and a dedicated team.
skMed 14y ago
Are you trying to say the overhead of SCRUM would increase the time to 3 months? SCRUM is a lightweight framework, so I am struggling to see how this could happen. Alternatively, do you think the estimation with points was the main problem and you couldn't get a correct feel for doing it without resulting in a conservative estimate?

michaelt 14y ago

MartinCron 14y ago

The fundamental thing I've realized while looking for "the optimal end-state process" is that it doesn't actually exist. Scrum is, for many development organizations, an incremental improvement over what they are doing now. The biggest problem that I have with Scrum (and all prescriptive methodologies) is that it's presented as a vision for the right end-state instead of a set of tools that you can use to help find the right process for your immediate context.

mongol 14y ago
I so agree with this. If there was such a ting as "100% scrum compliant" it would be a bad goal to strive for. Not because it is bad in itself, but because the process should be adjusted to the situation.

the1 14y ago

just code. code well.

sethg 14y ago
You can code, code well, and then discover that the feature you just implemented was something that the upper management actually didn’t consider to be very important, or that they wanted something completely different from what you thought they wanted. That’s the sort of failure mode that Scrum and other development methodologies are trying to protect you against.
- pnathan 14y ago
  This is an incredibly big deal. If the customer didn't order it, it doesn't matter how well you coded.
- the1 14y ago
  I tend to think bringing in agile specialists and installing scrum process to save the project is a bit dogmatic. If you worked on a project for sometime and wrote/rewrote a lot, you probably know what's needed to be written. It's fairly unlikely the scrum process actually helps at that point. What keeps you going at it is probably "faith" you built through out the year since the onset of scrum installment... and, just a habit. If you are afraid of writing unneeded, unimportant, and unpopular things enough to label them as a "failure", your focus may be to find needed and important things for your audiences. Your focus may be to read the draft to a select sample audiences everyday, every week, continuously, and apply various analytical techniques to different statistical models you built from the feedbacks to overcome your fear of rejection, and "manage" direction, completion, and shipment of your writing. Or just write. A lot. And read. A lot. You'll "get" trends. You'll "get" what works and what doesn't. Of course you need feedbacks. Of course you need plans and management especially if you are co-writing with many authors. But my focus is still to write.
brazzy 14y ago
That's kinda like saying that all you have to do to win the Superbowl is "just play. play well."

mmanfrin 14y ago

Minor counterpoint to the bit about meetings being boring: As a QA person, it is incredibly valuable to us to all be together so we can discuss things with the devs that are otherwise getting overlooked in bugtracking software or even in our chat. It makes it so that those orphaned problems can find a home. But our meetings are short. 5 or 10 minutes max. If you're getting bored than, to quote another commenter here, you're doing it wrong. Quick summaries, major problems, then get out the door.

base698 14y ago

You haven't really jumped the shark with scrum until you have in place a scrum of scrums, and a scrum of scrum of scrums taking up half the day for all the key players.

at-fates-hands 14y ago

> Iteration planning meetings are seriously expensive. I completely agree on this one. I've worked in several corporate environments utilizing Srum and the planning meetings were always a huge waste of time. I would rather light my hair on fire than sit around a bunch of PM's trying to figure out what features to include/exclude. Also, most of the people (PM's,Dev's,IA's) I talk to always say, "Nobody does Scrum/Agile right anyways." Which made me wonder if there is indeed a right and wrong way to do these.

skMed 14y ago
Perhaps it is the environment or Product Owners that are causing this slow down? Product Owners (PMs, etc.) should stack rank items in their backlog before a sprint planning meeting. This should make it fairly easy to allocate items for a sprint and identify features which either need to be 1. clarified, 2. split/scoped down. My sprint planning sessions have typically always gone smoothly as long as everyone came prepared and ready to contribute.
jt2190 14y ago
In my experience most teams do planning completely wrong. The goals of the planning meeting are simply: 1. Do a relative-size estimate the top n stories in the backlog. (Where n is some number slightly larger than the number of stories that usually fit in an iteration.) 2. Pick the stories to complete in the iteration. That's it. I often see teams: * doing one-by-one story estimation, and debating over how many points to assign. (The statistical method completely fails when it's done this way.) * getting into long discussions over the spec. (That's between the dev and product owner, to be figured out during the iteration.) * worrying too much about accurate estimates * worrying too much about how much work to take on
- smhinsey 14y ago
  I think the reason this happens is because no matter what people say, the idea that if you can't finish a story within a sprint it will simply slide into the next one is anathema. People spend more time on estimation when the consequences of mistakes are higher. If you can't realize that a story is larger than you thought and reprioritize mid-sprint without it being equivalent to missing a deadline in your old model, it's not going to work. In my experience this is the key failure mode of scrum.

dpham 14y ago

I work at Webs and we also recently abandoned scrum for a more kanban approach. While all points in the article resonated with our company, the biggest problem we had was not delivering projects on time. We focused too much on fitting as much work into a sprint as possible for maximized throughput. The problem with that, especially when you have alot of projects going on at the same time, is that alot of work was being burned across the board, but the needle for each individual projects didn't move forward fast enough and we ended up missing deadlines. Another problem with scrum is that it turns creative developers into code monkeys, and this in turn lowers code quality. Developers are constantly worried about trying to meet deadlines for the next two weeks rather than taking the time to do things correctly. This ultimately creates technical debts and hurts the team in the end. (also, if you're a manager and you use the developer points burned in order to rate performance and distribute bonus, then fuck you)

pherk 14y ago
I very much agree with the last point. Objective evaluation of a developer is much more than burned down points. I worked at Amazon and could see evidently that Scrum was turning good developers into mediocre ones. But not many raised a finger against it as Scrum was seen as the norm. And there was no scientific way to establish this fact.

njharman 14y ago

Excellent observations based on actual experience. A refreshing change from the usual "I don't understand what agile is but I did something I called agile and it sucked so I'm now blogging about how agile is broken".

gleiva 14y ago

We started doing Scrum around a year ago and it has worked well for us. I feel some of the points described in the article about Scrum are not because of the framework itself but because there could have been a lack of a Scrum Master, which is an important piece in the puzzle, to ensure Scrum effectiveness.

tosh 14y ago

The problem with SCRUM is that it is not agile. That's why we see most of the pragmatic companies adopting a kanban or scrumban approach and they see good results. I would argue that just having a kanban board during stand-up meetings and "walking the board" instead of interrogation-like status reporting is going to do wonders to team collaboration atmosphere, morale and actual productivity. You start to see and talk about the flow of value, what's next, what's in the moment ("what can we do right now?). You see context. All of that is missing with SCRUM or only possible with a highly motivated and responsible team that communicates a lot automatically. I'm not yet saying that kanban is solving the software crisis [1] but it turned around quite a few teams that I've seen and been part of. DISCLAIMER: I'm working on https://www.blossom.io https://www.blossom.io which is a lightweight kanban board. 1: http://en.wikipedia.org/wiki/Software_crisis http://en.wikipedia.org/wiki/Software_crisis

manmal 14y ago
Can you elaborate on why Scrum is not agile? You are the first I read claiming this.
- tosh 14y ago
  Great question. I might have a harsh tone in my previous comment but I've got really frustrated with scrum (or implementations of it) over the last few years. Scrum in my eyes is a process and from what I've seen it makes teams very process oriented. The whole idea of scrum master certification and the success it had in enterprise adoption might have something to do with that. It incentivises teams (at least all the teams I've seen) to work for the process as good as possible. They focus on complying to the process, getting estimates right (or working in a way that makes the estimates right), they focus on the backlog instead of throughput or frequent re-prioritization … If you can free yourself from viewing the 'process' as fundamental religion it's easier to apply agile & lean principles like focusing on delivering value and improving the framework, changing things, changing the process so it fits your needs, etc. In a nutshell: I see scrum incentivising people to work in a way that is not agile but pseudo-agile/feel-good-agile. I see no feedback loop for the process itself (at least I see no one doing that, except teams that adopt kanban and scrumban or do scrum but …). But I'm interested in learning from people who've made other experiences. It's an exciting topic.

martincmartin 14y ago

I've done a bunch of reading about Scrum. If you read between the lines, you realize that Scrum was created and popularized by consultants who go into dysfunctional teams/organizations, and tries to fix the worse problems. For example, the idea of a sprint is for a team to be able to work for at least a couple weeks on a single thing, without people being asked to work on other "small" projects, or without the entire direction of development changing every week. Once the team is functioning well, you can usefully relax a lot of the aspects of Scrum.

sjtgraham 14y ago
This is a really interesting insight. I have seen so many instances of prescriptive Scrum with no explanation as to why that it's appropriate, i.e. Cargo Culting.
- luriel 14y ago
  Most of the software industry is built on cargo cult.
mizhi 14y ago
After a bit of experience with scrum, one of the things I"ve come to appreciate is that it's not a one-size-fits-all methodology. I think the spirit of scrum (break work into chunks, have working code at each stake in the ground, define a project in terms of user stories, etc) is more important than the letter of the law, and being able to tailor the process to your current reality is more valuable than dogmatic adherence to some prescription.
- rockyj 14y ago
  Excellent point!
deleted 14y ago
[deleted]
ams6110 14y ago
I think you're being a bit generous. The consultants who sell "Agile" to dysfunctional organizations are the same ones who sold every fad methodology that preceded it to those same dysfunctional organizations.

deleted 14y ago

[deleted]

vpeters25 14y ago

Every time I come across "why scrum sucks" articles like these I can quickly point the problem: the ScrumMaster. #1 - Iterations are less efficient than pull-based approaches: A good ScrumMaster keeps an eye on the burndown chart and negotiates with the stakeholders and team to either add or remove tasks from a sprint. My first sprint ever as ScrumMaster, we estimated a 3 months project, we did everything in 2 sprints (1 month) #2 – Iteration planning meetings were wasteful: You are doing them wrong. A good scrum master keeps everybody focus on one user story at a time and keeps the meeting moving. I use a 3 min stopwatch in my phone. The whole meeting should not take more than 1 hr (I do 30-45 mins estimate new stories, the rest to plan and commit team to next sprint) #3 – Scrum is highly disruptive in established organizations: A good scrum master servers as a bridge between traditional management and keeps them out of the team's backs. This one is the reason I don't like being ScrumMaster anymore. A good ScrumMaster needs great people skills, I rather write code.

erichocean 14y ago
So scrum has a single-point-of-failure that organizations, more often than not, see high failure rates with? And we're still recommending companies adopt this, when the failure rates are both known to be high, and catastrophic when they occur?
- vannevar 14y ago
  Companies still do project management, and the project manager is a single point of failure. The reason the failure rate is high is that scrum is relatively new and companies still think they can get away without having a scrum master, while they know from long experience that they need good project managers.

gstober 14y ago

I read through the first bunch of these comments and scanned the rest...you guys, you guys... I might have missed it but I didn't see anything about client delivery that is viable...or do you have other reasons for being in the software game? Who really cares what process you use? As a client I want to be involved, I want to see how you're doing on an on-going basis, I want stuff that works well, I want stuff I can use and I want to alter by vision as you deliver because my business can change...

ajsharp 14y ago

In my experience, Scrum / Agile / XP tend to be more about the process than the results. I find these methodologies to be particularly useful for contractors and consultants, primarily because the value proposition for a consultant is much different than it is for an employee. A consultant comes in and typically some sort of statement of work or master services agreement is agreed to by both parties, which outlines roughly the work that will be performed over the course of the engagement. Once work begins, some Agile hoops will be jumped through (storyboarding, etc) in order to further establish and agree upon the work that will be performed. This way, at the end of the engagement, when the consultant has been paid for 3/6/9 months of work, they can point back to what was agreed upon each step of the way and say, "See, we're delivering what was agreed upon way back when." Employees at most software companies, and certainly at early-staging companies, don't work like this, nor should they. As a product engineer, your job is, in a nutshell, to figure out through software how to make the business work. There might be a high-level strategy laid out for you, there might not be. Either way, you're engaged in an inherently creative activity in order to devise and implement a solution to make users happy, and hopefully make money. Whether or not the employee delivered upon what was agreed to three months ago, or whatever the timeframe, is irrelevant (at least it should be). The question should be, "Is your work having a positive impact on the business?". There is an inherent necessity to quantify "positive impact" when working with consultants, partly because they cost a lot more in the short-term, and partly because the nature of their work is generally less creative and more controlled. So, if you trust the people you work with, and the company communicates it's vision well, IMO Scrum and Agile are too much procedural overhead. Of course, you have to meet those two conditions :)

leothekim 14y ago

Also, obligatory: http://programming-motherfucker.com/ http://programming-motherfucker.com/

cpenner461 14y ago

Several comments about the notion that at some point you outgrow Scrum. For those who have reached this point, I'm curious what you've switched to? Or has it been more of simply relaxing some of the constraints/procedures? Asking because I've recently started to wonder if/when we'll need to modify our mostly-Scrum process.

adrianhoward 14y ago
The most common (productive) change I've seen is a move to something that's closer to the pull/kanban/lean approaches. For example a pattern I've seen a few times goes something like this: * Teams get good at breaking down and estimating backlog items, they tend to all become the same "size" and need about the same amount of "work" * Product Owners get good at prioritising the work so that the most valuable stories are at the top of the queue * Dev team and product owner turn have a collaborative relationship rather than a boss-minions relationship. * The combination of those three factors means that the planning meeting basically turns into "we do the next N stories" where N is the number of stories you get done every sprint. So the utility of this meeting disappears. * The process of work flowing through the team starts resembling single-piece flow. Everybody works on the next most important thing. * People start continually delivering, rather that just being able to deliver at the end of the sprint. * The last two points mean the utility of breaking work into sprints kind of vanishes. * Everybody notices that they're doing flow-ish things rather than batch sprint-ish things and starts looking to the lean / kanban world for ways to optimise the process further.

wballard 14y ago

Interesting points, but I feel that the root cause of these process debates is one un-natural act: estimation. Personal opinion is that far too much energy is put into processes to generate predictability, which is only practical when you have done it before, repeatedly. All this focus on estimation, points, timing -- it just doesn't create what is needed to both do a great job and go fast: clarity. This is why I don't run my shop with deadlines. I have no experience that deadlines/sprints/iterations make things faster, or create better ideas -- the things I'm actually interested in.

jpatil 14y ago

What people fail to realize is that Scrum is a specific process. There are actual guidelines on how it should be implemented and what the team make up should be. People think they can take Scrum and tweak it to meet their needs (even if it hurts the process) and have it still be effective. People believe that they can "scale" Scrum to teams of 100s of people, in different locations, across time zones and with people who speak different languages and expect it to work the same. It wont and was not designed to. Additionally, Scrum is not designed to handle unanticipated work. How many times will a team be working on a sprint when a fire happens, especially at a large company? The team needs to disrupt the sprint and handle whatever unplanned work it is, from a defect a major customer change request or whatever. The whole sprint gets thrown out of wack and what was defined as the ship requirements needs to be redefined on the fly. However, Scrum allows partially done work and if a new work item is injected at the end of sprint, the Q&A team may not be able to meet the new ship requirements of either the new work item or the rest of the sprint work. With that said, Kanban was designed to not be a prescriptive process. Kanban is all about making small incremental improvements in WHATEVER YOU ARE DOING NOW. By visualizing work you are able to see where you are becoming overloaded and where blockages are occurring. By adding WIP limits and through pull instead of push you are helping to even out the flow of work and ensure that work is getting completed to 100% at a relatively constant speed. There are other aspects of Kanban that help, specifically metrics, the CFD, and swim lanes, but really with these two aspects, you can constantly visualize what is going on and figure out how to improve your work process on demand and in your own way. While I am a big proponent of Kanban for countless reasons, many organizations cannot simply change overnight. Many organizations cannot grasp the concept of no time box and continuous deployment. Putting faith in the work ethic and self organizing capability of the developers doesn't jive with many companies (even though the studies show teams are much more productive when self-organizing). Other people, like the author, like the idea of iterations. In addition, many teams see great value in doing the retrospective. Lastly, the teams in the organization may have been trained in Scrum and been doing it for years. To all of a sudden change to something new can cause major disruptions in work and full on rejection and revolt. For these types of organizations, I tell people to try Scrumban or Kanban with Iterations, whatever you want to call it. Teams can use Scrumban as a stepping stone to becoming more Lean or then can just use it going forward to improve and scale Scrum. Using Scrumban, teams can move slowly to self-organization and from estimating to prediction. They can handle injected work more easily and move to continuous deployment. Moreover, they reduce multi-tasking/ task switching and ensure a even flow of work. For anyone wanting to learn about Scrumban, I send them to this video -> http://www.youtube.com/watch?v=0EIMxyFw9T8 http://www.youtube.com/watch?v=0EIMxyFw9T8 It's an awesome video that is just over 6 min long. I don't know who these guys who made it are and am not promoting them but the video does the job well.

demian 14y ago

We need to drop the idea that there is THE methodology to organize software development. I like the approach of this post, but I would had prefered a little more context on the type of projects he manages. A professional software manager should be able to identify the key aspects of a project, and with that define the methodology (borrowing from different aproaches and using different tools). Some projects require centralized design with a top-down approach, and more of a "programming workforce" self-coordinated with some progress metric. Other projects require more sophisticated engineering design, technical expertise imbued in a creative enviroment by a relatively small team of engineers/developers. In my opinion, iteration is all about exploration. Scrum basically discards the role of a "designer" for the systems. But sometimes you need a designer.

JoelMarsh 14y ago

There seems to be some very scrum-savvy people here. I have used it many times, but I am interested in your thoughts about how designers typically work within that framework. In my experience design and scrum don't play very nicely together. Thoughts?

adrianhoward 14y ago
There are a bunch of folk (me included) who spend a lot of time thinking about getting UX and Agile folk to play nice together. You can find some of my rantings via lanyrd http://lanyrd.com/profile/adrianh/ http://lanyrd.com/profile/adrianh/. You'll likely find Jeff Patton's work of interest - this might be a good starting point http://agileproductdesign.com/blog/emerging_best_agile_ux_practice.html http://agileproductdesign.com/blog/emerging_best_agile_ux_pr.... There's a stack of stuff under https://pinboard.in/u:adrianh/t:agile/t:ux https://pinboard.in/u:adrianh/t:agile/t:ux that you may find interesting. Some of it may need filtering through my brain before you see the agile/ux connection though :-) The UX track at Agile 2012 had a bunch of great sessions around getting UX and agile running well together (bias warning - I produced the track :-) http://agile2012.sched.org/overview/type/user+experience http://agile2012.sched.org/overview/type/user+experience - I think all the sessions have slides now. Nag me if not. There are also the sessions from Agile UX NYC earlier this year http://agileuxnyc.com/presentations/ http://agileuxnyc.com/presentations/ Personally I'm finding UX works better outside of an iteration context with a more lean/kanban approach. The stuff Janice Fraser is doing at LUXr for example http://www.slideshare.net/clevergirl/ http://www.slideshare.net/clevergirl/. Google around the "Lean UX" topic. Ignore the folk who talk about it as if it's just about less deliverables. It's more than that. Finally the agile usability mailing list http://tech.groups.yahoo.com/group/agile-usability/ http://tech.groups.yahoo.com/group/agile-usability/ is a useful place to chat about this sort of stuff.
- JoelMarsh 14y ago
  Amazing. I'm glad I asked. Thanks!