Why I’m done with Scrum

My first foray into Agile was with a product team back in 2004-2005. It was my first “real” job out of college, and my first experience with a death march. During the death march, I was struck on how bad the idea of death marching was. Working weekends, long hours etc. were a sign of failure not on the development team, but our a failure to plan, set expectations, and deliver frequently.

This rather horrible experience pushed me to explore better options, leading me into Scrum and XP. For a team that released once every year or two, delivering (and having acceptance) around stories etc. were very helpful in turning our team around.

So I’ve had a lot of success with Scrum – but I’ve had greater success in ditching it. Here’s a few (of my many) my reasons why:

#1 – Iterations are less efficient than pull-based approaches

With Scrum, there is an explicit commitment (whether the Scrum books tell you or not) on what stories are going to be delivered within the sprint, and ones that are stretch goals/extra/end ones.

There’s something psychological about timeboxing, and working filling the space allotted. When we moved away from explicit time-boxed iterations, and just delivered as fast as we could without iterations, we saw a marked improvement in delivery.

We still had regular checkpoints on schedule/timing/etc. but no longer were burdened by iteration boundaries to decide to do more work.

#2 – Iteration planning meetings were wasteful

Iteration planning meetings are seriously expensive. Group discussion around design, group estimation, group acceptance, all highly inefficient. These meetings are helpful when the team has problems with commitments or trust, but otherwise, these meetings require a lot of time and are very, very expensive.

I remember just getting bored to tears listening to discussions around stories I wasn’t developing on to begin with. Eventually, we had to ask the question, “are these meetings providing the value we are paying for”. Yes, there was some value, but not near enough to warrant so much expense. I’m sitting in a meeting, thinking, “can’t I just start actually developing software”?

Instead, just about everything was JIT’d. Design was done with our architect and product owner. Estimation was done in concert with tech lead and architect (though only really when there was significant new work). When stories were ready, they were put on the board. When a developer was ready to develop, a quick meeting took place between the architect and developer on the story.

Fast, efficient, and focused on delivery.

#3 – Scrum is highly disruptive in established organizations

I hate the term “scrum-but”. That these are viewed as dysfunctions is just insulting. For established organizations, Scrum is very hard to deploy. Moving from yearly or semi-annual releases to weekly iterations is very, very hard. And very easy to fail at.

Pull/flow-based approaches start with what you have, and work on improving that. Scrum works when the organization is open to change. Flow-based works when the organization is not, by starting with existing work, highlighting inefficiencies, and allowing the organization to decide to improve (or not). Shoving Scrum down the organization’s throat, especially when it comes from the development team, has a high probability of failure.

Disruption can be good, but it’s extremely risky. I think of Kanban more as “Working effectively with legacy code”, where we focus on improving what we’re already doing, rather than the “File –> New Organization” approach of Scrum.

#4 – Focus not on delivery

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. Lean focuses on delivering value, and having a set of approaches on discovering your unique way of doing so, where Scrum has a framework for a process and tells you if you don’t follow this approach, you’re doing it wrong.

Ultimately, our goal is to continually deliver success. Well, most developers anyway. Too much discussion comes around “are you doing Scrum” versus “are you delivering”. Delivering is what matters. Process is merely the how.

What I like about Scrum

A lot of people have had success with Scrum, including myself. I like Scrum, when it works well. What I don’t like is the assumption that it can work everywhere. It can’t, and it’s not a problem with your organization if it doesn’t. It’s a problem with Scrum.

Scrum forces iterations, forces feedback, forces smaller iterations. These are all good things, which I loved about Scrum.

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. If it’s hard, then you’re using a process to force organizational change, and that’s a rather lousy, failure-prone way to do it.

Related Articles:

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

About Jimmy Bogard

I'm a technical architect with Headspring in Austin, TX. I focus on DDD, distributed systems, and any other acronym-centric design/architecture/methodology. I created AutoMapper and am a co-author of the ASP.NET MVC in Action books.
This entry was posted in Agile. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Jamie

    I’ve had very similar experiences to yourself. We moved to a Kanban system a while back and loved it. Removing the time boxing got one of the biggest thumbs up from our team. Nobody said they really benefited from the artificial deadline that sprints imposed on them. Now cards just move across the board, we have planning and retrospective meetings as needed and our board reflects how we work, not how we “should” be working.

  • Jamie

    I’ve had very similar experiences to yourself. We moved to a Kanban system a while back and loved it. Removing the time boxing got one of the biggest thumbs up from our team. Nobody said they really benefited from the artificial deadline that sprints imposed on them. Now cards just move across the board, we have planning and retrospective meetings as needed and our board reflects how we work, not how we “should” be working.

  • David Lindsley

    Interesting.

    While I agree that we should be focused on delivery, I think time-boxing is there to (help) avoid over-scoping and BUFD, and to get everyone to commit to frequent, rapid delivery. If you don’t need time-boxed iterations to do that, that’s fantastic, but IME most organizations can use help in that area.

    Team meetings can help create a culture of collective code ownership. They can also help avoid over-scoping. Again, if you don’t need that, that’s great, but it’s not representative of most organizations I’ve dealt with.

    I heard someone say recently that most organizations that are succeeding with Scrum are doing Scrum + XP. The development is organized around XP principles — like frequent delivery for rapid feedback — Scrum is there to keep the suits happy.
    Which would seem to imply that if the devs get wrapped up in Scrum, they’re not going to be (as) happy or (as) productive.

    • Anonymous

      We definitely found initial value in those team meetings – it helped us move in the right direction. My question is – do we need to start with Scrum, or work to improve with what we have? I don’t like the literature of Scrum that says you can’t deviate from Scrum unless you’re doing it 100%.
      It took a lot of trust to give up those group meetings. But once we looked at the numbers and our reasoning, it was mostly emotional reasons and not empirical data that we had these group meetings. People said they liked them, yet it was mostly fear of not having them that held us from moving away, not that we actually enjoyed these long meetings.

      And don’t even get me started on meetings where we actually tried to do design during these meetings. Good god, what a waste that was.

    • Anonymous

      We definitely found initial value in those team meetings – it helped us move in the right direction. My question is – do we need to start with Scrum, or work to improve with what we have? I don’t like the literature of Scrum that says you can’t deviate from Scrum unless you’re doing it 100%.
      It took a lot of trust to give up those group meetings. But once we looked at the numbers and our reasoning, it was mostly emotional reasons and not empirical data that we had these group meetings. People said they liked them, yet it was mostly fear of not having them that held us from moving away, not that we actually enjoyed these long meetings.

      And don’t even get me started on meetings where we actually tried to do design during these meetings. Good god, what a waste that was.

      • http://twitter.com/aigarius Aigars Mahinovs

        Two week sprint planing meeting should be under two hours. Now you figure out how much waste that is and how much into each task should you be able to go during that time.

      • http://twitter.com/postAgilist Post-agile Architect

        I’m glad you wre able to see what those meetings cost. Scrum true believers always sweep those costs in time under the rug as a necessity that can’t be questioned..but of course it can be…the same scrutiny should be applied to TDD as well

  • David Lindsley

    Interesting.

    While I agree that we should be focused on delivery, I think time-boxing is there to (help) avoid over-scoping and BUFD, and to get everyone to commit to frequent, rapid delivery. If you don’t need time-boxed iterations to do that, that’s fantastic, but IME most organizations can use help in that area.

    Team meetings can help create a culture of collective code ownership. They can also help avoid over-scoping. Again, if you don’t need that, that’s great, but it’s not representative of most organizations I’ve dealt with.

    I heard someone say recently that most organizations that are succeeding with Scrum are doing Scrum + XP. The development is organized around XP principles — like frequent delivery for rapid feedback — Scrum is there to keep the suits happy.
    Which would seem to imply that if the devs get wrapped up in Scrum, they’re not going to be (as) happy or (as) productive.

  • http://genehughson.wordpress.com/ Gene Hughson

    In my opinion, tailoring your process to your situation has always seemed the most agile option of all.

    • James Banner

      +1000 to that. There is no silver bullet.

    • http://www.facebook.com/thabo.letsoalo.3 Thabo Letsoalo

      Amen to that. And being able to ‘tailor’ your ‘tailored’ process even further at any time during the process is good. An example of a flexible agile development tool that can be adapted to how you work (including scrum) can be found under the templates section at eyequu.com . PS: I am the Chief Ninja there.

    • http://blog.thecodewhisperer.com J. B. Rainsberger

      Yes, and was always the point. Any set of rules is meant to be a starting point, not a process to follow indefinitely.

      • http://genehughson.wordpress.com/ Gene Hughson

        Agreed, but what should be and what something develops into rarely coincide – Cockburn’s Pledge of Non-Allegiance wouldn’t have come into being if people didn’t turn guidance into dogma.

        • http://blog.thecodewhisperer.com J. B. Rainsberger

          Yes, which makes me a bit sad that some people run away from the words Agile, Scrum, XP, while others (like me) would like to help them retain some of their original meaning. Eternal struggle.

          Not enough people recognise all this as a sign of the *success* of the ideas.

  • http://genehughson.wordpress.com/ Gene Hughson

    In my opinion, tailoring your process to your situation has always seemed the most agile option of all.

  • gabbered

    What are you successfully using to replace it?

  • gabbered

    What are you successfully using to replace it?

  • Steve

    I am deep in the bowels of an established company who is all about the Waterfall. Most importantly, they’re all about the needless artifacts for the sake of artifacting. When they asked me for my Unit Testing documentation i nearly quit.
    That being said, while I agree that the planning meetings can be inefficient, I do have to say they are important. There’s an old saying that “Work fills to expand the time allotted”.
    I’m trying to convince the guys here to adapt some sort of agile. They’re terrified though because the middle management doesn’t know what they’ll do all day if they don’t have unit testing documentation to read.

  • Steve

    I am deep in the bowels of an established company who is all about the Waterfall. Most importantly, they’re all about the needless artifacts for the sake of artifacting. When they asked me for my Unit Testing documentation i nearly quit.
    That being said, while I agree that the planning meetings can be inefficient, I do have to say they are important. There’s an old saying that “Work fills to expand the time allotted”.
    I’m trying to convince the guys here to adapt some sort of agile. They’re terrified though because the middle management doesn’t know what they’ll do all day if they don’t have unit testing documentation to read.

    • http://www.linkedin.com/in/matthewtagg Matt Tagg

      Get out while you still can! :p What a sucky place to work haha

    • http://www.linkedin.com/in/matthewtagg Matt Tagg

      Get out while you still can! :p What a sucky place to work haha

    • http://twitter.com/arnislapsa Arnis Lapsa

      Consider submitting to DailyWTF that one :D

    • http://www.hmemcpy.com/blog/ Igal Tabachnik

      Oh wow, I feel for you. I have recently consulted with a company that “tried to do scrum and it didn’t work”. They asked me to write documentation on unit testing. After my attempts to explain that this is useless failed, I wrote a document in about 3 hours, detailing everything from configuring the environment to the actual writing of tests. Guess how many people bothered to read it?

  • Michi

    We had the same experience and moved to Kanban. Now, two years after switching to Kanban, we love it! Here is a small presentation about “why kanban fits the jimdo culture”. http://prezi.com/rr-b-d0u_yg0/why-kanban-fits-the-jimdo-company-culture/

    • Anonymous

      Cool, thanks for sharing your story!

    • Anonymous

      Cool, thanks for sharing your story!

    • NewsMaster69

      Wow that was awesome….. I could cut glass with these things right now! :)

  • Michi

    We had the same experience and moved to Kanban. Now, two years after switching to Kanban, we love it! Here is a small presentation about “why kanban fits the jimdo culture”. http://prezi.com/rr-b-d0u_yg0/why-kanban-fits-the-jimdo-company-culture/

  • Joan Comas Fernandez

    Without time boxing, how are you measuring the team performance?

  • Joan Comas Fernandez

    Without time boxing, how are you measuring the team performance?

    • Bryan

      With Kanban, you measure overall flow – how fast do items work through the work queues. You look for the slowest, potentially blocking, spots, and improve those.

    • Bryan

      With Kanban, you measure overall flow – how fast do items work through the work queues. You look for the slowest, potentially blocking, spots, and improve those.

  • http://twitter.com/leebrandt leebrandt

    Great Post. All the same stuff that got us using Kanban in 2008.

    @Joan Cycle Times and Cumulative Flow Diagrams can give you the quantitative numbers you need. The best measure of a teams performance, however, is whether they deliver business value when the business needs it.

    My $0.02.

    Again great post. Sharing it with ayone who will listen. :0)

  • http://twitter.com/leebrandt leebrandt

    Great Post. All the same stuff that got us using Kanban in 2008.

    @Joan Cycle Times and Cumulative Flow Diagrams can give you the quantitative numbers you need. The best measure of a teams performance, however, is whether they deliver business value when the business needs it.

    My $0.02.

    Again great post. Sharing it with ayone who will listen. :0)

  • Francisco Aquino

    Jimmy, Scrum is a self-destructive methodology, it ceases to exist the moment people know what to do, when to do — then the process becomes a burden and annoyance, you may have hit that point.

    • SHD SYD

      WOW +10,000 !!!!

      • NewsMaster69

        But what would we do with all the BAs and PMs and Directors and….. If there was only a way to get information from checking code in…. too bad…. Anyone got a blocker? yeah, toots, it’s you…..

  • Francisco Aquino

    Jimmy, Scrum is a self-destructive methodology, it ceases to exist the moment people know what to do, when to do — then the process becomes a burden and annoyance, you may have hit that point.

  • Anonymous

    Excellent article and I can’t agree with you more. I stopped using Scrum at Crowdtilt and started to focus on deliverability and productivity. Team members work on what excites them and what we all think should be a “priority”. If it is in JIRA, it is important and needs to be addressed.

  • Anonymous

    Excellent article and I can’t agree with you more. I stopped using Scrum at Crowdtilt and started to focus on deliverability and productivity. Team members work on what excites them and what we all think should be a “priority”. If it is in JIRA, it is important and needs to be addressed.

  • JS

    I am a programmer in a large software company that transitioned from iterated/waterfall to SCRUM recently (by order from above). And I hate it, for different reasons than you though (but I am no expert, so I may be wrong on some counts):

    1. It indeed caused disruption. It’s like with IT in big organizations – the original processes won’t get replaced, only another processes are put on top of them.

    2. The finance and marketing etc. still think in terms of delivered features for the release cycle. So you have to commit to what you will deliver anyway. So the priorities of backlog items really don’t matter all that much in the end. Worse, agile makes it difficult to see if we are satisfying the objective or not, because the planning period is shorter. Not to mention, if you know the time you have in advance, you can actually do better job than the task requires. Doing the fastest possible thing is not always the best thing to do.

    3. The focus on customer and delivered features is creating a technical debt. The priorities of tasks and their order are driven by what customer wants, not by architectural needs. Imagine you would build house based on customer priorities:

    - #1 priority – shelter. You would build a roof on the ground.
    - #2 priority – so I wouldn’t sleep on dirt. So you would lift(?) the roof and put some concrete underneath.
    - #3 priority – I need some furniture to fit in here. So you would lift the roof again and build some walls.
    - #4 priority – maybe make it so I don’t need a candle when I am at home. So break holes into walls to make for windows and doors.
    - #5 priority – second leve. Oh s**t, we need the groundings!
    Etc. Sounds ridiculous? But that’s how it’s done, it’s agile..

    4. Related to previous point, sometimes the tasks touch the same modules, but priorities are different. Agile doesn’t take this into account and properly plan for this. In large legacy applications, like we work on, most overhead is actually in opening the old modules and understanding the existing code. When I work on it, it’s just worth to do a simple low priority task just because you already work on that piece. Agile won’t allow you to do that. It seems to really be better suited for applications written from scratch, where the architectural concerns come less into play.

    5. In our team, people are very specialized to various parts of code. Agile seems to assume everybody can do anything. Waterfall seems to plan for this much better, because you know in advance you just can’t split that one single expert.

    6. I personally like the waterfall better. For example, with waterfall, I have a rough idea how much time we have left, what kind of features are we delivering. It allows me to think about architecture and approach much better, in accordance with what others are doing. Often, there is a lot of synergy among features that we work on. It’s also less stressful. And timeboxing is pointless (if you want me to sprint, why are you stopping me all the time along the way?).

    There are really two sides to this. You can either ask programmers to make something in shortest possible time, like in Agile, or you can ask them to do their best in the given time, like in Waterfall. Guess which way will give you better result in the long run, with competent programmers? (The latter.) Agile is just a return to mediocrity.

    • Mark

      1. Disruption is sometimes necessary to implement change. The question is, is the disruption worth the change? It may not always be.

      2. The whole point of user stories is that you start from a business requirement and have some freedom in how to implement it technically – if that process is creating technical debt, then the problem is your process for choosing implementation routes, not scrum. And making something “better” is, in my experience, a quick route to failure: one man’s “better” is another man’s scope change. Deliver the requirements defined by the business, and if that leaves you time to spare, great, you can fit in some more stories (as defined by the business) to that iteration. The business defines “what” and “why”, the delivery team define “how”.

      3. Scrum (and Agile in general) never said “don’t plan”, they just emphasize that you should do enough planning based on current knowledge and requirements, and then plan again when either of those change. That tends to mean that technical spec documents go out the window, but don’t throw your common sense out with it. Don’t look at stories in complete isolation. Make sure you have a reasonable number of stories per sprint. Make sure the product owner gives you an idea of broad requirements up front (epics).

      4. This is simply the question of balancing short-term efficiency (let Bob own that bit of code, he already knows it) versus risk (oh no, Bob’s been hit by a bus!) and general agility (Bob’s busy with other stuff right now). There are pros and cons each side; you’re right in that agile methods tend to emphasis low risk/high agility (duh) over short term efficiency… the issue is that delivery teams by their nature will tend to lean towards short term efficiency, but project planners and the business in general are likely to favour low risk, more flexible approaches. If the business wants both, they need educating about the classic “triangle” (quick/good/cheap: pick any 2).

      5. See above. If your codebase is so complex that each bit of it requires a specific person to work on it, that in itself is an issue that the business should be aware of. There are ways you can broach that problem (decrease complexity, improve documentation [again, agile doesn't say "don't write stuff down"], increase testability, foster team learning etc) and some of them will impact short term delivery.

      6. As others have said, neither predictive (waterfall) nor adaptive (agile) approaches are inherently better than the other, but each suits projects and teams better dependency on circumstance. Predictive methods are easier to plan and, um, predict, but only if changes are (very) tightly controlled, the costs of up-front planning are not underestimated, and you recognise that complex systems cannot be reliably “predicted” 100% up-front. Adaptive methods cope with change very well, but make it hard to produce concrete plans with concrete feature sets and schedules. Choose the best tool for the job – it might well be a predictive tool.

      “You can either ask programmers to make something in shortest possible time, like in Agile, or you can ask them to do their best in the given time, like in Waterfall.”

      - That’s probably the worst description of either approach I’ve ever read.

      Agile stresses agility – responsiveness to change and uncertainty – and because of that can lead to shorter delivery times. But it does require a different mindset (as you have demonstrated, taking things literally does not fit well with agile methods) and can make high-level planning more difficult.

      Waterfall stresses predictability – we know exactly what is needed and can therefore plan exactly how to do it – and because of that can be easier to plan against. But it assumes a lot – namely, that it is possible to clearly document in a predictable timeframe all the requirements and implications of those requirements, and that it is possible to design a complex system in theory without significant omissions, mistakes or issues.

      History has shown that predictive approaches tend to lead to a very high failure rate (in terms of cost and quality), but it’s been the status quo for so long that many people have trouble thinking in different terms.

      Adaptive approaches (including Scrum), in my experience, don’t necessarily solve all the issues that software development teams face, but they often do a good job of making those issues more visible early in the process, which makes it possible to deal with them before they get out of hand. This is potentially a huge benefit, but is only the first step in improving delivery processes. One of the biggest issues some teams face in adopting such methods is thinking that getting early visibility of a problem (such as technical debt) with Scrum implies that such problems are caused by Scrum; predictive methods tend to hide such problems behind assumptions and theoretical planning.

      • JS

        “The whole point of user stories is that you start from a business
        requirement and have some freedom in how to implement it technically”
        I understand this is a theory of it, but I am not sure this is a good idea. In reality, how affects what can you build and how long it will take, i.e. the technical reasons influence the business reasons. So if SCRUM or Agile is built on assumption that flow of information is only way, it can’t work in the real world IMHO.

        “Scrum (and Agile in general) never said “don’t plan”, they just
        emphasize that you should do enough planning based on current knowledge
        and requirements”
        It really seems to me that you are doing the same thing with Waterfall. Proper research may include prototyping as well. This is just common sense.

        “you’re right in that agile methods tend to emphasis low risk/high agility (duh) over short term efficiency”
        I am not sure about that. If Bob is hit by bus, the methodology of choice won’t help you, because the change will force its way anyway. But I am really confused what you’re trying to say there. In general, I don’t see how planning over shorter timescales can help you.

        ” If your codebase is so complex that each bit of it requires a specific
        person to work on it, that in itself is an issue that the business
        should be aware of. ”
        But isn’t specialization also an advantage? And – to be cynical – the business knows, and doesn’t care.

        “Adaptive methods cope with change very well, but make it hard to produce
        concrete plans with concrete feature sets and schedules.”
        Unfortunately, as I already mentioned above, it’s business itself which wants to have concrete plans (to mitigate risk, actually). Change is risk.

        “That’s probably the worst description of either approach I’ve ever read.”
        Read what I wrote again. Under Agile, what you do is a given feature, and time needed is the free variable you’re trying to minimize. In waterfall, you have the global timeframe to deliver, and you’re maximizing features delivered (and their quality).

        “Agile stresses agility – responsiveness to change and uncertainty – and because of that can lead to shorter delivery times.”
        Actually, no. If you model change as a random process, you will see that you are often likely to change what you have previously changed, if you react to each change immediately. In fact, unless you’re building a significant portion of software from scratch, then in environment with change it’s cheaper to just implement the accumulated changes when you’re done. This is something that Agile advocates unfortunately overlook.

        “But it does require a different mindset” – as I said, I like waterfall better, because it better suits to how my mind thinks about problems.

        “But it assumes a lot – namely, that it is possible to clearly document
        in a predictable timeframe all the requirements and implications of
        those requirements”
        I am not sure that’s necessarily true. In waterfall, you can adapt to change as well, and it’s common sense to do so. That doesn’t mean the plans are worthless. I don’t see how the agile method makes you do less work, if change occurs.

        “History has shown that predictive approaches tend to lead to a very high failure rate”
        Compare to what? I would say jury is still out on Agile.

    • http://www.facebook.com/dan.johnson.75641297 Dan Johnson

      Great discussion! Just wanted to jump in here with an observation. The example I’m seeing above about building the house is really interesting in that it exposes a myth about software devleopment that is used as a false narative. To the point, have you never observed or built a house before and you didn’t realize that you would eventually have to suspend the roof above a floor with support beams? The example shows the use of short-sightedness and labels it ‘Agile” when, in fact, it’s poor programming practice or a lack of experience being demonstrated. I don’t mean that to be harsh, but sometimes I’m not sure if people are going for effect or if they mean literally what they say. I’ve seen the examples – ad nauseum – in every “Agile” book trying to teach ATDD where they build a line of code and the, oops, “let’s go back and correct that and add…”. All the while when I was reading the initial code example I kept thinking “they’re going to have to correct that”, and sure enough they did. You’re allowed to engage your brain and think ahead and plan. The only ones benefitting from this approach are the consultants that bill their time, and their second vacation home, on refactored code. Back to the larger discussion on Scrum, in my implementation of Agile I’ve always stressed that Agile was the approach one took when requirements were not stable, not known, or were known to change drastically and results needed to be proven ASAP. I never stress effeciency because that’s a human factor (as seen above), but it lends itself to it when all those involved are engaged to make it work. If you know exactly what you need to build and everyone associcated with the project knows it as well and there’s no need for constant communication throughout the project work – go with waterfall. I know companies that use waterfall very lucratively for one-off projects when the project is really a matter of configuration vs. coding. Again, think about it. Automatons are entertaining when Disney employs them, but it’s a frustrating way to live as a human.

      • JS

        But isn’t this “You’re allowed to engage your brain and think ahead and plan” just plain old waterfall in disguise?

        • Caleb holt

          part of the agile manifesto says
          “we believe in responding to change over following a plan” but at the bottom of the manifesto it says there is value in all of the things on the right. So it doesn’t say you can’t follow a plan, it just says we value the things on the left over the right. So responding to change is more important than following a plan. Which is where waterfall differs. But it’s always important to remember there is value in the things on the “right” as they say. Because if you say there is no importance in the things on the right you aren’t only going to fail, but you’ll not really be agile because that’s not what they say.

    • Anonymous Coward

      I think what you experience isn’t SCRUM. I’ve seen many (especially larger) companies introduce agile methods without really understanding what they’re about. The consequence was always just more bureaucracy.

      Agile methods are especially attractive to management to be applied this way because they make it possible to eliminate controls, and thus reduce responsibility. The fact that especially in larger corporate environments they are used this way can’t really be blamed on the methods.

      (This all coming from a strong opponent of agile methods – IMO they fit the bill only in about 20% of all SW dev contracts – only contracts where agility is in fact needed, while strong and formal controls on the delivery process from a business POV are not that much needed.)

      • JS

        Well, if they are misunderstood by corporations, then it’s a failure of Agile proponents to explain how it should work. I am not sure on the responsibility; I would rather say than shifted from management it’s getting more diluted.

        And I think you’re right – in our case, it’s the business itself that doesn’t want to be agile. I actually use agile for my own projects, where I don’t know if I will still work on them tomorrow. For open/hobby software, and for startups etc., and new software, I think it can be great. But it has downsides.

      • David Murphy

        Yes, you can see that mentality in the job ads. Project Manager contrcat job ads frequently require (in England) an Agile Project Manager, Prince 2 project method AND some variant of agile method. The PM is responsible for budget, reporting, control etc etc etc. And in large corporations frequently you are constrained by the dictates of a PMO and the need to blend with ITIL.

        Business and corporate IT are sold on the idea of cheaper quicker, without realising the potential consequences to their precious organisational structures. They also operate matrix structures where you have to predict your need for specialist resources – implying big up front planning down to task level months ahead.

    • Caleb holt

      A roof is not a deliverable, so your metaphor is already broken.

      But I also think that saying waterfall is better than agile is a false statement in that you are comparing apples to oranges, but rather than being a matter of opinion deciding which is better in this case it’s a use-case that decides which is better. If the rest of your company isn’t delivering when you are, then why worry about deliverables?

      I believe that developing agile also requires different development methods than waterfall so if you only adopt the agile methodologies there is also a greater concern on code being modular. When you have a changing industry with changing priorities you need a development model that reflects that, when you have a requirement like “build house” then you can probably design it up front and not worry about it changing on you.

      Saying agile is a return to mediocrity is just plain ignorant and wrong. Assuming that agile means make crappy software is insulting and bullshit. Agile leads to code that can change when the requirements change, much of software development is breaking new ground and gives the customer a chance to realize that he had a misunderstanding in what he really wanted, and when he does realize that it roots it out early on and gives the developers a chance to fix the problem and deliver something of better value to the customer. And also you are just plain wrong if you think that agile is write code and make it crappy but just focus on fast. Code quality is still a priority and if you don’t see that there is something you are missing from the methodology. Maybe you have a boss who heard about scrum, forced it on your team and that forced you in to an unfamiliar situation that causes you to do this. But in real agile teams that doesn’t happen.

      • JS

        “A roof is not a deliverable, so your metaphor is already broken.”
        Actually it is – the customer wanted shelter, so I delivered him a triangular roof sitting on the ground. It protects from elements and is the simplest thing I could build that worked.

        “..deciding which is better in this case it’s a
        use-case that decides which is better.”
        Well, explain that to suits who decide things in my company. The waterfall as we done it in the past was quite flexible, but it may have been because I just got a good manager.

        “if you only adopt the agile methodologies there is also a greater concern on code being modular”
        Which in reality means it’s not suitable for almost any legacy software out there.

        “Agile leads to code that can change when the requirements change”
        I am skeptical to this, because I don’t see why I wouldn’t want to code like that under waterfall (only would I know how! – to produce code that is easy to adapt to anything is a holy grail of SW engineering). Basically, your whole paragraph is nothing I can’t do under waterfall. My biggest gripe with agile is shortening of the time horizon you do your planning in (and focus on features, more about that in other replies), and I can’t see how doing that can lead to more quality. And if agile doesn’t do that, then it’s not different from waterfall.

        • Caleb holt

          A roof is not a deliverable in the sense that if a construction company gave their customer a roof they wouldn’t be happy while if I give my customers a smaller product that can still make them money they are happy.

          I almost completely agree with your 2 middle points.(But we all know there are exceptions). Mostly just reference my previous point that the rest of your company would have to be focused on deliverables for it to matter if you are.

          “Agile leads to code that can change when the requirements change” I do see that I wrote this down but I wasn’t thinking the word “code”. I think I meant something like this cartoon

          http://www.projectcartoon.com/cartoon/349868 I see the difference of Agile and Waterfall as possibly not noticing this misunderstanding of what the “customer really needed” until it’s too late. I’ve had experience with this and no longer had the problem in the cartoon when smaller changes were delivered.

          (The rest of the paragraph fits what I said… I don’t know how that sentence made it there, but that’s not really what I think or what I meant. Modularity can allow code to adapt to changes, but there is no reason waterfall can not have modular code.).

          Just to be clear, I’m not defending scrum, just agile. Also not attacking waterfall, just saying it’s a use-case thing.

        • David Murphy

          When I started as a project manager and we used waterfall, I always practiced it flexibly – we used prototyping, close user involvement throughout and made use of contingency in the budget to allow flexibility. I also ensured developers were involved in the planning and costing exercises and aimed to try and deliver parts of the system as we went along.

          The business frequently simply wanted a finished system, with a fixed budget and timescale, but of course requirements gathering soon showed they didn’t really know what they wanted.

  • JS

    I am a programmer in a large software company that transitioned from iterated/waterfall to SCRUM recently (by order from above). And I hate it, for different reasons than you though (but I am no expert, so I may be wrong on some counts):

    1. It indeed caused disruption. It’s like with IT in big organizations – the original processes won’t get replaced, only another processes are put on top of them.

    2. The finance and marketing etc. still think in terms of delivered features for the release cycle. So you have to commit to what you will deliver anyway. So the priorities of backlog items really don’t matter all that much in the end. Worse, agile makes it difficult to see if we are satisfying the objective or not, because the planning period is shorter. Not to mention, if you know the time you have in advance, you can actually do better job than the task requires. Doing the fastest possible thing is not always the best thing to do.

    3. The focus on customer and delivered features is creating a technical debt. The priorities of tasks and their order are driven by what customer wants, not by architectural needs. Imagine you would build house based on customer priorities:

    - #1 priority – shelter. You would build a roof on the ground.
    - #2 priority – so I wouldn’t sleep on dirt. So you would lift(?) the roof and put some concrete underneath.
    - #3 priority – I need some furniture to fit in here. So you would lift the roof again and build some walls.
    - #4 priority – maybe make it so I don’t need a candle when I am at home. So break holes into walls to make for windows and doors.
    - #5 priority – second leve. Oh s**t, we need the groundings!
    Etc. Sounds ridiculous? But that’s how it’s done, it’s agile..

    4. Related to previous point, sometimes the tasks touch the same modules, but priorities are different. Agile doesn’t take this into account and properly plan for this. In large legacy applications, like we work on, most overhead is actually in opening the old modules and understanding the existing code. When I work on it, it’s just worth to do a simple low priority task just because you already work on that piece. Agile won’t allow you to do that. It seems to really be better suited for applications written from scratch, where the architectural concerns come less into play.

    5. In our team, people are very specialized to various parts of code. Agile seems to assume everybody can do anything. Waterfall seems to plan for this much better, because you know in advance you just can’t split that one single expert.

    6. I personally like the waterfall better. For example, with waterfall, I have a rough idea how much time we have left, what kind of features are we delivering. It allows me to think about architecture and approach much better, in accordance with what others are doing. Often, there is a lot of synergy among features that we work on. It’s also less stressful. And timeboxing is pointless (if you want me to sprint, why are you stopping me all the time along the way?).

    There are really two sides to this. You can either ask programmers to make something in shortest possible time, like in Agile, or you can ask them to do their best in the given time, like in Waterfall. Guess which way will give you better result in the long run, with competent programmers? (The latter.) Agile is just a return to mediocrity.

  • http://gorodinski.com/ Lev Gorodinski

    This makes a lot of sense! I was programming long before being exposed to project management and development methodologies. My first substantial programming job was with a small startup where we didn’t adhere to any of those methodologies, although some on the team were informally aware of them. We just focused on delivering software and developed our own micro-methodologies based on need. When we grew, we brought in developers from more corporate backgrounds and they brought some methodology baggage with them. I was always confused about the “Agile” terminology because I thought the system wasn’t as “agile” as what we had before. Only when I understood what waterfall was did I understand agile. Ultimately, we selected the parts of agile/scrum that we liked but continued to employ our own approaches.

  • http://gorodinski.com/ Lev Gorodinski

    This makes a lot of sense! I was programming long before being exposed to project management and development methodologies. My first substantial programming job was with a small startup where we didn’t adhere to any of those methodologies, although some on the team were informally aware of them. We just focused on delivering software and developed our own micro-methodologies based on need. When we grew, we brought in developers from more corporate backgrounds and they brought some methodology baggage with them. I was always confused about the “Agile” terminology because I thought the system wasn’t as “agile” as what we had before. Only when I understood what waterfall was did I understand agile. Ultimately, we selected the parts of agile/scrum that we liked but continued to employ our own approaches.

  • Pingback: The problems with scrum | Smash Company

  • jdlinkin

    When scrumming, you’re cumming :)

  • jdlinkin

    When scrumming, you’re cumming :)

    • Joe Coder

      What does this even mean? I can’t tell if its good or bad. Are you saying that with Scrum you’ll enjoy giving the customer something prematurely that will likely leave a bad taste in their mouth?

      • Joe Coder

        Or possibly something they will regret months from now?

      • Joe Coder

        Or possibly something they will regret months from now?

    • Joe Coder

      What does this even mean? I can’t tell if its good or bad. Are you saying that with Scrum you’ll enjoy giving the customer something prematurely that will likely leave a bad taste in their mouth?

  • http://www.sandglaz.com/ Zaid Zawaideh

    I fully agree. I feel the whole way Scrum other “Agile” processes are enforced flies against the original Agile manifesto. We designed Sandglaz around the idea that people suck at planning and estimating how long their work is going to take, so why waste time doing that? We’re the only tool that fully embraces that and allows you to create fuzzy plans that follow you automatically.

  • http://www.sandglaz.com/ Zaid Zawaideh

    I fully agree. I feel the whole way Scrum other “Agile” processes are enforced flies against the original Agile manifesto. We designed Sandglaz around the idea that people suck at planning and estimating how long their work is going to take, so why waste time doing that? We’re the only tool that fully embraces that and allows you to create fuzzy plans that follow you automatically.

  • raph

    To me all these techniques are like religions. They all contain useful guidelines. As you say it very well, it is when you start following them ‘by the book’ that problems arrise.

  • raph

    To me all these techniques are like religions. They all contain useful guidelines. As you say it very well, it is when you start following them ‘by the book’ that problems arrise.

  • Timothy Myer

    Thanks for this very thought-provoking post. Having worked exclusively as a developer and coach on Scrum/XP teams for the last 5 years (and having tried to introduce XP practices to waterfall organizations for a few years before that), I can certainly understand some of your frustrations with Scrum, but a few of the points you make are still not exactly clear in my mind.

    Re point #1, a few commenters have commented on moving away from Scrum for Kanban. Scrum and Kanban are not necessarily mutually exclusive (see http://leansoftwareengineering.com/ksse/scrum-ban/). What in particular in Scrum prevented you from pulling more work from the backlog if you had completed all the stories that you had committed to before the end of the iteration boundary? I understand your point about work filling the space allotted, but was this issue ever brought up during pairing sessions (say, by navigators questioning drivers for going off track) or at the team level during retrospective? Were you still tracking velocity, even without iterations? How did dropping iterations affect your ability to predict and to do release planning? Did you try experimenting with different Sprint lengths (1 week, 1 day)?

    Re point #2, have you ever tallied up the exact percentage of how much time you were spending in meetings? What techniques did you use to make the Scrum meetings more efficient? I have voiced the same complaint about the expense of Scrum meetings on almost every team that I have been a part of. A very wise coach once tallied up the time for me on a whiteboard, though, and the numbers are pretty difficult to disagree with. This is the gist: we had a team of 6 devs (one was a part-time SM) and were working with 1-week sprints; we spent 1 hour/sprint in sprint planning, 1 hour/sprint in sprint review, 1/2 hour in retrospective and 10 minutes/day in daily planning. All those meetings took 8% of our total time at work and we spent the rest of our time directly developing customer-visible features. Compared to many companies where I have seen developers spending downwards of 20-40% of their time directly contributing customer-visible value (often because of ill-defined work that has been started and later needs to be changed or that is not high priority work and eventually gets dropped), 92% is not too shabby.
    As for “listening to discussion around stories [you weren't] developing on to begin with”, did you use a parking lot or yellow card in your planning meetings to prevent the meetings from losing focus or going off-track? Did discussions often go too far into implementation details and did you bring that up in retrospective? I would also be curious to see an example of a user story that you knew that you would not be developing on to begin with. To me, this often indicates a potential issue with the user stories themselves, or it indicates that individual team members have ownership over areas of code, and a well-run sprint planning meeting can make such problems visible; whereas in a system like Kanban without Scrum, attention might not be brought to such problems.

    Re point #3, I agree that “shoving Scrum down the organization’s throat” is never a good idea, whether it comes from the C-level or from the development team. An enterprise Scrum adoption is as much a cultural and mindset shift as it is a re-organization of teams, an adoption of a set of ceremonies and a new release cycle. One benefit to Scrum is that it provides a model for scaling across a large enterprise. How did dropping Scrum affect your coordination with other teams in your organization – e.g., did you find a need to replace the Scrum-of-Scrums or Metascrum with something else?

    Re point #4, I will also admit that some people end up seeing Scrum as an end in itself rather than as a means for delivering customer-visible value at regular intervals in a sustainable way. Do you have large information radiators with the Agile principles and values hanging in your office? What in particular in Scrum do you feel makes Scrum so inwardly focused rather than customer-focused? Is it the process or is it the people using the process? A quick story – I was coaching a blended hardware/software team in New Zealand a few months back and we were using daily sprints. My colleague and I stepped out for the afternoon and came back at the end of the day. We asked the Scrum-Master-in-training if he facilitated the retrospective that afternoon, and he said they did not have a retrospective. Then he added, we huddled as a team and voted as a team that we would rather spend the time finishing the work than doing a retrospective today. I felt really proud at that moment.

    • Todd Cantalupo

      Great counter points, Timothy.
      I’m curious about your SM in training that huddled with the team to decide not to have a retrospective “today”. Did the team have one the next day or did they skip it all together?
      I ask because I’ve seen teams vote not to have a retrospective … period. The result is that the teams rarely, if ever, spend any time on improving what they’re doing. Is that the case with this team or had they evolved to “ri” state?

      • Sheik Yerbouti

        Not to mention that *daily* sprints seem like a really bad idea in every situation I can imagine. What sort of work made this practical?

  • Timothy Myer

    Thanks for this very thought-provoking post. Having worked exclusively as a developer and coach on Scrum/XP teams for the last 5 years (and having tried to introduce XP practices to waterfall organizations for a few years before that), I can certainly understand some of your frustrations with Scrum, but a few of the points you make are still not exactly clear in my mind.

    Re point #1, a few commenters have commented on moving away from Scrum for Kanban. Scrum and Kanban are not necessarily mutually exclusive (see http://leansoftwareengineering.com/ksse/scrum-ban/). What in particular in Scrum prevented you from pulling more work from the backlog if you had completed all the stories that you had committed to before the end of the iteration boundary? I understand your point about work filling the space allotted, but was this issue ever brought up during pairing sessions (say, by navigators questioning drivers for going off track) or at the team level during retrospective? Were you still tracking velocity, even without iterations? How did dropping iterations affect your ability to predict and to do release planning? Did you try experimenting with different Sprint lengths (1 week, 1 day)?

    Re point #2, have you ever tallied up the exact percentage of how much time you were spending in meetings? What techniques did you use to make the Scrum meetings more efficient? I have voiced the same complaint about the expense of Scrum meetings on almost every team that I have been a part of. A very wise coach once tallied up the time for me on a whiteboard, though, and the numbers are pretty difficult to disagree with. This is the gist: we had a team of 6 devs (one was a part-time SM) and were working with 1-week sprints; we spent 1 hour/sprint in sprint planning, 1 hour/sprint in sprint review, 1/2 hour in retrospective and 10 minutes/day in daily planning. All those meetings took 8% of our total time at work and we spent the rest of our time directly developing customer-visible features. Compared to many companies where I have seen developers spending downwards of 20-40% of their time directly contributing customer-visible value (often because of ill-defined work that has been started and later needs to be changed or that is not high priority work and eventually gets dropped), 92% is not too shabby.
    As for “listening to discussion around stories [you weren't] developing on to begin with”, did you use a parking lot or yellow card in your planning meetings to prevent the meetings from losing focus or going off-track? Did discussions often go too far into implementation details and did you bring that up in retrospective? I would also be curious to see an example of a user story that you knew that you would not be developing on to begin with. To me, this often indicates a potential issue with the user stories themselves, or it indicates that individual team members have ownership over areas of code, and a well-run sprint planning meeting can make such problems visible; whereas in a system like Kanban without Scrum, attention might not be brought to such problems.

    Re point #3, I agree that “shoving Scrum down the organization’s throat” is never a good idea, whether it comes from the C-level or from the development team. An enterprise Scrum adoption is as much a cultural and mindset shift as it is a re-organization of teams, an adoption of a set of ceremonies and a new release cycle. One benefit to Scrum is that it provides a model for scaling across a large enterprise. How did dropping Scrum affect your coordination with other teams in your organization – e.g., did you find a need to replace the Scrum-of-Scrums or Metascrum with something else?

    Re point #4, I will also admit that some people end up seeing Scrum as an end in itself rather than as a means for delivering customer-visible value at regular intervals in a sustainable way. Do you have large information radiators with the Agile principles and values hanging in your office? What in particular in Scrum do you feel makes Scrum so inwardly focused rather than customer-focused? Is it the process or is it the people using the process? A quick story – I was coaching a blended hardware/software team in New Zealand a few months back and we were using daily sprints. My colleague and I stepped out for the afternoon and came back at the end of the day. We asked the Scrum-Master-in-training if he facilitated the retrospective that afternoon, and he said they did not have a retrospective. Then he added, we huddled as a team and voted as a team that we would rather spend the time finishing the work than doing a retrospective today. I felt really proud at that moment.

  • http://twitter.com/Mkelland Mkelland

    It’s funny – I completely agree with the article – but it’s a bit of an awakening. Our interpretation of what agile *should* be was very much founded on the concepts that you’re espousing. I always thought that timeboxing was a means to an end – you manage to get out of waterfall using timeboxing to gain trust within the team and ensure tight management and, once you have that trust, you move to a flow model which is far more agile than “Agile”. So we’ve been doing the flow model, using Trello as our backing system, for quite a while now, but calling it “modified Scrum”. I guess we were modifying it enough that it wasn’t Scrum anymore at all.

  • http://twitter.com/Mkelland Mkelland

    It’s funny – I completely agree with the article – but it’s a bit of an awakening. Our interpretation of what agile *should* be was very much founded on the concepts that you’re espousing. I always thought that timeboxing was a means to an end – you manage to get out of waterfall using timeboxing to gain trust within the team and ensure tight management and, once you have that trust, you move to a flow model which is far more agile than “Agile”. So we’ve been doing the flow model, using Trello as our backing system, for quite a while now, but calling it “modified Scrum”. I guess we were modifying it enough that it wasn’t Scrum anymore at all.

  • http://twitter.com/cromwellryan Ryan Cromwell

    Sounds like you’re in a good place. I don’t really think Scrum is at fault, but I don’t think anyone should use Scrum if they don’t need to control chaos or complexity.

    There isn’t anything inherently conflicting with pull/flow based systems and the Scrum framework. I work with teams that ship each feature when it’s done inside Scrum. They use iterations to create a forecast with the rest of the business.

    If you’re in any meeting and people aren’t getting anything out… stop the meeting. Kanban, Scrum, XP, Waterfall, ad-lib. That’s just silly. It is an odd part of human nature that we see guidance of Sprint Planning timebox is 4 or 8 hours and think they need to fill that time. If you’re ready to start in 20 minutes… go to town.

    I think the those in both the Scrum and Kanban world would agree both exist to put themselves out of a job. Those who don’t might be in it for the wrong reasons.

    • http://twitter.com/cromwellryan Ryan Cromwell

      Just so you don’t feel like this is unfounded, the creators of Scrum talk of this integration of continuous flow and Scrum often. Jeff Sutherland calls it Scrum-C. There is a trainer discussion board at Scrum.org in which this comes up a lot. Most organizations aren’t anywhere near continuous flow, so it just doesn’t come up as often as we hope. Some day…

    • http://www.facebook.com/victor.simson.1 Victor Simson

      Being an Agile approach, Scrum is highly flexible; that is, it can be stretched and bent to fit any project’s requirements. It is best suited for projects that require splitting a huge and an unplanned project into manageable chunks of work based on business priorities. As such, it can be used for any project system and by any team.

      http://scrumstudy.com/blog/?p=33

  • http://twitter.com/cromwellryan Ryan Cromwell

    Sounds like you’re in a good place. I don’t really think Scrum is at fault, but I don’t think anyone should use Scrum if they don’t need to control chaos or complexity.

    There isn’t anything inherently conflicting with pull/flow based systems and the Scrum framework. I work with teams that ship each feature when it’s done inside Scrum. They use iterations to create a forecast with the rest of the business.

    If you’re in any meeting and people aren’t getting anything out… stop the meeting. Kanban, Scrum, XP, Waterfall, ad-lib. That’s just silly. It is an odd part of human nature that we see guidance of Sprint Planning timebox is 4 or 8 hours and think they need to fill that time. If you’re ready to start in 20 minutes… go to town.

    I think the those in both the Scrum and Kanban world would agree both exist to put themselves out of a job. Those who don’t might be in it for the wrong reasons.

  • Joshua Chi

    #1 – Iterations are less …

    “explicit commitment” is based on estimation. And we all know estimation is difficult and we should not have “accurate” estimation. So we give relative estimation of our work by comparing with our previous sprints and past experience.
    So “explicit time-boxed iterations” would be translated to “relative/abstract time-boxed iterations”. This works because your commit a relative work rather than exact hours or works. And if you could let business owner or PO understand this, it is really helpful for the team and product.

    I can not agree with “delivered as fast as we could without iterations”. I think Scrum put people on an important place, rather than work itself.
    You can not work like this if your feature is really big and need a lot of cooperation.
    But I have to say this is works if your product is small.

    #2 – Ite…

    “Design was done with our architect and product owner. Estimation was done in concert with tech lead and architect” – what’s your team’s opinion?
    I will feel disappointed if I can not practice more. How about let everyone join these kind of discussion. If every team member can contribute some of their idea, they will more likely to work for their idea.

    • Anonymous

      I can not agree with “delivered as fast as we could without iterations”. I think Scrum put people on an important place, rather than work itself. You can not work like this if your feature is really big and need a lot of cooperation.
      But I have to say this is works if your product is small.

      This was in a 24-month project with sometimes up to 30 people involved in development, requirements, testing, planning, QA etc. And our numbers said we went faster without Scrum.

      What I also did not like about Scrum was explicit roles. Our roles at the end of the project were *much different* than what was started. I don’t see Scrum literature that says “in your retrospective, question whether a Scrum Master is a complete waste of time”

      Now, we did have success with it at the beginning, for sure. And I’ve had success with other teams, too. I’ve just had more success without it.

  • Joshua Chi

    #1 – Iterations are less …

    “explicit commitment” is based on estimation. And we all know estimation is difficult and we should not have “accurate” estimation. So we give relative estimation of our work by comparing with our previous sprints and past experience.
    So “explicit time-boxed iterations” would be translated to “relative/abstract time-boxed iterations”. This works because your commit a relative work rather than exact hours or works. And if you could let business owner or PO understand this, it is really helpful for the team and product.

    I can not agree with “delivered as fast as we could without iterations”. I think Scrum put people on an important place, rather than work itself.
    You can not work like this if your feature is really big and need a lot of cooperation.
    But I have to say this is works if your product is small.

    #2 – Ite…

    “Design was done with our architect and product owner. Estimation was done in concert with tech lead and architect” – what’s your team’s opinion?
    I will feel disappointed if I can not practice more. How about let everyone join these kind of discussion. If every team member can contribute some of their idea, they will more likely to work for their idea.

  • Anonymous

    1 – “Iterations are less efficient than pull-based approaches”
    Ok, so if pull based works, no one stops anyone from pulling more stories into the Sprint, if you are not motivated to do that then you have some problems that even Scrum can’t solve.

    #2 – “Iteration planning meetings were wasteful”
    Yeah, do an upfront design, that is very useful as history has taught us.

    “I remember just getting bored to tears listening to discussions around stories I wasn’t developing on to begin with.”

    Yeah just worry about your stories who cares what the project architecture or design will look like. Let a architect desisgn the system. 2 developers may write the same repetitive code because they didn’t talk to each other. Who cares, we will have tools to make the code DRY. But lets not waste time talking to each other.

    #3 – Scrum is highly disruptive in established organizations
    Yeah, continue to be inefficient, produce bad code, have more managers than developers but please don’t change anything.

    #4 – Focus not on delivery
    The entire goal of scrum is to produce deliverable software every sprint (2-4 weeks). If this is not delivery focus, I dont know what is?

    “Moving from yearly or semi-annual releases to weekly iterations is very, very hard. And very easy to fail at.”

    Excellent, status quo please, getting efficient is hard, we might fail, let us stick to inefficiency.

    BTW, I am not against Kanban, I am just against Waterfall. And your article kinda encourages people to go back to waterfall. Kanban works only if the team has a certain maturity level, move a team from waterfall to Kanban and they are sure to fail.

    • Anonymous

      - Ok, so if pull based works, no one stops anyone from pulling more stories into the Sprint, if you are not motivated to do that then you have some problems that even Scrum can’t solve.

      We did start with that, the thing we questioned is when we did this, there was literally zero meaning to an iteration any more. It was at most a weekly velocity meeting w/ the business. We had no “acceptance” as part of a sprint etc.

      Where I see teams go wrong with iterations is that those become commitment boundaries – leading to some really unhealthy behavior from teams. People gaming estimations and so on, I’ve seen it again and again in Scrum organizations.

      - Yeah, do an upfront design, that is very useful as history has taught us.
      It is useful. Big Design Up Front is not useful. Coming in to a meeting with some expectations on what a story is about is very helpful. Coming with nothing and expecting consensus in that meaning is not. Card and a conversation? We’ve totally ditched that. It doesn’t properly set expectations on what will actually be delivered.

      - Yeah, continue to be inefficient, produce bad code, have more managers than developers but please don’t change anything.

      Alternative is to shove a process down people’s throats? That is very risky and rarely works. I’ve seen it happen a half a dozen times, and Scrum is implemented, yet the organization is no better off. Start with culture, not with process.

      - The entire goal of scrum is to produce deliverable software every sprint (2-4 weeks). If this is not delivery focus, I dont know what is?

      Because if delivery was the goal, iterations would go away. In Scrum, iterations are the goal.

      • Anonymous

        Points well taken sir. We can debate on and on but the internet would not be the right place to do it :) . If you ever come down to India, we can talk this over coffee or beer.

      • Anonymous Coward

        I disagree with a few statements.

        Big design upfront can work, if both the problem domain and the solution domain are already well known to the team – which is often the case. Big detailed design upfront in the hope that it will survive implementation unchanged is an unrealistic expectation, but this doesn’t mean big design upfront isn’t useful. You do iterate on design, but you constantly know where you are with it, and are in a much better position to diagnose your technical debt, not just to be aware that it exists.

        In SCRUM, iterations are the means to achieve a constant velocity – to achieve some sort of predictability. When iterations become the goal, SCRUM was applied in a bad way. If you don’t have a need for tracing/monitoring velocity, SCRUM, or any iteration-based agile method, for that matter, is indeed of no use to you.

        • http://hammerproject.com/ matt kocaj

          BDUF can never work!

          If your team thinks they understand the “problem domain and the solution domain” well before the solution is built, then they’re kidding themselves. A good solution is never iteration #1 and a good design is never the first. This alone invalidates BDUF.

  • http://twitter.com/jpatil JP Patil

    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 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.

  • http://twitter.com/arnislapsa Arnis Lapsa

    I find it quite hilarious to participate in some kind of Scrum meeting, watching people with cs masters listening to process rules that 10 year old can comprehend in minutes and still struggling, being afraid, uncertain – all just because they can`t accept bit of chaos, are unable to act reactively. As I say it – doesn’t matter much what You know once You can adapt and learn shit fast enough.

    • rj

      For some software engineering problems, a little chaos is ok. When we are talking about a big messaging/communciations system, chaos will eat you alive due to rework. Please take reality into consideration.. there is no one-size-fits-all for software process.

      • http://twitter.com/arnislapsa Arnis Lapsa

        Software development is a fight against chaos. Software is direct reflection of what’s happening in our minds just like as music is a reflection of musician’s emotional state. Tricky part is that there’s a feedback loop that triggers once you stop **thinking** which throws you into abyss of more chaos. And since software brings order, more things can be automated – thinking devalues and getting into chaos abyss gets more and more inevitable. “there is no one-size-fits-all for software process” is indeed a way to go – but repeating this statement is already a contradiction to itself. I see Scrum as a tranquilizer that creates illusion of rapid thinking for those that are aware that they don’t – in some way that’s just giving up.

      • Henri

        This is so unfair … as Scrum coach I acknowledge the points in the article to a large extend (leaving scrum is an ultimate scrum evaluation), I like the post. The arguments in the last posts though are telling me to eat my meal within 10 minutes being food for a whole organisation. That for sure is NOT reality. Irrational reasoning to score points.

        Themes should not, never, be discussed in sprint planning that of cause lead to chaos. The lead engineer, architect or expert in the team should break it down to epics (as part of a release plan so marketing is involved) and then break it down to logical chucks that can be sprinted. If a story results in big chaos then first go back to the architecture, put the story at hand on hold and create an intermediate story to analyse impact of the total theme on architecture (not the details, but high level).

  • Pingback: Linkdump for September 13th | found drama

  • rjgood

    Very good assessment of the shortfalls of SCRUM. As with your approach, I also like to tailor a development process to the company/team/management. Never has a “out of the box” methodology worked in my experience.
    You have a great point of view for only 8 years of experience Jimmy. Keep it up!

  • Clay Anderson

    ScrumBut:
    Agile encourages flexibility
    Scrum is an Agile methodology
    Believers in “ScrumBut” discourage flexibility
    ==> CONTRADICTION <==

    I've seen Scrum work best when the rituals / ceremonies are viewed as just that. They are a nice way to establish and encourage a habbit. Instead of Scrum being "hard", I've seen Scrum lead to "complacency". After 8 months of 2-week iterations it gets difficult to keep the retrospectives productive (8 months means 16 retrospectives).

  • Rodrigo Silveira

    SCRUM, as described is indeed wasteful. On the other hand, I have developed a version of it where all the above described waste has been removed and, to boot, I use the pull to get “work” from the PRIORITIZED product backlog. In other words, if I can avoid, no more water fall for me!

  • http://twitter.com/simon_hardy Simon Hardy

    Can’t fault much of what you’ve said, except the commitment point. It’s a terminology issue but I’ve always found Scrum’s “Commitment” to be a commitment that the stories taken on will be all that is worked on during the sprint, not that every story will be finished.

    It’s a major difference, and is a main reason I see Scrum failing in the organisations I’ve been in. Where the correct definition is applied I’ve seen a world of difference and had great success with it. Where the incorrect definition is applied I’ve see perverse incentives take priority and teams undercommitting to not “fail”, which in terms has lead to longer running projects.

    • rj

      Have to agree with this. I work in an organization that requires full delivery of all stories every sprint, and puts tremendous pressure on everyone to do that. The point behind both lean and scrum is that you are properly and actively prioritizing your work on a frequent basis and delivering what you can given all the normal constraints on a business. When Scrum just becomes another whip to use on folks rather than an understanding of the complexities being dealt with, the organization suffers, just in a different process.

      And to all that might think I’m blaming Scrum, I’m not. Organizations managed in this way will do the same in waterfall.. its a people issue, not a process issue.

      I have some issues with the more ‘social engineering’ aspects of scrum (self organizing teams….).. but I’ve used the overall process effectvely over the last 8 years or so. If you are trying to deliver software to customer and keep them happy as the market is changing, you must have a process in place the allows you to adjust quickly. Lean/Scrum can help with that.

  • pling95

    I think this is a good insight. To me, two statements underpin this article: ”
    start with what you have, and work on improving that ” and ”
    Delivering is what matters. Process is merely the how. ”
    This points to Lean practices. Analyse what you have, identify waste and remove it. If you have a smart team and you involve them, they will come up with the processes that they need in order to deliver value.
    For all you know you will come up with Scrum, or Kanban, or a simple iterative framework, or something different but something that works for you nonetheless. It will be a gradual process driven by the people who use it. This is Lean. And this is what is most important.

  • bettyfjord

    As a dev with many years’ experience delivering and responding in very high-pressure environments, I still cannot believe how seriously this methodology stuff gets debated. Y’all clearly don’t have enough work to do.

    • Anonymous

      Best comment yet!

  • Pingback: Five Blogs – 14 September 2012 « 5blogs

  • http://twitter.com/lunivore Liz Keogh

    “Ultimately, our goal is to continually deliver success…” or to deliver any failure early, at least.

  • Quinn

    I transistioned to KanBan and XP Practices with our team about 3 years ago. The Flow and delivering value concepts are better in my opinion. Planning meetings are important but not the formal Scrum types…I agree…waste of time in my opinion. Planning and story writing should be quick, non-detailed, high level archtecture type event. Very ruff estimates like XXL, XL, L, M, S with XXL to XL being Epic to less than a day on the spectrum. Stories from that point on can flow into the backlog as needed with a short discussion with the Business owner and things flow with daily dev and system test builds and weekly ( over the weekend ) production builds.

  • http://blog.thecodewhisperer.com J. B. Rainsberger

    Yes, point #4 is objectively unfair. You’re describing “Scrum done wrong” and not Scrum. I get that: if enough people do the wrong thing, then the meaning of the term “Scrum” effectively changes. For this reason, I distinguish Scrum-as-designed from Scrum-as-practiced. Others might not care to distinguish.

    As for the rest, yes. As early as 2002 I remember people talking about iterations as a training concept with the goal of moving towards a continuous pull system for features. We used to tell each other how cool it will be the day that we no longer benefit from iterations. Still, I have my doubts about rank novices trying to jump from big bang delivery to pull systems for features. I admit that that’s merely a feeling and not based on any evidence. Perhaps that’s just based on the fact that I started learning about this stuff in 1999/2000 and not now when Kanban is so much cooler. :)

    Let me caution you: just because you no longer need the scaffolding now doesn’t mean that you never needed it. Iterations can play the role of scaffolding. They can help us develop discipline. Of course, they can become pointless status meetings, too, but people, not rules, did that.

    Thanks for these thoughts.

  • Pingback: Friday Links #220 | Blue Onion Software *

  • Pingback: Why I'm done with Scrum | Jimmy Bogard's Blog | Agile SE | Scoop.it

  • Pingback: Relaxing Scrum | ReStreaming

  • Pingback: Scrum’s Not the Solution for Everyone | JazzPractices

  • http://twitter.com/jaffamonkey Paul Littlebury

    That’s all well and good but how does that approach fit with business and client expectations? Don’t get me wrong, it is the right “Lean” way to go, but how are we going to translate that into a form palatable enough for the people who pay project bills? It was difficult enough getting business to get their heads round Agile concepts, beyond the sales pitch! When people are paying for something, they want fixed dates for deliveries – wouldn’t we all? Your view of Scrum doesn’t appear to account for that, which Scrum does. Scrum is far from perfect, but provided some kind of transition form palatable to both business and development. Scrum has had it’s day, but it’s very important to have a relevant successor (again, palatable to both business and development).

  • asdf

    Amen!

  • Pingback: Why I’m done with Scrum | Jimmy Bogard's Blog | DevOps in the Enterprise | Scoop.it

  • Jeff Sutherland

    Scrum is Lean Product Development. We have been meeting with the founders of the Lean Enterprise Institute and their IT expert has attended my Scrum training. They agree that what I am teaching is Lean Product Development and we are looking to work together both writing and publishing and looking for joint projects. Sounds like the Scrum you were in was not lean.

  • Pingback: Architecting the Process « Form Follows Function

  • balza

    I think Scrum is a good starting point, but is not enough. XP and Scrum are prescriptive, this means many rules and less self-discipline, so self-discipline and rules are inversely proportional. If you don’t have enough experience in Agile you don’t have developed enough self-discipline on the process, so you HAVE to adopt Scrum or XP, then when your company have run Agile for a while probably you have learned, and some questions rise, so you have to do the next step that should be called Lean (or learning?)

    • http://blog.thecodewhisperer.com J. B. Rainsberger

      XP helps people develop self-discipline through mindful practice, like many martial arts do. If you think that more rules means less self-discipline, ask anyone who has survived military bootcamp.

      • balza

        No, I’ve never done any military bootcamp, but, strange, I always belived that the main aspect in military bootcamp is discipline: only the commander knows the objectives, you obey to orders, you do anything to please your commander, the commander set the aims, the commander know the answers. There is no space for creativity or learning because you always have something to do. Where is self-discipline?

        • http://blog.thecodewhisperer.com J. B. Rainsberger

          I can only assume that you have a wildly different definition of “self-discipline” than I have.

          • balza

            What is your definition of “self-discipline”? Form me a synonym of “self-discipline” should be motivation

          • http://blog.thecodewhisperer.com J. B. Rainsberger

            @balza: Not for me. I use “motivation” to refer to the capacity to want to do something at all, whereas I use “self-discipline” to refer to the capacity to do a thing carefully or well or thoroughly even when one could get away with cutting corners.

            To me, motivation is about whether to do something, and self-discipline is about how well to do it.

  • Callum Anderson

    “When stories were ready, they were put on the board. When a developer was ready to develop, a quick meeting took place between the architect and developer on the story.”

    I would be interested to see if this led to information silos forming in the longer term? Surely the point of the planning meeting is that every developer knows what they are aiming for during the sprint. I could see this slipping into top down feature assignment quite easily.

    • Anonymous

      We thought it might too – but we had to balance this out against boredom. We’d try to get similar stories to similar developers for a bit, then switch things up to make sure that everyone got a chance to work with different parts of the system.

      What I forgot to mention was that for critical or new features that were really new concepts, we would do a quick team-wide huddle to get everyone up to speed. Wasn’t really a story review, but a concept review. But we made sure that only the people who needed to be at this meeting, were.

  • Pingback: Done with Scrum | blog.test-driving.de

  • Pingback: Scrum And Non-Scrum Interfaces « Bulldozer00's Blog

  • Pingback: Why I’m done with Scrum and switched to Lean | Active Risk Management | Scoop.it

  • Pingback: Why I’m done with Scrum & switched to LEAN | 23actions.com - Management Future | Scoop.it

  • Christian Duhard

    I am somewhat concerned with the .NET blogoshpere lately. We have folk like Jimmy, Ayende advocating that developers discard popular patterns and methodologies without proper context. I completely agree with the content of the article, but there is key information and context missing. Talented developers are capable of understanding the shortcomings of SCRUM and the Repository pattern. They bring all the best parts of those experiences to the next best way. There is a need address that hidden knowledge. Inexperienced developers still doing waterfall and using DataSets are going to have great difficulty knowing why SCRUM isn’t working, how to get to pull agile methodologies or how to use an ORM correctly.

  • Pingback: Why I’m done with Scrum | Jimmy Bogard's Blog | agile-development | Scoop.it

  • Jimmy

    To be honest, I can’t help but be slightly put off by this article. You have some positive things to say about Kanban which were interesting, but to be honest drawing a relationship between an implementation of Scrum at your company, which was debatably unsuccessful, and failings of the Scrum framework itself, appeals more to those that don’t know better, in a sensationalist manner, rather than encouraging intelligent debate.

    • jbogard

      I guess I wasn’t really interested in debating. Having done scrum for many companies over many years, I just stopped seeing the value in it. Or better – found things more valuable. I’m tired of doing it, tired of talking about it, just tired of it.

  • Dave M.

    To say that things are worthwhile only if they are easy seems like a copout.

  • Pingback: Hating on Agile goes Mainstream | Post Agilist

  • SJ

    Unfortunate. This is what happens when lazy and zealously text-book scrum masters fail to impart the true value of Agile *philosophies* to a change-resistant team; AND everyone forgets why they are there amidst the seemingly kitschy jargon and hokey machinations of the process. By the way – there is no right or wrong, but I suspect any Agile team experiencing something called a “Death March” was probably doing something very wrong much deeper than at a process level.

  • ec35

    If it looks like a fail, swims like a fail, and quacks like a fail, then it probably is a SCRUM.

    Since we have Kanban its fun to work again.

    I really dislike those Scrum-Ban folks who are desperately trying to move the parts of a fail to Kanban. Communication/meetings are important and shouldn’t be time-boxed at all. Everything has to take place ON DEMAND, not PLANNED. SCRUM is not agile, but formalized agility and thus a fail by definition.

  • disqus_wIzH7iPYfH

    Ahhhh yes, for those who never learned the dangers of scope creep. I guess it’s always a pendulum, isn’t it.

  • Pingback: Does agile work?

  • Kaiser Solver

    As we academics are fond of saying: show me the data. Quite simply, if a structured approach can be shown more effective than another approach in an appropriate domain, then probably it is a better approach.
    However, too much of this is treated as religion. Too much is ritual.
    Even where there is evidence, it needs to be evidence of the whole working in the appropriate context. Simply pointing at evidence that such and such component has been shown working in arbitrary context is not enough.

    It is also not enough to say that method a is better than x, if also method b and c and g have been shown better than x (and perhaps a). Best practice is best practice, not better practice.

    Certainly, the appropriate thing for an organisation to do, is to take benchmarks before implementing a new system, and then evaluate the new system. There’s something to be said for science.

    It’s all much too weak as it stands.

  • Olivia Jennifer

    It will definitely ease your work of handling a big
    project. As a project manager I use scrum in my projects. One of my friends
    referred me to use the Guide to Scrum Body of Knowledge by http://www.scrumstudy.com.
    I like the concepts of sprints, daily standup meetings, etc. the SBOK Helped me
    alot in Understanding how Agile
    Project Management
    works.

  • Olivia Jennifer

    People that are interested in SCRUM & Agile who want to grow their project management IQ, the website(http://www.scrumstudy.com) will provide you with resources, lessons, dealing with SCRUM ,sbok,free chapter test and many more.Agile Certification

  • Ella Mapple

    I really doubt whether its scrum falling
    short or adapting scrum the wrong way. A suggestion would be to invest on
    professional certifications. We use Scrum org wide for project management, and
    its working well compared to waterfall method. As part of company sponsored
    training, I also got my agile
    scrum certification
    ; Scrum
    Master Certification
    recently. The SBOK guide of Scrum will actually show how Scrum can be a
    very useful tool to keep organized and create better goals for your team.

  • me.too

    Start with Scrum. Learn the discipline. Move to flow if it seems appropriate. Agile is Agile.

    • jbogard

      Starting with scrum is very hard for most organizations I work with. Very disruptive. Better to start with what you’re currently doing, visualize what that process is, and relentlessly optimize.

  • KayZeeli

    My biggest concern is the application architecture. I think scrum/agile etc is good to bring in improvements to a system that is already built on a strong architectural foundations. However its bad idea to build a new product. Its difficult to argue for a strong foundation when everyone in the team start finding shortcuts to deliver “Customer epics”. ( and whats with the term epic? what’s wrong with the term requirement and/or objective.)