A few people have commented on twitter about Deming’s contention that 95% of what you see is down to the system and only 5% is down to the individual. They keep asking where he got the 95% from.
He used to run a course, which is still available as a book: Four Days with Doctor Deming. At the very beginning of the course he invited the participants to play a game with red and white beads. There’s a youtube video describing it here. The you pick up beads with paddles, the workers are rewarded for picking up white beads and punished for red, even ‘fired’.
When you look at the numbers for the game it turns out that the workers have no control over the physical process of selecting the beads. In one trial someone may do really well, and in another badly and get ‘fired’.
In statistics we use confidence limits. When we take a new measurement you look at it and can perform some analysis to say how likely it is that the measurement falls inside the existing set of measurements. Typically we use the 95% confidence limit to say that there is a one in twenty chance that the measurement doesn’t fit what we were expecting. If it falls inside then we have what’s known as the null hypothesis, that there isn’t any noticeable effect for that particular measurement.
Deming’s point was that in most processes any effect that the individual may have is swamped by the system their are part of, in fact the variability they cause is just part of that system overall. So if measurements are falling within the confidence limits you can’t point to one person over another and say they’re better or worse.
So changing things, for better or worse, mean you have to change the entire system. It’s an iron rule, the system always wins. No amount of arbitrary targets, shouting, or wishing can change this. I cover this in more detail in the video talks on my consultancy website.
One way of doing this is to have some kind of gatekeeper who inspects everything and makes sure it complies. This is the standard backwards command and control way of assuring quality: do the inspection after you can perform any intervention that might resolve the problem. It also means you have guaranteed that there will be a bottleneck. Of course, you can have it in front of any work, where there is some kind of oversight. This just means the delay is upstream of any value instead of down.
Instead, there’s an old trick, which is to have swat teams. These are teams made up of experienced individuals who know each other well and work together. Their job is to start new projects, but not finish them. They also work with teams that are stuck or lagging to help them get past whatever problems they have.
The swat team hands off to the less experienced team that will finish the job, it means that there is already a body of knowledge of how we approach things, what the architecture is, etc. built into the project. Of course, this will require pairing and patience. But it means that work gets started well, in a standard way, with all of the levers for continuous improvement in place, by people who know how to do this. Then it’s picked up by others who learn what the standard approach is, without a gatekeeper and a lot of bureaucracy.
This is a team version of staff liquidity, which is discussed in the Commitment book. Staff liquidity uses experts’ knowledge and skills in such a way as to make sure there is enough slack to deal with emergencies and still get the work done.
Speaking at Lean Agile Scotland http://www.leanagilescotland.com/speakers#francisfish - this is September 19-20 2013 in Edinburgh. The talk is based on the new material presented in the September 2013 release of the book.
Speaking at Agile Cambridge http://agilecambridge.net/ac2013/programme/ this is September 24-27th, 2013 at Churchill College, Cambridge UK. This is an updated reprise of the “it’s not your fault” talk on the consultancy site. I believe that InfoQ will be filming the session and I’m proud to follow in the footsteps of many people I admire.
I’m attending, but not speaking at, Design it, Build it http://www.dibiconference.com/ which is 7-8th October at Gateshead, UK (the 8th is my birthday).
I’m also going to Lean Conf 2013 http://www.leanconf.co.uk/ which is 26-27th October in Manchester. So, if any readers want to talk to me please seek me out if you are at any of these events, they’re all worth going to.
The process and the people
I am a Level 3 Kayak (L3K) coach and have been for several years, probably around 15. In the software industry there are a lot of folk who call themselves coaches, but I do find myself wondering if they’ve ever had any kind of formal training. It took me a lot of time, money and personal risk to become a coach and I don’t regret it at all.
By the way, I don’t consider a three day Scrum Master course to be formal training. I had to meet the prerequisites, which were things like being a Level 2 coach, and holding various first aid and rescue qualifications. Then I had to do a three day course, where I became a candidate, then I had to amass at least 50 documented hours of supervised coaching, and then I had to do another 3 days assessment. The people running these courses had to go through very stringent criteria to run them.
I also have to attend recognised events every few years to make sure I’m still up to date. I don’t see this in the software industry. I do see a lot of pretence and bureaucratic certification, but that’s a different thing.
A L3K can take people on white water, assuming he or she feels they are competent and the group isn’t too big. In fact I spend a lot of time working on flat water with the Guides and Brownies, which means I work with total beginners aged between 8 and 10 who can’t even hold the paddle. Many coaches don’t like this, they want to work with older and more experienced paddlers.
I love it. It means I have to keep going back to the beginning and making sure I can express them in ways people can understand. It means I never lose contact with the fundamentals. There is a story about an American football coach, who used to begin every training season holding a ball and saying gentlemen, this is a ball. You have to have the fundamentals or you won’t go far, and you have to return to them or you may lose your way.
People learn by doing. There is no substitute for this, but equally there is a problem where you can create an ingrained habit that is a bad habit, where that habit holds you back. This makes coaching a very tricky proposition, it’s not practice makes perfect. Although this is true, it’s perfect practice makes perfect. You need the input of someone standing outside where you are, who knows the common faults and their solution. Then you need to be willing to sometimes start again, or at least it feels like it. You need to be practicing in a way that grows your skill, not embeds problems.
For example in the kayking forward paddling is a fundamental skill. A beginner will place the paddle in the water and pull on it, this will give them some forward movement, after a while of trying and experimentation they will learn to paddle forwards in a straight line. But if you were to compare their paddling action with someone who was say, a top-level slalom competitor, you would see a number of differences. Mostly to do with keeping the paddle close to the boat and using twisting of the body rather than just movement of the arms to engage the core and leg muscles for maximum power.
So you have to keep learning to paddle forwards over and over again as you get better. I’ve had to almost go back to the start three times in the last twenty odd years I’ve been paddling and every time I come out of it with a better, more powerful stroke. But I can’t fill a beginner’s head with this stuff, it would only confuse them and put them off. I always try to get them twisting if they can understand it, that helps a lot.
When you find yourself in a coaching situation the other thing is you have to go where the people are. What this means in practice is there’s no point in talking about a complex stroke, or rolling your kayak, or even the many techniques for rescuing people who have come out of their kayaks until the person can paddle where they want to go consistently and competently. They first need to be relaxed, and have a certain competence, before they even try to do anything more difficult. They have to be able to paddle forwards somehow before they can improve upon it.
In fact, they are incapable of taking on any more information until they get past the fears and annoyances they are experiencing right now.
Introducing something new
When I was a very new coach we used the acronym IDEAS
I think these points are pretty obvious, with the possible exception of explanation, which briefly touches on the why.
Of these Activity dwarfs the others. My big fault when I was new to coaching was talking too much. You need to show what needs to be done in small enough pieces and then get them to show you what it is they thought you said by doing it. That’s the process, not talking. Demonstrating, doing, not talking. Watching them in action and knowing the common stumbling places to help them overcome them, not talking. The summary is also extremely important because it helps the good behaviour become fixed.
Finding a coaching opportunity
There are two kinds of opportunity:
- Catching people doing it right - reinforcement
- Catching people in need of correction or direction - tuning
Notice I was very careful not to say doing it wrong. If you see a behaviour you don’t want you must work out where it came from and then correct it. If someone is doing it wrong, it’s your fault for not explaining or demonstrating well enough, or they just weren’t ready for the finer points the first time you showed them.
It’s not a problem, just show it again. As long as they are paying attention and trying their best there’s nothing to get worked up about.
The worst word you can use is but, particularly with male participants. Everything positive you said before the but is lost. Because of our school system and the way we’re wired, we listen for the negative, so criticism and correction have to be couched very carefully. It’s best, in fact, to ask a question to try and draw out the reasons for the problem. It’s best to let people discover the right answer themselves. A coach is a guide, an instructor instructs - be careful to be the former. A coach creates a safe place for people to learn.
No matter how keen somebody is to learn something once they get tired they will start to find it hard. Try something else or just bring the session to a close. If you start to flag then the same is true.
It’s important to inculcate good habits. For example, one of the worst things you can do when surfing or using support strokes is to lean back. When you are a beginner on flat water you discover that it lowers your centre of gravity and makes things easier. On moving water it creates vulnerability and also locks your hips, making control and recovery much harder. So I teach leaning forward and encourage it, but it doesn’t always go in.
So, in coaching people to be better coders recognise the bad habits - rushing in hacking instead of thinking, pasting in whatever comes out of google without understanding it, having a cynical attitudes that damage team productivity or a default position of blaming others - which usually comes from not listening carefully and checking assumptions.
This also links with tiredness and stress; when you are tired you fall back on the original habits you had because they were the first thing you learned. They are the default position, so cultivate good habits from the beginning. I know from my own experience that this is far harder than it sounds.
The beginner doesn’t know what they don’t know. So in fact they are capable of discovering new things that the coach can’t see because of their preconceptions. It’s always good to engage with the beginner, that’s how you keep yourself fresh. It also means that beginners aren’t necessarily wrong, and the questions they ask can be really useful and stimulating. It saddens me that our awful educational culture means that people often don’t ask these useful, gem like questions, because they’re afraid of looking silly or standing out. I’ve built my career on a playful, constructive silliness.
Beginners also need simple rules to help them - rules that an expert knows are more like guidelines. Simple rules can get you from zero to 80%, and they are always worth sharing if you have some. But just be careful they don’t become the dead hand of bureaucracy and start choking everybody. Rules are a what and very powerful, but an expert knows the why and when to bend or break them. Beginners need to lay in the good habits, so don’t confuse them, and stay quiet until they start to hit the limitations of the rules, then they can learn.
Part of going where people are means you must leave your ego at the door. Part of respecting the beginner’s mind means that you must also listen to what beginners have to say. If you don’t listen you are no use. You can’t go where someone is if your arrogance means you can’t see the map they provide you. This is why I often feel doubtful at self-appointed coaches, and why I don’t get on with the macho culture you often find in software teams.
If your participants aren’t enjoying the experience they won’t learn anything except they don’t like it. If you aren’t enjoying it you won’t be able to share what you have to share. So always look for fun and interest in what you do.
First thing - I wasn’t interested in the data, but the data had come across from the Heroku dumps. I was just making sure no-one had messed about with the schemas.
I poked around in the files and noticed that everything schema related had a CREATE in front of it, and the table creates ended with
At the end of a line. I decided that I would write a little Ruby program that would print out everything between a CREATE and a ); After I had a poke around in the file I decided that a semicolon on its own would do the job
lines = $<.readlines.map(&:strip)
printing = false
lines.each do |line|
printing = printing || line =~ /^CREATE/
puts line if printing
printing = false if line =~ /;$/
This uses the $< variable that sets up either the list of files on the command line, or stdin if no files were supplied.
Ruby didn’t like the dump files, it kept complaining about invalid utf8 characters.
I used the file command to see what type of file it thought the dump was and it said binary.
Aha! Says I, we can use the string command to pull out all of the printable text
strings file1.dmp | ruby extract.rb
But the ruby command was finding lots of rubbish and not seeing the end of the table creates. I read the manual for strings and realised that it will only print 4 or more printable characters at a time, but you can lower the number, hence:
strings -n2 file1.dmp | ruby extract.rb
So in the end I used this to generate 2 files with each of the schemas in them and did a simple diff. All it showed was the name of the database was different.
How many times have you heard employers or politicians talking about empowerment?
They’re going to give you permission to make decisions that affect you, or perhaps the people you serve. They’re going to allow you to organise things in a way that makes you feel happy with what you do, gives you the autonomy to do it right. Oh. That’s big of them, isn’t it?
This rests on some fundamental fallacies:
- In order to have any capability beyond some repetitive mechanical work someone has to give you permission.
- Someone has to pick you, and other people (therefore) have to wait.
Think about it - did Gandhi ask anyone for permission? He saw a problem with the world and just started doing whatever he could to change it. I went to Thinking Digital in May and one of the talks towards the end was a 15 year old who had come up with a cheap test for pancreatic cancer that will find early stage using carbon nanotubes, antibodies and filter paper. Wow.
He’s bright, very bright. But lots of other people are too. He was upset by the loss of a relative to this disease and decided to do something about it, he read a lot and came up with some things to try. Then he badgered some medics with research facilities until one let him come and try to develop a protocol.
It works, I hope it will come soon too. But the point I’m making here is no-one told this fantastic young person no. No-one gave him permission. He just went and did something that makes the world a better place.
So, the next time someone offers to empower you tell them where to get off. Pick yourself.
If you work in a way that creates systems and processes where human beings make human decisions then empowerment is not needed, permission is not needed. Grab that filter paper, grab those nanotubes, talk to that person.
Since I first made this post, which is a sketch of an idea I will develop further in Unicorns in the Mist's next outing more things have occurred to me that I wanted to share here.
I was chatting on Facebook and realised that I believe empowerment is also insulting. To clarify:
Insulting to the “empowered” - as in “you’re no longer too child like to look after yourself”. My take comes from a lot of the rhetoric you used to hear when people who had been disenfranchised by poverty or some disability where being ‘empowered’ by the state to make bogus ‘choices’. Instead of addressing the real need for creating systems that meet and help their needs they were so powerful they can fill in a survey. This is of course a simplification but I hope it helps getting the point across.
And, of course, the flip side of being given permission is that it also allows the giver to take it away again. That’s big of them too. It assumes a paternal relationship and distribution of power where the empoweree (sic) has to rely on others to validate what they do. Just take a look at the whole crazy gang of incompetents and buffoons that try to run your life and think about how little permission they can ever grant you, or anyone else.
One of the other speakers at Thinking Digital was talking about opening up government data, which is a cause dear to my heart. Apparently at least some of the nominal owners of this data are concerned that people like us, the poor unwashed masses, might draw the wrong conclusions from this data. Wrong in terms of whatever ideology or spin they want to put on it. So the empowerment that this data may bring should be conditional on whatever they think we should be saying or knowing. Yeah. Bless them.
As Deming is reputed to have said in Jesus Christ we trust, all others must bring data. I’m not a Christian, but the rest of the sentiment is sound :)
Implementing Domain-Driven Design by Vaughn Vernon
My rating: 4 of 5 stars
I think this is a great book in terms of the ideas it promotes, but for me somewhat flawed.
It’s billed as a companion to Domain-Driven Design: Tackling Complexity in the Heart of Software and as such is less abstract and works through some case studies to get to the meat of what that the original DDD book only hinted at and actually went round and round a lot.
For me it harks back to a lot of things I have recently read and done, in particular the design process for good (for some definition of the word) object-oriented software, as Practical Object-Oriented Design in Ruby: An Agile Primer covers really well. Sandi talks about OO being all about the messages, and you end up with well put together clusters of objects if you start from there.
DDD comes at the problem from a different direction, instead starting out at a higher level of abstraction in the problem domain, rather than creating objects and seeing how they work together. It has some tools for uncovering what the business wants. It starts by looking for a ubiquitous language and making sure that the development and testing silos are speaking the same language as the business.
Of course, it’s more complicated than this. Vernon gives the example of a book publisher. The people commissioning a book need different language to describe setting up their relationship with an author and paying them, the people creating the book and illustrating it again have different needs, and distributing and stocking the final physical product is different again. So, if you were trying to create some kind of master book object that met all of these needs you may well end up with conflicting terms, and indeed needs expressed by those terms.
To get round this you break your problem space into bounded contexts, and these become functional areas which each have the own ubiquitous language. This gets around the weird mashing together of functionality that quite often makes large systems a complete pain to maintain. Each area manages its own needs and translates, as and when required, if it needs to talk to another. I believe that a pretty reasonable SOA architecture will fall out of this in the end.
I think I’ve understood this process after a hundred pages or so, but I don’t want to read any more of the book. I had the same problem with the original DDD book as well. The core concepts are pure gold, but the presentation is extremely repetitive, wordy and really hard to read for useful content. Both books needed more pictures and a catalogue of the concepts, organised rather like Martin Fowler’s Patterns of Enterprise Application Architecture - with about 100 pages of well-written and illustrated chat with the remainder of the book taken up with a list of the patterns in detail once you know how to use them. In fact, both books need a damn good edit.
The other thing that I find really annoying is things like bounded context, once introduced, are always capitalised Bounded Context. Maybe it’s just me, but the constant capitalisation of a concept really breaks the text up and interrupts the flow. The original DDD book does this as well. This capitalising thing is a disease caught from an old-fashioned style of writing, common to people who read the King James Bible, which was written at a time when you would capitalise nouns. Myself, I use italics when I introduce a concept and then either abbreviate it to, say, BC, or just use it as normal. This capitalisation reads like the old pompous religious tracts handed out by slightly demented people going door to door when I was a kid, and I didn’t like it then either.
So I would like a list of all of the Ideas Expressed With Capitalisation and how to use them, and about half the amount of text without all the waffle. I gave up because I got the concepts and the rest of the signal to noise was too low.
The cartoons of the cowboys make no sense to me either, and there was a weirdly old-fashioned feel to the one offering your stakeholder a cup of coffee to talk to them. You could probably put each chapter into about three paragraphs and not lose a lot of information.
So, I gave the book four stars because the ideas are incredibly useful, but be prepared to struggle with keeping awake between the useful nuggets.
Incidentally, if you want Sandi’s book, please buy it from her site.
View all my reviews