Agile Thinkers

Q1 - Alistair Cockburn

I really need to introduce Alistair Cockburn do I.  You think you know him?  Wait 'til question 3 ...

Q1. Hi Alistair, Tell me about yourself, especially, how did you get to be so damned brilliant? I don't say that lightly but some people I know go all gooey eyed when talking about your work and I reckon your approach to writing Use Cases gives sliced bread a run for its money. What's your story? What got you here? And, what does your wife think of all this agile stuff?

That's one question? Can't wait to see the rest!

Many thanks for the kind words ... There are enough people around me who think I'm incredibly stupid that maybe they sort of offset each other – kind of like the man with his feet in the freezer and his head in the over but who is, on average, at a comfortable temperature.

One of the things fairly unique about my background is we moved around a lot – My parents were English and wanted to get out of England after WW II, their goal was (a) to get far away from England, and (b) to travel the world. They dropped kids, in succession, in London (in the London Zoo to be exact), Kansas, Colorado, and Bangladesh. I was one of the ones dropped in Colorado. We lived there for almost a year after that before moving somewhere else. (Some people ask me where I was born; when I say "Just outside Denver", they say, "Oh!" as though they understand something, as though that fact might actually have any meaning.)

My father was an outside-the-box thinker and pretty headstrong. He nearly didn't get his MD degree because he kept disagreeing with one of the professors about some theory about the origin of diseases. He was an early epidemiologist. One of his earliest theories in the late 1950s was that diseases and parasites evolved along with homo whichever, all the way from pre-apes to modern humans. He couldn't get people to write about that in the US in the late 1950s because of the Christian evolutionist lock on science (so recently!). His book Evolution and Eradication of Ancient Diseases was published in 1963. He started a paleopathology movement, arranging multi-disciplinary autopsies on mummies. That was while I was in college, so I'd come home to see him discussing these trial autopsies (see http://ambassadors.net/archives/issue13/selected_studies.htm for  more on him).

Between my mother's arts-literary nature, my father's outside-the-box research and our constant moving (Sri Lanka, Massachusetts, Bangladesh, Ohio, Sweden, Detroit, Scotland, Cleveland, Salt Lake City), I had to adjust to many cultures and never got to be believing that one could be right ... quite different from home-folk in most parts of the world. I suspect this shows in the way the Crystal family of methodologies is constructed, and I believe you'll see it leak out on almost every page if you're looking for it.

I graduated from a city high school in Detroit at age 15, and went to be an exchange student to Sweden (1969-70) to kill a year before college. That got me hooked on travel even more. I arranged my own junior year abroad at St. Andrews. When I got married, I checked first with my wife-to-be that it would be OK to move to Europe for a few years. A few turned to seven, at the IBM Research Lab just outside Zurich, where I worked on formal specification techniques for a while (an interesting precursor to methodologies, and one I dip back into every now and then)  ... and that's where our two oldest children were born. We moved back to the US for a while, but I got itchy feet and sent myself plus family to Norway in 1997, where I worked with the Central Bank of Norway. Along the way, I discovered I like learning languages, so now I speak some extent of French, German, Swiss German dialect, Swedish and Norwegian. I tried to learn Farsi back in the late 1970s, but then the Shah got overthrown and I've never been there to tamp it down (sigh).

My wife is an artist. While I used to work in computer graphics at Evans & Sutherland, we had a lot to talk about. We still argue over additive versus subtractive colors. She's an outside-the-box thinker herself, tolerant, smart and self-motivated --- she would have to be or we'd never have been able to put up with each other for 28 years! Thanks to her, I have sculptures of skeleton faces and bones in my living room. Thanks to me (and my father), we have a smallpox mask from India  – a two-foot high scary face with tongue sticking out and snakes coming out of the head – hanging in our front entry way.

Agile comes easy to her – all she has to do is change her mind at any moment!

Anyway, you get a picture of our home life ;-).

Our kids grew up thinking this was normal :-). They're teenagers by now, so they don't any more, of course.

And regarding the word "normal", when my middle son Sean was in calculus last year, we realized that the "normal to a curve" is perpendicular to the tangent at that point, i.e., the vector pointing farthest away from the rest of the curve at that point. So now my kids have fun calling me "normal."

That was a freaking long question (answer). Sorry about that.

[If you feel comfortable here Alistair, I suspect people would love to
hear a little about your home life]

Not too much to say. Since leaving IBM in 1994, I live in Salt Lake City and do most of my writing in coffee shops (for example, right now). I wrote Surviving Object-Oriented Projects and Writing Effective Use Cases at the Beans & Brew coffee shop just below the ski resorts; I wrote Agile Software Development largely at the Salt Lake Roasting Company, Crystal Clear and my doctoral thesis at the Salt Lake Coffee Break (open till 2 a.m. every day!), and these days sit mostly at the Two Creeks coffee (good for articles, but not for books – for that I still need the Salt Lake Coffee Break :-).

I keep travel down to 50% so that I have enough home life for our family to survive; and I write books to have a good reason to stay home. Lately, I haven't been writing a book, so my travel time's been going up again. Ugh.

I swim competitively, mostly every lunch time when I'm home to keep fit and to keep motivated. My goal over the last 4 years has been to break every Utah swim record (short course yards) in the 50-54 age group. That obliges me to change events every year. I have 14 of the 18, but only 5 meets left – I don't think I'll get the last two, but I hope to get two more before time runs out.

Swimming and traveling don't go well together, mostly because I don't have enough discipline to train on my own while on the road.

Alistair Cockburn - Q2

Q2. I know a lot of folks who glaze over when I mention use cases.  They are kinda dull and they don't seem all that agile. I've never seen the point of drawing stick figures, for instance. But then I discovered your book and your particular way of writing them and I was wowed! A couple of weeks ago I took a client's management team (along with a few of their senior techies) through an example and they were also wowed. Can you tell us a little bit about the format and how you developed it to the point where you realized you had to write a book about it? Can you tell us about a real live agile team that's using them in iterative/incremental development?

You're right – by today's agile standards, use cases are long and dull. I probably wouldn't learn them today if I didn't already know how useful they are. Actually, this is a bit troublesome, because I am having difficulty finding new people to teach them – all the use case experts I know learned them in the 1990s.

What makes them hard is they require thinking and communicating – both tough sells at any time, and especially into the agile space, where the reflex is type-and-show. (It's a good thing I helped write the agile manifesto, or they'd have ripped up my agile membership card long ago for saying stuff like that!)

I got to use cases through my assignment at the IBM Consulting Group in 1991. They asked me to construct a methodology for their consultants to use on OO projects, with no constraints on what the answer was.

After some interviews, reading, and research, I settled pretty quickly on the Ward Cunningham / Kent Beck CRC cards technique - Rebecca Wirfs-Brock' "Responsibility Driven Design", and incremental development.

These left out something critical. As I wrote in "In Search of Methodology",
"Responsibilities reveal which object or subsystem will carry out a part of the required function, interaction diagrams show how the function is carried, but neither say why it is required in the first place. That is what scenarios and use cases provide."

It is similar to the "warp and weft" in weaving: one direction lays down the nouns or objects (or components) needed, and the other direction lays down the verbs or functions needed.

Trying domain modelling without knowing which subset of the domain is important is just too big and too hard. We saw in the 1990s companies spending /hundreds/ of work-years (I am not kidding) on domain analysis and domain modelling because they didn't know incremental development and how to bound their inquiry.

Anyway, in 1992 I read Ivar Jacobson's 1987 OOPSLA paper on use cases, and saw that they were just the right size and shape to fit into this hole that was left by all the OO techniques at the time.

I read the pre-pub draft of Jacobson's OOSE book, and didn't understand how to write them from that, so I flew over to Stockholm and took a class from his company on how to write them. After that I still didn't understand how to write them. Indeed, at that time, nobody knew how to write them, no matter how many words Ivar wrote on the subject. I think maybe they sit too close to his spinal cord for him to be able to see what he himself is doing.

So at that point, I had to work out how to break use case writing down into small enough pieces that I could write an instructional booklet for the IBM consultants to use. I sat at my favorite coffee shop for two days trying to break it down. It turned out to be a 3-Aha! problem.

* The first Aha! that hadn't been articulated to that point was that each use case collected scenarios based on a /goal/ - that's what held the various scenarios together.

* The second Aha! was that essential to the notion of goal is /goal-failure/. Specifically, every use case has not one but /two/ exits, success and failure. This goes against everything we had learned from Edsgar Dijkstra about single-entrance / single-exit subroutines, so I had to be quite careful that it really worked (David Parnas came up with an interesting semantics for multiple-exit functions back in the 1980s, so I knew there was some precedent). Anyway, the two exits turns out to be essential to understanding how they all fit together.

* The third Aha! was that goals are recursive – we have big goals, which we break into smaller sub-goals, which ... etc. We tackle each sub-goal in turn until we achieve the main goal. If we get blocked, then we look for an alternate sub-goal. All this is common sense (but not commonly articulated), and also a well known artificial intelligence technique. Therefore, there was good, safe theoretical and practical precedent for believing it would be sound.

From these three, I was able to construct a semi-formal theory that allows us to do what is easy and natural in writing and expressing ourselves, and which at the same time is mathematically sound ... and also, just by the way, produces use cases that look just like what Ivar Jacobson wrote! I think that was one of the happiest little problem-solving moments of my life, to be honest.

I wasn't allowed to publish this at the time, because the IBM Consulting Group thought all this methodology stuff was top-secret, mission-critical, revenue-critical information. Not true, of course, processes and techniques rarely are, but it meant I couldn't speak about it for some years.

A side note – I couldn't publish my first methodology, written in 1992-3, for the same reason. In fact that methodology never even got a name, more's the shame. It would be interesting to look at now, because it was one of the first agile methodologies contructed (after Tom Gilb's Evo). All it contained was use cases, incremental development, responsibility-driven design, and programming. I wrote a little article about it in Object Magazine just before leaving IBM (see http://alistair.cockburn.us/index.php/In_search_of_methodology).

Use cases turned out to be a 4-Aha! problem, because there was a little hole left over, which people would often get around to asking about: Why do we write down system internal actions (such as "check that the account has a high enough balance before giving out money"). The goal-subgoal business doesn't explain that. We used to answer, "Because these are requirements, that's why. If you don't write them, you'll get the wrong system."

The 4th Aha! came (no doubt at the coffee shop) a few years later, when I realized that a system's design enforces a contract across competing interests of various stakeholders, and that the use case describes the contract to be enforced. This introduced the stakeholders and interests model, which closed the gap. We now can say that every sentence in a use case describes a stakeholder's interest that must be satisfied or protected ... and now it is clear why we write all the validation checks in the use case.

I still wasn't going to write a book on the subject, because I thought my original article was sufficient, but around 1999, I got so scared by all the terrible book proposals I was having to review that I decided I had to publish a book just I wouldn't get stuck having to teach out of someone else's. That, combined with the construction of my class on the subject, and my just having coached a team at Fireman's Fund Insurance Company, indicated that I had enough information to write a "Shu"-level technique book.

You ask for examples of real use.

I'll give you two, my first and my most recent, which happen also to be my biggest and my smallest projects, the least agile of my "agile" projects, and possibly the most agile of my "agile" projects. The usage of use cases is quite different between the two. I'll also say how I recommend using use cases on modern agile projects.

The first project I call Winifred. It is written up in detail in "Surviving Object-Oriented Projects", and I reference it quite a lot because it was a very interesting and educational project, and I got to see it from initial bid until delivery and payment.

It was interesting for this discussion because I had just gotten done with my use case theory, and I got a call from the IBM Consulting Group field team to hurry up and go out to a project with 180 freshly written use cases (written in "casual" style, per my book). We used what I had plus what they had written to construct finally about 240 use cases, casual style, captured in Lotus Notes, to be used as the formal contract between the IBM Consulting Group and it's client.

It was a fixed-price contract, so we spent two months writing, examining and estimating those use cases, the interfaces, the estimated domain complexity, the people we could hire, etc. All of us were itchy-fingered programmers, and we were nearly gnawing on our fingertips from the frustration of not being allowed to start typing. However, since the contract was fixed-price, at about 15M$, we weren't allowed to start programming until the contract was signed on all sides.

Our incremental delivery cycle was 3 months; we did incremental and iterative development within each cycle, for about 9 weeks, followed by a 4-week debug-and-deliver cycle. More about this is written up in  Using both incremental and iterative development, so I won't repeat it all here.

My current project is the exact opposite. I'm trying to replace the Media Wiki engine running my website, because I think Media Wiki is crippled when it comes to any media besides text and images (but never mind that for now). What's interesting is that this is not a fixed-anything project, it consists entirely of one programmer and me. I pay for it out of my pocket, we pair-program whenever we're both available, and he/we work on it about one day a week.

So according to modern agile theory, we'd never write use cases for it, right? Wrong. I still need the basic advantages of use cases (see http://alistair.cockburn.us/index.php/Why_I_still_use_use_cases), like having some idea of where we're going, how big the project is, where we are, contextualizing our work.

Therefore, I wrote really really light use cases, and replaced the extensions with "work tokens" (I don't like either of the terms User Stories or Features for this level of granularity). My programmer friend and I peel off a work token to implement, then check how we're doing against the big picture given by the use cases. We're currently going through the use cases to see what's the mimimum we have to do before we can replace my Media Wiki engine with the new engine. Cross your fingers! (If you are reading this some months after I wrote it, with luck you'll see the new site. Compare it to Wikipedia).

These use cases are shown at http://alistair.cockburn.us/index.php/Examples_of_ultra-light_use_cases

What I recommend to a project team doing hard-core agile and using use cases is a little different from either of these. It is described in http://alistair.cockburn.us/index.php/Agile_Use_Cases.

Write the use cases as in "Writing Effective Use Cases." You probably won't have more than 30 of them.

Print out the one(s) you are working during this month or 3-month period, in 16 point font. Tape them to the wall of your work room (you are in a team room, aren't you?). Take a yellow highlighter and highlight in yellow the particular sentences you are working on this iteration or sprint. Color them green when they are done.

Now you can show what you are working on, what is complete, and what has been left out, at any moment in time. You'll get the benefits of use cases and user stories and agile and incremental and information radiators, etc.

P.s. typically, the first "story" or work token to implement in a use case is the first and last sentence of the main success scenario.

One last thing, since this is supposed to be an interview and not a tutorial on use cases (never mind that you asked for a bit of a tutorial).

Most researchers and writers write whatever's on their minds at the time, not really caring if it is right or wrong. I recall a professor telling me that this (some) particular author was famous for his first book – which turned out to be all wrong, but never mind that, because he got famous for it, and then got famous again for his later book which refuted his first book.

I recall at the time thinking, roughly, "Yuck! That's just bad research!"

Then I found that almost everyone does this. Booch wrote his methodology back in the 1980s, then spent half the 1990s recanting and cutting stuff out. I used to tell people to stick with him, he'd get to the right answer sooner or later ... but they could join me and I'd just tell them the right answer now ;-)

When I was given the assignment in 1991 to write a methodology, I made two rules for myself:

1. Always honor the programmers in their job activity, because if they leave, the company ships nothing, no matter who else is around; on the other hand, if everyone else leaves, the programmers can still ship useful software.

2. Try not to have to recant. This meant, for me, to be correct and err on the side of leaving good things out, rather than sticking bunches of stuff in and having to do like Grady and take stuff out.

I've been fairly successful in those two rules, particularly the second one.

My first methodology in 1992-3 only had incremental development, use cases, responsibilities, and code. I added design patterns in 1993-4. I added more stuff for the Project Winifred project, but only temporarily, for that project. Crystal Clear has some more stuff, but nothing I think I'll need to recant about. In general, my error, if any has been to underspecify than overspecify, and I'm still happy with that decision. We'll see how long it goes before I have to recant on something.

Q3 Alistair Cockburn

Q3. Have you ever worn a cowboy hat or flares?

Yes.

I had lime green bell-bottoms and blue platform shoes with about an inch of toe platform and two inches of heel platform. Really. Hopefully all photos have been destroyed.

Back in the late 1970s, I was one of those disco people. I pretty much stopped dancing disco after "Saturday Night Fever" came out in 1977 and John Travolta stole my moves :-). The movie did fire up disco popularity for a while, and I had a short gig as a professional disco dancer at a place where we were supposed to be the seed couple to get other couples up to dance. Really.

I got into trouble with the mountaineering ski crowd because I'd wear my black shiny plastic disco-style windbreaker to go back-country skiing, instead of the "just-rolled-out-of-the-garbage-can" polypropylene and wool outfits that constitute official uniform in that crowd.

When I moved to Utah (1975) I got myself a good cowboy hat, cowboy shirt, and cowboy boots (still have them, and they still fit). I scared the dickens out of my girlfriend when she came back from a summer vacation and I picked her up wearing all that. She nearly climbed out of my beat-up 1963 VW beetle when she turned on the radio and it came on with cowboy music. "Just kidding" plus a fancy dinner and lots more cleaned that up.

You can tell I'm culturally sensitive ;-)

Q4 - Alistair Cockburn - The Books

Q4 - Tell us about your books.  Which order should I read them in and what would I get out of each of them?  Which one are you most proud of?

Well, there's something like 8 books (depending on what the definition of 'is' is, and 'book' and 'your'). Here are some unpublished notes about them ...

Surviving Object-Oriented Projects was a summary of my investigations and project debriefings in the early 1990s. It contains snapshots of the projects I debriefed that led me to to recommend the kinds of things I do. Very little of it is specific to object technology, most of it is about what makes projects succeed and fail, how to staff for experimental versus production projects, project management strategies, and of course, how object oriented programming affects things. I still meet people today who tell me this is their favorite book of mine.

I succeeded quite well with it, with one exception. I wrote an appendix at the back called "Project Management Patterns". One of the reviewers (in 1996) complained bitterly about me getting on "the patterns bandwagon" and suggested strongly I drop the term "pattern".

Seeing that "pattern" is synonymous with "strategy", I did a global search-and-replace of "pattern" to "strategy" (and "patterns" to "strategies"). The surprise was that there were literally no further editing changes to clean up the wording change! When I submitted the appendix to PLOP 96, I changed the words back to "patterns", and after incorporating their recommendations, changed them back to "strategies." Try it – you'll find that most patterns are nothing more than strategies!

However, it turned out that my reviewer was completely wrong! and I was a fool to listen to him. Had I stuck with the word "patterns", I could have kicked off a project-management patterns movement, whereas as it now stands, few people have any idea that there are a dozen project management strategies sitting in the back of that book. Foo.

Nonetheless, I got permission from my wife to put all the proceeds from the book into a separate savings account for a little sports car. In 1999 I had $20,000 in the account, so I went to the local Mazda rep, showed her my screen saver image of a silver Miata, told her I had exactly $20,000 in the bank from my royalties, and lo and behold! She turned up with a silver 1999 Miata that, after taxes and registration came to $19,986. My son and I picked it up and bought ourselves (a small) dinner on the way home with the remains of the saving account.

– Note on creating a macro-structure –

I spent weeks drawing pie charts and mind maps of topics to make sure that it contained the full range of topics without getting stuck in any job speciality. I'm not really a mind-map person, but I tried it. What worked for me in the end was a three-layer pie chart, the inner pie showing % of space allocated for the major topics (chapters), surrounding circle showing % of space for major headings, some third-level breakdowns in a third surrounding circle. From these percentages I could calculate how many pages to spend on each topic (I knew I wanted a 300-page book, so I just did the math, then wrote that many pages on each topic.)

I can recommend this as one way to structure your book. Keeps it to size (and I know _many_ authors who could benefit from this discipline).

– Note on writing style –

I used to write really complicated sentences (still do, given half the chance). I ran across the book Revising Business Prose, a short, small easy-to-read, 80-page paperback, which taught me to write short, active sentences. I took one entire pass through the book splitting compound sentences, choosing shorter words and eliminating adjectives and adverbs. The book was much the better for the change. Try the book, I believe you'll like it. (p.s. I only used the advice in the first half of the book.)

– Book 2 –

Crystal Clear was the second book that I wrote (1999). However, XP was just on it's ascendancy at that time. I decided I couldn't compete with it's popularity, so I stuck the book draft on my web site and let it sit for five years, until friends pestered me to get it published just so some people would see that there is an alternative to XP.

Amazingly, a professor Chris Jones, then at Weber State University in Utah, found the draft on my web site, downloaded it and made his students use it for their semester projects - And he never even wrote to me! I found out years later when talking with his son Nate during an agile roundtable. Chris Jones later used my brand-new undergraduate software engineering text – while I was writing it, in real time! Talk about someone willing to experiment.

– Book 3 –

At that point I signed a contract to write a book series! Which meant I needed to write the zeroth book in the series, the anchor book. This was originally entitled Software Development as a Cooperative Game. I started drafting it in 1999.

– Book 4 –

But while I was drafting that, I was being deluged with catastrophic book proposals about use cases. I decided if I wasn't careful, I'd find myself having to teach out of them. Out of desperation, I scraped my hard drive for whatever I had on use cases and overnight submitted a 100-page book proposal for Writing Effective Use Cases. That was put on the front burner and came out late in 2000 – and has been paying my mortgage ever since.

– Note on macro-structure –

I'm famous for not finishing books. I generally run out of energy by half-way through the book (as, for example, Revising Business Prose, which is really short, but I still only read half of).

So for each of my books, I've worked hard to arrange that all the really important stuff happens in the first half of the book, preferably before page 100. The hard part, of course, is what to fill the second half with. I toyed with rubbish generators, but concluded that some readers would actually read the back half of the book and complain. So I fill the second half of the book with helpful-but-not-critical information. Dedicated readers can then mine the back half for extra goodies.

– Book 3, again –

I got back to The Cooperative Game, whose writing was redirected by the writing of the Agile Manifesto. The publishers renamed it Agile Software Development, even though the book is much more general than just agile.

What was fun about this book was that I got to design the page size, 2-column layout, typography, and even ran its production. We had a tight deadline to get it out by OOPSLA 2001, so I used all the advice in the book in doing the copyediting, illustrations, layout, etc. We shrank the time-to-production from 5 months to 5 weeks!

For example, at one point the copyeditor was resisting meeting me for a discussion. I started to explain why it would be useful to meet. She said, "I know all that – I'm editing that chapter!" :-)

The first edition of Agile Software Development was and still is my favorite book, because of the Introduction and first two chapters. It was the book I had long wanted permission to write, because in it I got to talk about the nature of communication and humans. Without the first two books behind me, I'm not sure I would have felt brave enough to write it.

– Note on macro-structure –

I had trouble getting the macro-structure of this book. The pie charts didn't work. What solved it was Writing For Story. Where Revising Business Prose teaches how to edit single sentences, this book teaches how to construct the macro-structure. Using it, I constructed the Agile book as a sort of mystery story, where every chapter resolves certain tensions but introduces new tensions to resolve. Take a look at Writing For Story and see.

I failed on my strategy of making the second half of the book "goodies", although I did get the most important information in before page 100 (my publisher wrote me just as the book was gong to press, "I'm just readng the book now – I'm up to page 80, and you still haven't gotten to the meat!" I wrote back – "That IS the meat!").

So this book is really two books in one – the first halves of two books, glued together.

– Book 5 –

All this time, Steve Adolph, Paul Bramble, Andy Pols and I had been trying to write a patterns version of Writing Effective Use Cases. I was also working on my doctoral thesis at the University of Oslo.

It was all too much, and I withdrew from the Patterns for Effective Use Cases after we worked out the pattern language. Steve and Paul invited my back onto the author list just before publication, but I thought that would take too much attention away from the work they had done, so Andy and I put ourselves as "contributors".

– Book 6 –

My doctoral thesis, which I completed late in 2002, was entitled People and Methodologies in Software Development. It was intended as the academic version of Agile Software Development, just as readable, but with the necessary attention to research method and full of researh citations. I gave my Agile book to the examining professors, and my thesis to Addison-Wesley. AW never got around to publishing it :-(.

Part of the point of writing the thesis was to let people who had read Surviving OO Projects and who had heard me rumble on for years about my project debriefings, get a closer look at what those debriefings and interviews looked like. It was also to answer the question, "Can methodologies ever converge?" (The answer is No, we'll need an ever-increasing number of them, which means they should be really really easy to construct).

– Note on macro-structure –

I rewrote this thing 3, 4, or 5 times. What cracked the problem was Lars Mathiassen cornering me and saying – "A thesis should answer three questions. You know those answers, don't you?" I said, "Yes." He said, "What are the three questions those answers answer?" I told him. He said, "Good – Start by saying what the three questions are, then answer them."

Egad! So easy! (after the fact). That's exactly what I did, and I still like the structure of the book: No windup, it just starts running at full speed. I wish more dissertations did that.

– Book not! –

My next book was supposed to be the project management patterns book, but the Agile Development Conference got in the way – I spent two years creating and babysitting that before the AgileAlliance took it over, and by that time I was already past the PM patterns topic – the book had "written itself" in my mind and my body didn't want me to take the time to write it onto paper. Shucks. I really miss that book.

– Book 2, finally! –

Finally it was time to dust off the Crystal Clear book and blow the cobwebs out of the words. It had been intended back in 1999 for people who didn't have any notion about small-team, incremental-iterative development. What a change in the intervening five years! By 2004, thanks to XP and agile, those topics didn't need any defending.

Crystal Clear: A Human-Powered Methodology for Small Team is currently my second-favorite book, because it covers pretty much the full set of topics needed by a team, with concrete examples of each artifact needed.

While writing it I discovered that project properties are much more powerful than methodology rules. Instead of saying, "Follow these rules, and good things will show up," I found it stronger to say, "Here are some good things to have show up – Ensure that they do!" And then let the people on the team find ways to get them to show up.

– Book 7 = Book 3, revised –

By 2006 it was time to update Agile Software Development, because five years had passed since the writing of the agile manifesto, and there were five years of discussion and misunderstanding to deal with.

After this revision, Agile Software Development: The Cooperative Game had become three books –  a 100-page book about people, a 100-page book about methodologies, and a 100-page book about agile development. If you read it, you might like to approach it in this way.

– Book 8, unpublished –

In fall 2006 I started on my next book, tentatively titled Software Engineering in the 21st Century, an undergraduate textbook for third-year undergraduates in a semester-long course. Neil Harrison and Chris Jones agreed to teach it in two separate courses while I wrote it in real time underneath them! Brave or foolish, we did it that fall term. I turned in 20 pages of book, powerpoint lecture slides, homeworks and class activities, twice each week, Monday and Wednesday. That was a wild ride (and it took me months to recover from the exertion, because I was consulting, teaching and traveling at the same time).

That book isn't out in paper form, because I don't have a publisher. I may publish it in pieces on my new web site.

I like this book, because I got to incorporate everything I knew and a bunch of stuff I didn't, all the latest and greatest ideas I could find about modern software development, cut down to the size suited for undergraduated. You can read about this book and course on my web site.

That leaves me with two books outstanding (PM strategies and the undergraduate SE book) plus a zillion more trying to get out. I'm literally limited by typing speed.

Which do I like best? Still the first edition of Agile Software Development. It's thinner than the second edition (I like the heft of the thinner book), and it contains that Introduction I enjoyed writing so much.

Which should you read first? Dunno – what's your reading style? Some people like Crystal Clear because it's the most concrete, some like Agile Software Development because it's the most theoretical. Some like Surviving OO Projects because it's contains the most project pragmatics. These three actually form a sort of trilogy, and I wish they could be bought as such.

Only read Writing Effective Use Cases or Patterns for Effective Use Cases if you're in the use case business, because they are really sharply focused to that specific topic.

Read People and Methodologies from my website if you're curious about my project debriefings or the argument that methodologies are transient and should be picked up, used and thrown away like tissues.

Go and get lost in the (currently) 800 content pages on my web site if you want more of anything. http://Alistair.Cockburn.us.

Q5 - Alistair Cockburn

Q5 - Tell me about your consulting work.  What do you like most about it?  Least?

 

This one should be short :).

 

What I like is that I get  control my own time. I can say 'No' once my travel schedule hits a certain threhhold (50%). That was actually the reason I quit IBM – they put me permanently in the field, and I started traveling 5 1/2 days a week, coming home Friday night and leaving Sunday afternoon. I lasted 3 weeks and then turned in my resignation. The primary immediate advantage I got was the ability to say No.

 

The second advantage, related, is that it's my own business, so when I work overtime, I know who's benefitting from it – and it's me! (Not some corporate stockholder or exec shooting for a bonus). Then, when I'm not actively working, I know what I'm dong and why – I'm changing baby diapers (OK, that was back in 1994), helping kids wth homework, going shopping, or going swimming. When I was an employee, that was all "the other me, the one outside work". Nowadays, it's all "just me", whether I'm filing papers, doing bills, shopping, consulting, teaching, writing, hiking, inventing flip-flops, whatever. There is "work me" and "home me", there's only Me. That's a really freeing feeling.

 

On the downside, my brain can never shut off. I call it "riding the fences" (rancher duty – making sure cattle can't go through a hole in the fence). It's a little process that runs all the time. I can't stop it. Invoices, clients, the work pipeline, the bills. I've met other small company owners who tell me the same story.

 

The other, and from my perspective, biggest downside, is that I don't have professional colleagues to trade notes with and learn from. It turns out that keeping up with all the new technology is done much better in an office situation – there's all this osmotic communication about the new browser APIs or Google's new products or something about the Eclipse interface or ... or ... or ...

 

Taking it all together, I'm much happier being on my own.