It’s time to cut the agile crap

Posted on October 19th, 2011 in Agile by siddharta || 14 Comments

via Geek and Poke

Agile is Bloated

I realised this the other day when, on a mailing list, someone asked about what the “Sprint Goal” was supposed to be. A reply came from someone else that they didn’t have a goal, but since “scrum mandates a goal”, they decided that their goal was “to implement stories”. Of course, this is a rather meaningless way to have a sprint goal.

So that got me thinking: Have agile processes become so complicated that they confuse the hell out of most people?

Take something simple, like user stories. Originally they were just little pieces of features to build.

Nowdays you’ll be told how user stories have to be from the user’s perspective. And they have to follow this “As.. I want.. So that” template. And that they have to be INVESTable. And oh, the stories have to be small. Like really small. Really, really tiny small. There is a whole industry around just making your story so small that it cant be cut any smaller. (PS: dont forget, vertical slicing only! Like a sashimi).

And you have to estimate them. There is a whole another industry around how to estimate these really, really, tiny small INVESTable stories. Using these things called ‘story points’. Y’know relative estimation and all that (psst.. relative complexity, not relative effort). But only with fibonacci numbers (they’re cool!). And overlapping probability distributions (also cool!). But be careful young padawan, because when it comes to tasks (which are SMART by the way), then you don’t use story points.

I could go on and on, but you get the picture. What a mess. And this is supposed to be a lightweight process? COCOMO is easier than this stuff (just kidding). I’m not surprised that most people fall into the pit of despair before they can get their Hello, World user story ready (see cartoon above).

How did we get here?

Just as we get anywhere: One step at a time. You see, people mess up. So we add a couple of rules. But they still mess up, so we add a few more. But they still mess up, so we add a few more. But they still mess up. And this time its because they cant comprehend all those rules that were put in.

Why do we have all these rules?

A fragile process requires a perfect environment and perfect execution. Without that, it will fail. Worse, it fails much more spectacularly than whatever was done before it.

A forgiving process process works in a variety of different environments and execution skills, perhaps with a range of results, from mild improvement to much more radical improvement.

Unfortunately, most of the attention has focused on fixing the environment and execution instead of making the process more forgiving. So, an agile transition goes

  1. Fix the organization
  2. Follow all the steps of the process

There are a whole bunch of people who will validate whether the organization is ‘ready’ for agile. It is the spherical cow syndrome again.

Today you need a PhD to understand agile. Woe betide you should you fail to understand the difference between a complicated system and a complex system. What?? You don’t know the difference? No wonder your agile team failed!

Agile really IS simple

When you really think about it, agile is pretty straightforward. There are only two concepts to it.

  1. Release a few features, get feedback, adjust accordingly
  2. Improve your collaboration and communication

Thats it!

All those things like iterations and user stories and fibonacci story point estimates are nice, but you can be perfectly agile without them too.

Start where you are

So your first release is three months long. You’re release cycles are  not of the same duration. You don’t use user stories. Your features take three weeks to deliver. You don’t do TDD. The team isn’t colocated.

That’s okay. The main thing is to delivering once a quarter or less, and incorporate the feedback. Then, see what you can do to improve collaboration.

Some of the agile folks are going to laugh at you and your ‘agility’. Just ignore them.

Yes, some of these things do help, but you don’t need everything at once right from the start. All these things are just practices. You can implement them if you want to, or skip them if you don’t, or implement them later if thats better. For what it’s worth, I’m no longer a fan of user stories.

Start where you are.

You collect requirements a certain way? Just do the same thing. Estimate a certain way? Continue that. Then add or replace pieces one by one as you hit roadblocks.

It’s not the most efficient way of doing things, but it is the most forgiving.

Somewhere along the way, the whole agile movement got derailed.

One set of folks went into researching how the organization could be fixed.

Another set went off into adding more and more rules so that people wouldn’t shoot themselves in the foot.

All this has just made things much more complex (or is that complicated :P ). And the more complex something is, the harder it is to get right. It’s a positive feedback cycle.

Back to Basics

All the jargon is unnecessary.

You dont need a PhD to understand this agile stuff.

Feedback. Collaboration. Thats it.

It’s time to cut the agile crap and go back to the basics.

Doing Distributed Agile?

Share and collaborate with distributed teams with our electronic agile board tools. Get all the benefits of electronic tools without sacrificing the benefits of physical boards. Supports Scrum taskboards, Kanban boards and user story maps. Check it out!

14 Responses to “It’s time to cut the agile crap”

  1. Chris R. Chapman Says:

    Good post; a few points:

    1) While I don’t disagree that we “got here” through incrementalism, the majority of environments where they are deployed can’t sustain them initially because they’re just not adapted to support the teams when they work iteratively. A secondary problem erupts due to the transparency of the process which has a habit of laying bare all the dysfunctions of the organization and its people. You need to adapt parts of both to make agile or lean work. Otherwise, you’re just cargo-culting.

    2) Understanding complexity theory doesn’t take a PhD, just a little common sense. There’s really sound reasons why using iterative/incremental practices with multiple inspect/adapt feedback loops works on wicked problems, and this understanding helps us explain to skeptics and business why they need to let go of the waterfall if they want a more productive team and better ROI.

    3) I think you’ll find yourself in simpatico with Schwaber & Sutherland who released a revised Scrum Guide in June that’s been distilled down to “just the rules”. There aren’t any burndown charts, chickens, pigs or points. It’s the three roles, three artifacts and five events.

    As Ken says “do what makes sense within the rules of Scrum”. Don’t be an autocrat.

    Scrum-On.

  2. siddharta Says:

    Thanks for your comments Chris.

    I would contend that if you are able to make frequent releases (around a quarter or less), then thats the core of agile and its not cargo culting, irrespective of how you get there.

    I also have some reservations on “they’re just not adapted to support the teams when they work iteratively”.

    That makes it sound like the teams want to work iteratively, but the management doesn’t. Management should see value in working iteratively first. Otherwise its putting the cart before the horse.

  3. Vin D'Amico Says:

    I think some of the complexity we’re seeing is the result of trying to get large enterprises to adopt agile practices. Command and control is so ingrained into big companies that they steer every approach toward it. T^hey won’t even consider an agile approach unless it can be controlled, measured and reported.

    We need to find ways to control, measure and report that are as simple as possible. Clearly, we’re not there yet.

  4. siddharta Says:

    Who says you can’t be agile in a command and control environment?

    Look at Amazon. The culture there is typical command and control – hierarchical, micromanaging, high pressure, highly political, lots of overtime. Yet it is also an amazingly agile and innovative organization.

    I’m skeptical that you must change the culture first, before you can be agile.

  5. Chris R. Chapman Says:

    You’re right: You can’t wave a magic wand and make an organization fully agile. It takes time, especially when the organization’s structures are not geared toward supporting it. Culture isn’t something you install off-the-shelf; it’s a summation of everything you do in your organization that makes you unique.

    In the same way that developers have had a misinterpretation of Royce’s single-pass/phased/gated delivery model put upon them for four decades, so too have managers had the scientific management models of Fredrick Winslow Taylor ingrained into them. While these practices brought good advances in the last century, they’re at odds with teams that work iteratively. I see it with all the transformations I’ve helped with – the agile team bumps up against every part of the organization with their JIT demands that need to go into large-batch queues in the organization.

    Ergo, management often “reads the agile brochure” without being fully aware of the implications it has for the entire organization. In my experience, this is happening at an increasing rate because of the “new flavour” traction agile is gaining with business in the wake of the PMI getting into the agile certification game. Canaries in the coalmine, IMHO.

  6. Raphael Says:

    absolutely right.

    Agile is going to be catastrophic for all those dogmatic enterprises because it will make even more evident their retarded process. At least PMI can hind all your crap and you can always say you did all by the book and exeem yourself.

    While people refuse to think about what they are doing, the consequeces of their actions and refuse to take responsibility this will continues.

  7. Blogreader Says:

    I reAlly don’t understand story points. To me they are just a proxy for hours, why beat arouind the bush and just use hours?
    I’ve been told it is a way to break down larger stories. Well hours do that as well. And that it can show velocity. Well it can’t as when you complete a cleanup of old crufty stuff to make new features easier then those new features story points will go down as they can be done quicker.
    What’s missing is a biz ROI on a feature. If you can show ROI/hours as going up that’s a good sign. Buoy that is hard to calculate.

  8. dennis Says:

    Good post. Agile is becoming more and more a dogmatic. We have to be able to say “the emperor has not clothes” when it is appropriate. And I think it is appropriate now.

  9. siddharta Says:

    I dont this it is about dogmatic as much as the some things are simply confusing, and unnecessarily so.

    Blogreader’s comment #7 above is a perfect example: story points.

    Only a handful of people actually understand story points properly. There are a *lot* of questions with story points. It is *extremely* confusing for beginners to use, and they invariably get into a right royal mess.

    Funnily enough, there is no consensus on story points, even among agile thought leaders.

    Yet, story point estimation is pushed hard in all training and by consultants as a holy grail, where it is positioned as an ‘innovative’ practice. People are taught that their usual estimation methods are completely outdated and if you want to be agile, then story point is the only way to go.

    This is quite false, unnecessary, and simply adds to the complexity for someone trying to get started.

  10. François SALAZAR Says:

    Hi,

    I agree and my position towards agility when my customers ask is : agility is a toolbox you can use once you are able to deliver. First, set up a working process to deliver, then and only then try to improve…
    Learning to improve is they key, if one thing must be achieve in an organization : this is ‘do it once, question yourself and improve’.

    Then, agile project means having an agile mindset at managers level and the ‘acceptation’ to leave autonomy to the subordinates… Sometimes this is the real roadblock on agility road. Managers want to control not only the goals bur the methods to achieve the goals and this is an error : “I want you to do this project with agile methods” is a nonsense from a manager … as in agility, people are free to choose and improve their way of working.

    Best regards

  11. Glenn Says:

    Yep, this is pretty much how any system fails, from governments to pop stars. It’s the baggage from trying to please all the people all the time that crushes the body. I think that all agile certification coaches should be strung up by the entrails of the high paid consultants who constantly call out for purity. Your project failed because you weren’t pure enough. Rubbish. It’s the Salem witch trials reloaded.

    Calling for a return to basic principles is the only path to sanity.

    You might also want to check out http://ccmbeta.dynamicalsoftware.com:8080/site/news/2011/choosing-the-right-pm-methodology-you-439131858.html because it describes various attitudes in the context of the phases of the Gartner Hype Cycle.

  12. siddharta Says:

    Thanks for the link Glenn.

  13. Jim Says:

    I don’t think I’ve seen more rigorous processes than those of scrum. Scrum hasn’t shown itself to be agile at all. It points a wrinkled finger at top down methodologies, incorrectly calling them “waterfall” processes. While scrum itself is imploding with non-agilisms.

    Let’s just take a shot at the basics of the Manifesto for Agile Software Development:
    1. Individuals and interactions over process and tools:
    a) Scrum seems to snowball with unnecessary process tools. Larger companies require you to become certified in these tools (Rally, JIRA, whatever).
    b) It’s rare to find a productive implementation of Scrum. Most are a mish mash of PM and story tracking tools that offer little interaction with your team.
    2. Working software over comprehensive documentation:
    a) Scrum seems to plummet from the sky here in larger organizations, where there are sometimes 70 people in a scrum, with 1 hour meetings every day.
    b) I think it’s interesting that Agile focuses on working software, and not a productive business environment. Who cares if you can generate a lot of software that nobody uses? I think we should focus on meaningful business solutions.
    4. Responding to change over following a plan:
    a) has anyone actually read this? If scrum does anything, it follows the plan like a tractor sprinkler follows a garden hose. God help you if you actually speak up about something in a sprint when you’re a chicken and not a pig…don’t get me started on that.
    b) How many sprints have you seen converted to MS Project and visa versa?

    I vote that any tool that requires you to become certified to follow its PROCESS, is probably an agile tool.

  14. siddharta Says:

    Absolutely agree. Agile processes often get way too complicated for something that is actually very simple.

Leave a Reply