me.andering – Willem van den Ende

I just got news that two sessions I co-submitted for XP Days Germany in Karlsruhe have been accepted. The Systems Thinking Workshop, together with Marc Evers and Pascal van Cauwenberghe

and Who has dropped the ball? Understanding Team dynamics together with Marc Evers. Both workshops are a continued development from the systems thinking workshop at xp2004.

Rebecca Ryan blogs about thought is the most productive form of work not. Thought is NOT the most productive form of work. PLAY is. PLAY engages all of our senses. It moves muscles other than our cerebrums. PLAY rejuvenates, makes room for risk, and reminds us what it is to feel truly alive

I’ve been recently hosting workshops with various kinds of games, and can corroberate what Rebecca writes. Games are not only educational, they are fun and allow the players to experiment, and connect with one another – since usually the players haven’t met before. If the game works well, it takes quite a bit of effort to get to the next item on the agenda . A brief game after lunch also works well to get energy back into the meeting. I haven’t tried playing games regularly in day-to-day work situations. It might be a worthwile to try, as it loosens up a group, takes the minds of off the routine and allows (if done well) equal participation by everyone involved.

Lately, I’ve been doing a lot of thinking. Time to start playing?

I’ve been reading some books that revolve around taking long term perspectives. How Buildings Learn, by Stewart Brant, looks a few centuries into the past, to see how some buildings adapt to changing circumstances and some don’t. The Clock of the Long Now by the same author inspires to look many millenia into the future. The Art of the Long View by Peter Schwartz is about scenario planning, a way to identify multiple possible futures and create options for those futures.

What might we get if we apply a long view to software develoment? What if we wouldn’t build software just for tomorrow, but for the coming several hundred years, like we build railroads and bridges for instance. Marc Evers pointed me to an article by Dan Bricklin, Software that lasts 200 years in which he identifies some possible answers to these questions. He argues, amongst other things, that no single company will be able to support an application for that long (and as applications are networked, that also means connections to other appications) and that in fact a durable kind of support eco-system is needed. This has interesting consequences on e.g. the future of funding Open Source. As he puts it in his conclusion Open source software discussion should be about keeping the trains running on time and not just saying it should run on Linux. The discussions should be about funding the companies needed in such an ecosystem and assuring their sources of healthy revenue. The code is not the only part of the equation, and leadership for all aspects of the ecosystem need to be addressed.

An aspect a friend of mine suggested that goes relatively unnoticed, is the tendency of some companies (e.g. Microsoft) to start patenting their data-formats and even encrypting data you created with ‘your’ word processor (if you read the licence contract, you will know it is not yours…). This will make it extremely hard to get to this data in the future. My friend suggests to put legislation in place, that forces any application that stores data, to be able to export that data to a plain text format, so it can be reconstructed in the future. I think that open standards for protocols and data formats are essential for longevity of data and applications.

It might also be necessary to archive not only the data and the programs, but also the hardware they run on. The Clock of the Long Now has an instructive example of someone trying to re-enact a virtual reality show he created on a Commodore 64. Eventually, this person got lucky because volunteers have created commodore 64 emulators, and someone also put his virtual reality program online, complete with the manual. If we want to keep an accurate historical record for the future then, as Dan Bricklin puts it: serendipitous volunteer labor must not be a major required element.. For instance, tens of thousands of open source projects now rely on SourceForge. What happens if the company supporting it looses interest? Will only the cool projects be saved by enthusiasts?

Being occupied with agile software development, I notice a tension. On one hand, we focus on creating software for today, not building things that are not yet needed. On the other hand, we involve all stakeholders (which might uncover long term consequences), strive to deliver a minimal feature set (so in the future, less features need to be re-created if software archeologists would like to re-run the program) and prevent defects.

Recently, I’ve participated in many discussions about the current state of market acceptance of Extreme Programming and Agile Software Development. I’ve spoken to people from various European countries doing (covert or overt) various flavours Agile (SCRUM, Lean Software Develoment, Extreme Programming) in Banks, Insurance companies, even a very non-agile national postal service and a big moloch like Logica/CMG . So it is no longer a few small projects in small pockets. It seems XP and Agile might be crossing the chasm into the mainstream, and become synomous with ‘software development’ within a couple of years. Other signs I see:

• Ponderings about ‘what is the definition of…’ Extreme Programming (on the XP mailing list) , Project, Agile, Leadership etcetera.

• DSDM and RUP have now adopted Extreme Programming, so there seems to grow consensus on what constitutes sound agile programming practices, as well as a growing chance of wider adoption of these practices. In many places SCRUM and XP are also combined.
• The number of conferences on agile is growing rapidly, besides XP2004, OT2004, Agile Universe, there is now also the agile development conference, xp days in the UK, Germany and the Benelux.
• Other conferences are adopting agile, as well as agile session formats. Yesterday I stumbled across Software Development Expo, they have experientials (highly interactive workshops) and an open space conference, as well as a track on People, Projects and Teams.
• The agile community in europe is both starting to face more outward (organising Agile Special Interest Groups to inform managers and software customers) and pulling together (keeping each other up to date on various events).

I’ll continue collecting some more signs, If you see some, let me know yours!

I’m working with Marc Evers on a simple stylesheet for the xp day benlux website and a new site for systemsthinking.net. Marc found the CSS Zen Garden. As it says over there: There is clearly a need for CSS to be taken seriously by graphic artists. The Zen Garden aims to excite, inspire, and encourage participation.. The site is very simple, containing one page of text, which you can see in dozens of wildly varying styles, many graphically very pleasing.

Adewald Oshineye pointed me to agileplanet.org/, an aggregator for blogs on agile software development. Some of my favourite bloggers are on there, so If you’re interested in agile software development, I recommend you try it out.

Johanna Rothman writes in this blog entry A trap that too many execs (women and men) seem to fall into is: work more hours and get more done. People don’t work more hours and get more done. They work stupider and make more work for other people..

Recently there has been an urge by the dutch government for people to work longer hours, based on the assumption that the Dutch don’t work enough. Last week I read, that on average people work more than thirty years ago – so the assumption is flawed. Working hours are spread out over more people. Compared to thirty years ago more women participate in the workforce, and more many more people (men and women) are working part-time.

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.

I’m starting to take more time for reflection and conversation, yesterday for instance, we had another systems thinking meeting, followed by some interesting dinner conversations. Marc Evers pointed me to this quote above Dina Mehta’s weblog “Conversation. What is it? A Mystery! It’s the art of never seeming bored, of touching everything with interest, of pleasing with trifles, of being fascinating with nothing at all. How do we define this lively darting about with words, of hitting them back and forth, this sort of brief smile of ideas which should be conversation?” ~ Guy de Maupassant

Last week at the lean service summit, there was an interesting presentation by John Seddon from Vanguard consulting about combining a systems thinking approach with lean principles. One of the things he brought up was the approach some improvement schemes approach change. Processes such as Six Sigma (and in IT, the Capability Maturity Model) start with planning, and analyse the current situation only after planning. Six Sigma for instance calls its steps DMAIC (Design, Measure, Analyze, Improve, Control). Looking at where we are (Measure and Analyze) comes after the map has already been made (Design). This is a bit strange – how can you plan the road ahead, if you don’t know where you are?

Managing change is better done by starting at check, so John Seddon suggests a change cycle that consists of only three steps: Check Plan Do. I can relate to this, because I have experienced the power of this cycle in various activities:

• Weekly planning games work like this Check what has been done last week and how that affects the customers’ situation, Plan what to Do in the next week. Very simple, but also very powerful, as the software evolves together with the customers’ situation.

• Retrospectives fulfill the same role: Check the current state of your process by looking back on the past project (or iteration), Plan new ways to add value and eliminate waste, by looking at what we can do better next time and Do by having the retrospective right in between your current and next project, and using the results directly in the next project.
• A systems thinking techique, that of creating a causal loop diagram (also known as Diagram of Effects) also follows this pattern. Check being telling a story and drawing observable values and the effects they have on each other, Plan finding intervention points within the effects or changing the system by introducing other observable values and Do enacting the interventions or changing the system.

It is important not to forget the Do step. I heard someone criticize Systems Thinking last week, he said he prefers Systems Doing. I think it is crucial to take immediate action after the planning has been done and go through the check-plan-do cycle in short iterations, that way up-to-date information is used in steering your system, so the goal can be achieved with less errors.

Playing the blindfold game at the last xp-nl proved this again – if you steer every 20 seconds, you won’t get the blindfolded person anywhere near the target. With 5 second iterations, this is much more doable.