You'd think with all my video game experience that I'd be more prepared for this

3 imperfect strategies for system test data management

2009-07-05T05:06:00.001+10:00

Automatic discovery of input data
Configurable input/output expectations and controlled data refreshes
Automated scripts to manipulate/insert data after each refresh

Some thoughts on roles and hand-offs

2009-07-05T05:01:00.000+10:00

Here's a typical role and hand-off sequence that I encounter in "waterfall" shops:

Customer -> Business Analyst -> Developer -> Tester

And then they learn about Agile so the sequence changes to this:

Customer -> Business Analyst -> Tester -> Developer -> (Business Analyst + Tester)

... which really misses the point. We're not just re-ordering hand-offs, we actually want to remove them.

What I'm looking for is a sequence that looks more like this:

(Customer + Business Analyst + Tester + Developer) -> (Tester + Developer (referencing Business Analyst and Customer as useful)) -> (Customer + Business Analyst + Tester)

If the Customer time is constrained,

Customer -> (Business Analyst + Tester + Developer) -> (Tester + Developer) -> (Business Analyst + Tester) -> Customer

Don't just make it visible, make it tangible

2009-07-04T05:58:00.000+10:00

I was talking to Erik yesterday and he was wary that I used the phrase "make the internal quality issues tangible" and said he preferred visible or explicit.

I suggested that explicit and visible aren't actually enough. I truly mean "tangible" because the particular situation I'm targeting is the non-technical audience that doesn't understand what is happening with the long-term health of their systems due to short-term project trade-offs.

Explicit is a number which is too abstract. Visible is better because then they can see. But I actually want people to feel, emotionally, the danger which they are putting themselves in.

Our target is tangible with visible being along the way there.

Selfish Superstar Inventory

2009-06-13T10:18:00.000+10:00

Bob Sutton is creating a Selfish Superstar Inventory based on the idea that organisations that destroy cooperation and information tend to celebrate solo, selfish superstars.

That post included a reminder of something described in Hard Facts:

organizations that emphasize the differences between the very best versus the "merely" competent and reliable employees may do a better job of holding on to the stars, but often undermine overall team and organizational performance.

I wonder if this observation holds true if you replace "organization" with "nation".

My rules for presenting at Ignite

2009-06-11T21:44:00.002+10:00

I've only presented at Ignite once but here are my rules:

1 concept per slide - no bullet points!

Use images or better yet hand drawn sketches

Rehearse twice... once to learn where to adjust, once more to make sure you can do it... no more, otherwise you'll become inflexible

Don't stop talking! The slide transition is simply a reminder to shift what you're talking about. If you try to match the transitions perfectly, you'll become inflexible.

Hold the mike up to your mouth and keep it there!

Jidoka is not just "built-in-quality"

2009-06-11T21:42:00.000+10:00

Sometimes people use "built-in quality" or "stop and fix" as a replacement for jidoka and I've realised that this is not accurate.

Jidoka is not just about stopping and notifying of problems immediately. It also includes the concept of separating human and machine work. Effectively the idea of using machines to free humans. The machines work for us, we don't work for them.

If we do consider the stop and notify aspect, it's not really about the automated stops and visual indicators. It's really more critically about people seeing problems and pulling andon cords. It's really more about people interpreting what is actually happening.

The most destructive thing to introduce is a sense of powerlessness

2009-05-31T11:24:00.000+10:00

The most destructive thing to introduce to a team is a sense of powerlessness; the most valuable thing to introduce to a team is a sense of possibility and control.

What I've realised is that for the situations where I have seen ineffective retrospectives, there has also been a lack in a culture of fixing all the small stuff day-by-day (aka daily kaizen culture). My thought now is that the first step should be encouraging daily kaizen through problem / countermeasure boards, daily standups, and just continually fixing all the small stuff before worrying about retrospectives, quality circles, and the like.

Problem / Countermeasure board

2009-05-31T09:55:00.000+10:00

There's a cool Lean tool that again I learned from KM&T which is called a Problem / Countermeasure board.

This is a visual management tool using an A3 or whiteboard, etc. that has headings similar to the following:

Owner | Problem | Containment | Countermeasure | Target Date | Status

The structure is simple because what we're targeting here is daily kaizen, all the little problems that happen day-to-day. Containment is about immediate workarounds. Countermeasure is about what we determine should be done after root cause analysis (e.g. 5 Whys) to fix the problem permanently. Status should follow PDCA.

The rules are also simple. When there's a problem, write it up on the board. Make the problems explicit to encourage us to deal with them.

A key point is that this is not a "whining wall". When you write up the problem, you are signing up to champion the effort. And the people signing up should be the operators (aka people doing the work), not managers.

My bio in Portuguese

2009-05-27T08:54:00.000+10:00

Will be presenting at Agile Brazil at the end of June and here's my bio in Portuguese:

Jason é Consultor Líder da ThoughtWorks. Após se deparar com o Extreme Programming em 1999, ele foi motivado a entrar na ThougthWorks em 2001, onde tem aumentado o seu conhecimento e experiência em práticas Ageis de desenvolvimento de software. Jason conheceu o Lean em 2003, a partir do Desenvolvimento de Software baseados em Lean da Mary Poppendiecks. Desde então, ele se aprofundou na literatura acerca do Lean, frequentou um Lean Summit, visitou fábricas Lean, incluindo a Toyota, e fez a Lean tour no Japão, em 2008. Pode-se destacar que: a atual perspectiva de Jason sobre Agile é certamente influenciada pelo Lean.

Steps for using a fishbone / cause and effect diagram

2009-05-26T07:31:00.000+10:00

Alan Beacham of KM&T recently clarified my understanding of how to use fishbone diagrams and I thought it was worth sharing:

The head of the fishbone is not a problem so much as an effect, whether negative or positive. This is why this tool can be used to both solve a problem as well as design a solution.
Brainstorm possible causes of the effect. Don't worry too much about categories at this point.
Cluster similar causes together (i.e., affinity mapping). The standard categories (Equipment, Process, People, Materials, Environment, and Management) may help at this point.
Filter out causes using anything from intuition to scientific analysis based on time, cost, and the impact of being wrong. This avoids going deep on irrelevant causes or causes we can't currently address.
Engage in 5 Whys on the targeted causes that are significant and that we can address

Bas Vodde on Agile maturity models

2009-05-22T20:35:00.000+10:00

From the Scrum Users list in an October 2008 thread on "What do you think about agile tests like Scrum Nokia test?":

In general, I do not find "agile maturity model", "Agile assessment models" or "agile tests" useful since they tend to be a simplified view on a complex subject.

Kanban is a tool for tapping people's potential by fostering creative tension in the workplace

2009-05-20T21:45:00.000+10:00

So many quotes I like from Chapter 2 of The Birth of Lean but I can't really quote the entire chapter so here is the best one:

"I thought of [kanban] entirely in terms of reducing work-in-process, raising productivity, and illuminating problems. Of course, it is good for all those things. But your basic aim is something else, isn't it? You use the kanban to create a positive tension in the workplace by reducing work-in-process, and that motivates people to do better than they ever thought they could do." -- Michikazu Tanaka

Three pictures on value stream mapping

2009-05-16T10:16:00.000+10:00

I was asked to sketch a few pictures to summarise value stream mapping and ended up creating the following:

Some thoughts on optimising the build process

2009-05-16T08:18:00.000+10:00

I've recently been doing work on improving a build and continuous integration setup so I've been thinking about a few things:

A significant change occurs when the time to complete a build and test cycle drops below the commit rate because this removes queuing in front of the build pipeline.

It's important to look at end-to-end cycle time as well as whether queuing is occurring.

Serialising continuous integration pushes batching behaviour to developer workspaces. Developers start committing larger changes which is prone to introducing defects.

If we have queuing in front of the build pipeline, we should be able to provide some compensation with cross-workspace sharing enabled by distributed version control systems.

Quotes from The Birth of Lean: Chapter One

2009-05-16T07:56:00.000+10:00

I'm currently reading The Birth of Lean which is a book about interviews done with people involved in the early days of the development of the Toyota Production System. Chapter 1 is Taiichi Ohno:

"The Toyota Production System is one and the same with TQC [Total Quality Control] and with its principle of zero defects. They're simply different names for the same basic approach."

"In the workplace, trying something immediately, even something imperfect, is always better than letting things sit while you refine a solution."

"Some people would have liked to turn out as much work as possible for "the good of the company." ... I told them to go take a walk if they got ahead in their work. We were better off if they would just twiddle their thumbs."

"... some kinds of work do not allow for stopping the line or even varying the speed of the line. ... Those kinds of work call for other approaches to highlighting problems and promoting kaizen."

Why are you cleaning?

2009-05-13T20:05:00.000+10:00

Via Kevin Kellher at GigaOM,

In Jeff Bezos' 2008 Letter to Amazon Shareholders there is a footnote with the following:

"At a fulfillment center recently, one of our Kaizen experts asked me, “I’m in favor of a clean fulfillment center, but why are you cleaning? Why don’t you eliminate the source of dirt?” I felt like the Karate Kid."

Cool.

Corey Ladas on just-in-time (though he calls it pull and kanban)

2009-05-12T18:16:00.000+10:00

"Don't build features that nobody needs right now. Don't write more specs than you can code. Don't write more code than you can test. Don't test more code than you can deploy." -- Corey Ladas

Summary of JAOO Sydney 2009

2009-05-10T18:30:00.000+10:00

Attended JAOO Sydney 2009 last Thursday and Friday so here are my thoughts...

Note: I don't normally attend any ThoughtWorker sessions because hey... I can just talk to them directly. Just assume those sessions were good. :)

Highlights: Avi Bryant, both talks. One on understanding why it's possible and important to make Ruby faster and another, which was the best of the conference, about sharing the experience his team had designing a new product. Beyond the talks, he just generally seems to be a cool guy (and a fellow Canadian!). Meeting him in person actually exceeds his reputation which I was already aware of from Seaside and DabbleDB. Myles, who is himself quite the impressive Ruby hacker, summed it up quite nicely: "Wow... he's good".

Mike Cannon-Brookes' talk about all the interesting things they're trying at Atlassian.

Low points: Too many bullet points! Gah! Given that I bumped into Linda Rising there, I was reminded of how PLoP uses shepherding to prepare papers before the conference and it occurred to me that presentation shepherding might be something worth introducing. Most of the speakers have very deep knowledge and experience. It's unfortunate when poor presentation style undermines message delivery.

Funny points: Steve Hayes saying the he doesn't want me to attend any of his presentations since I was doing presentation critiques via Twitter. Bullet points aren't "visual hooks"!

Fun points: Java Puzzler session with Joshua Bloch with a few puzzles that apparently were being presented for the first time.

Chatting with Linda Rising, Avi Bryant, and Steve Hayes about the peculiarities and origin of the Farenheit system for temperature and various other trivia.

Surreal points: Two people walking out of and red carding (i.e., score as dislike) Avi's second talk (aka the one I considered the best of conference). I found it fascinating that this occurred because it suggests some kind of fundamental flaw in understanding about the work we do. What was happening inside their heads?

Going to watch Star Trek at the nearby IMAX, bumping into Douglas Crockford, and inviting him to join our group.

Other random interesting points: MEF appears to be something like OSGi but not quite (which may not be a bad thing). Realised that a number of people didn't understand that Clemens Szyperski was not just talking about Dependency Injection and that wasn't the point. (I blame presentation style)

Javascript safe subset projects: Caja and ADsafe

Flex demos are always very slick and I'm quite weary of dealing with cross-browser issues so I wonder...

Things that could be part of a daily meeting

2009-05-05T20:11:00.000+10:00

Walk the story wall / kanban board to focus on the flow of work, not on the utilisation of people.

Walk the Problem / Countermeasure board / Kaizen Newspaper to focus on improvement.

Discuss one-point lessons since making things is about making people.

Free Lean Training Modules at Gemba Academy

2009-05-05T19:57:00.002+10:00

Via the Lean Blog,

Gemba Academy has a selection of free training modules on Lean. The Introduction to Lean video is quite good.

TagCrowd

2009-05-02T15:38:00.003+10:00

Wordle seems to have more options so I'm not sure how TagCrowd fits in but I guess it's worth seeing how my blog is trending...

created at TagCrowd.com

Focus on efficacy and esteem takes cares of itself

2009-05-02T07:27:00.000+10:00

I was thinking about Coding Dojos... and how the most interesting part was how we improved dramatically by introducing a point of reflection and adjustment in the middle... and then about how retrospectives should be about problem solving, not therapy... and then about problem / countermeasure boards... and then about how -5 to 0 thinking is not the same as 0 to +5 thinking, that is, just removing problems is not the same as defining perfection and removing what prevents you from getting there... and then about how effective it is to use direct observers focused on detecting problems with a process, even if the people working should also be observing... and then how observation could be focused on what is working rather than what is not... and then I remembered Randy Nelson from Pixar University talking about improv and the concept of "plussing"... and then I thought...

Wouldn't this be an interesting way to run a Coding Dojo? We have one or more people assigned to observation of problems and one or more people assigned to observation of things done well. At the mid point, those observers along with the other participants go through the problems and identify countermeasures, and go through the things done well and identify pluses. And then I thought...

Why should this be limited to a Coding Dojo? I've been in situations in projects where work is drying up and people don't really know what to do so they fill their time with miscellaneous activities. Why not deliberately, take on a role of observer? Why not do this throughout a project as a rotating role? Or perhaps we train each other to all take on this role as well as our normal one, use tools like problem / countermeasure boards and worked well / plus boards to continuously improve. And then I thought...

Maybe we don't even need to start too unconventionally? Maybe we just adjust how we approach our retrospectives. I then remembered Matt's comment asking me to expand upon why retrospectives should not be about sharing pain but rather about getting better which make me think about what I'm suggesting that is different.

This comes down to the difference between self-efficacy (belief in one's capability) and self-esteem (belief in one's worth). It turns out that building self-efficacy is much more important than building self-esteem which is devoid of self-efficacy. Self-esteem is better seen as a result of self-efficacy. When I say that "retrospectives should not be about sharing pain but rather about getting better", what I'm really saying is that if we focus on efficacy, esteem will take care of itself. Focusing on problems and countermeasures, worked well and plusing, is surprisingly effective in leading to immediate and sometimes dramatic improvement in efficacy and this has an incredible effect on feelings of one's own capability and of one's self-worth.

If you want an improvement culture, 20 expressions to avoid

2009-04-22T07:37:00.000+10:00

From 40 Years, 20 Million Ideas: The Toyota Suggestion System:

Everyone understands that!
We've never done that before, there's no point in trying.
I tried to do that before, and I know it won't work.
This isn't up-to-date enough.
Is this within the budget?
There are just too many plans being made -- I'll take a look at your opinion when I have time.
Let's talk about this some other time.
Let's wait a while and see how things turn out.
Why do you want to change? Aren't things going okay now?
There is a rule on this, so it's no good doing it that way.
I don't think that's technically feasible
This idea is really off the wall, the manager will never agree to it.
That's just not done at this company!
That might work somewhere else, but not here!
The real world is more complicated than that.
You don't really understand the situation, do you?
Your suggestion is good, but the company can't afford it.
This will create problems later on.
Even if I give you advice, there's still no way.
What is this suggestion? Can't you make it a little better?

Via Mark Graban

Lean Times Require Lean Thinking

2009-04-15T07:59:00.000+10:00

A presentation I did with Paul Heaton of KM&T about Lean:

Lean Times Require Lean Thinking

View more presentations from ThoughtWorks.

The world is full of fools, except for me, of course

2009-04-14T07:11:00.004+10:00

I watch people laughing at situations and I'm noticing that it is often perceived by observers as laughing at them for getting into that situation. And the result of this is predictable.

I worry that in many, if not most, cases that this perception is accurate. I suspect that this is what the person laughing believes: The world is full of fools, except for me, of course.

But perhaps I'm succumbing to fundamental attribution error.