Release-able vs. Demo-able

Last week, when I was at the Much Ado about Agile 2 conference in Vancouver, I had a conversation with Dan Rawsthorne. He said he wants to make sure his teams have demo-able software, not necessarily release-able.

Interesting. So what would have to be true for an agile team to have “just” demo-able software, not release-able?

  • If the entire team is large (think Scrum of Scrums) and the product has big features. Each smaller team can do their user stories, but they may not be able to totally integrate each user story with each other until enough user stories are done.
  • If there’s a hardware component and it’s not done yet.
  • I keep trying to think of a third reason, and I’m stuck 🙁 I bet you can help.

Even if at the end of an iteration, the product is “only” demo-able, that still means the team has integrated among themselves.

Thanks, Dan, for the jiggle.

8 Replies to “Release-able vs. Demo-able”

  1. depends on your definition of release…. but if your definition is deployable then any software which doesn’t meet a minimum features set to make the product worth while can have demonstratable bits but can’t be deployed eg, you’re writing CAD software and the only thing you have is the ability to draw lines. Releasing that to Architects is not going to go well. Demonstrating that will probably work well. It might be of great interest to an architect how two lines join together or something… it might not be useful to them at the moment but they will possibly have valuable feedback.

  2. One thing I notice when I go to classes (often with Dan as the instructor), is that folks get tripped up on the word “releasable.” So, coaches have often gone to “potentially releasable” or “demo-able” to describe the state that the features should be in so that the team can get credit for completing the story.

    Whether a team got a story done and whether a product is releasable at the end of each sprint can be two different things.

    I’m no Scrum coach, so I know Dan can provide a much more eloquent answer than I can but we talk a lot about something being “done, done, done.” Being “done, done, done” means that a story meets all of the criteria of the story and that the story is written in a way that really reflects “done” for the organization.

    As an example, I could say that I want a feature that is written, protected 100% by tests, integrated in some way with other pieces of the product, with complete user documentation, and maybe pair programmed or peer-reviewed in some way. And of course, I want to see it work in a demo 🙂

    So, when I think of done, that’s what I think of. But like I said, Dan would put it into writing in a much prettier way than I can.

    It’s such an important definition, “what is releasable?” And I’d love to see more discussion on it from different perspectives.

  3. One more idea: All of this “potentially releasable” or “demo-able” software is supposed to be no more than one sprint away from being releasable. Let’s say you’re five sprints in and the PO calls “we’re releasing what we have after next sprint.” That might be a dumb business decision because the product has limited features, but let’s just say…

    In one sprint, the team should be able to tie things together to create a releasable product, even if it has very limited functionality.

    The idea is to get something that works and has some business value, up and running ASAP. Something usable.

    I can imagine how you could have a bunch of piece-mail stuff that was “demo-able” but not “done, done, done” and you couldn’t pull it together for release in one sprint. So, I think that’s one more important part of the definition to think about.

  4. Johanna, thanks for the reference. Here are a couple more reasons something could be demo-able but not release-able.

    1. Your team lacks some ability to make it demo-able. For instance, you don’t have access to the lab to do stress testing, and the stress testing is done by your management / integration team when your piece is integrated with others.

    2. You aren’t actually finished. For example, you haven’t finished the documentation or training materials, and won’t do so until you get a bigger critical mass of “stuff.”

    Hope this helps… Dan 😉

  5. Typo Alert! In first paragraph, should say “Your team lacks some ability to make it release-able”, not “demo-able” sorry about that… Dan ;-(

  6. I good friend of mine, Michael James, reminded me that language is fickle and easily misunderstood, so I need to clarify…
    I think Katie has is right.
    In the same way that “release-able” implies “fit for use” to some, the word “demo-able” implies “just a shell, not real” to others. So, to clarify: what I mean is “demonstrably done”, where “done” means that the story met its agreed-to “doneness criteria” or, to put it another way, the story is “done-done-done”.
    Nothing gets demoed unless it’s “done”, that’s one of the first rules. And it’s also true that whatever you get done needs to be demo-able; that is, you need to be able to show that it is “done”.
    Enough said, I hope…

    Dan 😉

  7. I’m looking at this from a business development perspective and here are some things that can stop a release but without with demos can work fine

    1. performance – system optimised for 1 user versus 1000 for instance

    2. not all medium severity bugs fixed. if you are doing the demo you stay away from areas which aren’t ready for release or if it’s an online thing, simply disable some links

    3. data – in our case our app is a webapp which contains lots of data. you can demo it with a subset of the data, but you wouldn’t release it that way

    To look at it another way (the way i prefer!) what has to be complete in order to give a demo?

    1. front end design complete and tested

    2. at least one (preferably several) use cases paths complete so that you can tell the story with the demo

    3. clear understanding of when the release will be (needs to be accurate or you will rightly be accused of over promising)

    4. supporting material – this is the marketing materials and helps give some background to the reasons why you have built the software

    that’s basically it

Leave a Reply