Alistair Cockburn

Re: Using APEs to clear ANTs from your mind

Hi Alistair,

This sounds a little like Cognitive Behavioural Therapy where unhelpful thoughts (ANTs) are challenged and replaced with more positive alternate views (APEs). CBT seeks to uncover and disempower negative core beliefs that generate negative thinking habits. These harmful thoughts can lead to defensive or reassurance seeking behaviour that limit the person. By providing more realistic core beliefs one can transform a downward spiral of negative thinking into an upward soaring of self actualisation.

Good luck and thanks.

-by Duncan Green on 12/12/2011 at 12:59 PM

thank you, Duncan, I’ll have to look into that … for me, I am not replacing any views with any other views, I’m just cleaning the picnic cloth of my mind from ants (really) :). so I’ll have to peek at CBT next. cheers, Alistair.

-by Alistair on 12/13/2011 at 10:25 PM

Dr., I an intrigued by the ease at which you transcend between humanity and software enginrering as an integrated science. Humans create software and in this example I enjoyed the way you programmed your mind with what the other gentleman referred to as cognitive behavioral therapy.

Your APE mind program approach highlights humanity’s next feat the application of software engineering to the human mind.

Anthropology in software engineering is a very fascinating topic.

-by Pablo Beck on 8/16/2014 at 11:41 AM

Hi, Pablo, thank you, that is very kind. Indeed, in 1996 I gave a small panel position statement What can OO programming learn from anthropology? (discussion: Re: What can OO programming learn from anthropology?); and later hired an ethnographer to follow me around on a job to watch everybody. In 1997 I did another little panel thing with Software design and anthropology. So, in short, yes, I think software people can learn a lot by partnering up with anthropologists. ... The little thing with ANTs and APEs is just trying to sleep better at night : ). Alistair.

-by Alistair on 8/16/2014 at 1:55 PM

Elephant carpaccio

see also: Elephant Carpaccio Exercise (discussion: Re: Elephant Carpaccio exercise)

Trying once and yet again to describe the relationship of use cases and agile development, I found myself using carpaccio as a reference.

Carpaccio is beef sliced so thinly you can almost see through it.

Agile developers apply micro-, even nano-incremental development in their work. By this I mean that they take on a request for incremental end-user-visible functionality that takes anywhere from 15 minutes to a few hours or a day to implement. In developing this web site, it typically took us 15-30 minutes to implement each new piece of functionality.

That’s not because we’re so fast we can development 100 times as fast as other people, but rather, we have trained ourselves to ask for end-user-visible functionality 100 times smaller than most other people.

This is carpaccio of the functionality.

User stories describe these this thin slices very well.

The process runs in reverse of the culinary carpaccio. In culinary carpaccio, we start with an animal (OK, you vegetarians might be making zuccini carpaccio), slice it into bits and serve it. In programming, we start with an idea of an animal, describe it, and have the programmers produce it in reality.

Suppose now that someone has in mind an elephant.

They start with the tail, mentally slicing off and describing behavior-carpaccio for the programmers to implement. We are about to face two questions:

  • What will happen to the morale of the group when they finish the tail and suddenly hit the body?
  • How do we ensure that what comes out the production process is really an elephant (or whatever animal the sponsor had in mind)?

Life seemed so easy for a while – the slices were thin and easy to produce. Then one day the size, shape, texture, suddenly changed. Everything got more difficult. Working on elephant-body-sized carpaccio slices is much more daunting. Velocity goes down, morale goes down, etc.

The envisioned product always had a size and a shape. User stories don’t convey either. Therefore, use something else to convey them. Jeff Patton uses “story mapping” to convey that, but that is the only other thing I know of that comes close to doing the job beside use cases.

Produce an elephant

What will assure that an elephant will come out the other end?

In XP, the “customer” is declared to be omniscient.

Ask the customer anything and he or she will answer with an answer that is carpaccio thin and guaranteed to fit the rest of the carpaccio slices to produce an accurate elephant.

However, very few real people have that capability. We need something else.

Use cases have a shape and a size – they describe the size and shape of the elephant, so that each carpaccio slice can be set at its correct place in the elephant. The use case gives the programmers context, so they can ensure the piece fits its adjacent pieces, and the testers can check that it does.

Use cases don’t slice very well into carpaccio – user stories do that.

Moral: learn to write 1-2-page use cases to describe the size and shape of the elephant, so you can slice it into carpaccio for development; learn to write micro- user stories from the use cases so your agile developers can work in micro-increments.

(see also Laminating not slicing (discussion: Re: Laminating not slicing))

Manager or Leader?

Many people have tried to articulate what the difference is between a “leader” and a “manager”. Most of them trivialize or insult the manager, so I don’t care for them.
(see also Quotes on leadership (discussion: Re: Quotes on leadership) has this lovely graphic:

Starting a list of “Bad Leader / Good Manager”, just to reverse the usual sin of comparing bad managers to good leaders. (These are not matched pairs)

Bad Leader Good Manager waffles (doesn’t look like ne knows where ne’s going listens thinks he/she is in charge knows the differences of the ppl on the team, draws on each person’s strengths, mitigates their weaknesses. Fails to inspire, doesn’t share a vision that others subscribe to (or completely lacks vision), lack of ability to empathize (not sympathize – leaders need to know how their followers feel so those feelings can be harnessed). They also lack a sense of purpose, of drive/determination Feeds the team (resources, affirmations, encouragement, etc). Protects the team from shit. Understands the big picture and can translate it into tactical actions effectively. They understand the world that their team operates within and knows how to effectively move within that world. They can also tell when something is wrong with the team before it becomes obvious, and they also keep an eye out for disruptions that will negatively affect the team.

Hoin and Regine
“The Soul at Work” p. 287+

Here is an example of honoring the manager properly:

  • “Managers are cultivators. They don’t manage people; in fact, they rely heavily on people managing themselves.
  • ... They connect people to each other to create new pathways and fluid communication
  • ... They replenish people by creating the opportunities for participation.
  • ... focused their efforts and attention on inclusive diversity, openness, fertilizing connections, and holding the space
  • … holds the space by making it a safe space for expressing opinions and ideas.
  • ... Cultivators hold the emotional space ”

Aubrey Daniels
Bringing out the best in people by Aubrey Daniels (discussion: Re: Bringing out the best in people by Aubrey Daniels)

  • “Planning and delivering reinforcement are the two most important behaviors of supervisors”

Sanjiv Augustine
Managing Agile Projects

did a very good job of separating the two in his book. I don’t have the book here so I can’t quote the good bits, but he has the separation laid out in almost every chapter. Recommended book.

Seth Godin

“Leadership is about creating change that you believe in.” (p. 14)
“Management is about manipulating resources to get a known job done.” (p.13)

from TED 2009

  1. create space in another person’s mind for a future
  2. create space in another person’s life for action
  3. frame what actions are positive
  4. surround yourself with able leaders w management ability
  5. direct, then do
  6. promise to show up for the journey, and to repeat these steps

NASA “Project Leadership Forum”
2009.06.26 … Spoke at the NASA “Project Leadership Forum” in D.C. hosted by the NASA Academy of Program/Project and Engineering Leadership. A couple of key phrases about leadership showed up there (more when the videos of the talks get posted somewhere).

Alexander Laufer

to “lead” already implies “change”. So a leader leads a change. (Somehow this thought had escaped my notice – had it escaped yours? It hit me pretty hard in the lecture.)

If the leader in question is the PM, the person is leading a change in order to stabilize things (we can lead in order to increase stability). (This thought knocked my socks off.) ... and then the PM can “manage” the stable ongoing situation.

Rolling it up to the shortest (and probably least comprehensible) phrasing:

The PM leads in order to manage.

Terry Little (former Executive Director of the Missile Defense Agency, if I have his bio right):

A former Director of Acquisitions in the GAO (General Accounting Office) said, “I argued for fewer heroes and better processes … but now I think we need to find more heroes.” (commenting there on the shortcomings of processes compared to key individuals (see :) ((n.b. I have that quote a little wrong, but you get the idea, see also Glen Alleman note, below)
Leaders deal with barriers ruthlessly
Leaders have a bias for action
A leader declares him/herself accountable for an outcome … and demands the team be equally accountable

aside – Glen Alleman, not about leadership but too good not to add, told me that at his company, when something goes wrong and they do a review, they always ask at the end,

“Could our process, properly followed, have detected this situation?”

I love that question, wish more groups would ask it.

“Resistance: Moving beyond the barriers to change”
(2009.07.02) p. 9-10:

“Resistance to change climbs fast when people can’t figure out where they’re headed. ...
“A goal gives hope – a good antidote to fear …
Make your change goals easy to see, and identify an end point that makes the struggle of change worthwhile.”

Donald Phillips
“The Clinton Charisma”

p.95. ”... convince others that a certain undertaking is worthwhile, and to motivate them to take action on their own initiaitve.”
p 95 conversation and storytelling as tools. Clinton: “One of the president’s most important jobs is to consistently explain to the American people what we’re doing and why”
p 105. vision and hope. “the feeling of expectation that hope brings is grounds for people in the organization to believe t something good is going to result frm their own individual efforts.” ... Clinton continually preached and reaffirmed his vision – whereve he went, to whomeever he met, and by whatever means necessary.”

Timothy Clark
“The Leadership Test”

Leadership is influence & accountability, putting stewardship ahead of self-interest.

he adds, “influencing volunteers”, highlighting that they can leave at any instant. He adds 5 elements in his test: Pack your pack, Share the stage, Take the Oath, Sign your name, Pour your cup. More or less means, Carry your share of the load, share accolades with others, promise to operate with honesty and integrity, take accountability, pass it along & help others).

(p.s., beautiful little quote:

“The great paradox of life is that pouring your cup fills it ups. The more you pour, the more it’s filled. This is the other get-rich theory of life. This is where you find your greatest joys and deepest satisfactions…”

Mojo Marshall Goldsmith

p 130

leaders are optimistic about other people’s futures

Mort Meyerson (CEO of Perot Industries)
_” quoted by Margaret Wheatley in blank">

“the first task of a leader is to make sure the organization knows itself.”

“Authentic Leadership Conference”

their poster highlighted 3 interesting things:

  • Strengthen Beliefs
  • Expand Vision
  • Encourage Trust

Chris Crane (TED 2009)
“The Leadership Test”

  • - look to create a dynasty of leaders
  • - Chris: hire only A players – they hire AB players; B players hire BC players
  • - Hire well, then only retain the correct ones (fire earlier rather than later)
  • - leader must direct others;

Ken Mulligan

What would a person do at this point who didn’t have your limitations?

William Deresiewicz
Solitude and Leadership

Appropo leadership, he writes the negation: “was obeyed, yet he inspired neither love nor fear, nor even respect. He inspired uneasiness. Not mistrust—just uneasiness. no genius for organizing, initiative, or for order learning, no intelligence.”

Invert those to get the properties desired:

  • loved/feared,
  • respected,
  • obeyed,
  • generates an easiness,
  • organizing,
  • initiative,
  • order,
  • learning,
  • intelligence.

Good starter list, great article / lecture.

Werner Erhard, Michael Jensen, Steve Zaffron, Kari Granger
Introductory Reading For Being a Leader and The Effective Exercise of Leadership: An Ontological/Phenomenological Model

FAIR USE: You may redistribute this document freely, but please do not post the electronic file on the web. We welcome web links to this document at:
We revise our papers regularly, and providing this link to the original ensures that readers will receive the most recent version. Thank you, Werner Erhard, Michael C. Jensen, Steve Zaffron, Kari Granger
Introductory Reading For Being a Leader and The Effective Exercise of Leadership: An Ontological/Phenomenological Model Harvard Business School Negotiation, Organizations and Markets Research Papers HARVARD NOM RESEARCH PAPER NO. 09-022 BARBADOS GROUP WORKING PAPER NO. 08-01 SIMON SCHOOL OF BUSINESS WORKING PAPER NO. 08-02 WERNER ERHARD MICHAEL C. JENSEN STEVE ZAFFRON KARI L. GRANGER

These are notes to myself, extracts of key paragraphs. People who have not been through the Landmark Education sequence may not understand the turn of phrasing used; nonetheless may be interesting for others. Goes without saying (meaning: I have to say it): read the original document and its links, etc.

  • Leadership is defined as an exercise in language that results in the realization of a future that wasn’t going to happen anyway, which future fulfills (or contributes to fulfilling) the concerns of the relevant parties, including critically those who granted the leadership (those who lead you, and those you lead).
  • Being a leader is defined as, committed to realizing a future that wasn’t going to happen anyway that fulfills the concerns of the relevant parties, and with the availability of an unlimited opportunity set for being and action, being the kind of clearing for leader and leadership that shapes the way the circumstances you are dealing with occur for you such that your naturally correlated way of being and acting is one of being a leader and exercising leadership effectively.
  • Leader and leadership create leader and leadership as realms of possibility in which when you are being a leader all possible ways of being are available to you, and when you are exercising leadership all possible actions are available to you. Mastering leader and leadership as realms of possibility leaves you free to be and free to act, rather than being constrained by common notions about what it is to be a leader and what it is to exercise leadership effectively. When one’s focus is on fulfilling a commitment rather than acting in a particular style, all ways of being and acting are available, and are often required to “get something done”.
  • Leader and leadership exist in the sphere of language, whether that be literally speaking, or speaking in the form of writing, or speaking and listening to yourself, that is, thinking, or the speaking of your actions, as in “actions speak louder than words”, or in providing what we distinguish as authentic listening. When you see someone being a leader or exercising leadership, or when you have experienced being led, you see someone functioning in the sphere of language. And, more pointedly when you are being a leader and exercising leadership you will be functioning in the sphere of language. (Remember that sometimes actions speak louder than words.)
  • Leader and leadership exist in the domain of a created future, a future that fulfills the concerns of the relevant parties, that the leader and those being led come to live into, which future gives them being and action in the present consistent with realizing that future.

or even shorter:

  • Realizing a future that wasn’t going to happen anyway,
  • which future gives being and action in the present,
  • being the kind of clearing that shapes the way the circumstances you are dealing with occur for you such that your naturally correlated way of being and acting is effective.

Peter Levini

key phrases:

  1. “Self-awareness. If you can’t accept self-awareness, you should not be CEO.”
  2. “What are you trying to accomplish? What’s the end game?”
  3. “Translate energy to the areas you are least comfortable understanding.”

Mark McKergow

  • Create spaces – and are active in them
  • Use the ‘soft power’ of invitation
  • Have Response-ability (Balancing defining the event AND responding to what happens)
  • Use Co-participation (Balancing providing for everyone AND joining in alongside everyone else)
  • Ensure Gate-opening (Balancing defending boundaries AND making new connections)
  • Spend time front stage, on the balcony and back stage

W.C.H. Prentice
“Understanding Leadership”, in HBR book “The Mind of the Leader”

  • understanding of his fellow workers and the realtionship of their individual goals to the group goal
  • each player must also want to carry it out … the problem of every leader is to create these wants and to find ways to channel exising wants into effective cooperation
  • The one who leads us effeccively must seem to undertand our goals and purposes. must seem to be in a position to satisfy them; must seem to underand the implications of his own actions; must seem to be consistent and clear in his decisions.
  • an effective leader will be aware of the need to balace dependence with indeendence, constraint with autonomy… recognize that many peole are frightened by complete independence

“What Makes a Leader?”, in HBR book “The Mind of the Leader”

  • they are driven to achieve beyond expectations

Abraham Zaleznik
“Managers and Leaders”, in HBR book “The Mind of the Leader”

  • Managers tend to view work as an enabling process invoving some combination of people and ideas interacting to establish strategies and make decisions
  • one often hears leaders referredto with adjectives rich in emotinoal content. Leaders attract strong feelings of identiy and difference or of love and hate.

Chris Matts, Pollyanna Pixton, Niel Nickolaisen


  • On the hiring side, we found that brainteasers are a complete waste of time. How many golf balls can you fit into an airplane? How many gas stations in Manhattan? A complete waste of time. They don’t predict anything. They serve primarily to make the interviewer feel smart.
  • On the leadership side, we’ve found that leadership is a more ambiguous and amorphous set of characteristics than the work we did on the attributes of good management, which are more of a checklist and actionable.
  • We found that, for leaders, it’s important that people know you are consistent and fair in how you think about making decisions and that there’s an element of predictability. If a leader is consistent, people on their teams experience tremendous freedom, because then they know that within certain parameters, they can do whatever they want. If your manager is all over the place, you’re never going to know what you can do, and you’re going to experience it as very restrictive.

Disney Institute on Leadership
c/o Mike Cottmeyer

  • Leaders must establish, operationalize and sustain the values and vision by which their organizations thrive.


  • - AC: breathe life into an idea
  • - AC: don’t lead, just show up and do
  • - AC: lead = create a space in others’ minds (inspire, advertise)
  • - AC: leader must be willing to stick around for the whole trip … ?and willing to organize and direct?
  • - AC: directing others is to retain credibility
  • - AC: during times of no change, a leader generates in others a priority, a sense of worth, about keeping in the same direction, keeping the direction fresh. (The leader keeps the rhythm of the drums beating the direction.)
  • - AC: a leader reaches into the heart and mind, indicates a direction; a manager arranges actions of people
  • - AC: saying “manager” already implies that a goal exists; saying “leader” already implies the person is creating or directing attention to a (possibly forgotten) goal.

following up a little discussion on FB: My latest reading gave me this thought: “saying “manager” already implies that a goal exists; saying “leader” already implies the person is creating or directing attention to a (possibly forgotten) goal.” In this sense, both views are possible: one could convene a group of people to identify a direction, and then manage to that direction. However, when we say that someone is a leader, we don’t imply that they were appointed, but rather that they have an ability to reach inside the hearts and minds of other people and create desire to pursue a direction. .... and after that, then this person is still called a leader if he/she does something specific with the group afterwards.

Large scale agile is a phase change

“I have this frozen swimming pool.
I want you to make it behave like a bathtub full of cold water.”

Phase change: “A phase of a thermodynamic system and the states of matter have uniform physical properties … During a phase transition of a given medium certain properties of the medium change, often discontinuously,”

We start from small-scale agile, everything is very fluid, easy. We make rules for adjusting our working with small environmental variations: war room, adjacent offices, cube farms …

(You know this analogy is going to break very quickly, don’t you?)

There are roughly speaking, “uniform physical properties” across these situations.

However, ice doesn’t behave at all like water. It’s solid. It hurts when you fall on it. It floats, oddly enough.

The point is, it is so different you can’t call it “water”. You call it “ice”. You can call it “frozen water”, but by saying so, you mean “not water”, so very different than saying “warm water”, which means, “still water”.

Large-scale agile doesn’t have the same properties as small-scale agile does. You can call it “large-scale agile”, but that’s like trying to get away with calling an ice cube “really cold water”.

I don’t have time to keep going. An appointment, sorry.

You know the analogy of water/ice will break.
But the metaphoric use of phase change might not.
Large-scale agile just has properties that are too different.

Dadaguil: The flea that thought it drove the elephant

In Colocated and distributed agile are different beasts (discussion: Re: Colocated and distributed agile are different beasts) I introduced the word “dadaguil” for distributed agile to indicate it is so different from collocated agile as to need a totally different word. I may have unleashed a monster. With this note, I want to put a leash on that monster. Doubt it will work, but here goes….

In the early 2000s, Jim Highsmith used a slide I loved, showing a flea on top of an elephant, pretending to drive it. The flea says, “Turn left!” and eventually the elephant turn left. The flea says, “I am in control!”.

Jim used that slide to describe project managers who thought they were in control of the project that was successful. I use it for that and every other time someone says they made a project successful, with implication they can do it again.

Projects are so complex, with so many people involved (not to mention external events), that you can’t, because you have about as much control over the behavior of all the other people on the project and the external events as the flea has control over the elephant.

(related aside: I delight in collecting conflicting project management strategies to show just how different the winning strategies are, from project to project, as in Advancedpmstrategies1-180.ppt. To be “in control of success”, you have to first pick the correct one of the conflicting strategies, then you enter the arena of the flea driving the elephant.)

Dadaguil projects are so much more difficult because the people sit in different places (by definition). You, as a person, are only in one place. If you use remote media, then your communication is diluted in just the way that makes dadaguil projects so difficult to begin with. And you are only one person in the network of everybody influencing everybody.

So now, having coined the term Dadaguil to mean “something very different from collocated agile”, I already see people saying, “I am good at that.” and “I want to be certified at that.”

But that is like a flea who once thought it drove an elephant to teach other fleas to pretend they are driving elephants, when they are just sitting on top, getting taken wherever the elephant takes them. And giving them certificates to show other fleas that they can truly drive elephants.

Maybe I should ask Jim if I can use that slide to make certificates, “Certified Flea Thinking It Can Drive An Elephant.”

Re: Colocated and distributed agile are different beasts

This is great clarification for many folks new to agile. Particularly because those who are often attempting distributed agile are “told to” by their leadership—who has declared that their teams be agile without understanding what needs to happen to support that cause.

Not only are they stuck trying to learn agile, but they are setup in the most challenging organization with (for example) developers in Asia-Pacific areas, testers in Europe and product owners/managers in the U.S.! On top of that geographic challenge teams are trying to understand “what is agile?” and keep their job by delivering value regularly.

Very frequently, no one in Leadership has set the stage for the internal or external customer that progress will be slower before it is faster and that learning a new way of working will require EVERYONE to have patience until values AND practices are understood, learned and then mastered.

-by Adam Beck on 8/10/2014 at 4:18 PM

Well spoken Dr Cockburn!

Now, how do I become a CDM*?

*Certified Dadaguil Master

-by Henrik Kniberg on 8/10/2014 at 4:28 PM

Henrik, you know how to scare me.

Hi Aliatair –
This is something that concerns me much these days and you’ve summed it up well. There is some barrier between knowing experientially and knowing intellectually, and that is the core here. In my own work (as many of us do) I have collaborators I see regularly in person and some far away. There is no question which works better, no matter what tooling.

Thanks for articulating it well.

-by Nancy Van Schooenderwoert, @vanschoo on 8/10/2014 at 5:52 PM

Excellent article Alistair, well described … I am with Henrik except I want be a CCM – Certified Colagile Master :)

-by Tony Ponton on 8/11/2014 at 2:04 AM

Tony, Henrik: I may have unleashed a monster with that dadaguil thing. Now people will claim they’re good at it, which imho is roughly impossible for reasons that maybe belong in another blog post. hmmm, how to leash this monster….

Colocated and distributed agile are different beasts

Recent Change Note: Trying to correct the link to your book.

“Agile” is a value center, not a pile of practices. Still, when I think of “agile” development, I think colocated. Distributed agile development is, for me, a different beast. So for just this moment, I will give them different names: colagile, dadaguil

(I pronounce it “da-da-gueel”, no reference to the dadaist art movement of the 1910s).

For me, colagile involves people looking at each others’ faces, feeling their mood, overhearing relevant (and some irrelevant) snippets of conversation, forming a group that breathes as a single community.

Dadaguil makes it not only much harder, does not multiply the difficulty of accomplishing that, it exponentiates the difficulty of accomplishing that.

Important note: Please do not infer from this that dadaguil is not agile: agile is a value center. So the question would be phrased: Given this group of people in their respective locations, would you prefer to use or abandon the agile values? (answer: Use). And then: How would you set up the project to best make use of that value center? (answer: The usual, look it up online).

Dadaguil is much harder because of the difficulty in achieving the information transfer, the mood transfer, the trust transfer that comes naturally with colocation.

Yves Hanoulle is writing a small article describing the difference and difficulty of building and maintaining trust amongst a distributed team (link goes here). Read that and take it as given.

Colagile is the natural form for agile teams to operate. Little more needs be said; read Crystal Clear ( ) to learn more about this natural form.

Now, then, what must be done to make dadaguil work?

All the usual stuff:

  • Get the team colocated at the beginning and periodically thereafter, to get that form of trust that only face-to-face can give.
  • Use microphones and video links so teams are “always on, always there”; “presence & awareness” is the term from the CSCW community (computer-supported collaborative work).
  • Use good automation to get a single shared repository of design information.
  • Work in small slices, so work gets completed and visible.
  • Pay super-, ultra-, extra-, superlative attention to the mood, trust, communication, sensation of co-working inside the team.
  • Add more ideas, techniques and practices beyond those to reduce the barriers to serendipidous discovery, lower barriers of fear, increase trust, visibility and success.

All the usual stuff, just on steroids. Not cheap, not easy, not natural. Doable, with great cost. You can maybe do it. It’s just a different beast.

Postscript: Large-scale agile is also a different beast for similar reasons. I think it probably needs a different name, too, possibly one without even the “agil” in it.

Re: Elephant Carpaccio exercise

Alistair – seems like a great exercise but I’m finding the explanations around #2 less than I need to fully understand your analogies and digest the exercise enough that I could reproduce it. Any more links? Perhaps an annotated example of a team’s process and output may help?


-by Mick Maguire on 2/12/2010 at 11:44 AM

Hi, Mark,

er, sorry, I just posted the exercise itself for those who want to carry it back to their company after doing it. Probably is necessary to go through it oneself to comprehend.

On the other hand, I do wonder what would happen if you got some people together and read the Elephant carpaccio (discussion: Re: Elephant carpaccio) and Trim the Tail (discussion: Re: Trim the Tail) articles as a group, then just did the exercise as described, then discussed.

If you do this, please let me know what happens,


-by Alistair on 2/12/2010 at 12:21 PM

Alistair,you are truly online with your presentations.
Keep up the good work.

-by sesta on 12/14/2010 at 4:50 PM

Thank you, sesta :). Glad to know it’s valuable. Alistair.

-by Alistair on 12/15/2010 at 1:57 PM

I found this exercise simply and useful, so I tried to add some variations in order to solve some issues I found during sessions I facilitated.

You can find those variations searching for Elephant Carpaccio V2 onto Medium or Linkedin.

The original recipe should be preferred because of its simplicity, but in some cases variations worked fine.

-by mregazzi on 7/30/2014 at 11:16 AM

I am unstable, precarious

I am unstable, precarious
ly balancing gales
that change by hour, by minute.

I watch others, stable & strong,
but unable to adapt.

They tell me (the women) that I should be simple,
stable, like those others.
Easier to relate to.
Not complex.

If only I knew how. But stop balancing for just a moment, and I crash.
So on I wobble, precarious.

And this makes me dangerous:
Unstable, I change direction in an instant.
Used to gale forces, I keep going in the same direction, no matter how hard you push on me.
Yours is only a breeze in the gales.

181:© Alistair Cockburn 2014

Time enough for love.jpg

Recent Change Note: What Heinlein might have used for the cover pic for his novel, "Time Enough for Love".

Energy matters

Doesn’t even matter.

Matter is energy.
What matters draws pushes pulls
causes gives energy.
Energy matters.

So it matters.


I matter.
I am energy
That matters
To someone.


`180:© 2014 Alistair Cockburn / / being )

Re: Video of Carpaccio exercise

The video is blocked. (at least in Norway it is)

-by Niklas Bjørnerstedt on 2/28/2011 at 3:13 PM

Same in Italy: the video is blocked. That’s a shame, it looks very interesting!

-by Matteo Vaccari on 5/21/2011 at 1:39 PM

hmmm, yep, here’s what I get : “Recording and Viewing Blocked:
Click here to see available content.” ... Click Here refers to it leads to a list not showing my video. found this URL:

-by Alistair on 5/22/2011 at 11:40 AM

I checked all links above, I only got “This content is no longer available.” :/

-by Qing on 10/7/2012 at 5:10 AM

arghh bummer. I’ll peek around a bit when I get time. sad.

“This content is no longer available.” for me as well.
Is there any chance to see the video anywhere else?

-by Gian Carlo Pace on 6/18/2014 at 5:58 PM

Nope. I neither taped it nor stored. At the whim of the owners. Sorry :(

f8cking beautiful

what do u do when it’s so f8kng beautiful nd
u can’t take it all in nd it’s right there where
everyone cn see it but they don’t nd
u stare nd stare nd try to memorize it nd
want to lie there nd sleep there nd wake there nd
live there nd stare nd stare but ur eyes r 2
small nd your body is 2 small nd yr mind
is 2 small so u stare more nd try to hold it nd
u know u finally have to turn away

and it will still be there tomorrow, when u aren’t.

175: copyright 2013 Alistair Cockburn

Re: Why I still use use cases


We’ve spent many years enhancing our up-front functional documentation process—created in the form of use cases—to solve specific problems, all traceable back to one simple statement, “I need more information to implement this.”

Frighteningly, sometimes it wasn’t until we shipped that we realized the developers needed more information. We’ve now enhanced our process so that most of the work is done up front. The result? We have more accurate time estimates. Programmers are happy, there are fewer bugs discovered interally, and most important there are MUCH fewer bugs discovered once the product ships.

We have adopted many of the concepts of Agile development—such as daily build and test, build the smallest piece of functionality that delivers value, etc.—but have retained our up-front work. It’s worked extremely well.

-by Dave on 9/15/2009 at 10:35 AM

I never thought I’d contemplate user stories as being anything other than a flash in the pan. I couldn’t agree with you more Alistair about what you say in this article. But stories have ‘traction’ (ugly expression – sounds like snow tires). I’ve been looking hard at stories now and I think I like the fact that the users can get involved. That’s good. Not everybody makes a great story teller. Face it, when you get stuck next to a guy on a transatlantic flight and he tells you his life story in 22 minutes… ho hum). But people have a voice and they want to be listened to. Fine. But a decent story has a beginning, middle and an end. I can take this whole story metaphor a long way. In fact that’s what I did at . I reckon the Agile business analyst is really the story teller. Actually, I think I prefer that as a job title :-)

-by Peter Merrick on 6/2/2010 at 9:56 AM

Nice job title! sold!

I set in your URL ,and thanks.

Back UCs – how does the master storyteller keep all the upcoming details straight in her/his head? That’s where I’d consider inject UCs.

cheers – Alistair

-by Alistair on 6/2/2010 at 1:49 PM

UC and “Stories” are part of the SysML process for aerospace and defense systems and most importantly Systems of Systems (SoS).
Alistair may not have intended this when UCs moved into the agile domain, but for the multi-billion programs we work SysML and the associated UCs are a critical success factor.

-by Glen B. Alleman on 6/5/2010 at 12:25 PM

Hi, Glen — Nice you see you managed to get a post to stick (finally)!

I’m really glad to see UCs sticking somewhere. Super valuable technique.

Anyone using them for SysOps manuals or the like? A systems engineering predicted this to me in the 90s; wondering if it ever grew roots there.


-by Alistair on 6/5/2010 at 7:09 PM

Hi there,

I started out using use cases and I think its often their misapplication that forces people to move away from them (over specification of trivial scenarios that are low risk?). I have found user stories for more collaborative and easier to work with however, could you respond to a few points so I can play devils advocate :-)

“2.The main success scenario of each use case provides everyone involved with an agreement as to what the system will basically do, also, sometimes more importantly, what it will not do. It provides the context for each specific line item requirement, a context that is very hard to get anywhere else.”

User stories provide this with acceptance criteria being specified with users (from the story conversation), and context can be provided to a necessary extent for agile teams in the user story summary using the user statement e.g. “As a user who has saved a shopping cart I can … ” and the ending so that e.g. “so that I can save time when retrieving previous shopping”. Questions about context can also be recorded in the conversation.

“5.The full use case set shows that the investigators have throught through every user’s needs, every goal they have with respect to the system, and every business variant involved. It is the final part of the completeness question. (And yes, I did indeed sit down and walk through 240 use cases with a client, at the end of which, I turned to her and asked: “And is that everything?” She said, Yes, and we built that, delivered it, got paid for it, and it is still in use ten years later.)”

An agile team doing regular deliveries and a ba with good stakeholder management should potentially be able to work through every users changing needs over the course of a software project; the completeness question is probably hard to handle as the system ideal completeness will evolve over time. Validation can be done iteratively in this way and react to change effectively.

-by Arran on 8/6/2010 at 2:12 PM


I’m curious about this text here: “These days, iteration/sprint lengths are so short that it is not practical to implement an entire use case in just one of them.”

Well, I’m a big fan of only “ONE user goal per use case” (delivering tangible value to business). I believe it brought the ideal granularity to work with inside Scrum. My use cases tend to have around five steps in the main scenario and from 3 to 6 alternative flows.

In this configuration one 5 people team is being able to deliver 4 to 7 use cases every two weeks.

If a use case is taking more than a sprint to be delivered, aren’t we talking perhaps of a use case that could be decomposed and the resulting UCs still deliver value if executed isolated?

-by Claudio Br on 11/12/2010 at 1:49 PM

I would love it if what you say is true, Claudio. Can you share an example of a use case that takes 1-3 days to complete? Mine seem to be bigger, so maybe there’s something to learn here. Alistair

-by Alistair on 11/14/2010 at 1:27 AM

Hi there,

If Agile is used for the software development lifecycle, then the problem I have is developers are not really interested in reading long documents i.e. 12 tables of use cases. If a project has similar requirements as a previous project and you are working with a e-commerce product platform already in place, then use case “customer logs in” is not necessary and states the obvious, as the developer already knows how to develop the login page.

Should these type of requirements go straight into a product backlog instead? Can a customer be the reader of a use case document for sign-off?

-by Vanessa on 2/22/2011 at 11:59 AM

I followed a link endorsing the usefulness of use cases and landed here. Glad to find you Alistair.

When I first read about User Stories I was very skeptical of their usefulness particularly after the evolution of Use Cases—-the way you evolved them.

All the reasons you have given are obvious (to me) and they did not have to come from you. But since you have done it, we should see the end of User Stories soon. Or has it already happened? I would celebrate their demice.

-by Putcha V. Narasimham on 7/4/2011 at 6:25 AM

Hi, Putcha. User stories are very much here to stay. They are the new equivalent of numbered requirements or feature lists. The question now is how to balance the utility of use cases with that of user stories. Most people think they serve the same purpose and are therefore competitors, when in actuality they are like a hammer and a screwdriver, complimentary tools. What I wish for is not the demise of user stories, but people learning balance in using the tools available to them. Thanks for writing, and best wishes. Alistair.

User stories only make sense in agile projects. Only in agile do we:

  • commit the order of work with respect to business value only
  • base how much to complete in a time box on a calibrated sense of “bigness” rather than aggregating projected work from up-front analysis.
  • shamelessly admit at the beginning of every time box that we can’t guarantee delivery of everything we plan to do in the box but that our historical data suggests we’re somewhere near right.
  • don’t pretend to know up front what stories we’ll discover along the way or which ones will become a part of a business release cycle but only that we will do the most important things first as we become aware of them and shipment can occur when the organization decides we’ve created enough value to make business occur.

User stories are there to drive that style of work.

Use cases make sense – after we’ve committed work, have started the time box, and are performing analysis – whenever they answer a question to which we need the answer. I’m guessing that’s a lot of the time.

-by Lupestro on 8/5/2011 at 2:30 PM

I use “User Stories” as a “very brief description of the use case or as an expanded use case title” :)

Both can go hand-in-hand.

-by Dhruba Sen on 8/5/2011 at 2:31 PM

I use “User Stories” as a “very brief description of the use case or as an expanded use case title” :)

Both can go hand-in-hand.

-by Dhruba Sen on 8/5/2011 at 3:08 PM

We’ve been experimenting, and with excellant results, combining use cases with user stories. One one project, we first write the use cases, then write thin user stores that refer to them. Example: we might have a user story for the Basic Flow, one user story for an Alternate flow, etc. That way, we can size and prioritise the stories into sprints, and always go back to the use case as a measure for completness.

In another project, the user stories are written first, albeit coarsly, then packaged and built into cohesive use cases.

I might add that I might deviate from other BA’s in that I attach, as an appendix to our use case, all the other ingredients – like data defintion (from a business perspective), decision tables, and if necesary, crude wireframes.

-by Dave Levitt on 5/4/2012 at 2:59 PM

Hi, Dave – thanks for the notes – yes, agreed on all counts. “Attaching” those things to the UC works, whereas “embedding” them doesn’t. again, thanks for the note.

Great article, interesting read.

Do you feel that User Stories (including epics) can’t constitute the same completeness overview?

Up-front estimates are notoriously difficult to accurately provide regardless of approach. If you suggest writing out full use cases to facilitate this, waterfall style, you risk the estimate changing with requirements or locking the stakeholders into said requirements. I’m not sure what the answer is here.

Use cases can work in an agile context, of course. Writing them JIT and getting the granularity is the key to making this work I think. A big use case is much like an epic story – it needs to be broken down… That or the sprints you describe are too short. It’s a question of size and velocity here.

Have you experienced User Stories with clearly defined acceptance criteria, defined / explored prior to implementation as the story moves up the stack? BDD methodology introduces scenarios which addresses a lot of the issues you describe:

Feature 1

Scenario 1


Scenario 2

This language is really nice to communicate, and it ensures that people are thinking about the right things.

Food for thought!

-by Tom Tom on 8/17/2012 at 7:20 AM

I am working in a company that has no methodolgy they claim. Through experience I think it is Waterfallish. As part of my responsibility I am to help them come up with a methodology. After being in the company and observing their habits and client reactions, I think Agile Scrum would serve them well. However, I am a huge fan of Usecases and know that they are needed to communicate especially to offshore QA! I like the idea of creating a User story then use case. Any further suggestions will be greatly appreciated!


-by Great Education! on 6/5/2013 at 4:55 PM

Use cases in practice allow to create ‘complete’ requirements. It is possible to do despite most people think. By ‘complete’ I mean good enough to answer all developers questions and to produce product that enable high performance of it’s users. Usually it just takes a lot of time to create requirements. I keep spending too much time on writing requirements. I usually deliver use cases and detailed requirements too late. However in each project where requirements took too long the project finishes on time. Development goes really fast when developers know what is the purpose, how the functionality will be used, what are alternative scenarios and what exception handling they have to think about. They have most od the details defined when they start so they can design architecture that doesn’t need much changes later. There is very little rework.
Also very important think is support after the project is delivered. With carefully modeled functionality through use cases support needs are much reduced.

-by Łukasz Pasek on 7/23/2013 at 3:41 AM

I was coaching a team that was struggling on reaching consensus on the big picture because they were getting into the “story card hell” (Shore, 2005). After over a hour of discussions, I proposed to draw a UC diagram and every went smoothly after that. I found UCs more intuitive that user-stories (epics) for identifying high-level capabilities at the beginning of a project. Once we have high-level PBIs represented as UCs we can slice them into stories as it’s now proposed by Use Case 2.0.

-by Melvin Perez on 6/18/2014 at 3:42 PM