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.
Comments