Alistair Cockburn

Articles in Crosstalk Magazine

Over the years, I’ve had a number of articles in Crosstalk magazine (hosted out of Hill Air Force Base). I’ve included some on my web site, but their formatting is frankly better. Try reading these:

(Note 2011 – they moved all their articles! trying to track them down)

Date Article Oct, 2002 Learning from Agile Development - Part One Nov, 2002 Learning from Agile Development - Part Two Nov, 2004 What the Agile Toolbox Contains Feb, 2006 A Governance Model for Incremental, Concurrent, or Agile Projects April, 2007 What Engineering Has in Common With Manufacturing and Why It Matters May, 2008 Using Both Incremental and Iterative Development Aug, 2008 Good Old Advice Jan, 2009 "Spending" Efficiency to Go Faster July, 2014 Disciplined Learning: The Successor to Risk Management

Re: Crystal Methods (or How to make a methodology fit) 180

Hello
I’m interested in learning about the Crystal methodologies, especially for the Crystal Clear
I need to select the methodology for developing my undergraduate thesis.
Thanks

-by Giuliana Collantes on 6/15/2015 at 12:01 PM

Hi, Giuliana, thank you. The book is available on Amazon, it explains everything.

Re: Using the Heart of Agile on the problem of scaling

Hi Alistair

I’ve been experimenting recently with Strategy Deployment to help large organisations figure out “how do we know if Agile is working?. This generally involves exploring with them what end results they aspire to, and then what strategies they think are needed to make the breakthroughs required to achieve those results.

I can imagine using the Heart of Agile as a guide to identifying what those strategies might be, and then show how specific tactical initiatives to implement Agile practices correlate and contribute to those strategies.

Thanks

Karl

-by Karl Scotland on 6/13/2015 at 4:11 PM

thank you.

Using CRC cards

Humans and Technology technical memo HaT TR.99.01 (dated 99.03.11)

© Alistair Cockburn

You are welcome to read it and use what you learn. You may post a link pointing to it, but be aware that the link may change or vanish (like any web link).

Other related pages you should look at are: Responsibility-based modeling and Ward Cunningham's page. There are also books on the subject.

What it is

CRC stands for “Class-Responsibility-Collaborator”. It names a brainstorming technique that works with scenario walkthroughs to stress-test a design. It also supports a rapid and thorough exploration of design alternatives. It may be used during initial model construction as a brainstorming technique, and again later to evaluate the design. It may be done by one person, or up to 5 people, after which it needs careful facilitation.

In a CRC exercise, a card or piece of paper is made to represent an instance of an object type. Its responsibility is identified, either by invention or writing it from the object type definition. A use case scenario is begun. Someone talks through the scenario, and one or more people show the objects that work together to deliver the scenario. When one object uses another, the second object is said to be the first object’s collaborator. The names, the responsibilities, and the collaborations summarize the design at a low but accurate level of precision.

Relationships to other techniques

Responsibility-driven modeling may be done with CRC cards, or from an object interaction diagram, or from an object type diagram. CRC sessions are more fluid and support faster design evolution, but are more prone to confusion. Working from object interaction diagrams is slower and serializes discussion, which can be useful to check a design or to pace the discussion in a group. Working from object type diagrams is mostly useful for testing a design.

Steps

Refer to Responsibility-based modeling for more text. This section is a summary.

  • Step 1. Decide to use CRC cards and choose an coherent set of use cases

Decide to work with CRC cards as opposed to or in conjunction with object interaction diagrams and object type diagrams.
Select a set of use cases which look as though they will touch a related set of object types. These provide the scenarios for the group to walk through.

  • Step 2. Put a card on the table

Put a first card onto the table to represent the external actor who triggers the use case.

Put a second card on the table. This is the card to whom the first card will send its initial message.

Alternatively, put cards onto the table for all the known, relevant object types, and label the cards with their main responsibilities.

  • Step 3. Walk through the scenario, naming cards and responsibilities

Walk through the handling of a scenario of the use case, pointing to or picking up the cards, naming their responsibilities and how they handle and delegate each request.

In a brainstorming session, add new cards as new functions are needed, or reallocate the responsibilities of the cards already on the table. It is not always necessary to name both the object type and the responsibility at the moment the card is put onto the table, as long as they are both written before the end.

  • Step 4. Vary the situations, to stress test the cards

At any time during the walkthrough, you may vary the assumptions on the use case, to see if that causes a shift in the handling. With a good design, the handling is the same, but with the addition of a future object, or the change to at most one card.
If it is decided a new object is needed to create a more stable design, add a new card, with the needed responsibility put onto it.
Not all the cards on the table need be used; some may drift out to the sides if they are not used much. The cards that are needed at the end are those that get put into the design.

  • Step 5. Add cards, push cards to the side, to let the design evolve

CRC cards permit several design alternatives to sit on the table at the same time. An unpopular initial design may turn out to be a popular later design, or perhaps the final design is a small alteration of an initially rejected design.
Do not throw cards away, but push them to the side, in case it turns out later they are useful.

  • Step 6. Write down the key responsibility decisions and interactions

Often, the design turns around a few key decisions about the allocation of responsibilities. Write these down.
It is not useful to draw interaction diagrams for all the scenarios considered, but it is very useful to draw a representative few.

End Note
Often, while one group of people is discussing the cards, another person gets an idea for a better design and sketches it out on paper (typically, using an instance diagram), and then, when it is complete, shows it to the group, who move it into the cards. This is very effective, since it allows quiet, thinking time to mix with sharing and evaluation.

The typical resistance modelers feel to CRC cards is that it involves designing in groups and out loud. This resistance is what causes CRC not to be practiced as much as it might. Modelers are more comfortable staring quietly at instance and object type diagrams.

Using the Heart of Agile on the problem of scaling

The HeartOfAgile is a return to the center. Scraping away, for a moment, all the decorations that have grown around agile implementations, I find these four actions neatly describe the heart, or the spirit (心), or the center (discussion: Re: Shu Ha Ri Kokoro) of agile:

  • Collaborate
  • Deliver
  • Reflect
  • Improve

The nice thing is that we already understand what they mean (with the possible exception of “Reflect”, which people do all too seldomly). There is no vocabulary to teach. In practice, each of these can be as deep and complex as you like. in the Shu Ha Ri (discussion: Re: Shu Ha Ri) line, there are certainly Shu level techniques for each of these, and the Shu-Ha progression of learning and practicing. However, in the spirit of the Heart of Agile, one should return periodically to the center, scrape away all the Shu-Ha business, and look at those four actions.

The Problem of Scaling

Scaling is a real topic, not a false one. Imagine that you have just been named CEO of IBM, or AT&T, Verizon, or Telstra. You have been steeped in small-scale agile for years, and understand its workings and its values. Now you are given an assignment to run an operation with many lines of business, many platforms, many technologies, and many locations. How do you approach this situation?

Simply replying, “Reduce the company to 50 people and use small-scale agile” is a non-answer, I hope you can see. The situation is real, and deserves a real approach.

I am somewhat skeptical that “agile” as we are familiar with it, functions at this scale. The overarching topics are those of

  • competing personal agendas and reward systems, and
  • broad mental change in attitude.

Neither of those are unique to agile, rather, they are part of all large organizations, whether companies, volunteer organizations, NGOs, or government. The question is, how do we make any progress on those two difficult topics.

All of the agile scaling approaches try to introduce change by introducing vocabulary. Normalizing vocabulary has its value, but it doesn’t change behavior.

Thinking about the problem with the Heart of Agile in mind, I propose going directly after the behavior, prohibiting discussion of vocabulary.

Imagine asking these four questions, over and over, relentlessly:

1. Independent of anything else going on, how will you increase collaboration?

2. Accounting for everything else going on, how will you increase trial and actual deliveries to consumers?

3. How will you get people to pause and reflect on what’s happening to and around them?

4. What experiments will your people do at different levels in the organization to make a small improvement?

In this approach, people can’t hide behind the learning of new vocabulary or the shuffle in job titles and org structures. There is nothing but attitude and behavior to work on.

Will this work? I don’t know, but I doubt it can work worse than the alternatives. Frankly, I’d like to try it. Or rather, I’d like you to try it.

Alistair

Re: Shu Ha Ri Kokoro

That’s an interesting observation, Alistair, thanks for sharing.

I am a martial arts practitioner, and my sifu always says:
“In the end, the form is formless.”
For me, this always was synonymous with Ri level and implied an intangible simplicity. Obviously, I am surprised that you see the slope of complicatedness going downward after we have attained Ri level.

I would love to learn more about the differences you see between Ri and Kokoro.
Could you go into more detail?

Thank you
Urs

-by Urs on 6/8/2015 at 2:37 AM


I will reflect on your request, because the reply can’t be so easy. When I am consulting, and people ask questions, my answers vary all over the place. That’s “ri”. When an experienced facilitator walks into a room and the chairs and tables are all wrong for the meeting type, they adjust in surprising ways. That’s “ri”. And also complicated. When cooks substitute ingredients, that’s “ri”. In all these cases, they indicate that it is too complicated to describe what they did. “I just do it.” That’s “ri”.
On the other hand, when a super-expert is teaching, he or she keeps saying, “Just focus on the basics, just focus on the basics.” That’s kokoro. I took a few lessons from a tango teacher who taught this way: “You open up here, and create a ‘situation.’ Now, I don’t have to teach you the next steps, because all you have to do is ‘resolve the situation.’” That’s kokoro, and why I went to take lessons from him. I want to dance by just opening situations and resolving them :).
The transition from indescribable, different ways of doing things, to seeing all the variations as just variations of the basic is not transition I have ever watched. But I have seen people, and writings by people, on both sides of that line.
That’s all I have for now. Your question is difficult.
ps. I think “the form is formless” is “ri”. Seeing things as the basics is not the same.

-by Alistair on 6/10/2015 at 1:28 PM

Shu Ha Ri Kokoro

I just learned that it is possible to continue growing after Shu Ha Ri (discussion: Re: Shu Ha Ri). I call it 心, “kokoro”.

守 – shu
破 – ha
離 – ri
心 – kokoro


Kokoro simplifies.png

(Aside: I like that the Kanji characters reflect this curve, with the characters getting more complicated from 守 shu to 破 ha to 離 ri, and then getting simple again for 心 kokoro. Nice :).

As a beginner, we start with some technique. Shu. 守. We follow our instructions, as exactly as we can.

As we grow, we run into situations the shu-level technique doesn’t handle well. We look for other techniques. Ha. 破. Things get more complicated.

If we are lucky, we master at the reflex level, and every time is different, and natural. Ri. 離. However, it is all so complicated and interwoven at this point that we can’t explain anything.

True masters are annoying. “Learn the basics,” is all they say. Of course, in their hands, the basics seem to take on an infinite number of shades, but they keep just saying, “It’s just the basics. Wax on. Wax off.” This is the stage where they make things simpler again. I call this stage “kokoro”, 心, which means “heart” or “spirit”. The master learns how to live in the heart, the center, the spirit of the thing, and draw variations from there.

“Jiro Dreams of Sushi” is a story about getting to kokoro.

I discovered 心 “kokoro” as I was working out the HeartOfAgile.

Rediscovering the Heart of Agile

All through 2104, I found myself saying: “Agile has become overly decorated. Let’s scrape away those decorations for a minute, and get back to the center of agile. The center of agile is … ”

Craig Brown said I needed to get clearer and tighter about that thought, give it a name and drawing.

The name “Heart”

I wanted to honor a minor tradition of looking at Japanese words. They are sometimes more revealing (possibly because being outside my native language, triggers different associations). I found “chu shin” ( 中心 ), which to my untutored eyes should mean “center of the heart”. How perfect could that be! However, my Japanese colleagues said that phrase is too ordinary, used for the center of a circle or a city.

Reading further, I found just 心, which when standing on its own, is pronounced “kokoro”, and means “heart” or “spirit”. It is used by Miramoto Musashi in his Book of Five rings when he wants to talk about the heart/spirit of swordsmanship. In other words, it’s perfect for my uses. It is used with the genitive “no” ( の ), so one would write “Agile の心” or “Agile’s heart”. The word “heart” also works in English, for heart, soul, center, spirit. Hence, heart.

Kokoro extends shu – ha – ri, see Shu Ha Ri Kokoro. Another good reason for choosing it.

The Diagram

I watched over a short period how I talked in my beginner classes and my advanced classes, and found that when I was encouraging getting back to the center/heart/spirit of agile, I kept emphasizing these four things, and drew them in a diamond:

- Collaborate
- Deliver
- Reflect
- Improve


The 4 actions at the heart of agile

The Words

The nice thing about these four words is that they don’t need much explanation. They don’t need much teaching. With the exception of “Reflect”, which is done all too little in our times, the other three are known by most people. You know if you’re doing them or not.
So simply saying, “Collaborate. Deliver. Reflect. Improve.” already says most of what you need to say and do.
Each one unpacks into unendingly complicated skills, actions, tools, and all. Each is rich with nuance. And still, we can fold back up all the nuance and complications, and remind ourselves: “Collaborate. Deliver. Reflect. Improve.”

The heart/center/spirit of agile. Agile の心

What’s Next?

I created the funny little “fortune teller” – the first unfolding of the four words (Heart of Agile fortune teller.pdf) – just before giving the first public talk about the Heart of Agile at the Agility and Beyond conference in Dearborn, MI late April, 2015. The fortune teller is now available, and has become an interesting teaching tool in its own right.

Stay tuned to see what’s next :).

HeartOfAgile

This is a reminder to get back to the original spirit of agile:

  • Collaborate
  • Deliver
  • Reflect
  • Improve

All through 2104, I found myself saying: “Agile has become overly decorated. Let’s scrape away those decorations for a minute, and get back to the center of agile. The center of agile is … ”


Craig Brown said I needed to get clearer and tighter about that thought, give it a name and drawing.


The name “Heart”


I wanted to honor a minor tradition of looking at Japanese words. They are sometimes more revealing (possibly because being outside my native language, triggers different associations). I found “chu shin” ( 中心 ), which to my untutored eyes should mean “center of the heart”. How perfect could that be! However, my Japanese colleagues said that phrase is too ordinary, used for the center of a circle or a city.


Reading further, I found just 心, which when standing on its own, is pronounced “kokoro”, and means “heart” or “spirit”. It is used by Miramoto Musashi in his Book of Five rings when he wants to talk about the heart/spirit of swordsmanship. In other words, it’s perfect for my uses. It is used with the genitive “no” ( の ), so one would write “Agile の心” or “Agile’s heart”. The word “heart” also works in English, for heart, soul, center, spirit. Hence, heart.


Kokoro extends shu – ha – ri, see Shu Ha Ri Kokoro. Another good reason for choosing it.


The Diagram


I watched over a short period how I talked in my beginner classes and my advanced classes, and found that when I was encouraging getting back to the center/heart/spirit of agile, I kept emphasizing these four things, and drew them in a diamond:


- Collaborate

- Deliver

- Reflect

- Improve




The 4 actions at the heart of agile


The Words


The nice thing about these four words is that they don’t need much explanation. They don’t need much teaching. With the exception of “Reflect”, which is done all too little in our times, the other three are known by most people. You know if you’re doing them or not.

So simply saying, “Collaborate. Deliver. Reflect. Improve.” already says most of what you need to say and do.

Each one unpacks into unendingly complicated skills, actions, tools, and all. Each is rich with nuance. And still, we can fold back up all the nuance and complications, and remind ourselves: “Collaborate. Deliver. Reflect. Improve.”


The heart/center/spirit of agile. Agile の心


What’s Next?


I created the funny little “fortune teller” – the first unfolding of the four words (Heart of Agile fortune teller.pdf) – just before giving the first public talk about the Heart of Agile at the Agility and Beyond conference in Dearborn, MI late April, 2015. The fortune teller is now available, and has become an interesting teaching tool in its own right.


Stay tuned to see what’s next :).

Some other pages about the Heart of Agile:

TitleCategoryDateModByAction  Keynote introducing Heart of Agile at Agile and Beyond April 2015.pdfTalks05/03/1505/22/15 20:03AlistairTidiededit Heart of Agile Fortune Teller in DutchHeart of Agile Category05/03/1505/22/15 20:03AlistairTidiededit Heart of Agile Fortune Teller in EnglishHeart of Agile Category05/03/1505/22/15 20:02AlistairTidiededit Heart of Agile Fortune Teller in Spanish (discussion: Re: Heart of Agile Fortune Teller in Spanish)Heart of Agile Category05/03/1505/22/15 20:02AlistairTidiededit Heart of Agile fortune teller.pdfHeart of Agile Category05/03/1505/22/15 20:02AlistairTidiededit Heart of Agile fortune teller in JapaneseHeart of Agile Category05/04/1505/22/15 20:03AlistairTidiededit Heart of Agile, Collaborate sectionHeart of Agile Category05/05/1505/22/15 19:58AlistairTidiededit Heart of Agile, Deliver sectionHeart of Agile Category05/05/1505/22/15 19:59AlistairTidiededit Heart of Agile, Reflect sectionHeart of Agile Category05/05/1505/22/15 20:00AlistairTidiededit Heart of Agile, Improve sectionHeart of Agile Category05/05/1505/22/15 20:01AlistairTidiededit Heart of Agile logo.pngHeart of Agile Category05/22/1505/22/15 19:47AlistairCreatededit HeartOfAgileHeart of Agile Category05/22/1506/05/15 22:06AlistairTidiededit What do I call the Heart of Agile methodology? (discussion: Re: What do I call the Heart of Agile methodology?)Blog (discussion: Re: Blog)05/23/1505/23/15 14:23AlistairCreatededit Heart of Agile logo200pxH.pngImages05/23/1505/23/15 14:18AlistairCreatededit Rediscovering the Heart of Agile (discussion: Re: Rediscovering the Heart of Agile)Blog (discussion: Re: Blog)06/05/1506/06/15 00:24AlistairTidiededit Kokoro simplifies.pngImages06/05/1506/06/15 11:18AlistairTidiededit Shu Ha Ri KokoroBlog (discussion: Re: Blog)03/31/1506/06/15 11:12AlistairTidiededit


Many people are lining up to help with this movement. Join in.

Get the Heart of Agile stickers from StickerMule at https://www.stickermule.com/marketplace/5639-heart-of-agile-sticker

Re: What do I call the Heart of Agile methodology?


This does remind me of the Lewis Carroll naming game in Alice Through the Looking Glass:

The name of the song is called “HADDOCKS’ EYES.”‘
‘Oh, that’s the name of the song, is it?’ Alice said, trying to feel interested.
‘No, you don’t understand,’ the Knight said, looking a little vexed. ‘That’s what the name is CALLED. The name really IS “THE AGED AGED MAN.”‘
‘Then I ought to have said “That’s what the SONG is called”?’ Alice corrected herself.
‘No, you oughtn’t: that’s quite another thing! The SONG is called “WAYS AND MEANS”: but that’s only what it’s CALLED, you know!’
‘Well, what IS the song, then?’ said Alice, who was by this time completely bewildered.
‘I was coming to that,’ the Knight said. ‘The song really IS “A-SITTING ON A GATE”: and the tune’s my own invention.’

heh.

-by Alistair on 5/24/2015 at 3:40 PM


It seems to me,, that this is more like the chicken and the egg,, are you sure of what comes first? If none of it exists? The metaphor a symbol of something abstract. As they say,,, all roads lead to Rome.

Thanks for all work and support
Willis

-by Willis Hale on 5/25/2015 at 6:31 PM

What do I call the Heart of Agile methodology?

Think I’ll call it:
“Do This: Collaborate, Deliver, Reflect, Improve.”

That should about do it.

So if someone asks you, “What is the Heart of Agile”? Say,
“Collaborate, Deliver, Reflect, Improve”

“How do we get started with it?”
“Collaborate, Deliver, Reflect, Improve”

“Are we in compliance with the Heart of Agile or with the Heart of Agile (ahem)Methodology?”
“Do you Collaborate, Deliver, Reflect, Improve?”

So instead of creating a name for a thing that isn’t the thing, let’s name the thing the thing itself:
“Collaborate, Deliver, Reflect, Improve”

Let’s try that out for a while and see what happens…

( “You can’t skip this ad because it’s already over”. :)

Nonlinear people and catastrophe theory

In Characterizing people as non-linear, first-order components in software development (discussion: Re: Characterizing people as non-linear, first-order components in software development), I talked about how a tiny, almost unnoticeale event can cause someone to behave in a way that is all out of disproportion to the triggering event. “Spontaneous and nonlinear” is the way I described it.

One time when I was facilitating a meeting, one of the execs made a quiet – what I thought was seemingly innocuous – comment to another one; and in the next break, the 2nd one quit the company! I have long reflected on that event, wondering how I might have detected or deflected that comment or response. It was “one straw too many – the straw that broke the camel’s back.”

Then, yesterday, I suddenly remembered Rene Thom’s Catastrophe Theory which is really nothing more than a pretty little picture that allows us to visualize this transition and make mathematicians happy because there is a formula for it.

The picture is this:
(http://www.exploratorium.edu/complexity/CompLexicon/cusp.gif)

The explanation of the math is that the function looks like a bedsheet that is flat at one end, and folded in thirds at the other. At some point, an unnoticeable crease shows up … a bit further along, there is a top and bottom … and that’s where the catastrophe stuff happens.

But the point for this blog post is that the function is like the person : for a long time, there is no discernable different as one goes from left to right, then, for no noticeable reason, at no discernable moment, there is actually a difference that is a jump. The person goes from irritated to quitting.

Just thinking out loud here …

The cone of silence and related project management strategies

Humans and Technology Technical Report TR 2003.01, Jan 1, 2003

A person managing a portfolio has the job assignment to keep an alert eye open to oncoming trouble and an educated eye open for opportunity, acting in time for both, prioritizing choices along the way.

Managing a project consists of exactly this. Whether the entire team shares the assignment, it is part of the team leader’s assignment or it is given to a dedicated role, whoever holds the assignment is supposed to detect and act on future hazards and opportunities. Only through some odd misunderstanding of project life has project manager come to mean “the person who orders the others around.” It should mean “the most alert and most proactive,” the person that responds effectively to signals. Perception and creativity are intrinsically linked to the job assignment.

As I searched out experienced project managers, especially those labeled “good” by their peers, their perceptiveness and creativity stood out clearly. I began cataloging some of the more interesting strategies that I had been using over the years, and discovered that I was not alone ; almost every team lead and manager has had to invent similar strategies in their “normal” project life.

This article is about one such strategy, invented during my third visit to a troubled project. The problem was completely standard — you will recognize it. If you have ever been a team lead, you have been there. I’ve been in this situation many times and never found a solution for it. The fact that we found a solution that worked this time is why I am writing this article. Of course, in retrospect, we found that many of us had naturally been using this strategy for years; but not having a name for it, we didn’t even notice it in our bag of tricks. The purpose of this article is to give a name and a setting, so you can apply variations of it yourself.

Before telling you the problem and its incredibly simple solution, I have to warn you: To pull off the solution, you need a supportive manager. Remember, a manager is supposed to act to avoid trouble and grab opportunity, balancing priorities? This is a story of how we got ourselves out of a tight situation, with the help of a manager who understood how to support her people. Please don’t write to me to say that you can’t apply this strategy because your manager won’t support this solution – a manager who supports her people in their assignments is the key ingredient to this strategy.

The Problem Setting

Jim is lead programmer and domain expert on a project of eight people (Jim, six other programmers, and Aaron, the project manager). Jim has worked on previous versions of the system. Mark has also worked on the previous system and has domain knowledge. However, he gets diverted daily from this project’s activity by a second boss he has. There is nothing we can find that will reduce the level of interruption he has from the other boss, so he pretty much gets washed out of the project in terms of effectiveness. The other five programmers, of varying abilities, have been added to the project to help Jim get the work done, mostly on the many little programming assignments that don’t need deep domain knowledge. Aaron was recently introduced to help offload Jim from bureaucratic work. Their manager is Lisa.

The six programmers work in partitioned cubicles in an area accessed by a short hallway. Jim sits in a private office coming off this short hallway. Aaron sits around the corner and farther down the main hallway.

Jim has this private office so he can close the door to get privacy, but otherwise be available to answer questions from the other programmers. At least, that was the big idea.

The idea backfires. Jim’s office is tiny, so he keeps it open a crack. Consequently, he sees everyone walking up and down the hall, and he gets asked questions multiple times an hour by the other programmers. He also gets visited or called out every time there is a question about either the schedule or the system architecture.

Oh, and of course, upper management decided to outsource future versions of the product, so Jim has to interface to and transfer knowledge to the outsource company. In short, like so many team leads around the world, he gets nothing done during the day, and is reduced to working nights and weekends. He has no spare capacity left, and is burning out, all without the project making headway.

In my first visit, we go over the project schedule, create a simplified project plan and determine three things. First, the team can’t get done in time. Second, the only person who can do most of the actual programming is Jim. Third, Jim is calamitously overworked. Note that it took most of Jim’s day to participate in this session, so he ended up one day behind for getting this information (all of which was obvious to start with, except for the simplified project plan). So far, this should like like very many software projects.

Attempted Solution #1

It is clear that Jim needs more design time and fewer distractions. So we make the usual promises.

We promise that Jim will not get disturbed for trivial issues. Aaron will take all non-technical interrupts, the new programmers will work together to train themselves on the domain, Mark will track and reduce his disturbances from his other boss (whom we cannot get rid of), and Jim will focus on his programming. He will only be interrupted for major questions.

Of course, this doesn’t work.

Jim’s office is small enough to be claustrophobic when the door is closed. Besides, he case hear people walking up and down outside his closed door, and he frets that something is going wrong that he should be attending to. He keeps the door open a crack.

The other programmers on the project just need to get their questions answered, so they ask Jim anyway.

Mark can’t do anything about his other boss, who, for reasons we needn’t get into, has the right to create high-priority interrupts multiple times a day, and does. In other words, he never gets sufficient time to offload Jim.

No matter how Aaron tries, there are still meetings that need Jim’s technical expertise on the project and scheduling matters. Jim still gets called out of his office, or the meeting comes to him.

The “obvious” solution isn’t working.

Attempted Solutions #2, #3

How about having Jim work at home? We try that, but it turns out that he doesn’t work well at home. Besides the set of distractions around his house, he can’t get the high-speed line he needs to link to the development environment. He has to work in the office.

There is one would-be strategy that usually doesn’t work but we have to try. It is Bundled Distractions (written with a line drawn through it, to show that it is a generally unsuccessful strategy). The idea is to create office open-hours for Jim, and have all questions and interruptions come in during those open hours. We decide that he will handle questions for half a day a couple of days a week.

As is usually the case, Bundled Distractions didn’t work. The team simply couldn’t hold themselves back from questions, Jim couldn’t hold himself back from being helpful.

Why do I bother to mention this strategy if it doesn’t work? I do so because it sounds so good, and so rarely works. In 30 years of project life including 10 years as a consultant, I have never seen it work on a project (although it seems to work with university professors). Nonetheless, it is a possible strategy, and we were desperate enough to try it.

Cone of Silence

Before giving up, we revisit the problem one more time:

Jim needs quiet time to focus, real freedom from distractions, and a high-speed connection to reach the development environment. He can’t work in his home or his office. In a reversal of the usual project priorities, it seems he can’t be close and available to his teammates, he needs to be invisible to them.

I ask one last time (I’m sure this suggestion got made and rejected at least once before in our deliberations) whether Jim couldn’t get a second office somewhere else in the building, far enough away that people won’t be bothered to walk that far to ask him a question, but where he still can connect to the office LAN and have the feeling of being at work. This would provide him with a “cone of silence” in which to get his work done.

Much to my surprise, Aaron, Lisa and Jim all say, “Yes, we could do that – that might work.” To this day, I don’t know why this suggestion didn’t get picked up the previous times it came up (I don’t know that it didn’t come up, I only suspect that it must have been suggested). I think that every strategy is appropriate for a particular level of desperation, and we were not desperate enough before to pay it any attention.

In any case, they get enthusiastic about trying the Cone of Silence, as the name sticks. I remain skeptical, because it seemed to me that Jim will get drawn into meetings just as much as before, but don’t say anything, because we really are desperate by this point.

What Happened

I didn’t see or hear from the team for several months. In a casual phone call one day, Lisa mentions, “Oh, that Cone of Silence is working really well.” Apparently, Jim really does go to that office, and other people don’t bother him. For the first time in over a year, he has enough quiet time to focus on his list of work. He concentrates, he is happy, he makes progress.

What about all the other people on the project, and all the distractions?

The others still have questions, and they entire team moves more slowly than before because their expert is gone, but they make adequate progress without Jim. Aaron and Lisa keep people away from Jim. Aaron steps in and makes project decisions mostly without Jim. Lisa reminds people of the project’s true priorities, which include Jim getting his work done as top priority, and almost everything else second to that.

More months went by, and I receive a call from Lisa again. Almost off-hand, she mentions that Jim is almost finished with his work, well ahead of the project plan we created on my first visit. I confess to be astonished by this news. My view was that that schedule was unduly optimistic. It seems, however, that Jim, a combination of domain expert and senior programmer, was able to move faster when left alone with his code than he predicted.

Why Did it Work?

What worked, and why did it work?

What worked was that Lisa, the manager above the project manager, correctly saw Jim’s progress as the single top priority to the project. Everything else was secondary. Unlike many managers, she was willing to bend rules to attend to satisfying this priority. She was able to find another office, and she kept everyone appraised of the importance of working on the other assignments without Jim.

I highlight Lisa’s role, because I have encountered many managers who insist on keeping everyone within their sight, who won’t go out of their way to get additional resources such as a second office for Jim, or who yield to pressure to bring Jim back to attend meetings and answer questions.

Lisa accepted that the rest of the team would have to “muddle through” without Jim; she correctly assessed that they would, in fact, be able to muddle through, though at a slower pace. Many managers would chicken out at the last instant and recall Jim.

What also worked was that Aaron, the project manager, supported Lisa in the strategy. He had to make himself conversant enough on the topics to make decisions along the way. Note that Lisa had to trust and support Aaron in getting to this level, and Aaron had to support the strategy in not running to Aaron with his questions. Aaron also had to keep the rest of the team from running to Jim.

Besides the level of support, there had to be a barrier, the Cone of Silence itself.

Normally, I recommend putting a project team close together, because research shows that generally, people won’t walk up a flight of stairs to get questions answered, or, as it turns out, even a couple of bends in the hallway [Allen98]. Normally, we want people to get their questions answered, and so we ensure there is no flight of stairs between them.

In this case, we needed that very barrier.

Strategies are Interlinked

Project management strategies do not sit in isolation. I wrote down a dozen strategies, lightly interlinked, in the appendix to Surviving OO Projects. I now find them heavily, not lightly, interlinked.

Osmotic Communication is a strategy is described at length in Agile Software Development. The idea is that teammates sit in the same room or adjacent cubicles, so that they overhear each other during their normal working day, picking up information in their background hearing. Even while not particularly conscious of it, they learn who knows the answers to which sorts of questions and what is happening on the project. They can ask questions without particularly raising their voice, and often can answer a question without particularly getting distracted from their current work. In the normal course of events, Osmotic Communication is the ideal. In our particular project, the Osmotic Communication was good for everyone except Jim. Cone of Silence__sets up the opposite dynamic to Osmotic Communication, sufficiently so that I will come back to these two in a moment.

Expert in Earshot is described in CockburnEiE]. The idea is that novice workers should work within earshot of an expert, in order to pick up good work habits. Like Osmotic Communication, the Expert in Earshot backfired in our situation, actively causing problems because the expert couldn’t get his work done. This backfiring is mentioned in the description of Expert in Earshot as the “overdose effect,” an apt description of what happened on this project.

Progress Team / Training Team is detailed in Surviving OO Projects, where it is given the cute primary name Day Care and the more descriptive name Progress Team / Training Team. I now think that the longer name is the better one. Cone of Silence implements Progress Team / Training Team, since the project needed Jim to make maximum progress, and the rest of the team was allowed to work at a slower pace as they learned their material.

Cone of Silence, then, permits Progress Team to be implemented, at the cost of Osmotic Communication with the expert. It is a deliberate move away from Expert in Earshot.

In general, I find that Osmotic Communication and Cone of Silence are two strategies that need to be balanced, usually with more of the former and only a little of the latter.

Variations on a Theme

A good strategy gets rediscovered many times. After we applied the Cone of Silence successfully, I searched for other situations and some varied ways in which it was done.

A similar implementation of the strategy. I was once in charge of a research project that ran with half a dozen people over a few years. Partway through, it became clear that we were a bit lost in terms of our project structure and plan. I made a deal with a sister organization to get use of a quiet office at their location for two days to rebuild the project plan — I had found our normal office environment too distracting to get two days of quiet time there. I sent an email to my boss, Elizabeth, on the Sunday night before I went, saying what I was doing. When I called in to the office to check for emergencies on the first day, my boss scolded me severely for setting up off-site work without her permission, and for disturbing the sister organization. What a difference between Lisa and Elizabeth! As you can guess, that destroyed any peace of mind I might have within my little Cone of Silence, and the two days were not as productive as I had hoped, although still better than staying at the lab.

A larger implementation of the strategy. I met a manager at a company that was having trouble adopting Extreme Programming. The company had a tradition of “off-sites,” which in their language meant that they moved an entire project team out of the office to a special off-site location for a short period of time — a weekend to two weeks — in order to make maximum progress on a targeted section of software. In the “off site,” they would set up Osmotic Communication and a Cone of Silence for the team. The odd part was that the resistance he ran into was that the people there considered XP as nothing more than extended off-sites, and they therefore wouldn’t try it! (The logic of that I leave as an exercise to the reader.) If their off-sites are so effective, I would think they would legitimize this setup as standard practice for all their projects. Can your organization manage to?

Two very large implementations of the Osmotic Communication with Cone of Silence combination were IBM’s development of the IBM PC in the early 1980s and Lockheeds Skunkworks facility following the second world war (nicely described in the book Skunk Works [Rich94]). In IBM’s case, the executives decided that they couldn’t develop the PC with the existing IBM bureaucracy and working style, so they shipped the team off to a warehouse to get some privacy, speed and informality in their work. Lockheed’s Skunkworks facility designed their most difficult, top secret military airplanes. They sat, deliberately crowded together, with different specialties within easy earshot of each other, in a facility cut off from outside distractions.

A small implementation of the strategy. I usually wear airport-style ear-muffs when I need to concentrate while working in a large room (18 – 20 db hearing protectors . . . I buy them at any local gun shop). I find that this cuts down the noise just enough that I can concentrate, but lets me hear if someone calls my name. I’ll take them on and off depending on how much concentration I need, thus balancing Osmotic Communication and Cone of Silence. Other people use music headphones to get the same effect. Sometimes they never hear their colleagues speaking, though, so they get too silence and not enough communication.

Reflections

Why did it take so long for us to recognize and apply the Cone of Silence idea to Jim’s situation?

Partly, we hadn’t reached the appropriate level of desperation earlier. We worked through the easier alternatives first, because those would cause less disruption to the project. If one were to categorize the level of desperation as the levels of a fire alarm (one-alarm, two-alarm, three-alarm fires send calls to that many fire stations), then we might say that BundledDistractions and the other strategies we started with are applied at the one-alarm level. Isolating the team lead in a Cone of Silence is disadvantageous to a project under normal circumstances. Only when we reached the two-alarm stage was it a worthwhile tradeoff.

Also, these project management strategies don’t yet have an accepted set of names and study literature. Jim Coplien and I have been deliberately collecting these strategies for a number of years. Jim collects mostly organization patterns CoplienOP, I collect mostly risk reduction Project risk reduction patterns], but these are not yet at the stage where people look through them as standard problem-solving procedure. When I am in an optimistic mood, I think that this might change in another 10 or 20 years.

After we did apply it, why did it work?

It worked in part because people really do find a flight of stairs to be a considerable barrier to asking questions. It worked in part because Jim really could do his work in isolation.

The final, and in my opinion, most important reason it worked, is that his managers, Lisa and Aaron, were perceptive, creative and supportive.

References

Allen98: Allen, T.J., Managing the Flow of Technology, MIT Press, Boston, MA, 1984.

Cockburn98: Cockburn, A., Surviving OO Projects, Addison-Wesley, 1998.

Cockburn03: Cockburn, A., Agile Software Development, Addison-Wesley, 2002.

CockburnEiE: http://c2.com/cgi/wiki?ExpertInEarshot

CockburnPrrP: http://alistair.cockburn.us/crystal/articles/prrp/projectriskreductionpatterns.html

CoplienOP: http://www.bell-labs.com/cgi-user/OrgPatterns/OrgPatterns?OldOrgPatterns

Rich94: Rich, B, Janos, L., Skunk Works: A Personal Memoir of My Years at Lockheed, Little, Brown and Company, Boston, MA, 1994.

Re: Crystal methodologies

hello, i am a student. i am in the search of following questions? despit of other agile models XP, FDD, etc etc why another family of agile models named “crystal family” was needed? through different studies i am satisfied that “why to use agile process models” but still i can’t know that why crystal models? how crystal are more good than other agile models. kindly give me feed back. regards, Iram

Alistair’s reply: The Crystal family of methodologies was started in 1992, before XP, FDD etc. It was named “Crystal” in 1997, before the agile manifesto. It was one of the founding ‘agile’ methodologies.

It is different than XP or FDD because it is a family of methodologies, not just one.
I have a section on this question in more depth in the upcoming 2nd edition of Agile Software Development due out Nov 2996.

From that book, “A named methodology is important because it is the methodology author’s publicly proclaimed, considered effort to identify a set of practices or conventions that work well together, and when done together, increase the likelihood of success. [and later…] Crystal is my considered effort to construct a package of conventions that raises the odds of success, and at the same time the odds of being practiced over time. ”

—Alistair

-by Iram on 12/13/2008 at 12:06 AM


What if I don’t want to wait another 988 years for your book to come out? ;-)

-by Immo Huneke on 1/20/2009 at 3:55 PM

Nice. :). It seems I managed to get a bit ahead of schedule, and got the book out already in 2006. Whew, imagine you were going to wait 988 years to read it – I was going to have to be 1,042 years old to write it!

-by Alistair on 1/20/2009 at 10:52 PM


If you were to do a “compare and contrast” with the Poppendieck’s Agile Toolkit, what would be the key points?

-by Wade on 3/19/2009 at 4:50 PM


I’m a student from China. Greetings.

I’m not totally understand Crystal Methodology

can you give me more details on it such as the lifecycale model of it.

regards Newman

ps.It will be very nice of you to send me an E-mail because in china when you open a web page of other contries it will be incredibly slow.

-by 夏宜蜜雪 on 3/22/2009 at 10:13 AM


cxtemplar@hotmail.com

-by 夏宜蜜雪 on 3/22/2009 at 10:14 AM


Very refreshing ideas indeed. Words such as non-jealous and just-in-time make perfect sense.
I understand that the aim of Crystal would be to provide a methodology aiming to create a per-project methodology. It’s just a matter of words but, would it be correct to assume that Crystal is more like a meta-methodology than a methodology ?

-by Antoine on 8/10/2009 at 6:06 AM


Hi, Antoine – You are right, in a wide sense.

A methodology is nothing more than “the conventions a group of people adopt”, a nice, simple definition that allows it to drift over time and be easily documented and easily changed.

Knowing that, how can I possibly write down in a book the conventions that every team on the planet should use?

So instead, I write down the parameters and principles I understand thet help people work together and tell whether their conventions make sense. The “Properties of Successful Projects” are the guideposts, the principles are the physics of teamwork, the techniques and strategies are industry lore.

So in this sense, yes, it’s meta to any specific team’s methodology.

Good eye.

Alistair

-by Alistair on 8/11/2009 at 2:19 PM


Referring to the Agile Manifesto and values of valuing one thing over the other back in Feb 2001, I strongly believe that for any project people are very important but tool as well. I was reading an article defending the agile values, saying that tools are important but need people to operate. What about the people with out tools? I meant to say that aren’t they both have some importance in a project. Also working software over documentation. Documentation are considered to be overhead but what in case if the people working on the project are offered better job elsewhere and they leave the project with out documentation? Isn’t it the case if people are agreed to work till the delivery of the project and provide guarantee that they won’t leave until the project ends. I hope you will understand where I am coming from.

Secondly, does any of the agile methodology fits for any project. I mean like can the values and principles of methodologies be ignored if creating problems? Or in other words, is it practical to apply partial principles by omitting the one that don’t work for any specific case.

Thirdly, I was trying to evaluate the agile methodologies as was trying to find out their appropriateness for IT Projects? What can be the criteria for the evaluation and assessment of these methodologies?

Lastly, what can be considered as an international IT project? Is there any definition available which can distinguish international IT project? Please explain

I hope this would not be too much to reply.

Regards

Faisal

-by Faisal on 9/15/2009 at 4:37 PM


no saben de algunos proyectos que usen estas metodologias?? y tambien que usen MétricaV3
gracias de antemano

-by yoci on 9/27/2010 at 6:52 PM


What are sample systems developed using crystal clear methodology????please answer…...

-by erdz on 1/9/2011 at 9:46 PM


me too i say it:

What are sample systems developed using crystal clear methodology???? please answer…...

-by Ruben Huanca on 11/14/2011 at 12:20 PM

15M$ fixed-price contract using Smalltalk, COBOL, DB2 in U.S., 50 people, 1994-5; Insurance claims system in Germany, 6 people, 1998-2003; French post office 2002-4, 24 people; Belgian post office 2004-6; Radiology imaging advisory system in U.S., 4-16 people, 2004-11. Others I don’t know of. Alistair


I used Crystal Clear to develop a couple of petroleum exploration systems. C++, 6-15 person-year projects.

-by Satoshi on 11/28/2011 at 4:18 AM


Hello,

I’m currently working on a study about agile methods and their apllications. Would you say that agile methods and especially Crystal methods are limited to project issued of Software development? I would love to hear your opinion about that.

Thank you very much for your answer

Greetings,

Benjamin

-by Benjamin on 12/31/2011 at 1:11 PM

Hi, Benjamin; agile approaches, including and especially Crystal, have nearly nothing to do with software development specifically. It is just an accident of history that programmers articulated the properties of effective team design first. Crystal applies to nearly every group endeavor, with increasing relevance to team-based design, and eventually to software. Thanks for asking. Alistair

Hello and Happy New Year,

Thank you very much for your quick response, I would like to ask some more questions about Crystal methods and their applications to common project management. I would really appreciate it if you could find some time to answer 4 to 5 questions by mail?

Thank you very much in advance,

Benjamin

-by Benjamin on 1/1/2012 at 9:15 AM


Hi, Benjamin: I will if you read the book Crystal Clear first. I’m not interested in regurgitating in emails what I took a long time to write down carefully.

-by Alistair on 1/3/2012 at 1:19 PM


Hi Alistair,

Can you Provide me the one line definition of the following:

1. what is Agile methodology?
2. What is scrum methodology?
3. What is xp methodology?
4. What is Crystal Methodology?

I just want to know the answers of these questions because I appeared for an interview and these are the questions that I was unable to answers and for this reason I lost the job.
So, I want to know how to handle these questions in the interview. I mean what type of answer needs to be presented?

Regards,
Rahul

-by Rahul Sharma on 1/4/2012 at 2:00 AM


Hi Alistair,

Can you Provide me the one line definition of the following:

1. what is Agile methodology?
2. What is scrum methodology?
3. What is xp methodology?
4. What is Crystal Methodology?

I just want to know the answers of these questions because I appeared for an interview and these are the questions that I was unable to answers and for this reason I lost the job.
So, I want to know how to handle these questions in the interview. I mean what type of answer needs to be presented?

Regards,
Rahul

-by Rahul Sharma on 1/4/2012 at 2:06 AM


Hello,

I fully understand your concern and I asure you that I already read a lot about agile methods and Crystal methodology in particular. I read your book about Agile Software Development (The Agile Software Development Series) and it helped me a lot for my study. I just have a few questions about how the flexibility of agile methods is working in practice in complex projects where documentation is important. I was also wondering if you would have maybe some feedback of agile methods beeing used in non-software projects?

Thank you very much,

Benjamin

-by Benjamin on 1/4/2012 at 5:40 PM


Hi, Benjamin, Rahul: I’m sorry, simple Google searches turn up answers for all these questions. Alistair

-by Alistair on 1/4/2012 at 8:28 PM


what is crystal? please explain and give me examples I Just want to understand it.

-by chris on 3/6/2012 at 10:56 AM


what is crystal? please explain and give me examples I Just want to understand it.

-by chris on 3/6/2012 at 10:56 AM


what is crystal? please explain and give me examples I Just want to understand it.

-by chris on 3/6/2012 at 10:56 AM


why is crystal called a family of agile methods?

-by chris on 3/6/2012 at 11:01 AM


Hi, does crystal have any forum o webpage support where I can find the “official” practices?
(like scrum.org for scrum )
Thanks in advance :)

-by Juan Daniel on 4/26/2012 at 11:12 AM

yes – the crystalclear forum on Yahoo: http://tech.groups.yahoo.com/group/crystalclear/

Dear Alistair,

You are a patient man. :) Thanks for all your work, which has been most informative to me.

-by Bob Rodes on 8/26/2012 at 11:53 AM

LOL, Bob – that may be the first time I’ve been called that! Thanks! :). Alistair

hi, i am a student in a project search. i want to know more about crystal clear and crystal orange in agile methodologies.

-by francis on 9/27/2012 at 6:51 AM

_The discussion group is at blank">http://tech.groups.yahoo.com/group/crystalclear/ ... hit the Join button and I’ll get a message w your email address and OK you for the group…. Alistair

Hi Alistair,

Just want join the group for another new project.

Thanks,

James

-by Blvette75 on 2/27/2013 at 8:49 PM


This is satire right? Please tell me this is satire. Or I quit the IT industry.

-by Erwin Katz on 3/8/2013 at 6:16 AM


Hey Alistair,

I did my math – you are 59 years old :) Am I correct ?

-by Saravana Bharathi on 8/21/2013 at 3:56 PM


Hey Alistair,

I did my math – you are 59 years old :) Am I correct ?

-by Saravana Bharathi on 8/21/2013 at 3:56 PM


what is crystal family methology?

-by bpt5s on 5/16/2015 at 6:52 AM

Re: What to do instead of bad responsive design

So, to my mind something like twitter or kitkat.com do what I really want from responsive design: as I narrow my browser, they re-lay-out to fit everything in the new narrower space.
Are you saying that this is what you don’t like?

What I do find really irritating is sites following your unbroken-baguette example, overflowing the plate, so I have to horizontal scroll to read when I shrink the window.

I can see the 3-width shrink (desktop-tablet-mobile) being over-sensitive sometimes.

It’s true that e.g. alistair.cockburn.us/ also fits everything in a shrinking window without responsive design. But the text still has to move, so I still lose my place.

But to add ammunition to your cause: I see nothing ‘lazy’ in responsive design. It appears to take at least as long as doing two (or three) layouts + bugfixing the transitions.

-by Chris F Carroll on 5/13/2015 at 2:54 PM

What to do instead of bad responsive design

What to do about bad Responsive design?

Short answer: Design for the device.

I get to use really good mobile apps – they are clean, easy to read, easy to use. (Examples abound. Orbitz is a handy one). Whoever designed those understood the medium, its affordances and limitation, and designed for that.

Big screen is different – different medium, different affordances. Good designs on the big screen are very different than good designs on the small screen.

Responsive design is the lazy designers way to make designs that fit no screen well. Kind of like 1-size-fits-all clothes that meet a person the right size by random chance.

The worst of responsive design is the big screen, with resizable browsers – every movement of the browser window changes the layout and what is visible. This can never be a good design.

What I would like to see is this :

Designers,
- design for two screen sizes, “sparse” and “loaded”,
- select which to load initially based on the viewing device, and
- allow the user to easily change to the other
(e.g. I often want to use the “loaded” design, the full web site, when on my iPhone or Android, just because I want all that info and the peripheral affordances offered on big screens).

Even I, who hate responsive design, am being pushed by current trends to using it. All the people I hire to do design any more uses it by reflex. And it’s really hard to make something decent on both sized screens. So I’m using it under protest, hoping it will go away soon.

(This blog started as a FB post, I’m putting it here for my other friends to see).

Pages