Blog

Return from EuroPLoP 2005

I’ve just returned from the EuroPLoP conference in Germany. For those who’ve never been to a PLoP conference you don’t know what your missing – get along now!

Anyone will do – except for the fact that I hear the original PLoP (outside of Chicago) has changed its atmosphere in the last couple of years so maybe that is not a first choice. VikingPLoP is a great little conference but it is small. Still EuroPLoP isn’t that big, about 45 people this year, much less than the 65 when I first went in 2003.

I return from EuroPLoP as usual, exhausted physically (too much beer, too many late nights) and mentally (so much to think about, so much to read, so many good conversations) but also inspired and ready to move on to the next year.

(Unfortunately while I was at EuroPLoP some bombs exploded in London – you’ve probably heard about this already. London is my home town, I was born close to Liverpool but I now consider London home. It feels like someone has attacked a member of my family. Still, I didn’t let it ruin my conference too.)

A few things deserve mention here.

First, much to my surprise, I was award the 2005 Neil Harrison Shepherding Award. This is a great honour for me, although I feel “I’m not worthy”. I look at the names on the Staff and they include great people: Norm Kerth, Joe Bergin, James Noble and Frank Buschmann. Thank you to the programme committee, I am honoured.

Second: I ran a long focus group (5 hours over 2 days) with Lise Hvatum on the subject of Conway’s Law. This was a fascinating exercise that opened up all kinds of ideas and insights. We learned too much to write it all here. We will be writing a report for the conference proceedings in the near future. For now lets just say Conway’s Law isn’t necessarily a Law.

Next: there where several analysis patterns at the conference, including a couple in my workshop. Didi Schutz asked me: “Are Analysis Patterns really Patterns?” I think we all tend to accept Analysis Patterns as Patterns but I’m no longer sure they are Patterns.

A pattern should tell me what to build, it should tell me how to go about building it, the pattern is named after what you build. The activity of Analysis is not about building, it is about understanding, decomposing and deconstructing. Therefore, how can you have a pattern about this?

Because patterns are about building they are about synthesis. Obviously, analysis is not synthesis. In fact, I’m in very close to revisiting Henry Mintzberg’s argument about strategic planning. (I recommend The Rise and Fall of Strategy Planning for more detail.)

Finally: I’m conscious that there is much pattern lore that is handed down by word-of-mouth, and in a somewhat random fashion. If you have the right conversation you will learn about “the but form of forces” but if your unlucky nobody will tell you about the “noun phrase” rule for pattern naming. At a time when individual patterns are becoming less important and pattern sequences more so I feel there is a need to get this information to new pattern writers.

Writing a pattern should not be hard. You should not require years of learning. Patterns are usually written by domain experts, if you need to be an expert pattern writer too then we are going to loose a lot of opportunities for patterns.

I could write more but I’m going to draw the line there for today.

Getting ready for EuroPLoP

Well it is time of year again. On Wednesday I’m off on my annual pilgrimage to Munich – or rather a town about 80km West of Munich, all I’ll see of Munich is the airport.

It is the annual European Patterns Language Conference – otherwise known as EuroPLoP. The original PLoP conference still happens outside Chicago in September every year, and yes the name is deliberate – Pattern Languages of Programming but they chose something that sounded a little funny, thus “Plop.”

This is the third year I’ve been to EuroPLoP and it is going to be my busiest. As well as having my own paper work shopped I’ll be the work shop leader for my group, plus I’m co-leading a focus group on “Conways Law” with Lise Hvatum, and if that weren’t enough I’m shepherding a paper face-to-face.

Although EuroPLoP takes place in a conference retreat (formally a monestry, they kept the brewery and all drink is free) the energy levels are outstanding. Mentally I’m going to be challenged, emotionally I’ll learn to trust a whole bunch of people – most of whom I’ve never met before and physically I’ll be exhausted.

The focus group might be the most exciting bit of the conference. I’m expecting to learn a lot. However, as I’m the facilitator I’ll have to keep on my toes – a great challenge. Already this session has created a lot of interest.

I’m looking forward to shepherding a paper face-to-face. As a shepherd it is my job to help the authors make their paper better. Its a kind of coaching role, it is still their paper I just give them advice and help them improve it. The real trick is to help them make the discoveries themselves. The authors know the patterns best, my job is to help them with the “pattern” bit in such a way that they tease out a better pattern.

As to my own patterns, well, they have nothing to do with programming any more. My early pattern(s) did but the ones I’ve written for the last couple of years are focused on business issues. I’m trying to establish the pattern form as a useful tool in the business domain.

I really think patterns have a place in business education. So much of what I learn on my MBA could (should?) be expressed would patterns. That should make things a little easier to understand.

Anyway, enough for now, I have to pack…

Switzerland

No entries for a week – a bit of a gap by my own standards. I’ve been on holiday (vacation to US-English speakers). Went down to Switzerland for a week. We relaxed, we saw Zurich, met some friends, visited Lucerne for a few days (where I would recommend the Hotel Hofgarten), did some lake swimming, walked up (half a mountain) and generally had an enjoyable time.

Of course, Switzerland is expensive – I probably don’t need to tell you this – but its worth thinking about in more depth. What makes Switzerland expensive? Taxes are low, employment is high, salaries are high (so people can afford the prices) but you might expect these things to cancel out. At the moment I can’t answer my question.

(Another question I can’t answer: how can the subsidise the train system so much when taxes are so low? I suspect, the answer is limited public spending on health care, similar to the US where health care money is spent by the private not the public sector. This is the ultimate stealth-tax.)

What was clear is that Switzerland is a service based economy. Yes there is some farming, and some manufacturing – particularly precision engineering like watches and things but the driving forces in the Swiss economy are Banking and Tourism, both service industries – and both industries that don’t like change.

(OK, maybe I didn’t see another side of Switzerland since I only visited the home of Banking and Tourism, please correct me if I’m wrong.)

What is interesting is that Switzerland potentially offers a view into the future. We know that much manufacturing and even some services are migrating to low-wage economies, so what advanced economies like the UK is betting on is keeping the high-value services. There will always be some low-value services (e.g. bar tender) but the high-value ones are the ones really worth having and they are knowledge based. Bankers require knowledge of banking, IT people require knowledge of IT, Teachers require knowledge of their domain, and so on.

I’d like to learn more about Switzerland’s economic model and what it can teach us for the future.

I’d also like to know how Switzerland got to be where it is today. How did it create such an economy?

And, the malevolent curious side of me, would like to know more about the ghosts in Switzerland’s cupboard. The place is too clean, too wealthy – I was actually relieved to see homeless people, it told me the place was real!

An organization mapping exercise

Last night I ran an organizational mapping exercise at the Extreme Tuesday Club. What, you may ask is that?

Well, I learnt the technique from observing Jim Coplien apply it. Jim and Neil Harrison have been running these workshops for some years, their aim was to better understand development organizations and produce the patterns in their book “Organizational Patterns for Agile Software Development.”

Typically they run the workshop with a software development team, at the end of the sessions they have a collection of index cards they can analyze and produce a map of your organization. This map can then guide you through their patterns telling you which patterns your organization is using, which is isn’t using and which it should think about using.

This is a very powerful technique. It will tell you a lot you didn’t know, much that is obvious once it is pointed out and confirm a lot of suspicious various people have. As a tool for change its a great motivator: these guys come in, spend a day with you and can describe you back to yourself.

If you want to improve your software development efforts I strongly recommend getting them to run one of these studies.

Anyway, that is something else.

The sessions I ran with help from Giovanni Asproni and Rachel Davies was not really what Jim and Neil do, it was more inspired by Jim’s workshop. And what we didn’t do was go anywhere near the patterns. In effect, it was a demo of how you might go about mapping the interactions in your team.

So, what did I learn form this?

First thing I learned was that running this in a pub, with people drinking and eating, joining late and leaving early is far from ideal!

Second thing is that the people in the room hadn’t actually worked in a team together. So, we where trying to map an organization that didn’t actually exist. Naturally, each individual had different expectations of what they expected other people to do. The guy playing the “Architect” role had a different understanding of what an Architect would do to the person playing the Customer role.

To make matters more complicated, this was XTC, by definition, the people in the room believed in Agile development, Extreme Programming, Lean Software and all that jazz. Nothing wrong with that in itself but it made things even more complicated. There are few organization which are actually out and out XP, or Lean, or Agile. Everyone has a different take. For example, the person playing the “Project Manager” understood this as an enabler role, more of a coach, while others where expecting him to manage a project.

The other problem we faced was that time was limited – OK, time is always limited but the pub was going to close at 11pm. Having seen the technique used a few times before I knew where time would be wasted so I tried to hurry it along at stages. I probably over did this a little bit but it did allow us to finish in less than 2 hours so leaving time for a discussion.

The discussion that followed was very interesting. We discussed the technique, our companies, our experiences of agile, and how the technique had shown some things that we saw in real life (e.g. a frustrated developer got fed up of project management and testing and decided to talk to the user directly.)

Actually, discussions at XTC are always interesting but I don’t always feel I come away knowing something new. This was different. I got some insights from the exercise – I might write them up in more detail in the next few days or weeks.

The other thing I should say is that although this idea has come from software development its not confined to software development. It could be used to map any organization or process. (Interestingly, a lot of Jim and Neil’s patterns also apply outside of software development.)

Actually, in retrospect, since my objective was just to demonstrate the idea of the technique it may have been better to choose something from outside the software domain, say, getting a car services.

In the middle of the workshop I did have that “O no! Its all gone wrong, I can’t do this” feeling but in the end most people thought it was a great success.

(Who was it who said “In the middle of any change it feels like failure?” – I can’t remember, I think it was a Harvard Business School professor?)

I think I agree with them, it was a success for me because I got to try moderating this technique, it was a success for the participants because they go to see what an organization mapping technique could look like and it was a success for everyone because we did get some insights into the software process.

Do you believe in Phil Crosby?

So I’ve started using a bug tracking system.

Yet hate bug tracking systems – I believe they are wrong, rather than help fix bugs they help hide them, they create excuses for not fixing bugs. They allow us to say “Its in the system” when really we mean “No way will it get fixed.”

So, why have I started using something I don’t like…

He’s the simple explanation: I’ve now taken over some product management duties and I don’t have the people available to fix the bugs. I need to keep track of the problems that are coming up. I also need to show the company “I’m doing something.” Somehow people are impressed when I say “I’ve started using the bug tracking system.”

It also means people accept there bugs.

What we really want to do is not accept them, have zero-tolerance for such errors.

So, the longer version of why I’m using a bug tracking system…

Its a stock of work to be done, a queue, a buffer between now (the time they are discovered) and the time the work gets done. When they do get done…. well, that is the question.

It does have one attribute that is useful, it allows for prioritisation. So, we can decide which ones need to get done. But then, if we had zero-tolerance there wouldn’t be a need for this. (Or, if there had been more quality built in then we wouldn’t have the need either.)

A keen reader will probably also point out that with prioritisation comes the ability to decide not to do something. Say, we identify 100 bugs, we fix the top 20 and then the people above me decide it is good enough, why use scarce resources to work on such low priority items? If it does the job with these 80 faults why shouldn’t we just save our effort?

I suppose its a bit like building a car, and when it is done you see the faults, you fix some and sell it. Have you saved yourself a lot of work? Have you allowed your workers save time during the construction – thus introducing low priority faults – and later decided which time saving items where worth going back and paying for?

To my mind, if a job is worth doing its worth doing right. If we need to save time and money somewhere we should do it in a conscious management fashion “Don’t develop feature X” – not in a sub-conscious “Joe saved 10 minutes by not tightening the screws” kind of way – doing it this way allows the guys on the production line to decide what is worth saving on.

Really it comes down to “Do you believe Phil Crosby?” – that is, do we believe “Quality if Free” ?

People know what is wrong with a company and what needs changing

They may not tell their managers, supervisors or leaders but they will talk about it with others in the pub, the coffee shop, or at the water cooler, or some other place where it is safe to moan.

It is the work of a good leader to give people a safe place to express these problems in an environment where they can be dealt with. It is the leaders responsibility to listen, understand and see what can be done.

It doesn’t mean it is the leaders responsibility to do something about it. They may decide they need to act, but more often it is their responsibility to ensure the people facing these problems can act to solve them.

All too often people think “nothing can be done” so they moan about it to one another in the pub and absolve themselves from fixing it. Sometimes they don’t feel they can fix it, sometimes they don’t think they are allowed to fix it. In an enabled organization you want people to fix the problems as and when they find them.

I think it was Gerry Weinberg (Secrets of Consulting, 1985) who pointed out that problems can’t survive in the light of day. Once a problem is brought out into the light – or named as Gerry puts it – then your half way to fixing it.

The second half is more difficult: you have to want to fix the problem.

All too often people don’t actually want to fix the problem. Maybe they are scared of the solution, or maybe they fear the consequences of fixing it, or maybe one of many other reasons.

Growing

Two things you should know before I get into the meat of this Blog.

First, I have a lot of time for the writings of John Seely Brown. If you’ve not heard of him before get yourself a copy of “The Social Life of Information”.

Second, Wharton Business School at the University of Pennsylvania run an interesting e-magazine called “Knowledge @ Wharton”. Of the newsletters I’m signed up for it is one of the few I actually look forward to receiving.

In this month’s Knowledge@Wharton there is an interview with John Seely Brown, together with John Hagel he has a new book out “The Only Sustainable Edge: Why Business Strategy Depends on Productive Friction and Dynamic Specialization.”

You can get a feel for what the book is about from the interview and it sounds like it might be quite interesting. I’ll add it to my “I should read” list.

Anyway, the reason for mentioning all this comes towards the end of the interview and John Hagel says:

“Ultimately what we see is the re-conceiving of the role of the firm. Traditionally the role of the firm has been to increase the efficiency of transaction costs, whereas we see more and more that the firm has to provide opportunities for capability building of the people within the
firm. If the firm cannot do that, people will leave and seek out environments that can help them accelerate capability building better. It’s a very different way of thinking about what the firm needs to provide to its employees, and the role of the employees within the firm.”

Wow! Your not kidding, this is re-conceiving the firm. I’ve been giving some thought to this since I read it a day or so ago and I think he’s right. Lets take it a bit at a time.

Yes, firms have traditionally existed to produce efficiency in transaction costs. A car manufacture has all the designers, engineers, production staff, distribution, etc. etc. in one entity because they is how they can use them efficiently, no need to ask yourself “Can I trust this supplier?” when the supplier is yourself, no need to go hunting for trucks to deliver your cars when you own a fleet of trucks yourself – you get the idea.

Only building companies is hard. And we know from experience that competition drives down costs – this one of the reasons why US capitalism beat Soviet communism. But if competition results in the lowest costs and prices why don’t we compete for everything? Why shouldthat car manufacture have a fleet of trucks when if he adds competition his costs will be reduced?

Answer: transactions costs, because the savings from setting one trucking firm against another are less than the costs of finding the firm, negotiating a contract, monitoring the contract and paying the bills.

But this is changing, trends in outsourcing – often enabled by IT – mean that transactions costs are falling and it becomes worthwhile to use competition to reduce costs. We are already starting to see the emergence of virtual companies where almost all the activities are
outsourced.

You could argue that in future we won’t need firms because they can outsource everything. But hang on, some firms must exist because they will be the outsourcers!

So, if you are a firm that exists, say you are an outsourcer so you have to do what-ever-it-is you are going to need people. Why would these people work for you?

Well, one answer is they need to pay the rent or the mortgage. But if this is the only reason people work for you the chances are they aren’t going to be very motivated, if you are using the stick rather than the carrot people may go through the motions, they may do something, it mayeven be the thing you want them to do but it isn’t going to be very efficient.

Contrast that firm with the one that does uses the carrot. They create a place where people want to work, where people are enthusiastic, where they are motivated. Suppose they are doing the same – or similar task. Who is going to be the most profitable?

The answer to that question kind of depends on how you see the world and what evidence you decide to look at. For me the answer is the second firm. Trouble is, the second type of firm is much more difficult to organize, operate and manage. It also is also he opposite of the macho images we get from TV and Hollywood: “Do it or I shoot you”, “Make it so”, “I could tell you but I would have to kill you.”

But back to the plot…

Now remember, these firms are outsourcers, other people are giving them business to transact. So, which firm is going to win the bulk of the contracts? Right, the second firm.

So the question boils down to: how do I get these enthusiastic people to work for me? (So I can have a productive workplace and win those outsourcing contracts.)

This is where the Brown-Hagel argument really makes sense to me. It is the firms who give their people the opportunity to grow. Notice the word is grow, not challenge, not highest paid, but growth.

When I think about my own career is a search to improve myself, to learn more and, yes, grow. Sometimes I’ve done this by earning lots of money and using this to travel, buy a house so I can have my own space, buy car so I can experience things; and sometimes I’ve grown by working abroad, and sometimes I’ve just grown by working on an interesting project.
Once I’m not growing I’m not interested in work and my productivity goes down, I start asking: what next?

And then I come home at night. First I might cook – I find growth in cooking, new recipes, new variations on recipes I know, practicing a familiar one or inventing something from what I have in. And then often enough (too often?) I lock myself in my study to work on some pattern paper, or a magazine article, or (re)organising some body I’m involved in, why I might even write a blog!

Or maybe I settle down with a book.

If bed-time comes and I’ve not grown a little, learned a little something, thought about things I kind of feel I’ve wasted my time.

Maybe not everybody will buy into the Brown-Hagel argument, growing isn’t for everyone. But, where you do need them, and where you can take this advantage then I think your onto a winner.

Its the people, stupid

I read in the Financial Times yesterday that Warwick University are revamping their MBA course to increase the element of soft skills.

(As an aside, is it just me that thinks the FT and it’s sibling the Economist are obsessed by MBAs? – maybe this isn’t surprising as they are both owned by Pearson publishing. Anyone whose ever done an MBA will have spent a lot of money books published by Pearson. Before I put ideas of a conspiracy in your mind I’m not saying this. There may be some greater underlying course, e.g. Pearson tends to hire MBA’s as managers perhaps. Anyway, back to my subject…).

(And by the way, the other people who are obsessed with MBA are people who are about to do one and those who have recently done one – sorry, that’s me! – the first group asking “Why do one?” the second group asking “Why did I do one?”)

I don’t know how much emphasis Warwick puts on soft skills and I don’t know how it compares to what I did a few miles up the road at Nottingham University. However I understand their point and think they are doing the right thing.

An MBA course may fill your head full of new ideas, and tools such as IRR, NPV, Real Options, Four Forces, Cash Cows and other such ideas but this isn’t the stuff a manager needs day to day. Day to day you need to work with people; you need to make your operation tick.

Once in a while you will calculate IRR for a project, perform an SWOT analysis and draw up a new strategy but once you’ve done this you have to make it happen. And making it happen is more difficult. It allcomes down to people in the end.

Are all companies dysfunctional?

I’m from software development, when I was an undergraduate I used to love the fantasies my lecturers used to tell me about Formal Methods. If only everyone could specify their program formally then everything would be good. I loved these stories. And then I tried it.

They didn’t work like I was told they would, they didn’t solve anything, they moved the problem somewhere else. Now later in life I don’t believe they ever could – you see, I’ve discovered the soft side of software development.

After formal methods fell from the pedestal I read a lot on software process practice. I could see how you could make it all work like clockwork. This was good. And then I worked for a company certified to ISO 9001 – it was hell.

I never got started with CMM before I worked for a company that was introducing it. There is a lot of good in the CMM literature but it is a ruler to measure things by, not a thing that stands high by itself. Anyway, its upside down. The top layer is “self improving” and this is what you need right at the bottom.

Now I’ve been to business school and have a qualification to prove it. So I’ve worshipped at the feet of great companies, GE, Sony, JCB and others – my personal favourite was SAS Institute. I’ve read how it should be –Porter, Hamel, Levitt, Womack and others. (At least Tom Peters is entertaining – particularly since he’s happy to be inconsistent; may favourite is Henry Mintzberg, he knows things are not as they are “supposed to be” and he’s happy to say it. His great insight: things change over time, ideas emerge.)

Yet I work in business, and the company I work for is pretty enlighten, intelligent people and, at least on the face of it, its managed well. Still, I can find dysfunctional areas. Does this mean the company is doing something wrong? Is there some great thinker/author they’ve missed out on?

But then, every company I’ve ever work for has had some degree of success. Even one or two really really bad places have had successes, or at least a successful history. So why is it so difficult to find a company with gets it right?

Does your employer get it right?

Where is the company that knows its customer, isn’t stuck-in-the-middle, practices lean manufacturing, values innovation, develops software in a Agile way with CMM level 5?

I’m forced to the conclusion that such places don’t exist.

If such placed did exist we need so much literature?

And actually, if such a place did exist wouldn’t it be a bit boring to work at?
Somewhere in all companies there is dysfunction. This brings opportunities and challenges. It doesn’t necessarily mean the company is doomed – although it may be. The important thing is
self-awareness, is the company and employees aware of a problem?
(Problem: its difficult to admit your dysfunctional when your interviewing someone. So you paint a rosy picture, and when they join they get disappointed.)

It maybe they are aware, they are trying to fix it, or they are routing around it – who cares if your front line people can’t get their innovations accepted up the chain if the R&D department have great pipeline of new ideas?

No, its when people don’t know about dysfunctional that there are real problems. How can you deal with an issue if you are blind to it?

I’m sure I’ll return to this topic as I write more in this Blog.

Specification documents are boring

Have you ever read a specification document? I did today and I was reminded why I don’t like them.

They are boring. Even when they are telling you something you didn’t know they are boring.

They are boring because they follow the “form follows function” mantra. The function of a specification document is to communicate what one person wants (or thinks they want) to a second person who is responsible for implementing it. But there is more, the first person wants to specify exactly what it is they want, so thinks are set out in simple fashion, e.g. bullet points, no prose. Supposedly this limits ambiguity.

It also provides an audit trail so they can go back and see what has been done and what isn’t.

Yet in communicating from A to B they fail. They fail because they are boring and person B, the receiver, is going to switch off. The receiver is likely to read what they want to read, they will quickly get a feel for what they think the document says and proceed to read it like that. (Remember, the meaning of a message is decided not by the sender but by the receiver.)

Ambiguity still exists, in fact, because the document is so boring it can be difficult to pay attention enough to spot the ambiguity. And because everything is presented as bullet points it can be difficult to understand how the different parts hang together.

I suppose it does provide an audit trail but this is more damming than it is positive. We create an audit trail because we expect things to go wrong, we expect to need to trace back and apportion blame. So, we set up an adversarial relationship.

And when you’ve worked with a few requirements specification you know they are frequently the subject of battles so you don’t approach them with any enthusiasm. So you find them even more boring.

The result? Requirements documents fail on all counts; they fail to communicate, they fail to provide an mechanism for getting things done, they fail to enthuse, and they set up a bad work environment – so things are more likely to go wrong.

How do we fix this?

Well, I don’t have any hard tried and tested solution so these are just ideas:

  • On site customer, this is what Extreme Programming recommends and it seems to bring benefits
  • Close in Product Manager, if you can’t have a customer have a Proxy Customer, a Product Manager
  • Use verbal communication in addition or instead of written, involve everyone
  • Rather than try to specify everything down to the last detail allow people to engage on a voyage of discovery, involve them in finding the requirements
  • Paint pictures and visions, allow people to flesh out the detail themselves
  • Tell Stories

Stories are something that interests me. They are a topic I expect to return to over the course of this blog. In the meantime I’ll just recommend one book. It is The Springboard by Stephen Denning, Butterworth Heinemann (2001).