Slack

is the title of an excellent book by Tom DeMarco. This second snippet (here's the first) continues my tactic of rereading good books several times. As usual I'm going to quote from a few pages:

Talented managers are ... all sense organ, constantly attuned to the effect their leadership is having on their people ... Managers without such talent find themselves relying on formulas and "principles" of management. They reason, "This thing I'm trying to do should work; the fact that it isn't working probably suggests that I'm doing it half-heartedly." And so they do more of whatever they've been doing.

When the new automation is in place, there is less total work to be done by the human worker, but what work is left is harder. That is the paradox of automation: It makes the work harder, not easier.

In my experience, standard processes for knowledge work are almost always empty at their center.

The power you've granted is the power to err. If that person messes up, you take the consequences. Looked at from the opposite perspective, it is this capacity to injure the person above you that makes empowerment work.

When there is neither time nor staff to cope with work that runs more slowly than expected, then the cost of lateness is paid out of quality. There is no other degree of freedom.

... voluminous documentation of everything that will hold still for it.

Successful change can only come about in the context of a clear understanding of what may never change, what the organization stands for... the organization's culture... If nothing is declared unchangeable, then the organization will resist all change. When there is no defining vision, the only way the organization can define itself is its stasis.

multi-tasking

Many years ago, in a taxi, in Athens, I watched with a mixture of amazement and fear as my driver freed up both hands by steering with his elbows. It was quite an experience!

Multi-tasking is a bad idea when you're doing tasks requiring "immersion". After being interrupted it takes you a long time to get back to where you were. One of the least talked about reasons why pair-programming can be so effective is that a pair seems to be much more resilient to interruptions than an individual. In other words, yet again, pair-programming is partly about programming, but it's mostly about the pairing.

Jerry Weinberg observed that if you have two task to choose from you don't in fact have two tasks to choose from. You have three. Your third task is deciding which of the other two tasks you should tackle!

Recently, on a train, a man sitting opposite me was reading The Telegraph. An article on the front page about multi-tasking caught my eye. It quoted some research by Professor David Strayer from the University of Utah. It said multi-taskers often end up juggling activities not because they are good at it, but because they are easily distracted and cannot concentrate on the job at hand. And in contrast, the most efficient multi-tasker is the person least likely to do so because they can focus on one thing at a time. The implication is that someone who claims to be good at multi-tasking probably isn't!

smart swarm

is an excellent book by Peter Miller (isbn 978-0-00-738297-2). As usual I'm going to quote from a few pages:

As successful foragers return to the nest with seeds, they're met at the nest entrace by foragers waiting in reserve. This contact stimulates the inactive ants to go out. Foragers normally don't come back until they find something. So the faster the foragers return, the faster other ants go out, enabling the colony to tune its work force to the probability of finding food.

Instead of attempting to outsmart the desert environment, the ants, in a sense, were matching its complexity with their own.

Instead of trying to keep fine-tuning a system so it will work better and better, maybe what we really ought to be looking for is a rigourous way of saying, okay, that's good enough. [Deborah Gordon]

If a scout bee was impressed by another scout's dance, she might fly to the box being advertised and conduct her own inspection, which could last as long as an hour. But she would never blindly follow another scout's opinion by dancing for a site she hadn't visited.

J. Scott Turner considers the mound's function as a respiratory system so essential that the termites couldn't live without it. In a sense, he argues, the mound is almost a living part of the colony.

If individuals in a group are prompted to make small changes to a shared structure that inspires others to improve it even further, the structure becomes an active player in the creative process.

Unlike our systems, which are tuned for efficiency, the termites' systems have been tuned for robustness, which they demonstrate by building mounds that are constantly self-healing.

What really made the lights go on was the realization that termites don't pay attention to the environment itself but to changes in the environment.

Not only does this complicated structure represent an indirect collaboration among millions of individuals, it also embodies a kind of ongoing conversation between the colony and the world outside. The mound might look like a structure, but it's better thought of as a process.

We should think of it [the termite mound] as a dynamic system that balances forces both inside and outside its walls to create the right environment for the termites.

When you feel like you belong to something, it gives you so much more freedom and so much more energy that might otherwise be used up in anxiety, to do other things.

On January 12, 2006, several hundred thousand pilgrims had gathered in a dusty tent city at Mina, three miles east of Mecca...
By noon... about a half-million or more pilgrims filled the Jamarat plaza in front of the bridge... The pressure inside the crowd was crushing... More than an hour later, victims were piled up seven layers deep: 363 men and women were dead.
"Those in charge need to remember the root cause of the problem: too many people trying to get through too small a space. The ingress rate at the bridge was 135,000 per hour. The thoughput rate of the pillars was only 100,000 an hour. You can't put a pint into a half-pint jug." [Keith Still]

Curry velocity

Some people's introduction to curry begins with them ordering the hottest dish on the menu. They discover the dish is beyond their curry-capacity and they can't finish it. Amazingly, they often repeat this behaviour. Lots of curry goes to waste. Dishes are frequently only half-eaten. Curry velocity remains at zero.

Other people's introduction to curry begins with them trying something nearer the cooler end of the Scoville scale. They find the dish is below their curry-capacity. They finish it! No curry is wasted. Their curry velocity is above zero. The next time they may decide to try something a little hotter. But they are in control of the curry, rather than the curry being in control of them.

The Vizzini school of bad management

• Am I going mad or did the word "think" escape your lips?
• Hurry up
• Inconceivable
• Faster!
• You know what a hurry we're in
• I'm waiting!
• Catch up with us quickly
• I do not accept excuses
• Did I make it clear that your job is on the line?
• There will be no one to hear you scream
• Stop doing that. We can relax, it's almost over

Agile A-Z Keynote

I attended the excellent Agile .NET 2011 conference in Ghent, Belgium this week. Jason Gorman pulled out at the last minute and Erik asked me if I'd step in and do the keynote. I said yes of course and prepared this on the train+plane there.

An Agile A to Z

View more presentations from JonJagger.

rules of thumb

don't rush

I don't think I can put it any better than Jerry Weinberg did when I interviewed him:

Things take the time they take, not the time you hope they will take. Pushing for half-time produces half-baked.

As a self-employed software coach/consultant I get to travel a lot and visit a lot of companies. At the best companies there is a palpable sense of not rushing.

think team

Software development is all about collaborative learning. I think one of the weakest points of the Agile Manifesto is it's lack of emphasis on teams. The very first word of the four "X over Y" statements is Individuals :-( XP at least takes a firm step beyond programming as an individual activity by mandating pair programming. I look at Sit Together, a practice from XP1 and I think s/Sit/X/. In other words, whatever X is, X Together.

increase visibility

Software and the process of developing it can be, to paraphrase Douglas Adams, mostly invisible. You think more clearly when you have something concrete to tie your thinking to. You manage things better when you can see them and see them constantly changing. It's no accident that Kanban boards are as popular as they are.

Are your lights on?

is an excellent book edited by Donald Gause and Jerry Weinberg (isbn 0-932633-16-1). As usual I'm going to quote from a few pages:

Having followed our natural problem-solving tendencies, we have rushed right into solutions. Perhaps it would be wiser to ask a few questions before stating answers.

A problem is a difference between things as desired and things as perceived.

Don't take their solution method for a problem definition.

Each solution is the source of the next problem.

Designers - special people whose job it is to solve problems, in advance, for other people.

Approaching public servants with courtesy and respect for their humanity and competence will, for the most part, evoke humanity and competence.

The source of the problem is most often within you.

The source of a problem often contains some key element in its resolution.

In spite of appearances, people seldom know what they want until you give what they ask for.

We never have enough time to do it right, but we always have enough time to do it over.

Do you have any post-its?

Developers love solving a solution. Unfortunately their eagerness can get in the way of understanding the problem. When I'm with a client I sometimes ask a simple question such as "Do you have any post-its?" I'm careful not to say I want some post-its. I simply ask if they have any. I could be asking the question because I think not-having post-its is an indicator of something else - in the same way that not-having whiteboards is an indicator of something else.

Often they start searching for post-its. I politely stop them and say that I don't want any post-its - I simply want to know if they have any. My aim is to increase their own awareness of solving the solution before probleming the problem.

an interview with Jerry Weinberg

Jon
If you were stranded on a desert island with five books which books would you choose and why? Please don’t pick more than one of your own!
Jerry

• An empty notebook with as many square feet of blank paper possible, for keeping my journal of this desert island adventure.
• The complete Oxford English Dictionary, so I can study the English language in depth for the future when I might be rescued.
• Frazer's Golden Bough, so I can immerse myself in the vastness of human culture.
• Martin Gardner's The Annotated Alice (Lewis Carroll's Alice books, annotated by Martin Gardner) so I could read for wisdom and humor at the same time. (I've used this book as a text in s/w development.)
• If a Kindle counts as one book, I'd take that. Otherwise, Wilderness Medicine, Beyond First Aid, 5th Edition by William Forgey (I'd like to research this one, because I haven't read this, but I would need the best such book.)

I don't have any computer books on the list because I'm assuming I wouldn't have a computer. If there were such a book, I'd probably want *How to Build a Two-Way Radio Out of Coconut Shells*.

---

Jon
Which books would you change and to what if you did have a computer?
Jerry

• I would not need the empty notebook, as I could keep my journal on-line. Instead, I'd want a complete service manual for the computer equipment.
• I would not need the OED, for the same reason — an on-line OED. Instead, I would take Don Knuth's The Art of Computer Programming. I assume we count all published volumes as one "book."

The rest I would keep the same.

---

Jon
What do you consider your biggest contribution to the software world.
Jerry
That's easy. I answered that some years ago, and my answer hasn't changed. My biggest contribution to the software world is that I never invented yet another programming language.

---

Jon
What would you still like to achieve?
Jerry
I'd like to persuade more computer people to work on the unsolved problems of our profession, rather than the (pretty much) solved ones such as compiler writing.

---

Jon
Could you give some examples of what you consider to be the important unsolved problems of our profession
Jerry

• requirements: finding out what will really make people happy
• doing the things we know we ought to do
• not doing things we know we ought not do
• conservation of knowledge from one generation to the next
• developing some sense of standard practice (can be more than one, but not too many) that will be followed around the world

---

Jon
You’ve written that you get a lot of inspiration from nature. Could you give some examples - of both the inspiration and nature that inspired it.
Jerry

• Systems grow, and when they grow, they change. I've learned a lot about growing systems from natural systems and how they grow. For instance, there's D'Arcy Thomson's book, On Growth and Form, and a lovely little book, The Adaptive Geometry of Trees.
• Systems adapt. Way back, I wrote Natural Selection as Applied to Computers and Programs, inspired by such works as Fisher's The Genetical Theory of Natural Selection.
• Many of my insights from nature, along with references, can be found in my books on Systems Theory, such as An Introduction to General Systems Theory and General Principles of System Design.

---

Jon
If you had a one-time-only time machine how would you use it?
Jerry
I wouldn't. I have a rule: Don't mess with time.

---

Jon
Suppose you used it to visit your younger self what advice would you give yourself?
Jerry
When someone offers advice, you ought to taste it, but you don't have to swallow it.

---

Jon
In question one you mentioned Martin Gardener’s book, The Annotated Alice. Could you expand on how you used this as a text in s/w development.
Jerry
Alice's trip across the chessboard to become promoted quite nicely parallels a typical development process. It's no coincidence that Lewis Carroll (Dodgson) was a mathematical logician. He was able to do logic, and to make memorable the instances of illogic. For example, the Red Queen's behavior is that of many bad development managers ("Off with their heads.") The students were invited to find other parallels in the book, which hopefully set their minds to work.

---

Jon
What is the biggest change you'd like to see in the software world?
Jerry
Slowing down in order to do things right.

---

Jon
What would it take to make this happen?
Jerry
Hell would have to freeze.

---

Jon
What question would you ask yourself?
Jerry
What question would you ask yourself?

---

Jon
And what is your answer?
Jerry
What question would you ask yourself? Just kidding. That was a fun recursion.
Jerry
[this is the real question Jerry would ask himself] Why are you writing novels these days?
Jerry
[and this is his real answer] Like any life-changing decision, the switch to fiction has many reasons, all intertwingled. What follows are some of the reasons I have been able to disentangle.

• All my life, I've dedicated myself to helping smart, talented people be happy and productive. You can see that theme in my books, I think, and it's the theme I've continued in my novels (see list below).
• But not all my work has been through writing. Dani and I have also spent our careers training these smart, talented people through the use of experiential workshops — Problem Solving Leadership Workshop (PSL) Organization Change Shop (OCS), Systems Engineering Management (SEM), and the Amplifying Your Effectiveness Conference (AYE). We use experiential training methods because they are effective. They reach many people, and much more deeply, than your typical lecture class with PowerPoint slides.
• In many ways, reading a non-fiction book can be much like one of those PowerPoint lectures, so whenever possible, I have used stories to bring my non-fiction works to life. Stories have always been powerful for learning, going back thousands of years. Why? Because a good story arouses the readers feelings of participating in the experience the story describes.
• A great deal of the popularity of my books (and other non-fiction writers like Tom DeMarco) is in the stories. They make for lighter reading, which some people love and some people find objectionable, but overall, I have managed to present lots of hard stuff effectively through these stories.
• Some of my books have been directed specifically at Information Technology (IT) people. Some have not. Generally, the ones that have sold best and longest have been the ones not so specifically directed at IT people — books such as
  • An Introduction to General Systems Thinking
  • The Secrets of Consulting
  • Are Your Lights On?
  • What Did You Say?
  • Weinberg on Writing: The Fieldstone Method
  These readers tell me they like the stories, even those that have some technical content. In fact, they often learn technical concepts and details as a byproduct of reading and enjoying the stories. I like that, because it says I have reached many smart, talented people who don't happen to be IT folk. The novels do that even better. I hope more people try them.

---

Jon
Could you briefly mention some of your favourite music and films.
Jerry
Music: Almost anything Baroque. Any of Mozart (I have the complete recordings of his works, which should tell you something). Most music prior to 1850; almost nothing after that except Sousa, Gilbert & Sullivan, and Scott Joplin.
Films: (I'm probably missing some, but all these are favorites that I can see again at any time, with no hesitation.)

• The African Queen (1951)
• Bringing Up Baby (1938)
• Casablanca (1942)
• City Lights (1931)
• Duck Soup (1933)
• Fantasia (1940)
• The Gold Rush (1925)
• High Noon (1952)
• It's A Wonderful Life (1946)
• Modern Times (1936)
• A Night At The Opera (1935)
• Paths of Glory (1957)
• Singin' In The Rain (1952)
• The Treasure of the Sierra Madre (1948)
• The Wizard of Oz (1939)

---

Jon
Could you expand a little on your rule "not messing with time"? Does it relate to "Slowing down in order to do things right?"
Jerry
Yes. Things take the time they take, not the time you hope they will take. Pushing for half-time produces half-baked.

---

Jon
At your Problem Solving Leadership course I noticed you sometimes answered a question "obliquely". For example when discussing cancer treatments you told the story of the Aspen mountain passes and how none of them are really much good. Could you explain why you sometimes choose to answer a question in this manner.
Jerry
What you call oblique, I call powerful. Take your example. Few of my listeners have had cancer, but many of them have the experience of hiking on difficult trails. Thus, the lesson is more likely to stick, as it has with you.

---

Jon
You’ve said learning a new language (a human language, such as Spanish) really helped your ability to think in a Systems Thinking way. Could you expand on that?
Jerry
In my case, it was French, learned while living in Geneva for a number of years. After a while, I found myself thinking in French when my ordinary thinking wasn't solving a problem. For instance, in English we say things like, "I took an aspirin for my headache." In French, the expression would be "against my headache." To me, that seems to imply something different from the English expression — a different way of thinking about disease and cure.
So, in effect, after learning French, I have a second way of addressing problems — and once I have a second way, it's easy to see that there may be a third way, and a fourth way, and so on. Being able to see a situation in multiple ways is a key concept in systems thinking, and learning a new language favors that concept.
The same phenomenon occurs in so-called programming languages. Someone who can work in only one such "language" cannot truly be considered a real programmer, in my opinion. That's why in school, I always insisted that programming homework be done in at least two languages — along with a written analysis of how each language affected the way the student approached the problem.

Many thanks to Jerry for agreeing to be interviewed by me. Fiona Charles took the excellent photo of me and Jerry. If you're a fan of Jerry you should check out her excellent book The Gift of Time. This interview also appeared in CVu, a publication of the ACCU, an organisation of programmers who care about professionalism in programming and are dedicated to raising the standard of programming.

The dance of life

is an excellent book by Edward T. Hall (isbn 0-385-19248-7). As usual I'm going to quote from a few pages:

All societies depend for the stability on feedback from the people. Depersonalization reduces feedback to a minimum, contributing to instability and lowering the overall level of congruence in the society.

Some things are not easily bent to simple linear description. Time is one of them.

Symbols should always be viewed as tools and consciously distinguished from the events which they symbolize.

Without environmental change, complex forms of life cannot evolve.

It is clear that our emphasis on saving time, which goes with quantifying time and treating it as a noun, would also lead to a high valuation of speed, which is demonstrated in much of our behaviour.

Nothing can grow in a healthy way unless it is in a time-controlled, uniform manner; for example, it is the unregulated (out-of-phase) growth of cells in the body that characterizes cancer.

"We have everything, but we don't have each other" [Takeo Matsuda]

The Pueblos believe that thoughts have a life of their own and that these live thoughts are an integral part of any man-made structure and will remain with that structure forever.

The more information that is shared... the higher the context.

As context is lost, information must be added if meaning is to remain constant.

Viking Ship Museum

I went to the Viking Ship Museum in Oslo a few weeks ago. As I arrived a group arrived on a bus. They were led round the museum by a man who talked about the exhibits and viking life in general. I quietly attached myself to the group and listened to what he had to say. It was really fascinating stuff. For example, at one point he mentioned that Norway has the highest incidence of multiple sclerosis in the world. And that the countries with very high incidence seem to be the countries the Vikings invaded!

5 inch buttons

I spent a great morning with my friend Mark, an ace wood and metal craftsman. He made some 5 inch oversize wooden buttons (for a panto costume I think). I took loads of notes and photos and plan to write the morning up in an extended blog entry. But just for now here are some photos of his workshop. You don't go into his workshop so much as put it on! Like a old jacket that fits perfectly.

The Way of Zen

is an excellent book by Alan Watts. As usual I'm going to quote from a few pages:

For things made are separate parts put together, like machines, or things fashioned from without inwards, like sculptures. Whereas things grown divide themselves into parts, from within outwards.

...as soon as a boundary is defined it has two sides.

Man is involved in karma when he interferes with the world in such a way that he is compelled to go on interfering, when the solution of a problem creates still more problems to be solved.

Form is precisely emptiness; emptiness is precisely form.

When reading a difficult book it is of no help to think, 'I should concentrate,' for one thinks about concentration instead of what the book has to say.

Hurry, and all that it involves, is fatal.

A good haiku is a pebble thrown into the pool of the listener's mind.

If Christianity is wine and Islam coffee, Buddhism is most certainly tea.

It is the year 3016 - the remains of a large codebase have been found in Norway

The accu 2010 conference in Oxford has just finished (Tweet #accu2010). Olve Maudal and I were honoured to be speaking at this fantastic event - our joint presentation was called Code Archaeology: Stories from a real codebase. Inspired by James Bach's awesome Towering-Inferno keynote we added a small, somewhat hastily put together, fun-based introduction. It seems to have worked well; "code archaeology" proved a rich vein of humour (the beer and lack of sleep probably helped too).

The real value of our presentation was the main content in part two.

• a detailed look, going back 10 years, at many small changes from a real codebase worked on by developers who care.
• an equally detailed look at the trust-based culture Tandberg strives to maintain, helping them consistently create superb products.

There are some details that have to be confirmed before Olve and I can make part two available and I apologise for jumping the gun earlier. Meanwhile here is Part One.

P.S. Thanks to Anna-Jayne Metcalfe (@annajayne) who tweeted the title of this blog entry and Mark Ridgwell (@credfeto) for the photo.

Slack

is the title of an excellent book by Tom DeMarco (one of the authors of Peopleware). As usual I'm going to quote from a few pages:

The more efficient you get, the harder it is to change.

The survival tactic that Harry and others like him hit upon when their buffers begin to empty is to slow down.

The principal resource needed for invention is slack.

The purpose of the schedule was planning, not goal-setting.

You need to understand that management is utterly essential. It is.

Quality takes time.

You're efficient when you do something with minimum waste. And you're effective when you're doing the right thing.

When you're not safe, you feel afraid. And fear can inhibit change.

I see one pattern common to all winners. They acquire trust by giving trust.

We tend to resist learning things that really matter.

Most of us don't learn well from abstraction. We learn from example.

Training - practice by doing a new task much more slowly than an expert would do it.

Managing your risks requires that you go at some slower speed.

Henrik Kniberg's name game

Update: Henrik has now written a detailed explanation of how he plays the game here.

Henrik designed the name game to show how the lean idea of limiting work in progress can have a dramatic effect. Here's how you play:
Split into groups of six. In each group there are 5 customers and 1 developer. Each customer has a project - they simply want the developer to write down their name. That's it. During both iterations the following times have to be recorded (to the second):

1. the overall start time
2. the time each customer's project starts (when the developer writes down the first letter of their name)
3. the time each customer's project is delivered (when the developer writes down the last letter of their name)
4. the overall finish time

In the first iteration each developer has to act under the principle of "never keep a customer waiting" and tries to write all the names simultaneously. Let's see how a developer's name-sheet changes during this iteration. It starts off empty:

1.        2.        3.        4.        5.

the developer asks their first customer for the first letter of their name and writes it down; the first customer's project has started so they write down their project's start time:

1.B       2.        3.        4.        5.

the developer asks their second customer for the first letter of their name and writes it down; the second customer's project has started so they write down their project's start time:

1.B       2.E       3.        4.        5.

the developer carries on until they have written down the first letter of all their customers names; every customer will have written down their project's start time:

1.B       2.E       3.P       4.T       5.J

the developer asks their first customer for the second letter of their name and writes it down; if this completes the customer's name the customer's project is delivered and the customer writes down their project's finish time (Be will become Bert so not yet):

1.Be      2.E       3.P       4.T       5.J

the developer asks their second customer for the second letter of their name and writes it down; again, if this completes the customer's name the customer writes down their project's finish time (El will become Ellie so not yet):

1.Be      2.El      3.P       4.T       5.J

the developer carries on until they have written down the second letter of every customer; Jo is Jo so Jo's project is delivered and Jo writes down her project's finish time:

1.Be      2.El      3.Pa      4.Te      5.Jo

the developer carries on round-robin, letter by letter, until they have written down the full name of all their customers; every customer now has a project finish time:

1.Bert    2.Ellie   3.Pat     4.Terry   5.Jo

Stop the clock and record the overall finish time.

Now the developers swap customers (so they don't know their customer's names once more).

In the second iteration the developers act under the principle of "limit work in progress to 1 customer at a time". So no multi-tasking. Let's see how a developer's name-sheet changes during this iteration. It starts off empty:

1.        2.        3.        4.        5.

the developer asks their first customer for their whole name and writes it down. When the developer starts writing their name the customer writes down their project's start time, when the developer finishes writing their name the customer writes down their project's finish time.

1.Sally   2.        3.        4.        5.

the developer asks their second customer for their whole name and writes it down. Again, the second customer writes down their project's start and finish time.

1.Sally   2.Russ    3.        4.        5.

the developer continues round-robin asking each customer in turn their full name. All customers now have a project start and finish time.

1.Sally   2.Russ    3.Ed      4.Larry   5.Clive

Henrik writes:

Then we chart the results and compare and discuss. Typically the lead time per customer is at least 5x shorter in the second round, and the total time to do all customers is 3x shorter (so the developer could handle 3x more customers within the same time, and each customer only needs to be engaged in the project for 5x shorter time than before). Most people intuitively believe that, if you start something earlier, you will finish earlier. This exercise brutally murders that misconception :o) A simple exercise, but the effect is astounding.

If you like software-related games you might also like

• Cyber-Dojo
• Kanban 1's Game
• Simplest Name Game

Almost Instant Learning - Not

Fast track management. And an MBA in only 80 minutes! Just two of the many books spotted in the "instant learning" section of an airport bookshop. No thanks.

Beauty in the detail

Lichen covered bricks in an old weathered wall on the way to school.

Tandberg product development

My good friend Olve Maudal of Tandberg did a talk about Product Development in TANDBERG for the Oslo Lean Meetup. His slides are online at http://bit.ly/cxNvjc and are well worth a look if you care about what it takes to make world class software.