I’m still in the back of the Airbus but I want to write about a different subject now so its time to start a new entry, Back in April I ran a session at the ACCU conference about learning in software development. If you know me you know that I’m passionate about both these subjects. Indeed, I wrote my MBA dissertation on exactly this subject – Software Development as Organizational Learning.

Well my conference life is quote different from my work life and I don’t tend to present this material in work. However I did last Friday.

I founded and run my company TechTalk programme. This is an hour slot on a Friday afternoon where somebody – usually from inside the company but sometimes a guest – talks about something relevant to what we do. Usually it has a technical focus but I’m also keen to include marketing, strategy, customers, etc.

I prefer not to schedule myself as a speaker because I don’t want it to be seen as “Allan’s TechTalks” – I organize it for and of the company, I want the rest of the company to be involved. But after a little reluctance I was persuaded I should do something.

The talk itself was slight abridged from ACCU but took the same form. 20 minutes of slides and ideas on learning then open it to the floor and see get the audience to contribute ideas.

I could have talked for longer but I believe that learning is best when it comes from within. Rather than me lecture the audience with my ideas I wanted them to make suggestions themselves. That way I hope more of them will take root.

I haven’t had a chance to compare Friday’s results with those from the ACCU conference but it felt there where more specific ideas about how we learn in the company and how we can improve it.

The killer question for me came after the talk when someone asked “What next? What do we do with this?” I wish I had a good answer to this but again, I don’t own this. The people in the room own it. I can’t force them to do any of the things we suggested I can only hope that some of them will try.

In that way it was a bit of “throwing mud at the wall” – we suggest some ideas and see which stick. Where someone shows an interest in taking up an idea I’ll help if I can but I can’t force anyone – its change you see.

One thing that came out more clearly this time that didn’t last was the barriers to learning. I think we can do a lot to improve our learning by just removing barriers.

And the biggest barrier? Well, I’m sorry to say it is ourselves. Too often we start with the assumption: “I can change this” – “I need a manager to change this” so we don’t change and we don’t learn.

Now, I’ve spent some time reading management literature, and I’ve talked a lot to actual managers. The biggest problem they seem to see – at least in my office – is: getting people try new things, invent new ideas, take ownership of something.

So, I think, to change the world we change ourselves, we try and do something new.

This is a thought that goes around and around my head, I see it again and again, Amazon is a great example, so is Google, but its not only in the web world, it applies to TV (CNN), Zara/Inditex in retailing and elsewhere – the potato peeler was the last example I spotted.

(Although I should admit, I gave up peeling potatoes some years ago: it takes a lot of effort, you are removing a layer with a lot of flavour and vitamins and your going to boil the things anyway so there can hardly be any germs there – but I digress!)

Sometime when you change something – even just in one dimension – you turn it into something else. Take Amazon for example: was it something new in shopping?

(I’m taking Amazon because its an example everyone knows and they do their job pretty well, similar points could be made about most online retailers.)

Or, was Amazon simply the catalogue-shopping model transferred to the Internet?

Remember those big old catalogues? My Mum used to borrow them from my aunts, Littlewoods and GUS – I’m sure other countries have their own equivalents. Really, Amazon didn’t go anything these companies weren’t doing already but by putting it online it enhanced one aspect of the system – items stocked:

• the range of stock increased massively – first in books then in other things
• stock was changed more frequently, a new item can be added to the system and available for people to see in a day or two; the catalogue printing and distribution system meant stock items had to be decided months in advance

Everything else Amazon did was secondary to this change – things like wish lists came later – while things like the associate programme where just electronic versions of the old system – I recommend books as an Amazon associate the same way my aunt would lend my Mum the catalogue. And in doing all this Amazon made the whole system so much easier.

At some point Amazon ceased to be an online version of Littlewoods and become something of its own.

The same is true of CNN – news was always on TV, now its on constantly, after a while it becomes something itself, part of the fabric of life.

And the potato peeler? – Well its just a knife that has been specialised.

This happens inside companies too. I once worked on software to model the electricity supply in England. At first the model took about 24 hours to run, the Analysts thought carefully about each run and each one was an event. We speeded the application up, by the time I left it was down to 3-4 hours. The analysts changed the way they worked, they could try out more “what if scenarios”, if a run didn’t look good then junk it and move on, and you saved time in preparing for the run too because you could afford to do another one if you made a mistake.

The trick with all of this is to push hard on one dimension, when you change that one dimension everything else changes. The difficult bit is knowing where to push.

I’ve mentioned a few times that I’ve recently moved from software development to product management. Consequently I’m getting a different view of the development process. And of course, I have to deal with developers who never seem to do quite what I had in mind or when I had it in mind!

Before you ask I’ll admit it, my project is not running Agile/Lean. Why not? Because a) it was running when I got involved, b) its a “small” project – small in the sense of number of people involved. Why does small matter I hear you say?

Well, many of the process advocated by Agile are for social interaction, and they require social interaction – no point in having a stand up meeting with 2 people, or trying to pair programme if most days there is only one person.

Would I like it to run Agile? Yes

How would I change it? Difficult this one, probably, placed in the position of my managers I would never have started this project. The way I view projects is like this: if they are worth doing they are worth committing lots of resources to, if they are not worth committing the resources then they are not worth starting.

Put it another way: no side bets, no micro projects.

But I didn’t want to write about project management here. I wanted to ask: who ones the project?

As a developer the answer was clear: me – not the product manager.

As a product manager the answer is also clear: me – not the software developers.

Ownership is important. When you feel you own something you work harder, you take a higher pride in your work. I’ve been feeling this problem for a few weeks but my thoughts coincided with comments from the economist John Kay in Tuesday’s FT.

So often I’ve worked at companies where the product manager role was under developed or non-existent – that is a blog entry in its own right. In these cases as a developer I’ve stepped forward into the gap and tried to fill it. Tried to direct the product, I tried to create a “roadmap”, to care about the product, make it improve.

Its a matter of pride in your work. And I see this in other developers too, even if they aren’t trying to direct the product they want it to succeed – you don’t think people enjoy working on failed projects do you?

Now I’m a PM, I’m not developing code but I am trying to think about the product strategy, I’m talking to sales guys about what they need, I’m talking to customers about how they use it, I’m trying to make sense of all this and balance the demands for features, bug fixes, improved usability and the rest. I’m not coding it but I feel I own the product.

Part of this goes back to my question of identity. I still see myself as a developer, I feel I should be coding, I feel the developer owns the product but now, well, what right have I to have these feelings of ownership?

Multiple owners may make for competing ideas and demands but it is better than having no owners. I’ve seen code that isn’t owned by anyone, it deteriorates; I’ve seen products that aren’t owned they tend to die. Ownership is important, and somehow I need to find a way of balancing the needs of the multiple owners.

wMy local airport is Heathrow. Fortunately I’m not so close that I hear the planes so its mostly upside benefit, on a good day I can leave my place, get the tube to the airport, check-in (or what passes for check-in in these days of online and self-service checking) and through security in under and hour – not bad.

Anyway, I didn’t raise the subject of Heathrow to sing the praises of my house. The airport is in the middle of a major expansion with the construction of a fifth terminal – Terminal 5, this is due to increase the airports capacity by something close to 50%.

The project is massive, to give you some idea, the smaller of the two buildings is bigger than the existing Terminal 4, there are 13.5km of tunnels in the project and its going to cost about £4.2bn – or £4,200,000,000 – about $6.7bn.

For me there is something even more interesting about T5: the project is Lean. The team building the project have borrowed a lot of ideas and techniques from the lean production movement – also called Toyota Production System and best known for just-in-time production.

The owners of Heathrow are BAA (British Airports Authority as they used to be known) and they know Terminal 5 is risk, so risky it could sink the company. They also know their core-competence is running an airport. So, current management theory you would expect them to sub-contract this project to someone like Bechtel. But they didn’t, they took the attitude: this is so big a risk we have to manage it ourselves.

Because T5 is being built within the existing Heathrow perimeter space is at a premium. So stock is held offsite or brought direct from the supplier. There is only 24 hours of materials on site at any one time, if there is a delay it will be noticed quickly. Even if you had more space it might not be that useful, there is only one road in and out of the site.

When they came to raise the roof they took all the parts and sub-contractors to a large field and had a dry run. They then took it apart, took it to Heathrow and did it for real. now that’s real team building and training.

Then there is bonus payments: these are pooled, all sub-contractors share a bonus pool so there is an incentive to work together not waste time throw blame around. And if there is an unseen problem to solve, well that’s paid for out of the bonus pool too.

I could go one but I’ll leave you to read more yourself. There is a good piece in the Economist this week, and from last year’s Economist. Pieces crop up elsewhere, like the BBC’s In Business radio programme so keep your eyes and ears open.

What’s really interesting here is the way lean is breaking out of the production system. it came from car production, I know it in software and its gaining ground in the construction industry (check out Last Planner and the Lean Construction Institute.) For years people have pointed to the construction industry and said “they know how to plan and deliver” – thing is they don’t. How often is a construction project late and over budget? And unlike in software when you construction project goes wrong people get killed.

I used to think that the software industry took wrong turning somewhere about 1970. It decided to follow big Methodologies and project planning. I’m starting to wonder if the whole world took a wrong turn.

As I said last time I’ve been flying a lot, and that’s given me time to read. The book that I’ve been reading most is “Story Telling in Organizations: Why Storytelling is transforming 21st century organizations and management” by Larry Prusak, John Seely Brown, Stephen Denning and Katalina Groh.

Prusak is best know for his work on Knowledge Management and this is how he came to story telling. I’ve been reading John Seely Brown for a few years now and I highly recommend any of his writing. Stephen Denning I came across a couple of years ago in his “The Springboard” which is also about story telling in organizations. Katalina Groh is a film market who is new to me.

So, picking up from where I left off last time, according to Larry Prusak, story telling is what Louis Gerstner did when he took over IBM, Prusak goes on to suggests that this is what many leader actually do. They tells stories: how the company has failed, how they are going to fix it, what the new company will look like.

Go back to what I said last time about moving house and the need to take uncertainty out of the future. We don’t really want to move house, we like it where we are, only when we can see the story of our new lives, in our new house does the future look less scary. Only then can we start to think about letting go of our past.

Groh makes this point, how we need to let go of our past, let go of control so we can experience the future. Its something I’ve written about before (see the Need to Unlearn) but Groh weaves it in with story telling.

Now to pick up one of my regular themes: Patterns.

I think there is a link between Patterns (Alexander, Coplien, Vlissides, PLoPs, etc.) and stories. I’ve been pointing this out to anyone who will listen for a while now, and I’ve been basing this on what Denning wrote in “The Springboard” but having read “Storytelling in Organizations” I’m more convinced than every.

I intend to write more about his in future – probably in the prelude to some pattern paper, most likely for EuroPLoP 2006 but I’ll preview my reasoning here.

Patterns are really stories. If you look at the work of Alexander, Rising and even my own recent stuff you find that the patterns start with a short example – actually a story. This serves to set the scene. Prepares the reader. Then the pattern goes on to explore this subject more completely, analysing it, extracting the forces and context, describing the problem and how it was solved. Then they describe what happened afterward, maybe by revisiting the story or by telling some more.

My patterns still have an explicit formalism. As much as I’d like you to be able to read them without the section signposts I’m not a good enough writer. Also, I like the way the section heading tell you what the pattern is doing. Alexander, Rising and others are more experienced writers who write in a more prose like style.
If you read the work of Dick Gabriel he talks of patterns and poetry – poetry is just special form of story telling.

Both Patterns and Stories are about communicating knowledge. They communicate not just information but the context in which it was used and the action that took place around it. Anyone familiar with my writings and presentations knows I think knowledge must involve action. In the case of stories and patterns there is action embedded. Neither of them is happy to say “75% of successful companies segment their market” but both of them would say “By segmenting their market SuperShopper was able to better serve their cost conscious customers and quality conscious customers” – and both add that research shows this is common for 75% of all firms as an after thought.

Both Patterns and Stories are about change. Patterns show how forces are resolved and brought into balance, stories show how a problem was overcome

In both mediums less is more, there is a value to brevity. This allows the message to be communicated quickly and for the reader to see themselves in the story. OK, for patterns I’m going out on a limb a bit by saying this. Many people want patterns to include all the relevant information but I increasingly think brevity is an asset.
Good patterns and good stories pull the reader in, the reader can imagine themselves there. That’s why good patterns aren’t news, they name and explore something you already know.

Both are rooted in practice. John Seely-Brown and Stephen Denning make this point and it is critical to pattern writing where the “rule of three examples” is used a test. As such both are less concerned with original ideas and more concerned with what people do.

Good stories should stimulate your own thought processes and stories. In this way the story and the pattern are part of a gift culture. This is obvious to anyone who has ever taken part in a PLoP conference.

Something else which is less obvious. Patterns are of the greatest benefit to the writer. I’ve only come to realise this recently but my friend Klaus Marquardt tells me he’s been arguing this for a while so I’ve probably picked it up from him.

How does this fit with stories? Several of the writers in this book make the point that the most effective stories are the ones which connect with the listener. The listener can associate with the story and see themselves there; perhaps the story connects with something that happened to them or their family, perhaps the story tells them about something they would like to happy, perhaphs it describes their house, their software or their company.

This is why less is more. Too much detail in a story – or a pattern – makes it too specific. It ceases to be a story or a pattern and instead becomes a description of something that happened. Put it another way: it becomes just information “We went there, took a left, went there, drove a few miles” and in so doing looses the capacity to communicate actions.

Now one place where maybe the story and the pattern parallel fails is the element of story telling. Stephen Denning makes the point that it is the telling of the story that makes it powerful, not the content. I’ve yet to work out where this fits in with patterns but one explanation is that patterns are too focused on the story not the telling. And that might be why so few people actually read and use patterns.

As I say, don’t take that as truth, I’m still thinking that one through.

Bottom line: I’m increasingly conviced patterns are a form of story telling, the authors of this new books would learn a lot from getting to know the patterns community.

It happened in an unexpected way – I won’t go into the details but about 6-8 weeks ago I had an opportunity to move from the development side of things to the product side of things.

Has taken me a while to get my head around it all – I still am in fact. I spoke to a couple of the product managers here to get a better idea of what I should be doing but it wasn’t until I spoke to my long time friend Richard Hall that I really made progress on understanding what I was doing.

Richard’s been a Product Manager for many years, when I decided to do an MBA a couple of years he said:
“You’ll become a Product Manager, all MBAs become Product Manager!”
And I said:
“No I won’t! I’ll still be a developer.”

Well, I got my MBA and I stayed a developer. Now he’s been proved right, for a while I didn’t want to admit it to him – silly of me I know. I spoke to him at the weekend and yes he laughed when I reminded him what he said – note, I had to remind him, he’d forgotten.

I picked his brains a bit and I got some good information. In particular he pointed me at the Silicon Valley Product Group (http://www.svproduct.com.) They have some really good papers on their website, I recommend them to any new (or existing) PMs.

And this reminded me of something else. When I went to Silicon Valley I discovered all these Product Managers. Not marketing people, but people concerned with what should be in the product.

In the UK you never meet a Product Manager. You meet lots of “Business Analysts” but they aren’t the same. Over time I came to appreciate their role and I saw that the existence of this role, and good people to fill it, was one of the differentiating factors in the Valley.

Now I’m working for a company in London which is doing well, and guess what? Unlike most British companies they actually have Product Managers. Actually, Richard is back in the UK too and is a Product Manager for another successful British technology company. So maybe the idea is spreading.

I think I’m going to like being a Product Manager.

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.

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.

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.