scrum

is an excellent book by Jeff Sutherland, subtitled A revolutionary approach to building teams, beating deadlines, and boosting productivity (isbn 978-847-94108-4). As usual I'm going to quote from a few pages:
The most powerful part of Scrum from his [Jeff Johnson] point of view? Demos.
Scrum is not about the developers. It's about the customers and stakeholders.
I learned a lot about systems theory and how a system only has certain stable states. As a cell evolves, it moves from one stable state to another. Figuring out the rules to move a complex adpative system from one state to another, and how to make the next state a positive one rather than a negative one, was something I spent nearly a decade on.
To change a cell, you first inject energy into the system. At first there's chaos, there seem to be no rules, everything is in flux...
"How many gantt charts have you seen in your career?" I asked.
"Hundreds," he replied.
"How many of them were right?"
He paused. "None."
In business we all too often focus solely on individuals, even if production is a team effort.
It's the system that surrounds us, rather than any intrinsic quality, that accounts for the vast majority of our behaviour.
Every three weeks each team had to demonstrate to their colleagues what it was working on. This was an open demonstration; anyone could come. And if that demo wasn't both working and cool, [MediaLab] directors killed the project.
"Sprints." We called them that because the name evokes a quality of intensity.
Nothing gets moved to Done unless it can be used by the customer.
After engaging for a while in Sprints and Stand-ups, you stop seeing time as a linear arrow into the future but, rather, as something that is fundamentally cyclical.
People think in narratives, in stories.
The Product Owner has to be available to the team, to explain what needs to be done and why. While the Product Owner is ultimately accountable for the Backlog, there needs to be a constant dialogue with the team.
Orientation isn't just a state you're in; it's a process. You're always orienting... [OODA]


the genius in all of us

is an excellent book by David Shenk, subtitled why everything you've been told about genetics, talent and intelligence is wrong (isbn 978-184831218-0). As usual I'm going to quote from a few pages:
We're better at stuff because we;ve figured out how to become better. Talent is not a thing; it's a process.
We do not inherit traits directly from our genes. Instead we develop traits through the dynamic process of gene-environment interaction.
In truth, the [word] 'intelligence' has become a mere vocal sound, a word with so many meanings that finally it has none. [Charles Spearman]
Stability does not imply unchangeability. [Michael Howe]
In 1932, psychologists Mandel Sherman and Cora B. Key discovered that IQ scores correlated inversely with a community's degree of isolation.
Talent is not the cause but the result of something.
People make a great mistake who think that my art has come easily to me. Nobody has devoted so much time and thought to composition as I. [Mozart]
Heritability is a population average, meaningless for any individual person. When someone says that heritability of height is 90 per cent, he does not and cannot mean that 90 percent of my inches come from genes and 10 percent from my food. He means that variation in a particular sample is attributable to 90 percent genes and 10 per cent environment.
Genes don't directly cause traits; they only influence the system.
Genes are probabilistic rather than deterministic. [Michael Rutter]
We have far more control over our genes - and far less control over our environment - than we think.
What would be really interesting for people to see is how beautiful things grow out of shit [Brian Eno]
The brain circuits than moderate a person's level of persistence are plastic - they can be altered. They key is intermittent reinforcement.


the reason I jump

is an excellent book by Naoki Higashida, subtitled One boy's voice from the silence of autism (isbn 978-1-4447-7677-5). As usual I'm going to quote from a few pages:
The Reason I Jump unwittingly discredits the doomiest idea of received wisdom about autism - that people with autism are anti-social loners who lack empathy with others. (Foreword)
I very quickly forget what it is I've just heard. Inside my head there really isn't such a big difference between what I was told just now, and what I heard a long, long time ago.
What makes us smile from the inside is seeing something beautiful, or a memory that makes us laugh. This generally happens when there's nobody watching us. And at night, on our own, we might burst out laughing underneath the duvet.
When I see I've made a mistake, my mind shuts down. However tiny the mistake, for me, it's a massive deal. Once I've made a mistake, the fact of it starts rushing towards me like a tsunami. And then, like trees or houses being destroyed by the tsunami, I get destroyed by the shock.
There are times when I can't act, even though I really, badly want to. This is when my body is beyond my control.
When I'm jumping, I can feel my body parts really well... and that makes me feel so, so good. By jumping up and down, it's as if I'm shaking loose the ropes that are tying up my body. When I jump I feel lighter.
It's not quite that the noises grate on our nerves. It's more to do with a fear that if we keep listening, we'll lose all sense of where we are.
My guess is that the despair we're feeling has nowhere to go and fills up our entire bodies, makes our senses more and more confused.
When you see and object, it seems that you see it as an entire thing first, and only afterwards do its details follow on. But for people with autism, the details jump straight out at us first of all, and then only gradually, detail by detail, does the whole image sort of float up into focus.
Numbers are fixed, unchanging things. That simplicity, that clearness, it's so comforting to us. Invisible things like human relationships and ambiguous expressions, however, these are difficult for us people with autism to get our heads around.
I understand that any plan is only a plan, and is never definite, but I just cannot take it when a fixed arrangement doesn't proceed as per the visual schedule. Visual schedules create such a strong impression on us that if a change occurs, we get flustered and panicky.
We can put up with our own hardships okay, but the thought that our lives are the source of other people's unhappiness, that's plain unbearable.

some cyber-dojo measurements

cyber-dojo has hosted about 13,000 practice sessions so far. I've written a short ruby script to extract some measurements from a sample of 500 sessions. I was looking at transitions between red, amber, and green traffic-lights:
  • red means one or more tests failed
  • amber means the tests did not run (eg syntax error)
  • green means the tests ran and all passed
The first column is average number of lines added/deleted.
The second column is colour → colour transition.
The third column is sample size.

3.94 ambergreen 447
4.65 amberred 379
4.67 amberamber 1462
5.39 redgreen 607
6.01 redred 604
7.52 greenred 420
13.65 greenamber 436
17.67 redamber 432
22.18 greengreen 598

Here's how I interpret the results:
  • If you're at red or green and you make a small change (5.39,6.01,7.52) you're likely to stay at red or green.
  • If you're at red or green and you make a large change (13.65,17.67) you're likely to transition to amber.
  • There is a big spike in the number of amberamber transitions (1462). I speculate that long sequences of these transitions are occuring after a large 13.65 greenamber or 17.67 redamber transition.
  • I think the greengreen value of 22.18 is larger than it should be because it's including plain file renames.


deliberate duplication TDD at XP Days Kiev

Back in October I did a 90 minute TDD master-class at XP-Days Kiev using cyber-dojo. You can watch the video of the talk which is now online. In it I code a simple exercise (Print Diamond) using sliming and deliberate duplication with refactoring.
  • I discuss ‘sliming’ – the technique of hard-coding magic-numbers to make tests pass.
  • How can sliming help guide your choice of what test to write next?
  • How can sliming be combined with deliberate duplication?
  • With micro-refactoring?
  • How do you know you’ve slimed too much?
  • How and when should you unslime?
  • I look at the the word “unit” in Unit Testing to understand why the definition is useful.
  • I consider some very important differences between “real” code and “test” code – they are not the same.


systems-thinking at NorDevCon

Today I'm in Norwich to run a cyber-dojo at NorDevCon.
Last night I presented a short talk on Systems Thinking. Here are the slides:

improving

From The Mind of War
He also came to appreciate the routine practice and repetition that was required to become really good at something and to overcome the boredom by focusing on minute improvements.

From Taiichi Ohno's workplace management
Once he asked me how the terms kaizen and kairyo (reform) were differentiated in the West. I said that while kaizen means to make improvements by using brains, kairyo means to make improvements by using money, and that in the West, most managers only think of improvement in terms of money. [Massaki Imai]

From Nudge
The best way to help Humans improve their performance is to provide feedback.

From Becoming a Technical Leader
People improve their performance not by amputating their old behaviors, but by adding new ones.

From The Toyota Way
Extra inventory hides problems... Ohno considered the fundamental waste to be overproduction, since it causes most of the other wastes… big buffers (inventory between processes) lead to other suboptimal behaviour, like reducing your motivation to continuously improve your operation.

From Smart Swarm
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.

From Peopleware
The more you improve the way you go about your work, the harder the work will be.

The paradox of the CMM is that process improvement is good, but process improvement programs aren't, or at least they often aren't.

From Implementing Lean Software Development
The paradox is that in our zeal to improve the predictability of software development, we have institutionalized practices that have had the opposite effect. We create a plan, and then we act on that plan as if it embodies an accurate prediction of the future.

From Dr Deming
To improve output, production, sales, profit, quality, or any other important factor, every part of the organization had to improve.

From Toyota Kata
The improvement kata does not come to life in an organisation simply because it is a good idea.

In many cases the normal operating condition of an organisation - its nature - is not improving.

At Toyota, improving and managing are one and the same.

From Certain to Win
If a just-in-time production line had to wait for a formal decision process to work, it would hardly move at all, and it would never improve.

From Toyota Production System
Improvement is eternal and infinite.

From Quality Software Management: Vol 4. Anticipating Change
You need stability in order to make improvements.

Testing to improve, not to prove.

If leadership improves then the culture must improve.