Knowledge based product development

Today is my birthday, I always like where possible to take the day of work and do something enjoyable. This time I’m at home taking it easy, catching upon reading and writing. One of things is allowing to his finish reading my latest book. I normally have two or three books go at once, usually a novel, something serious and perhaps another book which I wish I had time to read.

I’ve commented here before that I have recently become a Product Manager – when I say recently it was almost six months ago now. Of course I want to be a good product manager so I’ve been looking around material to tell me how to be a good product manager, much to my surprise I find that there are very few books written on the subject of product management.

Indeed depending on your industry the role of Product Manager differs. In some industries the role of Product Manager is concerned with brand management and marketing, in other industries, like the software industry that I work in, Product Manager means somebody who determines what features the product needs, what work should be done on the product and who talks customers about what they want from the product.

So even when you find literature on product management you have to check to see which of the two types of product manager it is referring to. There is more literature on product management as a branding and marketing role then there is on product management as a development role.

In my search for product management books I came across “Product Development For The Lean Enterprise” by Michael N. Kennedy, 2003. This book describes what lean product development is, or rather what knowledge based product development is – as a book itself says knowledge based is a better description than the lean but lean is a better known term. The book is good in that it discusses not just product development but also the change process required to move from an existing product development setup to a lean, knowledge based, setup. What is unusual is that the book is written in the form of a story.

The story form makes it easy to read the book but makes it more difficult to understand what is speculation in what is hard evidence. This is compounded by the fact that the book does not give a great number of references. Indeed I was disappointed that the book fails to reference one or two books already in this field, for example “Thinking Beyond Lean” by Cusumano and Nobeoka, 1998 – another book I would recommend.

That aside, the book is worth reading and I recommended to anybody interested in the subject of lean production or product development.

So what does the book say? I won’t give a full precise but here is something to wet your appitite.

It points out that Toyota have a radically different product development strategy to just about any other organization. For example Toyota use setup-based engineering, so rather than design, say, one new gearbox for a car they may develop several new gearboxes and select the best one, or combine the best features of those developed into a new gearbox.

This may seem shocking to many project managers who see wasted resource but there is more to come. Toyota does not use traditional project planning scheduling techniques – no GNATT charts here. Instead they rely on hard deadlines, a fully engaged workforce and personal responsibility to meet meaningful dates.

The idea is that developing a new product is not just a one-off project it is part of a bigger learning exercise within the organization. The exercise generates new knowledge, this knowledge is itself an asset to the company, so the company is seeking to increase its stock of knowledge and experience. In effect developing a product is simply a learning exercise.

There is an interesting theory here the book does not discussed but I will. I don’t know of top my head who suggested this theory but I do know that I heard both Alistair Cockburn and Jim Coplien discuss the theory.

According to this theory there are two types of game, there are finite games, e.g. tennis, Cluedo, football, these are games which have a fixed stars and a fixed end, typically they are played to win at the end of the game there is a winner and there is a loser.

And then there are infinite games, these are games that never end, e.g. your career, life itself, in these games the objective is not to win but to survive, the games may be played in rounds and survival in one round allows you to play again.

In business, and specifically a product development organizations, you want to create a new product, you want to bring that product market and you want to be successful, in this way you’re playing a finite game and you’re playing to win. But at the same time you are playing in infinite game because there will be another product after this one and another round to the game. So in each round you play you have two objectives, the first is to win this round and the second is positioning yourself for the start of the next round.

So often when we develop new product, and specifically when we developed new software, we are concerned with the current project. We want to meet the current deadline so we do everything we can to meet the deadline but sometimes in doing that you are lessening your chances of winning the next round.

Software shows this perfectly, when you wish to meet the deadline is very easy to cut corners, to leave bugs unfixed, not to refactored code (so it becomes a mess) or too misuse the architecture in a way it should not be used.

The insight Kennedy, Toyota, Cockburn and Coplien offer is that is wrong to treat each round of the game in isolation, knowledge accumulated during one round is useful for the next round, indeed it is essential as the key to future competivity because in a knowledge industry, like IT and software development, knowledge is the greatest asset.

Unfortunately, many “best practice” project management techniques (or is it project managers themesleves?) fail to appreciate this.

Learning and change again

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.

VikingPLoP

Once again I’m sitting in the back of an Airbus writing. One of the nice things about flying – well travelling generally – is the long periods of just sitting around. Provided you can use them usefully they are great for reading, thinking and writing. But so often its difficult to use them usefully, on a long flight you just get fed up sitting there. And maybe I’m just trying to make a virtue out of an inconvenience.

I’ve been busy at work and home recently so I’ve had less time to blog. Now I have an hour to spare I’ll probably write a couple of entries – sorry dear reader, I don’t mean to overwhelm you. One of my own rules about blogging is to try and keep each entry to one idea – apart from small digressions – so I think the ideas in my mind just now mean two entries.

This week is VikingPLoP – the Scandinavian patterns conference. This one is novel in that it moves, the first VikingPLoP was in Denmark, then Norway, last year (my first) was Sweden and this year its Finland. Next year? Well, the obvious thing is to begin another circuit starting from Denmark but I’ve heard two other suggestions.
Suggestion one is to go to Russia, St Petersburg may not be famous for its Vikings but it is close by. I like this idea but I wonder how many participants we would get.

The second suggestion is to return to Denmark and stay there, I like this idea too. I think VikingPLoP would benefit from the continuity in location and organizers – different countries means different people organizers.

But the decision is not mine – and I’m glad its not. I am now on the organizing committee for EuroPLoP 2006 and ACCU 2006, two conference is enough for me!

For me there are two notable things about this PLoP and the patterns we’re reviewing. First VikingPLoP has a dedicated “Business patterns” stream. Business patterns have been around for a long time but they’ve been a real niche. Part of my personal objective has been to change this. In the past business patterns have usually been very IT related, I’ve tried to tackle this head on by going for the big issues in business – strategy, marketing, and operations.

The business patterns at VikingPLoP cover business theory (my Business strategy patterns for selling knowledge with products and services), business domains (Cecilia Haskins patterns for conference organizing), patterns for consumers (Susanne Hørby Christensen) and others. It feels like business patterns are coming of age.

And the second great thing about VikingPLoP this year is quality, the quality of the papers is very high and some of them have been a joy to read.

Pattern quality is important. The objective of a pattern conference is to improve quality, through shepherding, workshop review and authors own work. However, there is a feeling among some in the pattern community that quality has been slipping. This is one of the concerns of the EuroPLoP 2006 committee and we are looking at how we can improve this.

Change one dimension in the extreme

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.

Who owns the product?

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.

Pop goes another great business opportunity

I’ve mentioned before that I’m in the process of moving house. So yesterday’s Financial Times (10 September 2005) was very interesting.

The thing that really caught my eye was a story entitled Investors get chance to profit in property. A bank and an estate agent are planning to offer an investment product that will track the housing index.

At the moment, for the individual, the only way to get exposure to the property market is by buying property but that is not always what we want to do – it is expensive, time consuming and may not fit with our life style.

Now I’m not one of these people who considers property investing to be a good thing. The figures I’ve seen show that the stock markets out perform housing markets in the long run. However, we all need somewhere to live and once you add in the utility of owning a property then I think it makes financial sense.

But would I buy a second property and rent it out? No, its a lot of hassle and the returns are not actually that good. In fact, as far as I can see, the only real return is from rising property prices, if they are not increasing you loose. And don’t forget, they can, and do, fall.

In fact, its worse than that. What many people forget is that not only do property prices need to be increasing but they need to be increasing more than the next best investment – notwithstanding risk exposure. So, in fact, the stock market might expose you to more risk but the returns are better, or, a savings account or Government bond may offer better security at a return that is not a lot less.

Anyway, I didn’t mention this story to get into a debate on property investment – and please don’t take my advice, I’m not an expert!

No, I mention this story because Jonathon Sefton suggested this idea to me about 12-18 months ago. He’d done some research and decided he could buy a set of products that would create such an instrument but it wasn’t easy.

Then he suggested: would this be a viable business? And the suggestion: why don’t we do it?

Well we didn’t, and now someone else is. Once again I passed. Perhaps I need to set my sights higher. Maybe I’m too risk averse, or maybe I don’t know a good thing when I see it. One day I’ll get it right.

XP2 and the real problem in software development

I went to talk given by Rachel Davies last night. This was organised by the BCS SPA group who hold monthly sessions in London. Although I’m not a fan of the BCS (British Computer Society) the SPA group is quite interesting and active.

(As usual some of the most interesting conversations are held in the pub afterward so its always worth going for a pint.)

Rachel was talking about Kent Beck’s second edition of Extreme Programming Explained book. I have to admit that while I’ve had this book on my desk for several months I’ve not read it. Having seen Rachel’s very good presentation I have to say I’ll probably not read the book.

Its no secret that I’m not a fan of XP – or at least XP version 1. Don’t get me wrong, there is a lot of good stuff in there but I’ve never been happy with Kent’s “Do this, do everything I say or don’t call it XP”. I think every organization and team are different and the important thing to do is to create your own system that works for you.

So, while I’m a big fan of the Agile development movement I’m not fanatical about any of the methodologies. I view Agile as a collection of tools you can use to think about problems and devise solutions. Some of the tools can be used “out of the box” other need tailoring.

The best thing about the first edition of XP was that was a “call to arms” (as my friend Kevlin Henney says). The book describes an alternative way to live your life, an ideal, it rallied people and made them think “things can be different” – it offered an alternative identity, it said “developers are really important, don’t devalue coding.”

From what I hear about the second book its a bit of a kitchen sink. It doesn’t say no to anything, if it sounds like a good idea Kent’s included it. Its probably unfair to comment on a book I haven’t read so I won’t say any more.

If you are interested in XP, Agile or Lean development the best book you can read is Poppendieck and Poppendieck.

However, at the end of the evening I left with the same thoughts as I always have after discussing XP, Lean, Agile, software development process, etc. etc.

We know how to do it. There are plenty of books which tell us how, plenty of people who know the techniques, people who’ve don’t. Doing isn’t the hard bit.

The hard bit is: how do you change? How do you move from here to there.

This is the real problem and its hard. The “software development community thinkers” haven’t really addressed change.

This is also sad because IT is actually all about change. When you develop a piece of software and it gets installed you change the people who use it. You change the organization, you change the problem. In fact, the objective of introducing a new IT system is usually to introduce change. Nobody really wants to run SAP, they want to change their production department and SAP is merely the way to do that.

We often hear about software development failures – the figures differ but the message is usually the same “most software projects fail.” Truth is, most change initiatives fail, since software projects are about change is it really surprising that failure is so common?

Who are you? – identity and change

Identity has been much on my mind lately. Not identity as in “identity theft” – yes that is important but not what I’ve been thinking about. Nor internet identity as my friend John Merrells talks about it – XACML and all that jazz.

No, more identity in how we define ourselves and how that identity then defines us. I’ll give you a couple of examples.

As I’ve said before I’m moving house. This flat/apartment is me. I bought it eight years ago and although I’ve been away (2 years in California, 1 year in Nottingham) it is part of me and I am part of it. The daring red carpet in the lounge, the (slightly impractical) blue carpet in the bath room, the simple plain walls with modern art (Kandinski, Heron, Pollock, (Ellsworth) Kelly (no relation) since you ask) they are me. I defined the flat and the flat now defines me. Moving to another house I get the chance to redefine it but it also defines me, its got 3 bedrooms, a large kitchen – see.

And this applies at work too. I’m a software engineer by trade, what I do is write programs, design them too, perhaps get involved in process discussions or elements of project management. Testing? Maybe I leave that to others. And perhaps I want to leave project management to someone else.

A project manager I know always speaks to me about projects in terms of “risks” and “tasks to be done” – I once told him I was examining the strategy behind the project and his reply was something like “why are you doing the? It was determined by management months ago, all we have to do is execute.”

When we are young our identity is not yet framed: should I be fireman? an engineer? a policeman? And as we get older we can become rooted in that identity.

Much of what we do day to day is not rooted in the job title we hold, or even the role we are filling but it rests in who are. I was a software developer for about 10 years, no matter where I worked, what project I was doing, or what I was called I did more or less the same thing. My identity was intact wherever I was.

Perhaps this explains some of the problems I have now I’m a product manager. My identity is still largely a software developer. So when I’m wondering: “what should I be doing?” its not just the practical “what should I do in the next five minutes” I’m wrestling with its the (almost) metaphysical “who am I? what should I be doing in this identity?”

Changing employer doesn’t necessarily change your identity, you can be the same person just elsewhere. You have to do something more.

You can change your identity. I made a pretty good stab at it when I did my MBA. For a year you get to pretend your all sorts of other people: the head of GE, the head of IBM, a human resource manager, an entrepreneur, an academic…

When you choose to do an MBA your reaching for that new identity, if you believe the hype maybe you’ll be a McKinsey man at the end. And it is a new start in many ways, by the end of it you have an almost clean sheet, ready to start again. Maybe that’s why going back to what you did before seems like a failure to some people. But then, it is who you are.

So, identity has a role to play when your considering change. Think of all the coal miners who lost their jobs in the 1980s (in the UK). Their identity was coal-miner. Becoming a supermarket assistant, or an airport baggage handler was a big change. People don’t know what this strange new world holds for them – of course they are worried and scared – identity goes deep.

And he same thing happens in companies. Companies take on an identity and changing from that is hard. So it takes them time to recognise they are loosing money – think of General Motors – and it takes them time to get out of one industry and into anther – think of IBM, in retrospect the changes Gerstner made are obvious.

Where does this insight leave us? I don’t know, but when I look around me and wonder why people don’t change I often see identity, I’ll leave you with a few more examples:
– the software developer who continues to blame “managers” when he could change things himself
– the C++ programmer who can’t see any good in Java
– the support engineer who is continually busy
– the academic who bemoans the lack of industry interest in their work

I promise to return to this subject.

The final sustainable edge

I’ve finished reading “The Only Sustainable Edge” by Johns Hagel and Seely Brown. At the risk of boring my readers with a third entry on the subject of this book I think it deserves a wrap up – and a slight correction to some of my initial comments.
(See 20 August, and 18 August.)

The books central argument is that sustainable competitive advantage (to use a loaded term) is only achievable by companies that can adapt and change to take advantage of changing markets and environment.

I can agree with that central argument. In fact, I can imagine a lot of people agreeing with that statement. Problem is, it is incredibly difficult to do, far easier to find something that gives you and advantage now and try to guard that.

So how to the two Johns propose we do this?

When I started reading the book I thought one of the pillars of this was going to be the development of your employees. Helping your staff to learn, grow and change. Maybe I was guilty of reading what I wanted to read but I think the start of the book, and the epilogue do emphasis this idea. However, in the middle it gets lost.

The authors advocate the creation of “process networks” and “process orchestrators.” (Curiously, the word “orchestrator” is used a lot but doesn’t appear in the index, this makes me wonder if the book was rushed, or maybe is was just poor indexer.)

In a process network a variety of different companies come together to produce a product. Each is specialised in some aspect (e.g. design, manufacture, end-customers) and one company takes the lead in organizing all of these – the process orchestrator. Importantly, the orchestrator has a wide network of firms it operates with, for any one assignment it will choose which of its partners best fits the need and bring them together.

Li & Fung (of Honk Kong) are cited again and again as the canonical case of an open network, a company that maintains a network and works on behalf of its own clients. Nike and Cisco are examples of closed networks maintain networks for their own products.

This model works well for these companies but the authors then make the jump and claim that this will become the dominant model in the future. I’m not sure of this. I can believe that this model will work for some, there probably will be more companies working like this, but the dominant model? The way things “will be” ? I think not.

(I often find this is the case with books published by Harvard Business School Press. The authors (often management consultants) find some examples, say “look this works well for companies Z, Y and Z” and then jump to the conclusion: “this is how it will be for all companies, change now or die.” There is a singularity to the authors’ argument which isn’t the case. They show a model, it works yes, but does this mean the whole world will be like this one day? No.)

According to Hagel and Seely Brown the way to achieve these networks is through “loose coupling”. This takes a number of forms, and they openly admit they’ve stolen the term for the IT world. Given how much trouble software developers have actually implementing “loose coupling” (and the corresponding “high cohesion”) one wonders how much trouble business will have with it.

On the whole this is an interesting book. It takes a number of current trends to their extreme and shows what could happen to businesses. As such it may give you a new perspective on things. So should you read it? I’d say yes, its not very long (173 pages) so the cost of reading it is low.

One thing that will stick with me from the book, and is interesting as a stand alone subject is their discussion of offshore-outsourcing operations. According to the authors, it turns out that the advantages here are not only cost. Sure, you can save some money by moving your call centre or IT to India but there is another benefit.

In offshore environments you are likely to get better workers. Two reasons: first, the workers are more highly qualified; second, because this is a green-field site, and costs are lower, many of the “best practices” of management can be followed to help develop the workers. So, for example, lower wages mean a higher manager-to-worker ration so managers can spend more time helping the worker develop, e.g. feedback, coaching, etc. Consequently, the workers improve faster and the whole company will benefit.

One example of this benefit is apparently that “Most Indian outsourcing firms operate at [CMM] level 5 … while most internal departments in the US will likely operate at level 2 or 3.” (page 38.)

Now, switching back to more general comments about the book…

Unfortunately, I’ve never met any practicing software developer who believes CMM level 5 is either a good thing or good measure of success. In fact, most of the code-face people I’ve met who have experience of offshore software development believe it is pretty much a disaster both for their own jobs and technically.

For two authors well versed in IT I find their faith in CMM surprising. Likewise, they see the rise of SOA (Service Oriented Architecture) as a building block for their “process networks.” I think on both counts they’ve drunk too much Cool-Aid.