me.andering – Willem van den Ende

Ok, its’ a bit late, they have been online for some time. I hadn’t gotten around to selecting my favourites from the photographs I took at XP Day Benelux 2004 so far. Pascal van Cauwenberghe categorized and commented selected pictures on the XP Day Benelux website. I’ve also put up all photos without comments. This is one of my favourites:

The chicken Marc Evers and I used for the Systems Thinking workshop taped to the conference retrospective wall.

At XP Day Benelux we learnt that it is more like a Duck (have you ever seen a yellow chicken with feet made for swimming?). This came out of the Chicken Talks session. Originally, in the timeslot of the Chicken Talks, there was a session planned called Lightning Talks. As with any conference I guess, there are risks in the program. One of the risks for 2004 was that there would be no presentations submitted for the Lightning Talks. The Lighting Talks was intended as a session with brief five or ten minute presentations, presenters had to submit their talk before the start of the conference. The idea being, this would enable people to put last-minute ideas into the program, as the remainder of the program is already fixed several months in advance.

We did a risks analysis before the conference. Most risks did not materialize, the one for the lighting talk did. Since we had an overview of possible risks, it was easy to switch to mitigation actions for the few risks that do materialize.

As a mitigation action for the Lighting Talks Pascal van Cauwenberghe worked with session organiser Bernard van der Beken to invent an alternative session. The evening before the conference they had about three different ideas for a replacement session. To remain agile with respect to the program, we have no printed program leaflets. Instead, we put up the sessions on the conference website, and on a wall in the conference centre:
.Onwall Conference Program

I printed out the program the day before, and took a printer with me to print last-minute changes to the program and session handouts if need be. We decided to keep the new session description hand-written, so it would be more clear that the session had changed.

Pascal and Bernard came up with the name Chicken Talks, because attendees chickened out sending in lightning talks submissions, and the chicken plays an important part in the session.

The session centered around a variation of the Talking Stick Protocol (also known as Circle Talks ). The chicken was used instead of a talking stick. The other variation was, that instead of asking for the stick, the chicken is thrown around. The person holding the chicken must speak (he or she is also the only one allowed to speak, as with the talking stick). When the speaker is done, he can throw the chicken to anyone else in the group. As the chicken is softer than a stick, this is safe to do. This variation of the protocol ensures that everyone gets to speak, which is quite useful with a group of technical people, as they are often quite introverted. I could not attend this session, judging from the reports of those who did, it was a great success. One of the outcomes of the session was, that the group decided the Chicken was more like a duck… So from now on, it shall be known as Ducky the Chicken .

We’ve used the Chicken Talks at the newyears’ reception of our extreme programming users’ group two weeks ago, which also was a great success. I’ve added it to my facilitation toolkit. It was fun to see people throwing the chicken around, and observe how different people hold the chicken. It was especially good to hear people who are usually a bit on the background. If you try the chicken talks out, I’d be interested to hear how it worked for you!

So far I’ve resisted blogging about blogging, but the end of the year seems to be an excellent time for reflectiosn on blogging. Over at Unbound Spiral Stuart Henshall is writing about Giving up traditional blogging. A long piece with many interesting ideas about the past and future of blogging and comments from readers.

It seems, that as more and more blogs appear, it becomes harder to follow blogs, or even distill trends from blogs, since, as Ton Zijlstra writes, a lot of the information in blogs depends on their context. I personally haven’t made much time for reading all blogs I subscribed to recently, since I can’t make space for all the ideas generated by them. Don’t get me wrong, I’m grateful for all the excellent blogs around, but I can easily ‘lose’ a day by surfing the blogs.

Pascal van Cauwenberghe recommended me to read The Toyota Way by Jeffrey K. Liker. I can see why now I resonate with many of the ideas and paradoxes, articulated much more clearly than I can yet. I’ll go into some of the ideas with quotes from the book below – I find so much to quote I recommend you read it for yourself if you’re interested in the topic. The Toyota Way book focuses mostly on the Toyota Production System. As Liker says:

I want to be clear, that the Toyota Production System is not the Toyota Way. TPS is the most systematic and highly developed example of what the principles of the Toyota Way can accomplish.

I find The Toyota Way easy to read, it lends itself well to be read chapter by chapter while I’m sort of in the midst of a tornado this week: moving to a new house in Eindhoven, doing two consecutive nights of game workshops (Who’s dropped the Ball with Marc Evers for xp.be in Leuven, and Game Of Goose with Nynke Fokma for Ordina in Nieuwegein), as well as working with ZeelandNet on their next round of improvement through Agile Software Development .

Misconception: TPS is a set of tools

with mysterious sounding acronyms like 5S, JIT, Kanban. Unfortunately I encounter many (project) managers who are looking for ‘tools’ – handy spreadsheets, planning forms, testing-tools and work practices that will solve all of their problems. Some ‘tools’ can enhance your productivity enormously (e.g. Test Driven Development). If you want to go beyond that, you have to go beyond the practices into the principles – that is the way I see eXtreme Programming, its values and practices form a system. I often ask people:

Do you value the practices, or do you practice the values?

The Toyota Way is, like XP, an evolving system of values and practices. Fujio Cho, President of Toyota Motor Corporation is quoted saying:

Many good American companies have respect for individuals, and practice kaizen and other TPS tools. But what is important is having all the elements together as a system. It must be practiced every day in a very consistent manner – not in spurts – in a concrete way on the shop floor.

The book proves this principle applies to practice with stories about the birth of Lexus and the Prius. These stories show the work practices at Toyota continuously improve. Toyota maintains, even in times of prosperity, a crisis mentality. When there is no crisis, one is created, so participants continue to be challenged. These challenges can only be overcome by continuous learning through (amongst other things) questioning assumptions and embracing change.

Misconception: Lean equals Mean

A common mistake about the Toyota Production System (TPS) is, especially when it is called Lean Manufacturing, that it is mean. Recently, a session about Lean Thinking and the Theory of Constraints Pascal van Cauwenberghe and Rob Westgeest submitted to SPA2005 was rejected. One of the reviewers commented:

This reminds me too much of the Six Sigma style methodology we are implementing at name of company witheld that I just hate!

Six Sigma is a statistical process for optimizing large manufacturing processes. Many small-scale software and hardware companies are now applying it on processes which are too small to consider applying statistics to.

TPS is not like Six Sigma. It emphatically calls on the creativity and spirit of the people involved to learn and solve problems. Terms like Eliminate Waste and Lean are rapidly interpreted by some people as ‘downsizing’ – I think that view is short-sighted:

Eliminating waste means eliminating steps that do not add value for the customer. This means only value-creating and value-adding activities remain. This leads eventually to high-customer satisfaction and a long-term relationship with the customer, which means for Toyota a stable and growing stream of revenue, leading to high profit margins, a large cash-reserve and long-term job security for the people working at Toyota. As the book says:

Lean is about developing principles that are right for your organization and diligently practicing them to achieve high performance that continues to add value to customers and society. This, of course, means being competitive and profitable.

I see how many of the principles apply to my projects – there are many similarities with Agile Software Development and Agile Business Consultancy. I’ll ruminate some more about that offline and possibly come back to that later.

Several of my friends are currently working in organisations undergoing severe reorganisation. When I say severe it can mean reorganisations that are dragged out over a long timespan, decisions are delayed and made without buy in, and in one case, a large proportion of the staff is unsure about their job. I can tell you from the stories of my friends that this is bad for motivation, and creativity. Now there is also research to support this.

through a post by William Pietri in the XP mailinglist I came across The 6 Myths Of Creativity By Bill Breen in Fast Company magazine. If you believe Creativity Comes From Creative Types or Time Pressure Fuels Creativity, I recommend you read this article. If you don’t believe it, and need proof, read it too . Other myths: Money Is a Creativity Motivator, Fear Forces Breakthroughs, Competition Beats Collaboration and A Streamlined Organisation is a Creative Organisation.

Creativity suffers greatly during a downsizing. But it’s even worse than many of us realized. We studied a 6,000-person division in a global electronics company during the entire course of a 25% downsizing, which took an incredibly agonising 18 months. Every single one of the stimulants to creativity in the work environment went down significantly. Anticipation of the downsizing was even worse than the downsizing itself — people’s fear of the unknown led them to basically disengage from the work. More troubling was the fact that even five months after the downsizing, creativity was still down significantly.

In one organisation, middle management is unsure what is going to happen, so they try to shape up their department so it looks as good as possible. They try to stimulate creativity by fear (e.g. ‘if we don’t do such-and-such we will look bad in the review, and our department – i.e. your job – won’t make it’), they put on pressure and try to bypass the formal planning process.

This might work for a weak or two, but over a longer period, quality of the software developed and systems running in this department is decreasing ever so slightly – making it more and more likely users will start to complain, and make the department look bad in the review. With all the time-pressure and task-switching the team is more likely to make errors, because they have less time to communicate with one another, and stop the line to identify and solve root causes behind problems. Mmmm. sounds like a Diagram of Effects in the making. If you happen to have one about this problem lying around, please let me know!

On a related note, Nynke Fokma has just made a Diagram Of Effects of short and long term effects of Cooperation versus Competition based on the Prisoners Dillemma. showing that in some cases (for two parties), competition might seem to benefit one party, but in the end each can only gain by collaborating. One thing that seems obvious to me, is that both parties spend a lot of time computing trust. Time they might better spend in coming up with a creative solution…

When reorganisations last too long and people are uncertain, I see competion for jobs not only between departments, but also between individuals. The backstabbing, lying and manouvering is not pretty. That might explain why it takes so long after a reorganisation for creativity to return – people simply don’t trust their coworkers anymore. To paraphrase a Dutch anti-alcoholism ad:

Een reorganisatie maakt meer kapot dan je lief is..

(rough translation: A reorganisation wrecks more than you’d like)

.

At the beginning of the year, I noticed several people announcing which programming language they are going to learn this year. They follow a recommendation by Dave Thomas and Andy Hunt to learn a new programming language every year. I’ve been programming for over twenty years now, and in that time have programmed in a lot of programming languages. At first, I couldn’t come up with anything. I saw many people start trying ruby or smalltalk. Been there, haven’t completely done that. So, like many other people I’m getting (re-)acquainted with Smalltalk by programming in squeak smalltalk.

After some thought and blog-reading, I came up with two possible things to explore. I’m not so much interested in particular languages, maybe more in exploring different programming paradigms. Following discussions on e.g. the squeak mailing list on the future of CPU’s, it is obvious something is bound to change. CPU’s can hardly be made more complex than they are now (for they will be very unreliable) and can’t go much faster with regard to clock speed (barring other technologies such as light-switching). Two avenues that seem worthwile to explore are massively parallel CPU’s – CPU’s with multiple cores, and digital signal processing with FPGA’s (Field Programmable Gate Arrays).

Most popular programming languages don’t support parallellism well. I attended a tutorial on Java threads – it is so easy to create non-obvious, hardt to trace defects with them, that it is better to use them as little as possible. Patrick logan is writing about programming in Erlang:

I want to understand how to think in terms of processes being about as cheap to create as objects are in other languages.

Bill Clementson has a report about disruptive programming languages, reporting from a workshop he attended:

…the opportunity for concurrent programming to be a distruptive technology is in that many applications are either explicitly or implicitly concurrent or distributed but are poorly catered for by concurrency features (OS threads, language threads, RPC) in use today. If a language provided superior concurrency capabilities, it could displace more popular languages in specific application areas. Once the “innovator” language assumes prominence in the “niche” area, it would expand further in usage and popularity and potentially displace the more popular languages in other areas as well.

The report has an interesting comparison of reliability of the Apache webserver versus one written in Erlang. The Erlang webserver is able to handle far more concurrent connections.

Laurent Bossavit is writing about Recording design decisions. I gave up on the idea of recording (all) design decisions years ago, when I was doing research into that topic at the University of Twente, together with Marc Evers. We tried to come up with a formal model that would trace each decision back to a corresponding piece of code. The complexity of instances of that model was mind-boggling, especially if you start taking the evolution of source code over time into account.

We came to the conclusion, that the number of decisions involved in creating any computer program is too large to record meaningfully. Another conclusion we arrived at, was that many decisions are made at lightning speed inside our head, and some decisions we are unable to articulate. I think that is one of the underlying reasons attempts at documenting software in detail often fail (besides the fact that very few software people enjoy writing prose).

One thing I usually do when working with a team, is to regularly (every hour at least) check in code to the version control system, and add a one-line comment when checking in. These comments reflect the closest practical thing I found to keep a trace of design decisions. I noticed after some time, that we rarely look back on the comments – I think it is because team members find it more effective to ask each other ‘why is this part built the way it is’, re-create the assumptions underlying the design by asking ‘why’, and either working from those assumptions, or re-defining the assumptions and start refactoring.

The best way I found to get design decisions out in the open is to do Pair Programming, so two programmers are forced to articulate a larger part of their design decisions. Even then, it is recommended practice to code out versions of an idea as a Spike Solution, if a discussion takes to long, and continue the discussion after two versions of the idea are complete: sometimes an idea is more easily expressed in source code than it is in natural language…

I’m asking myself: Why would I want to record design decisions?. I haven’t felt the desire to do that since leaving university. If the design is simple, and we keep requirements as automated acceptance tests, we are free to change the design whenever we want to. The acceptance tests provide the context we need to start finding appliccable (design) patterns. Perhaps the desire to record design decisions is an indicator we are building overly complicated software?

Rather than making an effort to record more design decisions, we can get leverage from simplifying our design and doing more automated acceptance testing.

Now I’m back from my trip to Consultants Camp and San Jose, I’m still sleep-deprived and jet-lagged.

Neverheless, I went to the open space conference of the Dutch Society for Organisational Learning. The theme of this day was Unlearning. I had a great day, meeting interesting people from a variety of fields. Marc Evers and I put up a play of Warped Juggle on the planning board. We had a cozy session with five participants, which gave us some new perspectives on the Satir Change Model, amongst others – Unlearning happens during the chaos phase, and with scenario planning we might welcome chaos, rather than experiencing it as painful. We put up more output from this session on the SystemsThinking.net wiki.

I’m still busy making sense from the Cynefin framework for sensemaking (for a brief introduction on how I see it so far, see the previous post on Cynefin). I’m puzzling on how eXtreme Programming could fit in several domains, and how choreographies from one domain to another would work. Richard Veryard, also raised the question about XP, in his blog post on a brief history of methods. He places XP in the ‘known’ domain. As I was re-reading the Cynefin paper this week I’m making some progress in understanding it. Or so I believe. As my thoughts went in many directions, I created a mindmap about how I could place XP in the various domains.

So far I find the chaos domain the most puzzling. I’m not sure thinking about software is appropriate in that domain. In chaos brainstorming and deciding on a choreography to one of the other spaces (preferably complex) might be more appropriate. I can see how XP could fit (and misfit) in known, knowable and complex – although in each context it has a different effect, and you can use it for a different purpose. I hope to work on the mindmap a bit more and then write a longer post about it.

Rachel Davies is blogging about what for me was one of the highlights of XP Days Londen 4 – a presentation and workshop by Dave Snowden about Cynefin, a framework for Sensemaking. You can find more information about this in the paper Sense Making in a Complex and Complicated world by Cynthia Kurz and Dave Snowden (IBM Systems Journal, Vol 42, No3, 2003).

Luckily, I read the paper before going to the workshop – that left some room in my head to fill some of the gaps in my understanding the paper had left me with, rather than being overloaded (as most of the workshops’ participants seemed to be. It made quite an impression). By the way, the reason I read the paper was that I was wondering if paying to attend this workshop was worthwile. Since after reading I still had many puzzles, I thought it would be, and it was. I’m still ruminating over these ideas.

One of the ideas that resonated most with me was the Cynefin Domains model. It is sort of a two-dimensional matrix. The paper has a nice graphical depection that makes it clear that the boundaries between the domains are semi-permeable. One way I understand this model, that an organisation can move from one domain to another by making sene of where it is now – and seeing if the paradigm it currently applies for e.g. decision making is appropriate. I’ve transcribed the four domains into a table:

To give one illustration (more in the paper mentioned above) Systems Thinking and Scenario Planning fit into the Knowable domain. Someone at XP Days London asked me if I didn’t find it annoying that Dave Snowden sort of mowed the grass before my feet; Marc Evers and I were hosting a Systems Thinking workshop at XP Day London the next day.

I responded that I was very glad for the context setting Dave Snowden had done – we used the Cynefin Domains model in the introduction of our workshop, as we are constantly looking for a better way to briefly introduce Systems Thinking at the start of a workshop. I am not Systems Thinking it is one of the techniques I use to make sense of the world around me, if and when appropriate.

So how do I believe this model relates to appropriate forms of setting up an organisation? I immediately related this to Gerald Weinberg’s Cultural Patterns (aka Shooting and Aiming Stances) for organisations, so I came up with this mapping:

The Congruent cultural pattern would be equivalent to sensemaking: taking self, other and context into account, and choosing (and changing, if the domain shifts) a cultural pattern that is appropriate. When I was reading the wiki page on Cultural Patterns I realized I forgot Oblivious. Thinking about it now, I find it hard to place. Maybe the oblivious cultural pattern is not realizing where you are, and not making any choice for an organisational form.

The connection was somewhat natural, since with a group of systems thinkers we’ve been thinking about how to move from one cultural pattern to another. In the workshop and paper, Dave Snowden says they’ve identified a number (27 if I remember correctly) of specific choreographies to move from one domain to another.

For instance, working iteratively is a way of moving from Known to Knowable and back, and moving from Knowable to Complex can be done by Exploration (to move in the opposite direction, use Just-In-Time Transfer).

Dave Snowden talked about the relation with eXtreme Programming. At first sight, I would place XP at the Known/Knowable boundary, because of the Iterative aspect. He seemed to place it in the Complex domain which left me a bit puzzled.

The way I could place it there, is that XP also has an exploratory component (e.g. doing spikes), and the extremely short iterations make it possible to investigate multiple alternative solutions (relating to what Snowden calls probes, exploration and to Set Based Development). Another component to XP/Agile is delaying (design) decisions as long as possible, which relates to just-in-time transfer.

I just noticed I’m using a lot of emphasis in this post. It seems to have a high jargon density. I’m looking forward to the article collection promised at cynefin.net, so I could upgrade some of the emphasized words to hyperlinks. In the meantime, I recommend you read the paper if these ideas interest you. I’m also interested in any comments you may have on this blog entry, as I’m busy understanding the Cynefin paper.

A while ago, I wrote about the relative uselesness of Rehashing.

Every now and then, someone else will ask me questions about the past, since I don’t rehash voluntarily anymore. I prefer to work on the future. Marko van der Puil asks me how I reconcile that with facilitating retrospectives.

To me, retrospectives are as much about the future as they are about the past. We collectively investigate a set period in the past, to achieve closure on the past, and determine concrete actions for our future. If a retrospective doesn’t turn up personal and collective actions for positive change, we might as well have skipped it altogether.