pair programming presentation at XP Kiev

It was my pleasure to speak at the XP Kiev conference recently. I spoke about Pair Programming, or more accurately, about not programming alone. It really is about Pair Programming despite the picture of me fishing at the beginning! Here's the video :-)

XP values - some quotes

The Systems Bible

Management of the Absurd

The Conquest of Happiness

Mastery

The Aesthetics of Change

How to use conscious purpose without wrecking everything

The Agile Manifesto

The Systems Bible

fun with feedback frequency

I'm currently reading Brain of the Firm, by Stafford Beer. On page 36 he writes:

The outcome is startling ... ... the total system is dominated, not by the forward network, but by the feedback network ... The output signals will be of greater 'purity' than we had any right to expect.

The word feedback caught my eye.
Feedback is a key principle of complex adaptive systems.
Feedback is also one of the 4 values of eXtreme Programming.
Feedback also gets several mentions in the official Scrum Guide.
So I've been playing around with Feller's walk (named after William Feller) some more...

Feller's Walk

Each Feller's walk is 1000 steps long, and at each step I flip a fair coin.
As I walk I keep a running total (starting at zero):

• adding one each time I flip a head
• subtracting one each time I flip a tail

What will the total look like as the walk progresses?
Here's the plot of the step (x-axis) against the total (y-axis) during one simulated walk.

It starts at a total of zero on the far left and wanders along, edging upwards when a head is thrown, edging downwards when a tail is thrown, and ending at about -26 indicating that overall there were 487 heads and 513 tails (487-513=-26, 487+513==1000).

Apparently, most people's intuition is that the total will hover around zero.
But it doesn't.
You cannot rely on randomness to correct the problems that randomness creates.
Without constraints variance will accumulate.
If the total happens to be +24 the coin isn't going to throw more tails for a while to try to balance things up.
Without feedback the coin has no memory.

To help see this I simulated 5000 walks and plotted the frequency of the total (y-axis) against the total (x-axis) at various points along the walks:

• after 10 steps in gold
• after 100 steps in blue
• after 1000 steps in red
• I chop the x-axis to +- 2 standard deviations

step	freq[0]	max abs(total)	std.dev
10	1204	-10	3.19
100	405	36	10.15
1000	121	140	31.71

Over all the walks, at the 10th step:

• the total was zero 1204 times (5 heads, 5 tails, 5-5=0, 5+5=10)
• the total farthest from zero was -10 (0 heads, 10 tails, 0-10=-10, 0+10=10)
• the standard deviation of the total was 3.19

Over all the walks, at the 100th step:

• the total was zero 405 times (50 heads, 50 tails, 50-50=0, 50+50=100)
• the total farthest from zero was 36 (68 heads, 32 tails, 68-32=36, 68+32=100)
• the standard deviation of the total was 10.15

Over all the walks, at the 1000th step:

• the total was zero 121 times (500 heads, 500 tails, 500-500=0, 500+500=1000)
• the total farthest from zero was 140 (570 heads, 430 tails, 570-430=140, 570+430=1000)
• the standard deviation of the total was 31.71

The further along the walk I progress, the less likely my total is to be zero.
Without constraints variance will accumulate.

Once again, with feedback

Every Nth step, instead of flipping the coin, I look at the total and:

• if the total is negative (more tails than heads) I pretend I've flipped a head, and add one to the total.
• if the total is positive (more heads than tails) I pretend I've flipped a tail, and subtract one from the total.

This feedback increases the likelihood of the total staying nearer to zero.
The smaller the value of N, the greater the effect.

Estimating feedback effectiveness

Using the simulation I can measure how good (or bad) people's estimates are of how effective feedback is. For example, I can:

• run the simulation with some feedback (N==10 say) and display the results
• gather estimates with no feedback (N==never) of, eg
  • freq[0], or
  • max abs(total), or
  • std.dev, etc
• run the simulation with no feedback and see how the actual results compare.

Or

• run the simulation with no feedback and display the results
• gather estimates of the least feedback needed to, eg
  • triple freq[0], or
  • quadruple max abs(total), or
  • half std.dev, etc
• run the simulation with various amounts of feedback and see how the actual results compare.

I've put the simulation source up on https://github.com/JonJagger/Fellers-1000-coin-tosses.
The simulation runs directly from this URL https://rawgithub.com/JonJagger/Fellers-1000-coin-tosses/master/fellers.html so you can try out various values of N if you want to before reading on...

A little feedback goes a long way

Here's 5000 simulations of a 1000 step walk with N==25.
That means, that every 25th step instead of flipping the coin, the simulation nudges the total towards zero as described above.

step	freq[0]	max abs(total)	std.dev
10	1379	-10	2.97
100	553	32	8.04
1000	387	84	15.18

The effectiveness of one feedback nudge every 25 steps amazes me.

• freq[0] tripled from 121 to 387
• max abs(total) shrank from 140 to 84
• std.dev halved from 31.71 to 15.18

Startling! Just as Stafford Beer said.
Let's hear it for feedback!

you need to tell this to our managers

I did a very enjoyable live coding presentation using cyber-dojo at XP Days Ukraine last week. At the start I asked the XP question and, as usual, the audience told me lots about the XP practices (such as pair-programming) but struggled to name the four XP values, and failed to name courage.

On more than one occasion, while consulting or training at a customer's site trying to help explain and convey "an agile mindset", I've been told

you need to tell this to our managers

If I did tell their managers I'm pretty sure I know what would happen.
Can you guess?
Scroll down for my answer.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
I think their managers would say

you need to tell this to our managers

.
.
.
.
.

XP and culture change

Last week, at a clients site, I noticed an old, coffee-stained copy of the Cutter IT Journal. It was titled "XP and culture change", dated September 2002. Here are some quotes from it.

From Kent Beck:

Because culture embodies perception and action together, changing culture is difficult and prone to backsliding.

Is it easier to change your perception or go back to designing the old way?

From Laurent Bossavit:

A process change will always involve a cultural change.

We were also a culture of Conviviality, which you could easily mistake (as I did at first) for a culture of Communication... In Conviviality what is valued is the act of sharing information in a group setting - rather than the nature, quantity, or quality of the information thus shared.

Culture is what remains when you have forgotten everything else.

From Mary Poppendieck and Ron Moriscato:

If there were one thing that Ron's team would do differently next time, it would be to do more refactoring.

XP is a process that doesn't feel like a process.

The theory of punctuated equilibrium holds that biological species are not likely to change over a long period of time because mutations are usually swamped by the genes of the existing population. If a mutation occurs in an isolated spot away from the main population, it has a greater chance of surviving.

From Ken Schwaber:

Agile process management represents a profound shift in the development of products and software. Agile is based on an intuitive feel of what is right, springs from a completely different theoretical basis than traditional development processes, and is in sum a wholly different approach to building products in complex situations.

From Matt Simons and Chaitanya Nadkarny

A fixed-bid contract changes the very nature of the relationship between customer and vendor from collaborative to "contentious". "Embrace change" undergoes a fatal transformation into "outlaw change."

There is no way to pretend everything is fine when you have to deliver software to your customer every few weeks.

From Nancy Van Schooenderwoert and Ron Moriscato:

The advantages of pair programming hit you hard and fast. As you explain an area of code to your partner, you get a deeper understanding of how it fits into the current architecture. You're your own peer reviewer!

After pair programming for a while, we found ourselves in a situation where the entire team had worked somewhere in the module in the recent past. Code reviews became exciting idea-exchanging periods where refactoring tasks were discussed and planned.

With schedule pressure, there is a huge temptation to put off refactoring, and we did too much of that.

It's not enough for the code to work; it also has to serve as a solid base for the next wave of features that will be added.

All through the project, a frequent cause was that unit testing wasn't thorough enough.

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!

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.

We'll never survive!

One of the books for the accu charity book stall is my copy of Extreme Programming Explained by Kent Beck (1st edition).
One of the entries in its bibliography is a quote from The Princess Bride.
Buttercup and Westley are about to enter the Fire Swamp and face it's three terrors: the Flame Spurts, the Lightning Sand, and the Rodents Of Unusual Size (R.O.U.S.'s).







Buttercup says to Westley (Kent misquotes slightly here):

We'll never survive

and Westley replies:

Nonsense - you're only saying that because no one ever has.

I just love this line. And I love Kent's idea of putting a film quote in the bibliography. I love that it's in the bibliography in a section called "Attitude". I think Kent is hinting at their courage - that depending on your attitude life can be an adventure. After surviving the flame spurts Westley says to Buttercup:

Well now, that was an adventure.

And a bit further on he says:

The Fire Swap certainly does keep you on your toes.

Just before facing the R.O.U.S.'s Buttercup says:

We'll never survive - we may as well die here.

To which Westley replies:

No. No. We have already succeeded.

I love that line too. (I pretty much love every line of the film.) Again it's about attitude. As they make it out of the fire swamp Buttercup says (almost in disbelief):

We did it.

And Westley says:

Now, was that so terrible?

Attitude.
Caring about yourself.
Caring about others.
Caring about the code.

The XP question

What can you tell me about XP?

That's the question.

Take a moment to think about it.

What thoughts immediately pop into your head?

What words would you use if I was an alien and you were telling me about XP?
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Pair Programming is a common first choice. Also common are Testing (TDD), Refactoring, Collective Ownership. These are all fine things but notice that they're all directly related to the code. Programming the code in pairs, testing the code, refactoring the code, ownership of the code.

When I'm coaching or consulting I often ask the XP question. The overwhelmingly most common replies relate to the technical practices and not to the underlying values. I think that's a shame. I feel my understanding of XP's technical practices became much deeper when I thought about them in the light of XP's values.

Can you name the Four XP Values?
That's what the question is really about.
Can you name one XP Value?
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
If you did name a value what was it?
Was it Simplicity or Feedback, the values with a technical aspect?
Or was it Courage or Communication, the values with a stronger social focus?

Reading chapter 7 of Kent's book it's clear to me that the four values are core to XP. Kent writes (my emphasis)...

We need some criteria for telling us if we're going in the right direction... Short term individual goals often conflict with long-term social goals. Societies have learned to deal with this problem by developing shared sets of values... Without these values, humans tend to revert back to their own short-term best interest.

The four values - communication, simplicity, feedback, and courage... tell us how software development should feel.

How you should feel!
Do those words surprise you?
How do you feel about your answer to the XP question?

courage

I've been thinking about courage. Scott Peck writes:

The absence of fear is not courage; the absence of fear is some kind of brain damage. Courage is the capacity to go ahead in spite of fear, or in spite of pain.

Courage is one of the 4 values of eXtreme Programming. I was struck by how every mention of courage in Kent's book, and also during a short googling session, has a technical rather than a social slant to it:

• Communication supports courage because it opens the possibility for more high-risk, high-reward experiments...
• Simplicity supports courage because you can afford to be much more courageous with a simple system...
• Concrete feedback supports courage because you feel much safer trying radical surgery on the code if you can push a button and see tests turn green at the end (or not, in which case you can throw the code away).

It's sometimes said that Scrum is very good at surfacing problems, making problems visible, and that if we don't deal with these problems it's not Scrum that's failed it's us. Moments of social tension are exactly like that. Tension surfaces, is felt, but isn't held and openly dealt with, and so slowly sinks out of view.

Problems in software are always a mixture of the technical and the social. I think many developers find it relatively easy to be technically courageous but not so easy to be socially courageous. Being technically courageous but not socially courageous is solving the symptoms but not the root-causes. In every case, if you fail to deal with the underlying causes you create a bad self-fulfilling dynamic.

Courage relates to trust. Holding the issue and not letting it sink away feels risky. But if you never take any risks you're not likely to create any trust. Acting when you feel a little scared is what courage is.

Courage relates to congruence. Congruence is about alignment. If you feel X, it's ok to say that you feel X, to sound like you feel X, and to look like you feel X.

Moments of fear can be precious moments. They can become moments of courage.

extreme Programming explained

is an excellent book by Kent Beck (isbn 0-201-61641-6). As usual I'm going to quote from a few pages:

Without courage, XP just simply doesn't work.

Communication supports courage because it opens the possibility for more high-risk, high-reward experiments… Simplicity supports courage because you can afford to be much more courageous with a simple system… Concrete feedback supports courage because you feel much safer trying radical surgery on the code if you can push a button and see tests turn green at the end (or not, in which case you can throw the code away).

Pair programming works for XP because it encourages communication… In my experience, pair programming is more productive than dividing the work between two programmers and then integrating the results.

If people program solo they are more likely to make mistakes, more likely to overdesign, and more likely to blow off the other practises, particularly under pressure.

There are times when problems simply can't be solved by the emergent brilliance of the team, encouraged by a loving and watchful manager. At times like this, the XP manager must be comfortable stepping in, making decisions - even unpopular ones - and seeing the consequences through to the end.

XP is a communal software development discipline.

The best environment is one of mutual trust.

Under stress, people revert to earlier behaviour, no matter how badly that behaviour has worked in the past.

Today's design should be done today and tomorrow's design should be done tomorrow.

Nerds aren't generally good at talking.

When you say one thing and do another, bad things happen. This book [Gerald Weinberg, Quality Software Management: Volume 4(sic), Congruent Action] talks about how to be congruent yourself, how to recognise incongruence in others, and what to do about it.

The four XP values

Quite by chance I've notice several recent blog entry quotes mention the four XP values:

• Communication: Community has to do with communication.
• Simplicity: The art of maximizing the amount of work not done.
• Feedback: Practicing without feedback is like bowling through a curtain that hangs down to knee level.
• Courage: One thing that never ceases to amaze me is how relatively few people understand what courage is. The absence of fear is not courage; the absence of fear is some kind of brain damage. Courage is the capacity to go ahead in spite of fear.