Alistair Cockburn

A word is a bed of procrustes for an idea

Before we have a word, we have a general idea. It is fuzzy.
When we create a token for the idea and pass it along to someone else, we cut off the fuzzy, irregular parts of the idea.

Then, to make up for the missing sections, we make up another word, to cover another fuzzy idea that overlaps somewhat.
Now both words stretch and cut off the original ideas (see http://en.wikipedia.org/wiki/Procrustes)

In addition, now the two words overlap.
So when you use one word, you exclude the possibility of using the other word.

Since each word brings along a train of associated and related words, using the one word drives into view the entire train of associated words, and excludes the alternative, otherwise possible train of ideas.

see also http://en.wikipedia.org/wiki/Truncation_error and http://www.last.fm/music/Helsingfors/_/Truncation+Error

Re: Why I dont like Definition Of Done

It doesn’t need to be a contract. I find it useful for setting the quality bar for my teams. Also avoids miscommunications amongst teams, product ownership, and other stakeholders.

I have been burned in the past by developers claiming things to be done when they were clearly not.

-by Mark Lines on 11/17/2014 at 3:08 PM


I tend to agree with Mark on this one. I have not used “Done” as a measure of functional completeness (which would make it more of a contract. I have used it kind of as a “nonfunctional checklist” (if that even means anything) of completeness, that applies regardless of the functionality. It’s not done until it’s code complete. And automatically deployable. And has a sufficiently complete automated test suite. And has been code reviewed. Or whatever the list happens to be in the present context.

Does that make sense? It’s not a contract between dev and customer. It’s a contract between and among the dev te and itself. And it describes ways of working, not functional output.

-by Bill Barnett on 11/17/2014 at 6:20 PM


Bill, it starts innocently enough. But take a look / listen at how this is taught, described, lectured written, and behaved. You’ll see contract negotiation start instantly. Which is what prompted the posting.

It’s not that I don’t understand the pressures and reasons for having a DoD != shipped. However, DoD is all about the distance between what really got done and potentially shippable. If that distance is zero, no problem. If not, contract negotiation starts, and bad things almost inevitably ensue. Hence the post.

-by Alistair on 11/17/2014 at 6:38 PM


What’s with the image in this post? Is that a gardening tool?

-by ksteff on 11/17/2014 at 9:12 PM

hah, ksteff, that’s me in a hurry to find a pic. I was looking for a spike in the ground. no good one, but this was too cute to pass up.


I have come at this from a slightly different angle, having recently helped two smaller companies set up PMOs and their own best practices as they transition into enterprises. The challenge both of these organisations have faced is that they deal with customers who are much larger and insist on fixed price contracts. Both companies in question have managed to exert influence on their customers but it is a slow process and flexibility was the key.

The approach I took was to have the Product Owner (played by internal BAs liaising with the customer) agree a high level Product Breakdown (yes, this is a PRINCE2 term but the end Products / Deliverables can be made to map nicely onto Epics for software elements) with Acceptance Criteria agreed by Deliverable / Epic. These Acceptance Criteria go into the contract, giving the Product Owner freedom to negotiate the Story-level Acceptance Criteria in each sprint. This meant that the core functionality “as a user, I must be able to…” could be agreed up front while the mechanism for achieving this could be set on the fly. Any changes to the core functionality result in formal Change Control with associated contract haggles but this was infrequent and isolated from the devs.

Done then becomes a combination of the dev best-practice activities listed by Bill, above, with proof that the story-level ACs have been met. For this sort of work, it is vital that the story-level ACs are included in Done as it is not possible to forecast internal project costs effectively if they are not.

Regarding costs, we agreed a relatively high fixed price contract but on a call-off basis and subject to change control at the Epic level. This is not a pure agile approach as, by necessity, all Epics and some Stories need to be defined up front to set the initial fixed cost but it does still leave a lot of flexibility at build time.

s. the item in the image is a pin for securing your dog when camping, etc. You screw it into the ground, then clip the dog’s lead to the round eye which is free to swivel around the pin. Good if you are around, but not safe to leave a dog unattended as they can get caught up and strangle themselves. Experience shows they can also be used as a tent tie-down in strong wind!

-by James Pels on 11/18/2014 at 6:27 AM


The point here is to be agile. If you don’t want to be agile, that’s fine. But don’t pretend you are (and definitely don’t tell people you are) if you have contracts and they take precedence over learning (and adapting) together with your customer.

Personally, I prefer a story as a “promise for conversation.” One of the hardest things to do with a software team that isn’t used to this agile thing is to convince them to go talk to their customer. Often. :-)

P.S. Thanks for the prod, Alistair!

-by Stephen Starkey on 11/18/2014 at 7:00 AM

yep, that’s it, Stephen. You don’t have to pay attention to any of the values in the manifesto. None of them are mandatory. AND, also, contracts have a useful place (as it says in the manifesto). BUT, still, if you say you’re using the manifesto, start listening to DoD as contractual negotiation, and you might be surprised as to what you discover. I read all the above notes as “we like/need contracts because….”.


Maybe the language is more along the lines of
‘Is this (system) currently working for you?’ as a business question.

This can be answered with a range of responses e.g. “no, because” or “yes, but” and can be directed at a set of stakeholders – “it works well for me but not for accounts”. The business is then responsible for what working for them means (efficiency/speed/value).
Done becomes ‘working well enough that it is now time to concentrate on other things’

Also by saying ‘currently’ you acknowledge change is inevitable. Can also tie this in to automated testing.

-by jimduk on 11/18/2014 at 8:56 AM


+1 with Mark & Bill. It seems, and I use, DoD as an internal agreement only defined by and for the team. It’s a checklist per se, some kind of half-explicit knowledge / know how to assure a certain level of reproducibility / quality.

You are right though, the way it’s used / taught is exactly the opposite. But we just can’t stop using something because lots of people do stupid thing or interpret it in a way bending the ideal. Or I could stop explaining Agile/Lean is a good way to deal with product because some people are doing bad Agile ;)

-by stephanewww on 11/18/2014 at 10:04 AM

or you could amplify exactly that that Stephen suggests, more actual meaningful dialog between programmers and sponsors and end users. With running sw in hand.

The image for this post is a stake that gets used to tie down animals for grazing a field (so they can only move within the circle defined by the length of the rope). That can be interpreted in some interesting ways in this context, I think. Food for thought.

-by Oluf on 11/19/2014 at 11:26 AM

Re: A barrier a zillionth of a second thick

The wonder part got me thinking.

Recently looking out at the stars – I thought – they could all be gone and we’re just getting their last light – JUST KIDDING. No – I thought, gee, this notion of ‘big bang’ which is really ‘creationism’ sold as a Snickers bare when it’s just another OHenry bar – somewhat leaves me feeling robbed of my potential for awe.

Which is more more enticing ? the intellectual torment of how everything could come from nothing? or – that they just go on forever. Aristotle adopted the latter view, and I now settle on the latter view. I currently argue, if everything came from nothing, clearly it was nothing, or it would still BE nothing.

Every 5 year old hits that flaw in causality after being told “Why – God created the Universe” after chasing causality of 24 Why’s in a row… Only to retort “But mommy, who created God” – many parents just don’t know where to go at that point. I contend the model is incorrect.

Same with say – ‘time travel’ – if you just let go of an inferior linear temporal model ? you won’t have the Grandfather paradox (“Back To The Future”), after all it’s really an intellectual abstracted model we overlay to event phenomena, time doesn’t really ‘exist’. If that’s true, and Einstein says time and space are really two facets of the same thing, YIKES, what did I just infer about space.

Either way – those words ‘just wonder and wonder’ above, reminded me of when I realized I’d much rather contend the stars do go on forever and ever, with jaw dropped awe and wonder vs. the intellectual torment of how anything could come from nothing.

“So look and wish, and wonder”

Bout sums it up. Sometimes I think I’m content JUST to witness that anything COULD exist at all. A wish ? is truly ‘will’ – a ‘thought’ and all in all ? I’ve given this much thought as to who anyone is, or I am. Am I my name? No that’s inherited. Am I my genetics ? those are inherited too. Am I my income (currently zero – but transient), my language ? nope – inherited culture, I didn’t create all those words. So at the end of the day ? I can’t come up with anything BUT one thing, that CHOICE one has to choose what they think next. I COULD think about hmm – say Sloths right now, or maybe Lime Greed Koolaid I had as a child once, or say – whether there are more even or odd numbers in an infinite set, or maybe Chicken and – well- you see where I’m going. So – a WISH – IS a WILL – a CHOICE. My take on things ? In the ends ? It’s like Phil Connors in Groundhog Day “Ya make choices and ya live with em” – I now identify more with that ability to choose what one can think over what one thinks. I think in non being, I’d miss thinking most, I may not miss thinking about missing thinking as much as I’d miss missing thinking, perhaps not.

To look, to wish, and to wonder… Indeed. There is doing, but ultimately that’s pegged causally to the wish to act.

I need sleep, since I can’t comment on UML – and modelling, since I still don’t comprehend it all, eh – thought I’d maybe share something of value to me to invoke further wonder !

-by Tim Miltz on 11/16/2014 at 9:29 PM

Re: Humpty Dumpty lay in the sun

Pancakes and EGGS!! Humpty is a CANNIBAL! ? ? ! ? ! oh the horror… sob, sniffle…

-by michele on 3/11/2010 at 8:13 PM


LOL, busted! good call, Michele!

Alistair :)

-by Alistair on 3/13/2010 at 3:12 AM


I feel this is the only section of your site I’m qualified to offer any insight :)

Two comments KIND of related.

One ? I recall seeing this Japanese man or woman, who had earned the title oldest human alive, when asked what one common denominator they could find in diet, they said they ate an egg every morning of their life.

Two, giving thought to resolve this Chicken or the Egg paradox ? I think I’ve solved it – it’s really a question abou temporal state. Ok, I said temporal just to sound impressive (46, but STILL A child in so many ways). In realizing the chicken and the egg ARE one and the same ? just two different states ?

I think I’m ready for early retirement.

I JUST discovered you Alistair – I started programming as a child age 8 in 1976 or so on this Honeywell CP5 our Univ. had, and I have always struggled with UML and ‘use cases’ to all of last week I’m reading and reading, and I still can’t figure out just how specific or generalized they are supposed to be- and then all this story boarding or something, then reading – oh no – that doesn’t get you context, I found you were the culprit behind this entire movement :) All respect heh – so – just saying hi, and very cool to be able to do so. That’s all. Hope I brought a smile, because I don’t think I’ll be bringing anything useful on use cases, since I still…struggle with them.

Some of my other favorite mottos ? Always better days ahead but I haven’t been able to prove this one. I also realized recently, I don’t have to worry about dying, I’ve already not existed before I was born and the world existed just fine then. So clearly, statelessness in being isn’t anything new.

Very cute poem above. Heh.

REGARDS- I can see you have a built in smile- that’s all I have to say.

-by Tim Miltz on 11/16/2014 at 12:33 AM

User manifesto voting

I’m setting up this page for the explicit purpose of collecting votes on the User Manifesto (discussion: Re: User Manifesto).

To change the Votes below, click the Edit link there, and put an additional 1 next to your choice. Then click the “Save + View” link below the text box. That will produce a long string of ‘1’s as the vote. If you want to be nice, put a space after every five ‘1’s for easier viewing. And then don’t delete anyone else’s vote, for goodness sake – this vote doesn’t elect a president or anything, so there’s no real meaning to “winning” the vote.

On the other hand, you can just write down your preference in the Discussions pane.

Put your name and choice down below the votes if you’d like others to see your choice of voting.

If you want to propose an alternate linguistic structure for the manifesto, don’t do that here, add that to the User Manifesto Discussion itself.

Capice?

Here, I’ll set up a start:

User manifesto choice A: 11111 111

User manifesto choice B: 11111 11111 11

User manifesto choice C: 11

User manifesto choice D: 11

Alistair: choice A
Markus Gärtner: choice D
Evan Sanders: choice A
Inbar Oren: choice B
Geraldo Xexeo: choice B

I am a defender of the oppressed

I am a defender of the oppressed,

not those with burkas who are so oppressed
(not that all with burkas are oppressed),
for they have champions, however inadequate, however still in need,

not the poor, nor the handicapped, nor the white, nor the black,
the red, the yellow,
the sick, the dying, the new-born, the unborn,

for they all have voices,
still not sufficient, still in demand;

but for the artists,
the musicians, the mimes, the dancers,
the people without words,
for whom words are not a thing,

antagonized, minimized, oppressed
by philosophers,
lawyers,
rule-makers,
the system,
who think words are all,

who use words to declare that words are all,
and those without words aren’t.

While the dancers, the musicians, the sculptors, the mimes,
dance, sing, sculpt and play their experience of the world,
that rich, so much wider world they inhabit,
without words,

so richer than the impoverished world
of the legalized words
that imprison them,
remove the validity of their world,
declare them empty,

while the painters, the drummers, the dancers
see, feel, hear, move, the vastness of the world
without words.

I am words, defending them.

(© 2014, Alistair Cockburn)

Re: Agile contracts

Nice round up.

Payment per story points seems the best to me.

I like the idea of paying 5% if delivered on time. That could be a bonus split for the team.

Thanks for sharing!

-by MarcoBarbosa on 4/29/2010 at 5:33 PM


I am still partial to #1. I do not believe in charging for time, only results. Billing by the hour is inherently unethical.

-by Mark Richman on 4/30/2010 at 9:43 AM


@Mark — charging for time is not unethical, it’s just a kind of agreement. It’s appropriate when the customer can’t or won’t define precisely what they want in advance.

-by xpmatteo on 6/24/2010 at 10:53 AM


I read somewhere that we should have a higher price per story point in early sprints and a lower one in late sprints (since the idea of Agile is to deliver the most value early). Does anyone have some experience with this ? Do you know about any formula to put this in place ?

Regards,
Chris

-by Chris on 7/7/2010 at 6:27 AM


Good question, Chris … I have an idea, just for fun – how about reversing that logic and charge less for early sprints and more for later sprints, to entice customers to get their value quicker, up front, and to quit the product development sooner, as the value/feature starts to drop off? Encourage the behavior we want to see?

Any thought? :)

-by Alistair on 7/7/2010 at 11:10 AM


I am battling with one central problem in agile: how do you remain “agile” and open to change when you’re working against a fixed budget and defined scope, and a customer who is not a “software person”.

We use an adapted version of SCRUM for web development, which is part-software and part-design. Our customers have only a limited interest in being involved in the project. They want x by x date. But they also want to make changes along the way.

So do you baseline the project against the original scope document? And then measure each change impact on the budget?

It’s driving me kind of nuts — how can you merge an agile process with a non-agile budget?

-by Jarred Cinman on 11/25/2009 at 1:38 PM


I think Earned-value and burn charts (discussion: Re: Earned-value and burn charts) and http://en.wikipedia.org/wiki/Project_triangle might help you.

Also: don’t be afraid to say “no” to the customer. Every time you say “yes” to the customer you lose a bit of control over the project. If you say “yes” too much the project will spin out of control.

-by Floyd on 11/26/2009 at 7:18 AM


Thanks, could be a nice data for my benchmarking in the subject of CM.
LSS Expert – IECOACHdotCOM

-by Johan Wennermark on 9/21/2011 at 2:55 AM


bonuses and penalties can be a useful way to motivate the service provider but in the final analysis they really just change the arithmetic, not the approach; supplier cost and customer benefit progress/regress in a linear fashion. shift to marginal thinking, e.g., deliver early/at better quality/etc. and I will increase your marginal rate of return; deliver late/worse/etc. and I will decrease your marginal rate of return. With this model, the supplier is motivated to be more efficient, not just faster. Customer gets lower overall cost; supplier has strong motivation to deliver at or above expectation and strong motivation to avoid delivering below expectation.

-by Ken on 11/28/2011 at 3:21 PM


bonuses and penalties can be a useful way to motivate the service provider but in the final analysis they really just change the arithmetic, not the approach; supplier cost and customer benefit progress/regress in a linear fashion. shift to marginal thinking, e.g., deliver early/at better quality/etc. and I will increase your marginal rate of return; deliver late/worse/etc. and I will decrease your marginal rate of return. With this model, the supplier is motivated to be more efficient, not just faster. Customer gets lower overall cost; supplier has strong motivation to deliver at or above expectation and strong motivation to avoid delivering below expectation.

-by Ken on 11/28/2011 at 3:51 PM


I have participated in a Swedish market initiative to establish general terms for agile projects. I have in this work introduced a new term called “Spare timeboxes” (or spare Sprints). The purpose of these are to allow limiited scope creep. Number of spare timeboxes needed in a project depends on the uncertainty of requirements.

It’s also possible to agree incentives models based on use of spare timboxes.

A preplanning would require a definied timebox sequence, also including thes spare timeboxes. Based on this sequennce and assumed resource utilization it’s poosible the agree a goal price.

-by Lars Wendestam on 2/6/2012 at 8:52 AM


I have recently worked out one of these ideas in very much detail (a book published by Wiley & Sons with the title “Agile Contracts”) with the aim to make this topic chewable for all involved parties. Looking at Alistair’s list, it is quite clear to me (the geek) but in the last years I have seen cultures clashing at these quite obviously interesting concepts… meaning the classical ”... look I do not need that, as I am anyway telling you in advance what you should do…” (told by a legal or procurement person with its IT colleagues already shaking the head) or my favorite ”... it works fine now, why shall we change…” (from the procurement guy neglecting the real performance of the recent projects….

-by Andreas Opelt on 10/13/2014 at 9:47 AM

Re: Sampler of good and bad use cases

I am a bit confused about which the good and which the bad examples are.

I assume the black ones (i.e. the first three) and the ones with smilies are good?

Best regards,
Thomas

-by Thomas Schandl on 4/8/2009 at 8:50 AM

The ones with mistakes say “Mistakes” right above the use case title, and the good ones have the smiley faces. Hope that helps, Alistair -by Alistair on 4/8/2009 at 5:00 PM
Hi Alistair,

okay, so then all of the ATM use cases are mistakes.

I’m not sure how the ATM UC should be modelled ideally, or what exactly is wrong with some of the bad examples – but I already ordered your book, so I’ll learn it soon ;-)

bye,
Thomas

-by Thomas Schandl on 4/9/2009 at 4:38 AM

Right. Since I teach the ATM in my class, I don’t publish the preferred writing of that use case – either work it out from the book or come to the class :). So sorry. Alistair


Hi Alistair,

Do you regard data formats as requirements? I cant decide if they are a what or how (design).

If so where do you place data requirements in your requirements catalogue?

Thanks,
Mark

-by Mark on 7/20/2009 at 12:05 PM

Data requirements are Chapter 4. Use cases are Chapter 3. (euphemistically speaking, of course) :) Alistair

-by Alistair on 7/23/2009 at 4:48 PM


This list of good and bad use cases is not helpful at all.

Don’t just present a list of good and bad examples. Tell the reader instead why an example is good, why one is bad, and how a bad one could be improved.

-by Roland on 9/16/2010 at 4:07 AM

Hi, Roland, The discussion of what’s right, what’s wrong, how to repair, are in the books Patterns for Effective Use Cases, Writing Effective Use Cases, and in our various lectures and classes. This list is not intended as a tutorial, it is intended as a showcase of use case examples for people to inspect and discuss. If you wish, you can start that discussion by suggesting what is wrong with some of these, and how to repair them. Alistair


I bought Cockburn’s book Writing Effective Use Cases. What a BIG mistake… Its garbage… A total waste of money. Its poorly written with disjoint examples and poor explanations.

Its only matched by his arrogance above where he answers people questioning why he doesn’t give more info with “buy my book to see the answers”....

My recommendation: Look to another source….

-by mike on 1/26/2011 at 4:21 PM


Thanks for sharing, Mike. :). Alistair

-by Alistair on 2/8/2011 at 3:29 PM


Hi, this list was not helpful at all. In fact I am more confused then before I read this information.

I am really trying understand UML for my graduate course. This was written to appeal to UML experts and not students.

-by Sherri on 10/7/2011 at 10:11 PM


Yeah, gotta throw us a bone here Alistair…there are four ATM use cases with mistakes, maybe explain why one of the four is wrong. Market to us a bit more with your knowledge and we’ll be more inclined to buy the book. I’m new to use cases so this page isn’t terribly helpful…I’ll keep looking through the site though.

-by RS on 10/31/2011 at 6:51 PM


OK, the “book flights” cases are more informative. I advise less-experinced viewers of this page (like me) to look at those.

-by RS on 10/31/2011 at 6:56 PM


re: Mike’s discontent with Writing Effective Use Cases

Just in case someone reads these remarks and takes Mike seriously, please be aware that he is among a distinct minority. The vast majority of readers, self included, disagree, as witnessed by the book’s popularity and overwhelmingly positive reviews (e.g., as of 25 Oct 2012, it has an average 4.5/5 review among 55 reviewers on Amazon).

No disrespect intended to Mike; he is entitled to his opinion if he found the book to be unhelpful. Most readers on record disagree with him, however.

-by Steve Swope on 10/26/2012 at 12:55 AM


Thanks for the examples. I am a BA in a small team and it helps to see how some folks might approach use cases incorrectly so I can avoid the same mistakes. I think the negative feedback is due to individuals not yet understanding use cases, at least not formal use cases. Your methods and approaches work very well! I used your approach to build requirements for a custom system with a large team of developers/stakeholders and it was a success.

-by syz on 2/28/2013 at 11:23 AM


Thanks for the examples. I am a BA in a small team and it helps to see how some folks might approach use cases incorrectly so I can avoid the same mistakes. I think the negative feedback is due to individuals not yet understanding use cases, at least not formal use cases. Your methods and approaches work very well! I used your approach to build requirements for a custom system with a large team of developers/stakeholders and it was a success.

-by syz on 2/28/2013 at 11:29 AM

Thank you for that kind note! Alistair

Thanks for the examples.
Let’s assume a user has to fill a form. Where would I specify which information is mandatory? And what about validation of the input? Where do I specify such things?

-by Alec on 10/10/2014 at 4:30 AM


Thanks for the examples.
Let’s assume a user has to fill a form. Where would I specify which information is mandatory? And what about validation of the input? Where do I specify such things?

-by Alec on 10/10/2014 at 5:48 AM


Thanks for the examples.
Let’s assume a user has to fill a form. Where would I specify which information is mandatory? And what about validation of the input? Where do I specify such things?

-by Alec on 10/10/2014 at 7:27 AM

Love Trio

Love Trio

I

Demanding love is one-quarter love.
You love yourself and want your lover to be
The way you want your lover to be.

Undemanding love is one-third love.
You love your lover,
And accept the sins and lies as truth,
Or critical to your uncritical Love.

Unrequited love is a questionable love.
It is love in transit,
Becoming, or vanishing. If vanishing,
You may demand your lover love you back
(see footnote above, “Demanding Love”),
Or you may become a guardian angel.

The full one-half love demands you love your lover,
And love your lover’s needs
As you love your own.
If you must ask me what to do
in case of conflict,
you don’t understand.

The full one-half love demands you love yourself
As much as you love your lover,
And love your own needs
As you love your lover’s.
How do you resolve a conflict between
a need of your own and a need
of your own?
If you have to ask,
you still don’t understand.

The full one-half love is a most demanding love
(do not see footnote above, “Demanding Love”),
But it makes
One-half plus one-half
Two.

____

II

My love and your love
are as different as they are alike.

My love of you is like
your love of me is not like
my love of me is not like
your love of you.

Our love of Jim,
Jim’s love of Jane,
Jim’s love of John,
John’s love of Tim,
Our love of them, our love of one another,

Your love of it.
You love it.

Today I love.
Today I am love.

The love of loves:
That place in you which IS love.

____

III

In which the word ‘Love’ is dissected
to find its true meaning.

5 Billion beings
(human)
and many more creatures, in
12 Thousand dialects of
8 Hundred tongues,
for over
9 Thousand years
have tried
to define 1 word
which encompasses
Dozens of emotions
vital to existence,
and failed.

There are over
27 names for “a group of”,
each animal deserving its own noun,
21 words for “unhappy”
depending on the degree,
12 ways to say “snow”
(well, which snow do you mean?)
6 measures of beer,
and 1 word for love:
“Love”.

16 migraines,
2 pads of paper gone empty,
a wastepaper basket become full,
and one weary audience later,
a concession of defeat.
It can’t be said any better:
“Love”.

`44:© 1986 Alistair Cockburn / lovetrio / emotion )

Categories

Pages