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

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):

the overall start time

the time each customer's project starts (when the developer writes down the first letter of their name)

the time each customer's project is delivered (when the developer writes down the last letter of their name)

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.

It's sometimes necessary to remind ourselves that Shakespeare at some point learned to write a line of prose, Beethoven learned the musical scales, and as you see in the margin quotation, Vincent Van Gogh learned how to draw.

And the margin quote is from a letter written by Vincent Van Gogh to his brother...

...at the time when you spoke of my becoming a painter, I thought it very impractical and would not hear of it. What made me stop doubting was reading a clear book on perspective, Cassange's Guide to the ABC of Drawing: and a week later I drew the interior of a kitchen with stove, chair, table and window - in their places and on their legs - whereas before it had seemed to me that getting depth and the right perspective into a drawing was witchcraft or pure chance.

If you use a projector it's a good idea to let it do its job. Accidentally standing in front of the beam will obscure parts of the projection and annoy your audience. An effective, low-tech solution to this problem is a roll of masking tape! Simply mark out no-go areas on the floor between the projector and the screen/wall.

In Dan Pink's book Drive he mentions a publication called
ambidextrous. This got me thinking it might be fun to learn to write left-handed (I'm right handed). Every week or so I've been copying a short paragraph with my left hand and taking a photo the resulting scrawl...

When the top two classes are in one package and the bottom class is in another package the effect is to create a package dependency pointing upwards (think of the inheritance triangle as a fat arrowhead). It's odd that this style for drawing inheritance is so dominant as it is in stark contrast to how package/layer dependencies are typically drawn - pointing downwards. The solution is simple - rotate the diagram!

However, associations are conventionally drawn left to right.
Again the solution is simple - this time the diagram needs a reflection!

Is the title of a great science-fiction book by Jerry Weinberg (yes, the same one who wrote The Psychology of Computer Programming and The Secrets of Consulting - among many others). I really enjoyed reading this - the story moves along at a brisk pace and is full of invention. Sometimes the ideas seem so plausible you wonder if they are actually true. And some of them are! For example, Jerry assures me that dogs can and are trained to help owners cope with fits in exactly the way he describes towards the end of the book. Amazing. There's a clever twist in the title too which you might spot. Definitely recommended.

Learning: Any relatively permanent change in behaviour as a result of experience or practice.

Composition: An ordered relationship among the parts or elements of a work of art. In drawing, the arrangement of forms and spaces within the format.

Abstract Art: A translation into drawing, painting, sculpture, or design of a real-life object or experience. Usually implies the isolation, emphasis, or exaggeration of some aspect of the artist's perception of reality.

My wife and our three kids live in a fairly small end-terraced house. My work-related books are taking up too much space so I'm going to give a load of them away at this years
ACCU conference.
My plan is to choose a charity and ask everyone who takes a book to make a voluntary donation. I've already collected one boxfull. If you're coming to the conference maybe you'd like to consider contributing some books too?

is the title of a great book by Patrick Lencioni. The subtitle is "a leadership fable" and pages 1-185 form a story of how a new CEO starts to turns around a dysfunctional group of individual high achievers who are not pulling together as a team. Each "chapter" is rarely more than four pages long and the story moves along at a brisk and enjoyable pace.

The last forty odd pages explain the five dysfunctions model:

Absence of trust (invulnerability)

Fear of conflict (artificial harmony)

Lack of commitment (ambiguity)

Avoidance of accountability (low standards)

Inattention to results (status and ego)

Just one quote this time:

Politics is when people choose their words and actions based on how they want others to react rather than based on what they really think.

I'm self employed and work from home a lot. I have a small whiteboard stuck to the wall near my desk which my son Patrick enjoys writing on. So I bought another mini whiteboard for him. I hadn't planned it - but gradually the whole family has starting writing little messages on his whiteboard. As my children grow up (I also have two teenage daughters) they're leading increasingly independent lives and we seem to all be in the house at the same time less and less. The whiteboard provides a simple and direct way to chat asynchronously. And I think that helps them express themselves more freely.
I also bought a divers slate so I could jot ideas down as they come to me in the shower. They've adopted that too!

Title

Short Abstract

The usual format for a code dojo is fairly well known: participants split into small groups, each group codes on their own laptop, all groups work on the same coding exercise with keyboard drivers rotating within the each group periodically. Towards the end of the dojo the coding stops and everyone presents their work in turn. This form of practice is often called a kata.

A cyber-dojo is different in one important respect: each group still has their own laptop but they all perform the kata completely inside a web browser. A dedicated cyber-dojo server hosts the kata, saving the source files (and the outcome of running the tests) every time the run-tests button is pressed in the browser. Running a code-dojo in this manner creates many new exciting benefits:

starting the kata is virtually instant - participants do not need anything installed at all.

all the step-by-step incremental run-tests submissions can be inspected helping to place a much greater emphasis on the decisions taken during the kata rather than simply the code at the end of the kata.

the cyber-dojo server allows everyone to peek at the current submissions of all groups!

since all development environments are now identical it is even possible to introduce timeboxed iterations to the kata and rotate codebases at each iteration!

it speeds up the end of kata retrospective (since you don't have to physically involve each individual laptop).

The aim of a cyber-dojo is to introduce deliberate practice to software development. The talk will explain the nature of deliberate practice, demonstrate a live kata using the cyber-dojo server, and give away copies of the server software to anyone who would like to run their own cyber-dojo.

Outline

explain what deliberate practice is and how it differs from plain practice

remind everyone how a standard code dojo is run

introduce cyber-dojo and explain how it is different

reveal the new exciting code dojo possibilities cyber-dojo creates

performing a small live cyber-dojo kata

short questions and answers session

give away the cyber-dojo server software to anyone interested

Level

All

Expected audience

Anyone who is serious about wanting to improve their coding ability!

Names

Jon Jagger, jon@jaggersoft.com

Olve Maudal, olve.maudal@tandberg.com

Biographies

Jon Jagger is an independent software coach-consultant-trainer-enthusiast based in England. He specializes in agile software development (people, process and principles), test driven development, deliberate practice, design, analysis, OO, UML and curly bracket languages. He served as the convenor and principal UK expert on the ECMA C# committee and has co-authored two books on C#. He is a frequent visitor to Oslo and has presented at the Oslo C++ User Group and JavaBin. He is a regular speaker at the Accu conferences. You can follow him at http://jonjagger.blogspot.com/ and http://twitter.com/JonJagger
He is 43, married with three children. He loves freshwater river fishing.

Olve Maudal loves to write code, but is perhaps more interested in how software is developed than what it actually does. Since 2004, Olve has been working for TANDBERG, the leading provider of telepresence and video conferencing products and solutions. Previous experience includes developing systems for finding oil (Schlumberger 1996-2000), and developing systems for electronically moving money (BBS 2000-2004).
Olve is an active member of the vibrant geek community in Oslo where he is involved in JavaPils, Cantara, XP Meetup, Oslo C++ Users Group, Lean Meetup and a few other things.
You can follow him at
http://olvemaudal.wordpress.com and http://twitter.com/olvemaudal

Notes to the program committee

If there is demand I will happily run cyber-dojo's outside scheduled talk time.