me.andering – Willem van den Ende

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)

.

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.

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.

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!

One new idea that emerged during the European XP Week trip was to organise Agile Open – an open space weekend on Agile (in Software Development and otherwise) in spring 2005.

Marc Evers and I discussed this idea with several people during the xp days and afterwards (Marc also blogged about this ). The idea is, that we’d like more time to explore topics that come up during xp days and regular conferences in depth, and have a place where people from around Europe (and possibly elsewhere) can experiment with new sessions and show them to various xp-days organisers. Most XP days (even though they’re completely independentently organised) now have a session submission and review process. This works pretty well, although something kept nagging me. Duncan Pierce spelled it out clearly to me after XP-days London:

We’re reviewing session descriptions, instead of sessions.

Even though we’re trying to be independent and objective, it is much easier to trust someone you know with organising a session than someone you don’t know. I talked to some peope who thought about organising a session for this year, but didn’t get around to it. The threshold to start is quite high if you’ve never done it and are unsure about your facilitation skills. I’m starting to get more comfortable with it myself, based on the good feedback I’ve gotten over the workshops I’ve been doing. Even with experience though, getting a session accepted at a conference remains a somewhat mysterious process.

At XP Day Benelux we nevertheless had many new presenters this year. I hope next year we’ll have more new presenters, helped by the Agile Open – we’re thinking of an open space conference, where the program is decided on by the particpants at the start of the conference. We are looking to grow an overview of supply and demand with respect to workshops on Agile. With a stimulus to present session ideas before Agile Open, as well as questions for sessions from people with only a question or problem and no idea on how to organise a session around it.

One thing we’re already looking for from the demand side is more technical and entry-level sessions for XP Day Benelux.

Another reason to organise Agile Open is a recurring theme in many ongoing discussions: how to sustain a viable agile consultancy business, software house or corporate department. These questions are currently mostly debated at the bar or local user groups (and Mary Poppendiecks’ XP2004 keynote). I believe it is worthwile to go in-depth on this theme with a larger crowd.

We now seem to have a critical mass of people who want to co-organise, as well as participate so we’re going ahead with it. I’m going to send out a mail with a cost-estimate and details so far tonight to those who reacted until now. If you’d like to participate or co-organise or know someone else who might be interested, please contact me or Marc directly. We’re looking forward to make this event a reality and expand the ideas we’re having so far!

I’m driving to Enschede tonight to meet up with Laurent Bossavit, who’s in the Netherlands for EuroFoo.

Yesterday, Laurent wrote about Technology, sweet and sour

how he had to pay for WiFi service to notify me about his plane being late. In a sense, it is not in the best interest of airports to let your flight depart on time – the more time you spend on an airport, the more money you spend. For Schiphol Airport, the main source of profit used to be their shopping centre. I don’t know what happened after tax-free disappeared, but I guess not much has changed.

The dutch national railways (NS) have developed this system into a fine art. While punctuality of their trains has dropped to unacceptable levels (that was the main reason I bought a mobile phone, and after that a car several years ago…), they have at the same time turned around many of the medium and larger railway stations into shopping malls, with most of the restaurants and snack-places operated by the NS.

If the train doesn’t go on time, you are more likely to buy coffee or a snack, so the NS make more money on you. So, as a traveler you might be inclined to think that the goal of a railway or airline system is to bring you from A to B as quickly as possible, there might be multiple incentives for the operators, leading to other conclusions…

In the Extreme Programming mailinglist Kay Pentecost is raving about an interview with Johanna Rothman over at IT conversations on her book about hiring technical people and about Agile Project Management. I attended Johanna’s workshop on this topic at AYE last year, she has a many of useful techniques to offer – highly recommended.

I didn’t notice the IT Conversations site before – they seem to have a wide variety of subjects, both IT related and more people-oriented.

Together with Marc Evers I’m going to do a number of combined ballgame / systems thinking workshops at various locations in Europe over the coming month. This Tuesday, October 26th, we’ll be in Leuven at an Extreme Programming Belgium Users’ Group meeting.

In November we’re at a number of events I’m now dubbing XP Week. Friday November 19th at XP Day Benelux in Mechelen, Belgium. The Tuesday after that (November 23d) we’re in Karlsruhe at XP Days Germany and then on Thursday 25 we’ll do the systems thinking workshop at XP Day London.

On October 26th, Marc Evers and yours truly facilitated a session of who’s dropped the ball at XP.BE in Leuven. I’ll post a few pictures I didn’t get around to posting so far. The difficulty I have with posting pictures of game workshops like these, is that it might give away too many ideas for new player – the game is most educational if you play it for the first time, and I wouldn’t want to give away ideas and configurations tried, because at each play new ideas come up. I also don’t want to give away the surprises Marc and I plan that disturb the gameplay . On the other hand, I would like to show the energy and level of engagement of the participants in the game. As usual, the players got the instruction to keep as many balls in the air as possible.

Graph of balls in the air over time, a Diagram Of Effects (DOE) and players trying out a new configuration

We first asked the players and an observer what happened (events). We used that to create a the graph of number of balls in the air developed over time, and used that as a start for a Diagram Of Effects. The DOE was useful in generating more observations and interpretation of events by the participants. In the debrief there was some debate between the participants as to how much creating the DOE contributed to creating new ideas for keeping balls in the air. Pascal Van Cauwenberghe suggested to do more rapid prototyping based on small changes to the DOE. So, after what started as the debriefing, we continued with a few prototypes and discussions, and ended up with a surprising solution (not shown here, to not spoil the fun at future workshops).

Setting up another configuration

Some lessons we learnt (as appeared during the micro retrospective at the very end of the session):

• Energy is low during the introduction. Recommendation to try for next time: skip the introduction.

• Energy was low while Marc and Vera were drawing second version of causal loop diagram. The group also did not feel they owned the diagram. Try next time: make the diagram in groups, and start using post-its for the DOE variables right away – that makes it easier to change the diagram. During a brief introduction we can introduce the main aspects of the Diagram of Effects notation by drawing a mental model of what the bosses (Marc and me) think is going to happen.

• Connection to the context (eXtreme Programming) was not clear to everyone. Marko van der Puil has written a great blog entry about how the XP values relate to this game and to Systems Thinking. I hope his weblog is going live soon, so everyone can enjoy it. In a succeeding session we can ask participants at the start of the workshop to think for themselves about relations to projects they participated in, and observe how the four values ( communication, simplicity, feedback and courage) appear in playing and discussing the game.

• Some players were wondering what effect the DOE had on the final configuration. Next time, we’ll try to cut gameplay as well as discussion short even sooner. Stopping gameplay is hard, since players enjoy playing a lot as you can see in the photographs.

• Prototyping is important: if you have an idea, try the configuration ASAP, so you get feedback on your idea.

We’ll be playing this game three times within one week, at XP Days in Mechelen, Karslruhe and London. The workshop in Mechelen is likely to have a good turnout – the conference is virtually sold out, and many participants indicated a preference for this session. The London conference is now also sold out, so that will probably be a busy session as well. I’m looking forward to meeting you at one of these conferences!

Marc Evers points me to It’s time to fix tech marketing by Thornton A. May in Computerworld. Mr. May says:

In fact, assemble any senior group of IT thinkers, and even though they’ll probably fight over middleware strategy, Sarbanes-Oxley compliance campaigns, outsourcing initiatives and the future of Linux, they’ll agree that the way vendors market products and services is dysfunctional, if not an actual roadblock to value creation.

he names as one of the causes:

Inappropriate and outdated mental models on why and how technologies enter the organization. The days of “crossing the chasm” are over. Geoffrey Moore, the creator of this once-dominant descriptive framework, has moved on; vendors should too.

Even though I still like the Chasm model, I can relate to the mental models cause. IT departments have become quite diversified in their problems. In Cynefin terms, I think IT departments are moving from known to knowable or complex space. Therefore, selling one-size-fits-all products (e.g. ERP systems, which typically fit only in known space, because they assume an unchanging process) and services (e.g. software development based on proprietary methods) is no longer a viable long-term solution. Instead, vendors will have to look at patterns within the industry, and carefully select customers who they want to sell to.

One of the old-fashioned sales techniques reflecting one-size-fits-all thinking in my opinion is the venerable elevator pitch. It assumes you can prepare a one minute presentation about your product or service you can use anywhere. For my services, I find the elevator pitch simplistic – I prefer to spend time asking questions and listening to a prospect first, think hard if any of my services or a new service would fit the clients needs, and only then offer an appropriate service.

Selling to IT departments will become harder as IT managers themselves are under fire from their internal customers. See e.g. Job security top concern for CIOs in Computer Weekly. The average IT department has a track-record of not delivering value for money. So now CIOs jobs are on the line, as part of their departments are being outsourced and/or offshored – if the clients can’t get good service, they try to get the same bad service cheaper.

Agile product development and agile services can be a remedy to this, taking into account the offering of the supplier, as well as the context and capabilities of the client. It’s not going to be easy, and probably take a long time, as the way IT projects are managed has to change, meaning close collaboration between customers and IT people.

Convincing dissatisfied clients to become involved in IT projects and product development is quite a challenge, as both IT Departments and vendors have to show a profound and lasting care for concerns of senior management, end-users and the clients’ clients.