Maybe because of the delay (we skipped May eventually) we not only have more items, they are also longer. We try to keep the newsletter short, but the things we discussed at conferences and while making the product development training gave us some inspiration to explain some topics in more detail. If the topics pique your interest, you can read it online or subscribe.

Willem and Marc introduce cultural patterns that can be found in software organizations. By understanding the cultural patterns then you can better adapt your practices.

The presentation starts off a bit slow, but picks up after the introduction. At the time we were incorporating some feedback about our presentations, most notably that we said too little about ourselves, so that the audience had difficulty understanding where we are coming from, and why we had to say something about the subject.

The videographer and editor did a good job at choosing the shots – shooting a pair presentation with one camera is challenging, especially since Marc and I are on opposite sides of the projected slide. The last part of the presentation was helped a lot by questions from the back of the room, I remember Keith Braithwaite and David Anderson (you can hear them faintly in the background) and there were one or two others. Next time I guess we could repeat more of the questions so they are more audible on the video.

A surprising thing we ran into was that Agile was not as mainstream as we thought – a surprising small number of participants put up their hands when we asked whether they were using (at least some) practices connected to Agile Software Development. Luckily, the patterns are independent of this, so we hope those who were/are doing something else get value from seeing various ways to organize development. It’s all about choosing an approach that fits and makes you more effective.

In hindsight the presentation became more graphical and less textual with each iteration. We’ve left the presentation alone for some time, and now have new ideas on presenting the material, as well as some new ideas on how to place various approaches to organize development. We’d love to hear from you about opportunities to perform new iterations…

Tomorrow we plan to present the material in much the same way as at Qcon London, and spend the extra time we have on doing exercises with the participants, much like we did at XP Days Benelux and London last year, now with new and improved exercises . We’re getting better at presenting the patterns in a non-linear fashion and getting the idea across that one pattern is better than the other, but that they each have a context where they fit best.

After Beyond Agile in France, we took up the nice task of re-ordering most of the presentations, and drawing some of the choreographies you could see in the notes, so that we could tell stories more effectively, show the patterns in a context where they fit and explain why some choreographies are easier than others.

We start off with asking the audience questions about too much or too little process and whether they have been involved in some way in an agile transformation. At qcon, surprisingly little hands went in the air for any of the questions – so that might mean that agile is not that mainstream yet… We expect most people to have worked in either routine and/or variable cultures. Several people raised their hands on all questions . So that means it is a decent starting point – it is easy for most of the audience to picture what these cultures feel like from their own experience. Some of the others require a bit more explanation, as they are more uncommon or less easy to spot.

Routine and Variable can also help explain an endless source of conflicts within an organization. At Agile Open France there was a session on “Dev vs Prod” (Development versus Production – most of the participants worked in some kind of IT organisation where the Developers – people who program the programs – are not responsible for keeping the programs they make up and running – that is the responsibility of Production). Developers often prefer a variable way of working – being flexible, trying out new stuff and making the customer happy. When they hand their stuff over to Production, they are faced with forms and procedures – indicative of a Routine Culture.

Now, why would Production have these procedures?

Because (amongst other things), they have past experiences with Development handing in code that ‘Works On My Machine’, and even if the code does work, most software they have to use is Legacy Code. As Gildas noted at Agile Open France, most production software (e.g. mail servers, databases, some web servers) don’t give feedback until you restart it and go live. Some do some syntax checking (e.g. the apache web server), but even that is uncommon.

So any change to a production environment has a good chance of breaking it, which leads to the Production people getting complaints and working nights to get the whole thing back up and running. Wait, did I say working nights? That doesn’t sound very Routine, now does it…

Often when something goes wrong, a routine organization will temporarily go into a Variable state, in the hope that order will return soon. In the case of Production, going Variable is more unpleasant, because if you’ve been doing this for a while (I have, as a side project), you can feel in your gut that something might go wrong again, requiring even more heroic fixing… And this always happens when you least expect or want it (say, the day before you go on holiday…).

The two pictures with arrows already show two uses of the patterns:

• Predict and explain conflicts between parts of an organization
• Transitions from one pattern to another (and back) and why they happen.

And that ‘fixes’ one of the ‘defects’ we had in our presentation last year: explain early on in the presentation what we use these patterns for – we usually needed the Q&A round to explain the ‘why’… I hope to follow up with another post on another ‘why / how to’ : guide transitions from one cultural pattern to another, and explain why some transitions feel easier to me than others.

“[...]a small startup, should be working twice as hard as the bigger companies [...]“

Taken from tales from the WTF company, part II . If you work smart, read part I first…

Excercise for the reader: which cultural pattern does the WTF company exhibit? You get bonus points for identifying coping stances from the story as well ).

When Bob moved to the ABC Bank, he tried to repeat his recipe for success (weekly planning meetings and standups) and then later add stuff. This also would enable developers to deliver more value. Instead of being happy, they asked: “where are the documents, and procedures? How does my role/job description fit in a multi-disciplinary team? (‘I like the security my role provides’) Where are the handoffs?”

This time Bob found himself in a place with a Routine cultural pattern – everyone follows the rules, questioning or evolving the rules is not expected behaviour. And when you introduce for instance bits of XP, Scrum or Kanban, people might complain there is not enough ceremony. We’ll explain why that is later. For now, Bob could not say more than “don’t worry” to the people who were worried about their job…

Bob learnt that a routine culture works well if the context is well known, and is characterized by:

• Feedforward control,
• There is a best way to develop software
• Silver bullets
  • Methodologies
  • We need a tool!
• Management by controlling
• Process oriented

We often find routine cultures in ‘Production environments’ (e.g. hosting of web-applications) and environments like banks and insurance companies where stability is more important than innovation. Organisations with a waterfall process (which I considered so far to be a red herring, as I didn’t encounter it much, but I’m getting more work in this area) can also be considered to be routine.

When Bob worked at XYZ Widgets Inc. , he wanted to introduce weekly planning meetings and daily standups to track progress and release products sooner with less overtime. He expected happy responses at the customer’s site. Instead, several of the programmers went : “oh no, not a one hour meeting every week! Just leave me alone to code. And those ’standup meetings’ every day, do I really have to be there? Can’t you do them without me?”

Later, Bob figured out he found himself in an instance of a ‘variable’ cultural pattern. Developers (usually a few) work very closely with a customer, and do whatever they feel like to give the customer what they want. Don’t bother to ask them when they can deliver – they won’t be able to give even a rough estimate. But, at some point they will deliver, because they like the customer.

Bob experienced that variable culture works well if the problem/challenge is small enough, and is characterized by:

• Close cooperation between customers and developers
• Craftsmanship
• Hands-off management
• Performance and quality totally dependent on individuals
• Heroes

Come to think of it, a variable culture goes pretty well with the values of the agile manifesto… So is it any wonder that co-workers in a routine culture are afraid when you mention the manifesto? They see heroism, variation in quality and they don’t dare to care about innovation, because their environment traditionally thrives on providing stability… And there is no reason to risk sacrificing stability (unless there is a crisis of course…).

Marc and I presented another iteration of “Beyond Agile – People versus Process” at qcon. This transcript was inspired by the re-done introduction. I plan to write some more soon… We had an article in production that we’re going to rewrite based on last weeks Agile Open France. The choreographies, the random order and the questions you saw at the top of this post worked well, so we are going to do more with that.

Notes of Beyond Agile. Click the image for the full-size scan.

I decided to propose a run of “beyond agile”, so I could try a different way of presenting the cultural patterns before qcon London this wednesday. The runs at xp days last year (then dubbed ‘people vs process’) were well received, and gave us ideas for improvement:

• we needed the question and answer time to get across why we believe these patterns are useful in our work (they help us determine where we are, and decide on a strategy on where / how to go next),
• attendees got the idea that one goes from one pattern to the next in a linear fashion. We then presented it in a linear fashion then, so surprise,surprise…

In this instance, I ditched the slides and presented from flipchart. After presenting the ‘why’, the participants did a round of experiences on the questions:

• ‘did you ever experience people telling you that your mix of ‘agile’ practices is too much process? ‘
• ‘did you ever experience people telling you that your mix of ‘agile’ practices is too little process? ‘

We then gradually constructed the circle, starting with the cultural pattern (‘routine’) suggested in the story told by the last participant. Meanwhile, I explained some common choreographies (the arrows), each with their advantages and difficulties through stories:

We discussed more choreographies than could sensibly make the notes, and further discussions over dinner gave me some more inspiration. Even this ‘circular’ drawing follows the same linearity as in Gerald Weinbergs’ books. In wednesdays’ presentation we’re also going to talk about some other choreographies (e.g. going from routine, or routine to oblivious).

As you might guess from the notes, we ran the entire session in french. I needed to ask for some words, and probably my grammar is not up to par, but overall it went much smoother than I expected. The other participants were extremely helpful in letting me and Barry Evans speak as much french as we could, providing us with words when needed, and allowing us to switch back to english when we couldn’t manage in french – less and less frequently needed as the days passed .

So now it’s time to re-order the slides in a quasi-random order – some order that allows us to string stories together in a way that makes sense to the audience, add choreography slides and practice a bit more. I hope to see you at qcon on wednesday.

Mark Gallagher posted Noncertified IT pros earn more than those with certified skills, report shows

The report Mark Gallagher mentions seems to focus on linux skills. I hope it indicates a wider trend – companies looking for creative, inventive people who know how to do research, over people who wave a certificate.

From Marks post:

“A new report from industry research firm Foote Partners LLC finds that the average pay for noncertified IT skills topped that for certified professionals while compensation for IT jobs increased again in the third quarter of 2007. [...]

In May, Foote Partners reported a 9.1% increase in average salary among 149 noncertified IT skills over the last year, according to their IT skills pay survey.

[...]Foote Partners has been reporting that pay for noncertified IT professionals has been steadily increasing, while compensation for certified IT skills has been steadily declining for more than a year.”

Further Reading: Nynke Fokma lists possible advantages in favour of ‘certified agile professionals’ in Certifiblation:

“Command recognition from customers, clients, executives, managers, coaches, consultants, and other developers.”

I recognize people who wave a certificate. Probably not in the way they would like It seems employers are doing the same….

In a follow-up post, Marc Gallagher quotes Bernard Golden:

Golden points out that certification is only good for demonstrating ability in established, commodified skills. The job market has shifted away from “standard issue stuff” in the industry, which demanded basic skills from large numbers of employees and Golden said those days are long gone. Drawn to certified credentials are organizations that still require professionals who can perform basic skills (cost centers, for example).

I value creativity and the ability to overcome obstacles over certification. What do you value?

Credits:Joaquim Bonet i Chambó 14-2-1817 (birth certificate) by art_es_anna

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?

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

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)