What’s the first thing you tell someone about Agile?

I had lunch with a friend the other day, and he asked me about Agile. I didn’t know what to say.

Let’s call my friend a sales manager, working at a company that makes book-checkout software for school libraries. In addition to his main job, he provides the only testing the software gets, and he does it in his “free time”. (So, as he says, the software ends up getting tested by the clients.)

The friend tells me that when they make a change to the software, other things break. And that the programmers always document their changes in the code, so that people know what they were thinking, but they can’t prevent weird things from breaking each time. And when something breaks, the programmer says “Ok! I fixed it!” and they ship, only to discover that the fix broke something else.

Here’s what I told him…

It really looks to me like an Agile approach leads to software that is solid, maintainable, extensible. Test-driven design helps by making it *hard* to introduce bugs. Pair programming also helps with this, but if I try to explain that, this email will be pages and pages. :)

Anyway, it takes time to get old software to have that kind of… uh… agility, strong flexibility, but it can begin to happen right away, because every change you make to the software includes these “unit tests”. And the parts you change are the parts that most need to be cleaned up. They get cleaner, and the software breaks less often. Or in smaller, more manageable ways.

But I wanted to be able to tell him more. What you would say to a friend in this situation? I don’t mean if you were invited to come in an pitch a big Agilifying contract, exactly. But if you were having lunch, and he asked you how Agile is different.

What did I leave out?

7 thoughts on “What’s the first thing you tell someone about Agile?

  1. Sean McMillan

    Actually, your first two sentences look pretty good to me. When discussing agile with people, it’s often good to focus n what their problems are and techniques to improve them. The agile bag of tricks contains a lot of those techniques.

    For this topic, agile is two things — One is the agile values, and the other is the agile practices. The values drive the practices, but people in a burning building don’t want to be told they shouldn’t smoke in bed, they just want to get to safety. It’s a lot easier to discuss the agile practices than the agile values, but the values are what drive the whole thing.

    I don’t want to “sell agile,” but it’s easy to misunderstand advice like “focus on the (customer’s) problem,” when talking about agile as some kind of “I don’t know what’s wrong with you, but I know what will fix it.” People with problems want to hear about solutions to those problems, not about balanced methodologies that answer a host of common problems in software development, or about values. So even those those are more important, they need to be discussed later.

    (Rant Redacted… I was going to complain about the Scrum+XP = Agile here, but it wouldn’t really help.)

    1. Angela Post author

      Well, not sure it wouldn’t help… do you mean the practices vs. philosophy thing? Or these particular practices being called Agile?

      I was thinking about that as I wrote it. But I didn’t have clarity around why I shouldn’t say that what I want to offer him is “Agile”. Do you have something to tell me about that?

      I intended them as examples of what could make a difference. But maybe what you’re objecting to is actually the thing in the back of my mind that’s had me all ranty today, tweeting things like this:

      Agile is not “new, improved ways to get your code-monkeys to work harder.” Thank you.

      and this:

      Agile is also not “increasing profits by making coders test first or else.”

      1. Sean McMillan

        it’s fine to give advice, but it’s very hard (for me, at least,) to explain the big picture of agile while giving concrete advice. When you explain the values, many of the common practices fall out of them easily. But if you explain the practices, extrapolating the values is more difficult. And the conversation gets really tangled if you move up and down the spectrum of values-common practices-specific recommendations.

        It wouldn’t help for me to go on my rant about how one popular agile methodology (scrum+some xp) is getting just called “agile” these days, leading confusion among people who don’t know about other methodologies. That would just be distracting from the point here. (as if I haven’t done that enough… OK, since I’m here, Scrum, XP, Crystal Clear, Adaptive Software Development, and Feature Driven Development were all considered “lightwieght methodologies” before the term agile was adopted. Compare Fowler’s Original “New Methodolgy” article to the revised version to see some differences. )

        Rolling back to the actual topic, the first thing I do when telling someone about agile is to try and help them with their problems, using tools that I’ve learned from agile. Once the fire is out, then I’ll talk to them about the bigger picture.

        1. Angela Post author

          P.S. I think you’re right, and I just conflate XP+Scrummyness with Agile. Feel free to broaden my horizons as the urge strikes you. :)

  2. Sean McMillan

    It might be worth discussing high-level test automation, as every automated test is one that’s actually checking against regressions. However, this only works if the team buys in to the value of the tests. If the coders don’t care when they break a test because “tests are QA’s job,” then they won’t provide value, only makework.

    Talking about “free time” tells me the project is probably under time pressure. Which probably comes from a sloppy scope. If that’s the case, the whole suite of simple design + refactoring + planning game + onsite customer + acceptance tests can beat back the pressure and get scope under control, while improving delivery. That is, assuming that my guess is correct.

    Everyone conflates XP+Scrum with Agile. It’s an epidemic. Unfortunately, many of the other methodologies are out-of-print or have no good reference materials anymore. :-(

  3. Pingback: Episode 40 – Tice is the Reason I Drink (TDD, Pairing and Mobbing )

Leave a Reply to Angela Cancel reply

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

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>