One of the most common responses to problems and failures in implementing agile practices is "you're just not doing it right." I've heard it from many, many coaches, and I'm ashamed to admit that I've said it myself. While "you're just not doing it right" is probably true, it's also not helpful. For the past year, the question I've been asking myself is: "Is it actually possible to 'do it right' in most organizations?

A little bit of background on what started my crisis of faith: One day, a little over a year ago, a question was brought for discussion at our company's agile guild meeting: "Is agile right for all types of development work? It seems like some work simply can't be broken down into 2 week pieces." Of course in 15+ years of using agile practices and 9 or so years as an agile coach, it's a question I've heard many times. Obviously, no one process is completely right for all situations, and the people who ask this question already know that -- they're usually just looking for an opening to tell you why Scrum is no good for them. I could have repeated the easy to find information about when to use Scrum or other agile practices and when not to, but instead I decided to see what others had to say on the subject -- so I did what every good coach would do: I googled it.

I found Michael O'Church's 2015 article about the evils of agile, and especially Scrum, and thus began my crisis. Mr. O'Church's article was somewhat unique in its passionate hatred of Scrum, but that's not what made me question everything I believed. The real kicker was this: it had 777 comments (at the time of my initial read of the article in mid-2016; it now has over 1300). And by my rough count, over half of them agreed with everything in the article.

It was a real eye opener to see how much the article's premise that Scrum was actually damaging to companies resonated with so many people, and how most of those who thought Scrum was a good thing had nothing to offer other than "what you're writing about isn't Scrum" (I agree, it isn't) and "your company wasn't doing it right" (right again, they weren't). But apparently hundreds of other companies aren't doing it right.

We've gotten really good at telling people that they aren't doing it right, but we still aren't all that great at telling people how to do it right. Most of the advice I've seen (and frankly given) fails to take into account the complexities of organizational culture and history, and the long entrenched fears, behaviours and motivations of the people who work in an often volatile industry.

In this session, I want to explore what stops companies from being able to do it right, and what can realistically be done to help an organization move closer to being able to "do it right". We spend too much time "trying harder". In this session, I want to come up with ways to "try different".


Outline/Structure of the Workshop

  1. Introduction - who am I, and why the crisis of faith
  2. Is it truly possible to be agile? (A story of cockroaches, lights and cans of Raid)
  3. Requirements for true agility (discussion/brainstorming). I want people to dig deep here to figure out what is preventing their organization from having real success with agile methods. This goes beyond the implementation of specific practices -- we want to get to the root of why success eludes us, in spite of having smart, motivated people working on these issues.
    1. What are the prerequisites for real agility?
    2. How many of us meet these prerequisites?
    3. How much does "all-in" vs. "pick and choose" impact success?
    4. Is some agility better than no agility?
    5. When is it time to pack up your tent and go home?
  4. How can we get closer to "doing it right"? Identify the top 2 or 3 barriers, and look for ways to "try different" to make progress towards breaking down those barriers.
    1. What are the top barriers to success (poll/voting)
    2. What can we do to make progress towards breaking down those barriers? What have we already tried? Why didn't it work? What else could we try (keeping in mind "try different" vs. "try harder")
  5. Closing/next steps
    1. One thing we'll do differently tomorrow
    2. What's next? Keep in touch, build a community, part ways?

Learning Outcome

Participants (including myself) should leave the session with at least one idea they can try in their organization to make progress towards removing one of their major barriers to agility.

Target Audience

Coaches, managers, leaders, Scrum Masters, team members, skeptics. Anyone who wants to talk about the real barriers to agility, anyone who had experienced examples of "doing it right" that they can share, and anyone who is questioning whether agility is r

Prerequisites for Attendees

It would be helpful (although not required) if participants have read Michael O'Church's 2015 article: Why "Agile" and especially Scrum are terrible, and browsed through some of the comments.

Participants should come prepared to share what they believe stops their organization from "doing it right", and/or to share what they've done that's enabled them to "do it right".

schedule Submitted 3 years ago

  • Melanie Paquette

    Melanie Paquette - Accidental Agility: A tale of unintentional agile practices in a non-profit organization

    30 Mins
    Experience Report

    This summer I had the opportunity to participate on the board of directors for a market in a small community in rural Ottawa. The amount of work required to organize a regularly occurring market is staggering. We were entirely staffed by volunteers with varying skills sets, work experience, age, and availability. Within the first few weeks of the market season, I realized that we were actually operating in an agile fashion - by accident! This talk will explore how a diverse group of people, most with no software development background, organically adopted agile practices in planning and running this community market. We'll also take a look at how some of the lessons learned could be applied in other contexts.