me.andering – Willem van den Ende

What?

It’s the Return of the Naked Agilists. What? In case you haven’t guessed it’s a conference. A different one. You can attend this conference from the comfort of your own home- you only need Skype to be able to attend.  Save the date now:

Date:     Saturday 19-Jan-08
Time:   20:00 GMT – 21:30 GMT
Venue:  Your place, or mine

You’ve got until the end of December to propose a few-minute presentation or a one minute question. After review, the most interesting ones will be put on the agenda.

Thanks to Kevin Rutherford for bringing this to my attention.

I’ve just returned to the comfort of my own home, after staying in the comfort of other people’s homes and hotels around XP days London. I’m planning to procrastinating on writing about XP Days, a guest lecture plus live coding on Test Driven Development at the university of Bath, upcoming coding dojos (public ones in the Netherlands, and another one live at the BBC).

More later, perhaps. I was afraid expecting it would be difficult to keep posting a blog entry every day while on the road. I was right… I get more out of conferences by being fully present at the location (real or virtual) and not splitting my attention over the conference, e-mail and blog posting.

Reading the title you might go, what on earth is Smidig? Well, let me help you:

“Smidig 2007 er Norges første konferanse rundt smidig systemutviklin”

I guess that means:

“Agile 2007 is the first conference in Norway on agile systems development”

(Smidig might also mean Lean, I cna’t quite make that out from the context. Agile was my best guess)

And it gets better:

“Begge dager vil bestå av Lightning Talks før lunsj og Open Space etter lunsj”

Wich probably means:

“Both days will consist of Lightning Talks before lunch, and Open Space after lunch”

Now for the disclaimer: I don’t speak Norwegian, nor have I ever been to Norway. However, I do understand lunch (and I have been to lunch) – and lunch is written as some people in the Netherlands pronounce it…

This looks like a promising conference format – the Lightning Talks are probably submitted fairly just in time, and feed the Open Space, which is, as always, as just-in-time as it gets. If you actually understand what is written on the Smidig 2007 page, I recommend you go there, November 26 and 27 in Oslo, Norway.

this picture from smidig.net who seem to be ‘cake builders’ doing ‘fast delivery’ . Fitting

November seems agile conference month, there’s a lot going on… One could theoretically continue on from XPDays Germany 2007 before the weekend to Smidig after the weekend and then on to AgileNorth 2007 in Manchester on the 29th.

… Smidigs’ conference format seems to be ‘more than two days, more eXtreme than XP days‘ .

Or not? I’ll be co-hosting an open space during XP days Benelux next week. Deb Hartman recently ran an open space at XP Day Manhattan 2007 . XP Days London seems to be missing an open space, but it has… The Pub .

And there is the virtual world wide open space called the internet…. the latest edition of carnival of the agilists is out, featuring my post on making more money without certification, Rebecca Wirfs-Brock on Challenges When Communicating Designs, Michael Feathers on Elegant Byte Counting, and something about remote work and not washing down shavings in the laundry room.

Check carnival of the agilists out, ladies and gentleman. And then book a place at a Smidig or XP days near you, before heading out for the weekend…

Yesterday saw the trial run of People vs Process: Cultural Patterns of Software Organisations. We had a lively session with eleven active and critical (in a good sense) participants. We got useful feedback for the next rounds, and a solution for a puzzle we couldn’t solve before: an example organization with a congruent culture.

congruent? by Alexander Aden

As Nynke Fokma puts it:

“Congruent culture: starship enterprise -> when going somewhere, we can go where no one has gone before, we can carry anything and we can beam ourselves anywhere, but this is all science fiction, or is it”

As Jerry Weinberg describes it:

“Everyone is involved in improving everything all the time.”

So far we had come up with Toyota as a possibility. However, I’m a bit wary of using Toyota as an example – the risk of a Toyota cargo cult in IT is slightly too big to use it all the time. Searching around, you can find gems like Two Faced Toyota :

“Meanwhile, Toyota’s playing footsie with federal regulations. Their Texas-built pickup hits dealer showrooms in February– at the same time other manufacturers are beginning to introduce some of their 2008 models. But Toyota is adamant the new Tundra is an ’07. That’s because the U.S. government is changing the way they calculate the fuel mileage ratings for ‘08 model year pickups. [..]

As you can imagine, Toyota’s heavy emphasis on their new gas-guzzling leviathan hasn’t gone unnoticed by auto-oriented environmentalists. In fact, environmental groups are finally facing reality: their automotive eco-darling is (gasp!) nothing more than a business. A business that conforms to all CAFE regulations, of course, but will do whatever it takes to make a profit. “

Porsche came up as a possible alternative, now the most profitable car maker. I read about it in the financial times, and should have kept a clipping. They say so themselves in the Porsche Principle, and this:

“On the labour market, because to secure our long-term success we don’t eliminate jobs, we secure and create them. On the business base issue, because we are committed to Germany and are a constant reminder to others that one can succeed here too. “

Sounds good, but whenever I see one of their gaz-guzzling high speed SUV’s pass by, I don’t know. Not bad for a car maker, and very effective and efficient. But still a car maker.

A participant suggested Semco. Marc and I went… Duh! We knew about that one, but somehow it didn’t come up during the preparation. Semco is a federated business, operating out of Brasil. It’s ceo Ricardo Semler wrote about it in the Seven Day Weekend :

“At the risk of offering a description, Semco is a federation of businesses with a minimum common denominator. What I mean is we are not monolithic, yet there are common themes and threads uniting us. All our business units are highly engineered, premium providers and market leaders in their niches. We haven’t ventured into any of them by chance.”

From their values page:

10 – Have the humility to recognize our errors and understanding that we can always improve.

Sounds close enough.

So, now we’re still looking for examples of a congruent culture example in IT or electronics. Or something to dispell our happy feeling about Semco. Anyone?

Preparations for the trial run of People vs Process: Cultural Patterns of Software Organisations this Wednesday are starting to wind down. The presentation, exercises and stories we want to do are virtually done. Marc uses cultural patterns to describe some common failure modes when starting with an agile way of working : Agile choreographies in the culture space:

Most of the time, transitioning to an agile approach means going from a Variable or Routine culture to a Steering culture.

Practices like daily stand-up meetings, short iterations, frequent releases, iteration retrospectives, test driven development, continuous integration, big visible charts, stop the production line mentality all help improve the visibility and stability of the software development system.

These are all indicators for a steering culture.

The transitioning process itself often escapes the attention of the unwary. That can result in an oblivious or variable transformation process, which in turn can result in one of the failure modes Marc mentions. A heroic (variable) or unconscious transformation can result in reduced performance, that you often won’t be able to notice… Or you’ll get lots of ‘resistance’ and think ‘how did that happen?’

The process of transformation itself can be done in a steering way, for instance by using a change backlog. It helps if one knows, for instance by experience, where to look. Because we don’t have a stable process yet, we have to rely on observation. To know what to observe, we can rely on experience. Either our own, as we go along, or re-using past experiences, e.g. from an experienced mentor/coach who knows where to look.

Using past experiences in various contexts to choose practices that apply in a new context, and doing risk analysis combined with scenario planning (elaborate, or back-of-the-envelope, depending on the complexity of the environment) already gives the change effort itself some characteristics of an anticipating culture.

For risk analysis, some of the failure modes Marc mentions are valuable input. Up-front identification and analysis of risks, their likelihood and mitigation strategies can be done in a simple ‘agile’ fashion as well – get the people involved in a room around a flip chart and brainstorm away for an hour or so. Then keep the flip chart on the wall, and re-visit it every iteration or two. As in all things ‘agile’ we do an ongoing assessment – of risks materializing, as well as potential new risks…

Otherwise, the result of an oblivious or variable transformation process might be, ‘that agile method does not work, let’s try to surf to the next wave…’

Photo Credits:

1. Smoking, Picking Nose and Driving by Mike “Dakinewavamon” Kline
2. Pink Swirl by tanakawho

I read in several places that systems thinkers tend to keep their work to themselves, and that stories work best to get more people to do it.

So, here is a story with a diagram of effects – want more traffic? .

Context: Last week, Marc Evers and I were working on a quote for a community website, based on a request for proposal we got. We made the diagram to clarify our interpretations about the clients ‘business’ – a not for profit foundation supporting a community of practice.

I’m involved in a number of websites, e.g. to support my business, conferences and as of recently wyrd web – a budding company to support more of that. The diagram helped me understand this client, and some of my other contexts involving a community and its’ website(s) – e.g. systems administrators don’t always see why uptime and responsiveness provides business value to a community of practice (which if done well supports a thriving eco-system).

We decided to send the diagram to the client, and then I posted it. The diagram itself is isomorphic with part of its message: quality content drives traffic, which in turn drives quality content. The post attracted a nice comment, which helps me to write more about this topic .

We’ll see in the coming weeks whether this diagram helped the clients’ contact person in sharing our understanding of an effective website’s value with the not-for profit’s board.

As a programmer told me:

One programmer is fanatical about code quality, he is especially strong against duplication. He is also the one who maintains an install program for our servers, and one for development workstations. They should be quite similar in operation – however they are two different scripts, one was once a copy from the other, but they have now diverged. This means defects have to be repaired twice, and the scripts are a complicated mess that only that programmer can maintain, with a lot of effort.

When I asked him “why did you duplicate these scripts” he said: “The what? oh yes, that is not a program. That is something I just put together so we can install our program. It’s not a program, it’s just a script… “

For some reason this second programmer sees the install script as a
non-program, so the same routine that applies to programs, does not apply to ‘scripts’, therefore duplication is not a ‘problem’ – he can not see it as a problem, even when the first programmer asks him about it.

The second Programmer has an oblivious pattern for one part of the project where he may apply a routine or steering pattern to other parts.
The first Programmer seems to be aiming for a congruent culture (albeit, so far a culture of one person only, a micro-culture so to say):

Congruent culture – everyone is involved in improving everything all the time; it is a culture of ongoing reflection and improvement.

So in that view

Scripts are programs too

And if there is a problem (defects caused by duplication in this case), you stop, work on the problem, find out what caused it and what we can do to prevent it from happening again. And, last but not least, we do this with the whole team, so everybody can step away from their micro-culture.

In a way, a congruent pattern makes it irrelevant whether something is a program or not…. if something gets in the way, we do something about it.

(This post is part of a series on cultural patterns of organisations. Marc Evers and I are hosting a trial workshop next week, so we’ll be posting some more stories and pattern descriptions as we are working on our introductory presentation this week).

Credits:

(photos under a creative commons 2.0 ‘by’ license)

“Oblivious” by James Craig (picture of a standing duck oblivious of a waterfall, because it faces the other way)

“Oblivious” by Emily Nieves (picture of a lady in the water with her eyes closed)

To me (agile) software development is about delivering business value to the customer (by as little software as possible), and doing what works in practice. Today I’m writing a bit about routine versus variable cultures in organisations.

A current project, recent writings by Marc Evers and Nynke Fokma and upcoming sessions on organizational cultural patterns (based on Gerald Weinberg’s work) inspire me to write a little about… routine , so I can explain what the session is about, and evolve my understanding beyond what’s in the book. I’ve been using variations of this model for quite a while now, so it is about time to write about it

My mentoring/coaching clients fall roughly in two categories: those doing some form of chaos development, and those who supposedly have a bureaucratic, routine based process.

Digging deeper, my clients fall into one category: those who have some form of chaos development…

I’ll explain my digging along two lines:

1. Routine processes are uninteresting strategically
2. Routine processes are not focused on results. They only (seem to) work, because result-oriented people find a way to work around it and don’t tell anybody…
3. Routine is boring

Routine software development culture :
“We are developing software – follow The Rules”

Routine processes are uninteresting strategically

As Marc Evers writes in Keep on failing (in the small…):

“Predictable projects are not interesting, not in a strategic sense. If it’s predictable, there’s probably someone who has already done it or even created a product or service for it. Most interesting, strategic IT projects are in the complex space, where cause and effect are only coherent in retrospect and do not repeat. Best practices, recipes and step-by-step methods don’t work here. You need to steer based on feedback instead, through a cycle of probe, sense, respond”

So, if you want to create an entirely new market, you have to work based on feedback, if you want to go somewhere with an innovative product, you have to dance to the beat of life, and create your own beats

Routine processes are not focused on results

Because, to get anything done in a routine environment, you have to bend the rules. “The Rules” are usually made to prevent change of any kind, and “The Rules” have a tendency to grow in volume. As they grow in volume, they inevitably start to contradict themselves. Therefore, my clients only fall into one category

Now, as an investor or product owner, if you start a new project, you might feel tempted by the false idol of “The Rules”. It is easy to find IT suppliers who happily work with “The Rules”, making big, fixed-price contracts and maybe even using some form of Model Driven Architecture / Design, which is a translation of working by “The Rules” in software development terms. . .

As Nynke Fokma writes in Great innovations that help the world

“The intention of MDD, model and routine driven developments, is to make software work routine. It is a focus on the tool rather than on people”

So, why do routine-oriented people get scared when you mention agile. They hear a transformation from:

“We are developing software – follow The Rules”
to:
“We are developing software”,

which would be a Variable culture.

The mental image of a Variable culture for someone in a Routine culture looks like this:

“Variable Expansion”

If you remove “Follow the Rules”, Routine people can’t see the safety net. A Variable culture doesn’t have a safety net, so we don’t want to go there from routine.

However, as a mentor, a Variable culture is a much more pleasant state to start than a Routine culture – there are no “The Rules” to unlearn…

People in a variable organisation know that they are developing software, which makes them more aware than people in an oblivious culture:
“Are we developing software, really?”
“Oh, no, this is not software, It’s just some macro’s I made in Excel and Access” (never mind that these macro’s are the only things that are keeping track of millions of euros worth of business, as I saw in a moderately large manufacturer).

Clients in the variable space are usually a lot of fun for me. They are results oriented, and often have delivered software recently. They know they are developing software, they hire me to do better.

Usually, when they get to the point to hire a mentor or go for training, they know they have a bit too much chaos development. They already have some areas for improvement in mind, maybe some practices too, and with some creative questions, maybe a small retrospective, we collectively find some more.

We keep the results focus and the fun people are having at work, and add just enough process to make the team(s) more productive (deliver less defects, more business value).

What that looks like? I’ll leave that for an upcoming post…. There are loose ends here, some intentionally…

I’m not saying you don’t need any _routines_, which is differently from having a routine culture. Appropriate routines create a stable basis on which you can build and experiment. On the other hand, as nynke says: if you are in control, you are not going fast enough…

Credits:

The beat of life photo by ♥ Cherie ♥

“Variable Expansion” photo by Andreas Kollegger.

Gerald Weinberg, for his work on organisational cultural patterns

Nynke Fokma and Marc Evers for blog entries and discussions.

I prefer small change over big change. I’m talking about transformations, of course . Small transformations make it easy to check if what we want to happen actually happens, and how far of we are. If you’re reading this blog there is a fair chance you are familiar with growing software in small steps – I apply the same principles when working on myself or helping others to improve their (development) performance.

(more…)

Brian Marick blogged in an unhappy trend: Leadership about “the great man theory of management” gaining tracktion in the agile space. I couldn’t agree more.

As far as Leadership has a place in agile teams, I believe it should be, as much as possible, self-organizing so people (and teams) lead themselves.

We’re exploring this by example for xp days benelux through relentless reflection and continous improvement; Pascal outlined how we facilitate the presenters in perfecting their sessions, and how we try to walk our agile talk, because we expect nothing less than perfection.

The drawing carousel Marc and I ran at agile2006 did not run as expected (in a good way) I called Vera Peeters, who originally designed the workshop, to tell her how it went. So far every drawing carousel we have ran is interestingly different in some way, we are puzzling on causes, so we can get more people to experience the flow resulting from promiscuously pairing in short episodes.

We had a somewhat smallish audience, so we assembled one team. Team dynamics were great. After strictly facilitating iteration reviews and standup meetings the team started to self-organise these. The team started to quickly decide pair rotation, and many decisions were taken through osmosis – as pairs rotated, information was spread around, so not everything needed to be discussed at the reflection and standup meetings.

One of those things, as we discovered during the session debrief, was that the team did not deliver a drawing, but more of a collage made of cutouts. We asked how that had happened, because we had been present at all of the iteration reflections and standups, and we were still surprised by the result. Cutting was not mentioned during the meetings (or at least, we did not notice…). The team said consensus on cutting was reached within the first three iterations, solely through pairing.

The team also asked difficult questions before the first iteration (I won’t mention the questions here, as that may spoil a future run…). Having one or more experienced testers, who are skilled in looking for holes and asking critical questions, in the team present at the first planning meeting helped in preventing rework early on.

The team had gotten into the zone / flow, where the team operated as one.

Factors that may have contributed to this:

• good mix of experienced agilista’s and ‘newbies’ – getting the ‘innocent newbie questions’ often expose holes in product and process – it also makes the debriefs easier to facilitate, as what happens in the simulation is,through the questions, easier to tie to real life
• Running it with only one team gave Marc and me ample time to discuss facilitation strategies during the drawing episodes. We were also able to pick up more keys from observation.
• Lynne Azpeitia was in the room as well, mostly observing, that gave us even more information to steer the session.
• There was no competion on resources with other teams (if there are more teams, the limited number of scissors, glue sticks and sticky tape rolls leads to resource competition and wait times – teams are not allowed to change tools while drawing, only after the standup and before restarting drawing.).

In hindsight, I did get a key for the team making cutouts. At one point, the team ran out of scissors. We had about five pairs, and four scissors… If they were mainly drawing, they would not need that many scissor.

pair drawing

switched pairs

drawing and cutting a prototype

standup

standup with list of tasks on the flipchart in the background

Editing the task list

drawing signed with business cards (some business cards were created on the spot with mini-index cards)

The team proudly presents their result

See also Other entries about drawing carousel, mainly photos from previous runs.