me.andering – Willem van den Ende

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’ll be co-hosting exploring the agile space at the Agile Business Conference (October 2 and 3 in London), and it seems at xp days London as well – People vs Process: Cultural Patterns of Software Organisations both with Marc Evers. I also recommend you check out the continuous integration and testing unconference – CITCON Europe 2007 in Brussels, October 19 and 20.

I chose not to choose a license, apparently. I thought me.andering had a license, it must have disappeared. And I chose the right day to do so, when I went to creative commons site to choose a license, it turned out that today is Software Freedom Day, a “worldwide celebration of Free and Open Source Software.”

So, this is the new license:

This work is licensed under a Creative Commons Attribution 3.0 Netherlands License.

I chose an ‘attribution’ license, because I seem to believe that liberal sharing creates more value (and attribution tends to create more pagerank, which creates some value for me ). I hope this blog helps you create value (monetary or otherwise) , writing on business value does not seem to go well together with a ‘non-commercial-share-alike’ license (let alone a ‘no-derivatives license’ – I wonder how that one holds up against ‘fair use’, see below).

Two points on sharing and value:

1. Marc Evers shared this with me yesterday: Fair use worth more to economy than copyright, CCIA says (by Thomas Claburn) “The Computer and Communications Industry Association — a trade group representing Google, Microsoft, and Yahoo, among others — has issued a report that finds fair use exceptions add more than $4.5 trillion in revenue to the U.S. economy and add more value to the U.S. economy
   than copyright industries contribute. “Recent studies indicate that the value added to the U.S. economy by copyright industries amounts to $1.3 trillion.”, said CCIA President and CEO Ed Black. The value added to the U.S. economy by the fair use amounts to $2.2 trillion.”
2. Yesterday, Hans Konstapel shared a story ( How to Destroy your Company by Implementing Packages or Outsourcing) Marc Evers responded to it, I responded to it, and got a gift in return… Graham Oakes posted a thoughtful comment that would merit a proper post – I call it “three reasons why project price depends on corporate ladder position”.

Sharing: good… Not sharing: bad . I wish you a happy Software Freedom Day !

My take on projects in ye average bigge organisation has been: the price of a project depends only on the position on the corporate ladder of the manager who starts the project. The lower the level of the manager, the cheaper the project.

Please note that delivered functionality or business value is not part of the ‘project cost’ equasion…

I have often wondered about, and looked in amazement at these large projects that seem to go on forever. I believe that most projects can be done with less people in less time, and many projects are not worth doing at all.

Maybe someone at <insert large ‘consultancy’ company here> did actually invent a working perpetuum mobile…

Read what a (former) big shot in a large company writes on how this mechanism works in practice, and what it feels like to be on the receiving end. How to destroy your company by packages, outsourcing and ‘consulting’ companies (and not paying attention to your users and customers)….

“Outsourcing is a brilliant trick of the managers. The responsibility for the failing project is moved to an outside vendor. They are now the object of aggression.

The real customers don’t talk with the programmers. They talk with the managers that are talking to managers that are talking to managers. Somewhere in the chain of communication all the meaning is lost. The result is something they don’t want, the users don’t want and the customers don’t want. Last but not least the process took so long that the market has changed. They have to start all over again.

Do you now understand why we there is such a shortage in IT specialists? About 30% of IT-projects is succesful. This means that 70% of the IT-specialists are working for nothing.

My advice

Adapt what is working as long as possible.

A team of 15 people is capable of doing more than a team of 1000.

Do it yourself.“

Hans describes a full circle process of what happens before a project is outsourced. I call it the “Shit” cycle I couldn’t resist making a drawing of it:

I missed one phase in the process: the pre-project phase, which consists of a sales rep of <insert large ‘consultancy’ company here> taking the high-level manager to the golf course…

What I don’t know is, each time the project goes through the cycle again whether golfing is required (Hans writes about one project that cycled for ten years…).

Making someone responsible to be a product owner, might make a development team feel absolved for ‘customery’ things. For a long time my gut feeling has been that the whole team (product owner, developers etcetera) should place themselves in the customers’ shoes. Attending presentations on product ownership in the eXPerience reports track at Agile 2007 confirmed that feeling.

Getting everyone to ‘crawl in the skin of’ their users creates simple to use products that do what they must and no more. Sometimes with amazing, simply beautiful interfaces.

There were presentations by:

• the BBC – Effective product ownership within a multi-component project by Mike Lowery and Marcus Evans,
• Yahoo – Less, Never more; Launching a product with critical features, and no more by Gabrielle Benefield and Scott Gatz, and
• Oxygen Ript (TM): Innovation and Collective Product Ownership by Ken H. Judy and Ilio Krumins-Beens.

The BBC story was on using the time of product owners wisely, I hope to write about that in a separate post.Yahoo’s and Oxygen’s stories are both about strong product ownership, focus on essentials, and last but not least: crawling under the skin of users. In the case of yahoo those were college students, in the case of oxygen women who are planning something, e.g. a home (re-)decoration or a wedding.

Both stories reminded me of ‘The Knowledge Creating Company’ by takeuchi and nonaka (1995). There is a chapter on how Panasonic created the first bread-baking machine. The chief engineer on that project had tried to understand bread baking from reading a book, and failed. Then he went to take lessons with a master baker in an Osaka hotel. He then tried to explain the bread-making and -baking process to his colleagues, and failed. Eventually groups of engineers would do internships with the master baker to get a ‘gut feel’ for breadmaking – this eventually helped them to resolve the myriad of constraints on a breadmaking machine.

Looking through the agile2007 proceedings, the written version of oxygen’s experience report actually mentions the knowledge creating company, I did not see that in the presentation.

If you are interested in product development, and haven’t read the knowledge creating company yet, I strongly recommend you do so. It is not an easy read (quite thorough), but you’ll come back with a more thorough understanding of product development.

The book also has good tips on how to collect knowledge and share it from one project to the next (or at the same time) – collecting and condensing knowledge takes time and concentrated effort – this gives project managers something to do with the spare time they get once their teams start to self-organise…