me.andering – Willem van den Ende

Yesterday, I was reading again in Quality Software Management volume 4 – Anticipating Change by Gerald Weinberg. In chapter eight I found a description of Virginia Satir’s Five Freedoms, which goes nicely with the Learning to See theme from the day before:

• The freedom to see and hear what is here, instead of what should be, was, or will be.
• The freedom to say what one feels and thinks instead of what one should.
• the freedom to feel what one feels, instead of what one ought
• the freedom to ask for what one wants, instead of always waiting for permission
• the freedom to take risks on one’s own behalf, instead of choosing to be only ‘secure’ and not rocking the boat

these originate from The Satir Model: Family Therapy and Beyond.

I was at Marc’s yesterday, brainstorming some more topics for workshops. One thing that came up, about which we did not have a clue on what a workshop about the topic would look like, was Learning to see things as they are, rather than how they should be. This capacity enables one to see the future(s) more clearly, and have an open dialogue within a group about the future. If you don’t know where you are, how do you know where you’re going to?

A number of books and techniques I’ve been studying over the past few months have the theme of learning to see. Value stream mapping and causal loop diagrams are two such techniques. Peter Schwartz writes in his book The art of the long view about discussing multiple futures, rather than just the companies’ official future. The book Presence: Human Purpose and the Field of the Future discusses seeing things as they are as well.

While writing, I realize a workshop on Perspectives Nynke Fokma created would be about learning to see as well. Time to start working on that one.

Perhaps seeing things as they are is impossible, since seeing is done by perceiving. Nevertheless, striving to collectively learn too see, enables more robust and diverse forecasting.

Steve Denning concludes Use narrative as well as analysis with:

What hampers the creation of such new narratives is of course the corporate culture, which, as we saw in chapter 7 on Taming the Grapevine, holds the existing corporate story in place with an iron grip. The story of what the business is and how it works is not something that has to be argued for, but rather life as it is lived there, a matter-of-fact down-to-earth common sense apprehension of the obvious realities of the organization, which any wide-awake person would grasp if he would just open his eyes.

In the early days of the dot-com boom, reading the book Patterns of Software by Richard Gabriel made me aware of the risks of having too much (venture) capital for a project. If a project has too much money allocated to it, there may not be enough driving force to eliminate wasteful work.

One of these wastes is not automating repetitive tasks. Fast Company Now guest host Keith Yamashita refers in Systems thinking: The Product to a speach by eBay founder Pierre Omidyar:

So people often say to me – “when you built the system, you must have known that making it self-sustainable was the only way eBay could grow to serve 40 million users a day.” Well… nope. I made the system self-sustaining for one reason:Back when I launched eBay on Labor Day 1995, eBay wasn’t my business – it was my hobby. I had to build a system that was self-sustaining… …Because I had a real job to go to every morning.

When you’re the sole programmer and product visionary, this is doable. Your lack of time will force you to choose between glitzy new features and stabilizing the system (e.g. by preventing and removing defects and automating repetitive tasks). I’m curious how eBay does it now it has become much larger, and more people will likely be involved in decision-making and programming…

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)

.

This is the title of a session Marc Evers and I submitted to XP Day benelux 2004. It got accepted! You might expect that, as we are also organisers of this conference. But I didn’t – we strive to create an independent review process, where a number of criteria are pre-defined, and outside reviewers are invited. Some of the organisers had their session rejected, so I guess this process works. The preliminary program is looking like a lot of fun and learning will be going on in interactive sessions. We’ll put the program on-line as soon as presenters confirm their appearance.

So what is our session about? It introduces systems thinking using causal loop diagrams (also known as diagrams of effects, Systems thinking is a methodology independent tool for understanding team and project dynamics and for finding effective interventions. We will use an experiential approach through playing a ball game (“group juggle”). All participants will be involved, either as a ‘player’ or an observer. We ran this game as part of a larger session at XP2004. The image below shows participants at xp2004 playing a second round of group juggle.

This game is derived from The Systems Thinking Playbook by Dennis Meadows and Linda Booth Sweeney, and I highly recommend this one. At a systems thinking meeting last week, we played another ball game, warped juggle. It struck us, that these games are very versatile and can be used for many purposes, e.g. showing group interaction, mental models, experience organisational change in the small, and explain causal loop diagrams as we’ll do at xp day.

In the Extreme Programming mailing list, Dale Emery points to a simple and interesting game that emerged during the agile development conference. You can read details on The Blindfold Game in Brian Maricks’ blog. I like this game, maybe I’ll try it out at our XP users’ group meeting

Brian relates problems the players are having with steering a car, roleplayed by another person, with voice commands every twenty, five or one seconds to iteration length in an agile software development process. He notes, that many people have problems with one-week iterations (which are then similar to one-second feedback in the game), although they can often be taught to deal with them.

I’ve experienced a situation where a one week iteration was too long. At the end of a four week project, the customers had difficulty of thinking of enough new functionality for a full week, yet there was still work to be done. On the other hand, I also experienced one week iterations being to short, especially in the case a large refactoring has to be made to existing software.

Over the years, I’ve worked on projects with one week, two week, three week iterations, and before that in projects without iterations… Iterations are necessary in my book, to get feedback from the project and steer it, so it stays on course (or changes course if the context requires that). The relation to me between the game and the real-world is, that in real-world projects I find it worthwile to look at the effect the iteration length is having on the project (as Brian does in his reflections on the effect the number of seconds has on the time it takes to get the role-played car to the target). If you think iterations are too long or too short, change the iteration length for a few iterations, and evaluate (e.g. with an iteration retrospective) what difference it makes to your project. After the experiment it will be easy to decide if you want to keep the new length or not.

As XP2004 was drawing to a close, many interesting ideas came by. Ideas that stuck so far were:

• solving problems by daydreaming
• research on presencing that is performed by MIT, and is supposed to be a kind of ‘sixth discipline’ for the learning organisation, being the ‘flow of the learing organization’, which is called Presencing
• Many german companies are reverting back to becoming an ‘unlearning organization’ – they hire army officers as managers in order to fight their crisis with a more directing, command-and-control style of management. Someone at lunch was actually working for such an organisation.
• the importance of cultural training, or at least cultural awareness in organisations. Organisational departments such as sales, software development, systems support, operations, all have a distinct (sub) culture, including preferred ways of communication.

Value Stream Mapping is a technique that is already used in the context of Lean Manufacturing. At OT2004 I attended the workshop “Understanding the Software Value Stream” by David Harvey and Peter Marks.

Borrowing metaphors from other domains, and applying them to the creation of software can be, from my experience, a dangerous thing. Even adding the word ‘development’ after ‘software’ is dangerous, since that also implies a metaphor. I consider borrowing from manufacturing especially dangerous – I consider software ‘development’ to be a creative activity best carried out inside a ‘living company’ not a kind of machine.

Value Stream Mapping seems worth exploring though, so the main question that remained in my head after the workshop was: how can we map Value Stream Mapping to software ‘development’, without implicitly taking over the ‘production metaphor’.

As described on http://www.mamtc.com/lean/building_vsm.asp:

Value Stream Mapping is a method of visually mapping a product’s production path (materials and information) from “door to door”. VSM can serve as a starting point to help management, engineers, production associates, schedulers, suppliers, and customers recognize waste and identify its causes. The process includes physically mapping your “current state” while also focusing on where you want to be, or your “future state” blueprint, which can serve as the foundation for other Lean improvement strategies. Interesting results that could be achieved with the above are:

• Enabling all stakeholders in the process to see the whole picture. In my experience people usually only see their own part of the process. Optimizing one part without considering other parts might cause the whole process to deliver less value instead of more.
• Both materials and information is taken into account. In software development we work with information only, but since information is supported by VSM, this could be sufficient.
• Focusing on ‘what is’ and ‘what could be’. Reflecting on process is a useful, and often difficult activity since assumptions have to be made explicit. Imagining what could be without taking the current situation into account, however, is much more difficult. There are other techniques (such as Diagrams Of Effects) that are useful, VSM could be a useful addition, since it takes information flows (rather than actions) into account.

Continuing the quote:

… A value stream is all the actions (both value added and non-value added) currently required to bring a product through the main flows essential to every product:

• the production flow from raw material into the arms of the customer

• the design flow from concept to launch

The idea of adding ‘non value added’ steps to a value stream is to identify steps that are wasteful and can be eliminated. Adding everything makes brainstorming about the process easier, because different stakeholders might find different activities valuable. Separating production and design flows is not something that is generally applicable to software.

For instance, in my daily practice of software development, there is no visible distinction between design flow and production flow, because each step in a process based on Extreme Programming encompasses both production and design. One of the things that came up after analyzing the value stream we created at OT, was that not only is value produced at multiple steps in the process, also very early on in the process value can be realized. Ordinarily, for a production line, I would think value is created at the end of the production process, when a product is handed to a customer and (possibly) money is exchanged.

In a process with short iterations, typical of agile software development, value is also created during planning meetings with the customers. For instance, customers get to re-think their business process while brainstorming their next wishes for software (and, as a consequence, perhaps changing the value ). At the next xp-nl meeting (http://www.xp-nl.org/Wiki/XpBijeenkomst4.5 ) we’re probably going to explore Value Stream Mapping further.