The power of open-ended requirements

David Barnholdt and I recently attended a 1-week PSL workshop (Problem Solving Leadership) with Jerry Weinberg, Esther Derby, and Johanna Rothman, one of the best courses I’ve ever attended. After that course we’ve been thinking about ways to make our own training courses more interactive.

David was first out and invented a brilliant exercise demonstrating the power of open-ended requirements. I built upon that idea and tried out my own variant for the first time last week, with 20 people divided into 4 teams. Here’s what we did:

Step 1 – follow open-ended spec:
Team 1 & 2 were given the task "Draw a summer meadow", Team 3 & 4 the task "Draw a christmas card". The teams were given direct access to the customer (me & Arne, my co-teacher). When they showed prototypes and asked for detailed requirements we were cooperative but gave only high-level answers such as "I want the picture to make me long for summer" or "Some more life would be nice", letting the teams figure out the implementation.

Step 2 – write detailed spec:
The teams were now asked to write a detailed specification for their picture, so that offshore teams could re-create the same exact picture as closely as possible. Due to "bandwidth cost restrictions" we only allowed written text in the specification :o)

Step 3 – follow detailed spec:
Send the spec to the "offshore team" – i.e. team 1 & 3 swapped specifications with each other, and team 2 & 4 did likewise. No communication between the teams. So now each team had to try to recreate the other team’s exact picture using only an overly detailed spec ("draw a 2.5cm wide blue cloud 2 cm under the top-left corner"….etc)

Step 4 – art gallery
All pictures up on the wall. Each person got to grade each picture (draw 1-5 dots on it) indicating which pictures they would most like to take home.

Step 5 – debrief
Not surprisingly, in 3 of 4 cases the "offshore team" pictures from step 3 were significantly uglier. See the examples below. We talked about open-ended specs vs detailed specs, and how this can impact the overall quality of the product. We also talked about how each of the first three steps felt like. Several people mentioned that they recognized the feeling (and result) from real projects they’d been in.

My conclusion:
Fun exercise! The debrief part was a bit too rushed and controlled from my part, I should have been more open-ended there (go figure…). And I might work on the timings. But everyone I talked to liked the exercise, and people referred back to it several times during the course, so I will most likely do this again!

Thanks again David :o)

So, here’s one of the examples. Guess which picture below was drawn to en open-ended spec and which was drawn to a detailed spec…

12 responses on “The power of open-ended requirements

  1. My critique to these exercises is that the open ended requirements works best not because they are open ended, but because the implementors knew what the end product was supposed to look like anyway, despite the open endedness of the requirements.

    Unfortunately, the same is not true for the normal kind of software we write. It may be true for something exceptionally concrete, like “Build me a web application with which I can create and manage todo-items”. We all kind of sort of know what needs to be done, but if the application is much more complex, perhaps on the bleeding edge of what has ever been created ever by anyone, open ended requirements may be just disaster.

    I’m not saying it HAS to mean disaster, just that your exercise does not prove much, as far as I can tell.

  2. True, all simulations and exercises are limited.

    One thing the exercise does illustrate though is that it is more important to continuously help the team learn the purpose of the final product (how it will be used and how it should feel) and get them in direct contact with the customer, rather than to constrain the team to a perfectly detailed specification.

    Usually this will you get a better product, with less time spent and more fun while building it.

  3. I think the opposite of Mats.

    If it is bleeding edge or something not familiar, no one knows what to make of it. So a detailed specification would just be stupid since everyone is in the dark.

    If it is familiar, a detailed specification may kill creativity and miss the opportunity to come up with a new approach to a familiar problem.

  4. So, if the domain is similar, then open-ended requirements works best, and if it is bleeding edge, then open-ended requirements also works best?!

    Is it always the case, that even if the product owner has thought about the desired functionality in detail, he should just leave it out, since it would “hamper the creativity” of the implementors?

    The product owner may be the world expert in the area, and the team might consist of newly graduated engineers. If you take Henriks and Davids experiments at heart, the product owner should just skip the details, and get out of the way?

  5. The lesson, to me, is not in the result produced so much as in the behavior of the team. There is a powerful motivational difference between enabling a team to contribute creatively, and giving them detailed instructions to follow mechanically.

    I see this pattern consistently when delegating work, whether it is software design or management.

    Delegating effectively means letting go of your preconceived notions of how the task should be done, and freeing the delegate to think creatively about how to achieve the goal.

    The teams with less specific requirements usually produced a better result, not because open-ended specifications produce better results, but because people working creatively produce better results.

  6. That explanation makes much more sense.

    To me, the summer meadow experiment is dangerously deceptive, since everyone knows what such an image should look like. To convince me about the whole thing, a much less obvious example must be used.

  7. Excellent! One of my big takeaways from learning from Jerry, Esther and Johanna has been the power of experiential workshops. Although my CSM has always been heavy on experiential exericises, I’ve learned to spend significantly more time on debriefs – which are really rewarding.

    By the way – Citerus is hoping to arrange the PSL once again next year. We’re maintaining an interest list for those who consider coming.

    Finally: do as Henrik will – go to the AYE conference with Jerry et al in November, in Phoenix!

  8. Henrik, I too used David´s exercise in a recent class. The purpose was to discuss the detail of the test case specifications we create. Is it really essential to have much detail or can it actually be an obstacle? The point is, I think, that SOME requirements and SOME test cases can/need to be defined in detail. But for a lot (most?) of them the amount of detail is counter-productive. I have in many requiremnet analysis workshops asked the question – is this the exact way you want this problem solved? The answer I get is often that ” Well we though we needed to write this much detail, but it does not really matter exactly how you solve it as long as it works!” This is often the case with use cases and I feel the same way about test specifications. So my reflection is: think about it twice if you really need it, before you create really detailed specifications. Open ended test cases in the form of charters have proved to be much more efficient and find lots of bugs, many of them that would never be found with regular scripted test cases.

  9. There’s a huge limitation in this experience in only allowing the teams to “Swap specifications” and not letting them “talk about the specifications”. When you lose face-to-face or voice-to-voice communication you lose quality of work, regardless of how detailed your specifications are.

    One motto I have is, if the document is not worth reviewing and talking about, it’s probably not worth creating in the first place. (This sets aside some documents I create only for myself, with the value being the analysis the creation of the document supports.) We need to be agile in our documentation, creating just enough to create high-quality, efficient work for everyone involved.


  10. Yeah, that’s one of the things that the exercise illustrates. In fact, in the latest version of the exercise I told each team to create a tourist brochure about their country. Then when they wrote the spec I told them it would be sent to an offshore team in China. Then when they swapped specs I told them “you are now the offshore team in China, pretend that you know nothing about the country that is being described in the picture – just follow the spec”. The results were very interesting :o)

    It tied very well into the following discussion on user stories and how important it is to have an ongoing dialog about the requirements rather than try to capture every little detail in a written spec.

  11. I agree with both of you. I think that a mix of both kind of specifications would be good. The programmers needs to know the main purpose as well as detailed information. I believe it therefore is very valuable when programmers get to meet the end-users or intended end-users. Then a sense of understanding to how the product/system is to be used can be obtained, that is difficult to get through any kind of specification. I think it is very good for programmers to actually once see how an application is used in real life. I find it very odd and interesting that this happens so seldom. During my 12 years of programming I have only once or twice met the real end user. This seem to seldom be prioritized by the client.

Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.