Hi. I'm Jon Jagger.
I help software teams improve their effectiveness.
I built cyber-dojo, the place teams practice programming.
I'm based in the UK.
I've worked in 22 countries.
If you don't like my work, I won't invoice you.
Hire me

Pages

is an excellent book by W. Edwards Deming (isbn 0-911379-01-0). As usual I'm going to quote from a few pages:

All industries, manufacturing and service, are subject to the same principles of management.

Quality comes not from inspection, but from improvement of the production process.

Today, 19 foreman out of 20 were never on the job that they supervise.

Fear amongst salaried workers may be attributed in large part to the annual rating of performance.

Absenteeism is largely a function of supervision. If people feel important to a job, they will come to work.

He that would run his company on visible figures alone will in time have neither company nor figures.

There has never been a definitive study of quality in the dental profession; nor is there likely to be one. Partly because they tend to work alone, dentists resist the idea of being evaluated, or even observed, by others.

Where there is fear, there will be wrong figures.

It is well known that rework piles up: no one wishes to tackle it.

This company had been sending a letter to every driver at every mistake. It made no
difference whether this was the one mistake of the year for this driver, or the 15th:
the letter was exactly the same.
What does the driver who has received 15 warnings, all alike, think of the management?

The more defects code has the more time and effort it takes to get it to done.
This seems a self-evident truth.
But beware! The
Causation Fallacy
says it is not easy to know what is cause and what is effect.
If a feature misses its deadline pressure often builds to ensure it doesn't miss the next deadline. And under pressure people don't think faster. Extra pressure usually increases the likelihood of defects. This suggests

Lateness causes defects.

So do defects cause lateness, or does lateness cause defects?
Or do they rotate around each other like partners on a dance floor?

A team is doing Scrum with 3 week sprints.
Suppose at the end of a sprint they've got nothing to done.
What should they do?
There's a strong temptation to ask for more time. To make this sprint a 4 week sprint. Most of the work in progress
is 90% done, they say. Another week and things will have got to done, they say. It seems reasonable.

Trying to run systems
beyond their capacity is not a good idea.
In this situation Scrum's fixed-duration time-box constraint has served it's purpose admirably. The problem is not the choice of 3 weeks. Changing 3 weeks into 4 weeks is not addressing the problem. The problem is the team planned to pull in an amount of work and get it to done in 3 weeks. But they're not yet in control of their process - they don't know what their capacity is. They pulled in more than 3 weeks worth of work.
Probably a lot more. But we just don't know!

Taiichi Ohno considered the fundamental waste to be overproduction, since it causes most of the other wastes.

Advice from a genius with a lifetime's experience.
Toyota manufactures cars. It makes cars. Its production line is an actual line. If manufacturers are prone to overproduction imagine how much more prone software developers are! The things we make are not even physical things. In software, things are mostly invisible. It's difficult to manage what you can't see.
In Quality Software Management volume 2, First-Order Measurement, Jerry Weinberg writes:

Without visibility, control is not possible.
If you can't see, you can't steer.

Rather than asking for another week, the team should really be thinking about addressing their real problem. Their real problem is that they're pulling in too much work. They have to somehow learn to pull in less work. So they can start to be in control of their process rather than their process being in control of them.

Consultants who see culture change as something distinct from the work and, as a corollary, something that can be the subject of an intervention, miss the point. When you change the way work is designed and managed, and make those who do the work the central part of the intervention, the culture changes dramatically as a consequence.

Successful change can only come about in the context of a clear understanding of what may neverchange, 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.

Culture hides much more than it reveals, and strangely enough what it hides, it hides most effectively from its own participants.

An often noted characteristic of culture change is that an idea or a practice will hold on very persistently, apparently resisting all efforts to move it, and then, suddenly, without notice, it will collapse.

I've previously blogged about being taught ITA spelling at primary school. About how it causes me spelling problems. I was reminded of this when speaking to Geir Amdal at the excellent Agile Coach Camp in Oslo.
Geir showed me this wonderful blog post with lovely twist on the famous quote:

Knowledge is power. Francis Bacon

It reminded me of something my Mum used to say to me when I was little:

Hunger is the best source.

For many many years I didn't understand what she was saying.
I was seeing the word sauce as source. She was actually saying:

Hunger is the best sauce.

Food tastes better when you're hungry. Reflecting on my confusion I realize I'm actually quite proud of
this mistake. This was a long time ago remember. I was a small boy at the time.
Even then, it seems, software was calling me.

I was speaking to Olaf Lewitz at the awesome Oslo coach camp last week.
We were discussing why drinking coffee doesn't create the same social dynamic as smoking cigarettes.
I chatted with Geir Amdal too and quite by chance he mentioned he's given up smoking. And how approaching
a work colleague and asking if they want to go outside for
a smoke is not the same as asking if they want to go outside for a talk.

Then I remembered something Olve Maudal said to me recently.
He said that kids being allowed to eat sweets on Sundays was not really
about kids being allowed to eat sweets on Sundays at all. It was really about
kids not being allowed to eat sweets on any day except
Sunday. Similarly, apparently in the USA when you're driving along you sometimes
see a big sign at the side of the road saying "Litter here" and then another
sign a mile or so later saying "Stop littering".
These signs are also not really about littering. They're about
not littering in the places outside the designated littering
zones.

There's a crucial difference between smoking and drinking coffee.
Smokers tend to smoke in groups in designated areas because smoking is not allowed
except in those areas.
Coffee is different. Drinking coffee is, by default, allowed everywhere.
When you want a coffee you walk to the coffee machine and make a cup of coffee.
There's often no one else at the coffee machine so you take your
cup of coffee back to your work desk. It is precisely this take-it-back-to-your-desk
default which is why there is only rarely someone else at the coffee machine.
It is a self-fulfilling dynamic.

If you want to encourage more social interaction between your team
members here's what you might do:

Buy machines that make really good coffee.

Put them in a nice area with lots of space to congregate in.

Ban drinking coffee at work-desks.

The third step might seem a bit draconian. But it's vital. You could justify
it on the grounds that spilling coffee onto expensive computers will waste money.
But the real reason it to encourage developers to drink their coffee
near the coffee machine. Together. To encourage communication.

When I bought my kindle I forgot to get a case to protect it. I searched around on a few sites looking for a case but didn't find anything I particularly liked. Before I knew it, it was time to head off to the awesome Agile Coach Camp Norway 2012. I wanted to take my kindle but needed a case to protect it. It was too late too order a case via the internet. But I had an idea. I could use a book! A regular old-fashioned hardback book.

I simply cut out a kindle-sized panel from the middle of about 100 pages and then glued the holed pages all together:

Viola, I have a case for my kindle. A book-case you might say.

I showed off my new book-case at the coach camp. It was a hit. At dinner one evening Marc Johnson mentioned he too has a kindle and loves it but misses the social aspect of a real book. The simple fact that most real books display the book's title on its front cover. People can see what you're reading. I sat next to a really interesting man on a plane once. He noticed I was reading Jerry Weinberg's Quality Software Management, vol 2, First-Order Measurement and asked me about it. We chatted away the whole flight.

My kindle book-case allows me to regain this missing social aspect. I can simply print the cover the publishers use for the real book and stick it to the front. So now I have something close to my ideal kindle case. It just needs a clear front cover sleeve so I can easily slide a cover in. And some kind of clasp. As a final bonus, I can pay homage to one of my favourite films:

is an excellent book by Don Reinersten (isbn o-684-83991-1).
This is the second snippet entry for this book (here's the first). It continues my current theme of preferring to re-read a good book many times.
As usual I'm going to quote from a few pages:

Whenever we see an intense need for communications it is typically a sign that the system has been incorrectly partitioned.

A complexsystem can often be built faster when there are stable steps along the way. This is what Nobel laureate Herbert Simon called "stable intermediate forms" in his book The Sciences of Artificial.

We cannot predict the behaviour of a system simply by understanding the behaviour of its components.

There are more possible interactions in a system of 150 components than there are atoms in the universe.

The act of partioning the system is extremely important, because it creates interfaces… these interfaces are both the primary source of value within a system and the primary source of complexity.

The nonlinear behaviour of queueing systems will amplify variability within the system.

We get into an interesting death spiral when we overload our development process.
Overloads cause queues; queues, being nonlinear, raise the variability of our process, and variability raises the size of queues.

The weak cross-functional communication of the functional form sacrifices our other economic objectives.

In life, we design most processes for repetitive activities because a process is a way of preserving learning that occurs when doing an activity. … We need to find some way to preserve what we have learned without discouraging people from doing new things.

We get large queues whenever we have large batch transfers in the process.

There is a strong interaction between the design of our organisation structure, our architecture, and our development process.

I was thinking about that the other day and I realized something important. I realized that when I read the word recipe I thought about the ingredients but not really about the non-ingredient related instructions in the recipe. About time. A recipe doesn't just tell you what to mix with what, and in what order, it tells you how long to apply heat. And how much heat. These two things matter just as much as the ingredients. If you change the ingredients you'll get different bread. But if you change the time or the amount of heat you'll also get different bread. Although it might not look much like bread.

Suppose the recipe says to heat the oven to 200 degrees and then cook for 30 minutes. That's 6000 degree-minutes.
Now 1200 degrees for 5 minutes is also 6000 degree-minutes. But the bread will be predictably black.
Similarly 1 degree for 6000 minutes is also 6000 degree-minutes. But the bread will still be ingredients.
Or rather it won't. You see 6000 minutes is 100 hours. Which is 4 days as near as makes no difference.
That matters because ingredients are organic. They have a shelf life. A sell-by/eat-by expiry date. They decay.
And even if baking the ingredients for 4 days at 1 degree did produce something vaguely bread-like the extra time would create extra cost. In lots of ways. Extra time does that.