Sunday, July 23, 2006

Book review: Thinking beyond lean (Cusumano & Nobeoka)

I originally read Thinking Beyond Lean (1998) over four years ago, it was good at the time and its still good. A few weeks ago I picked up the book to check something and decided it was worth a re-read. Four years ago I didn’t know as much as I do now about lean production and lean product development so I thought it would be worth another look.

The book is a study of how car companies develop their products, and specifically, how they reuse the designs to product additional products, e.g. the Ford Mondeo in Europe is the Ford Contura in America and a Jaguar something in both places. Of course, as you might guess from the title Toyota is the pace setter in this field as in so much else.

I did write about the book after my first reading and still agree with what I said then, there is good advice here we can apply to software development.

The book is interesting for two reasons. First it is an interesting insight into product development at some very companies. Second it looks at the subject of reuse in a context of multi-project management.

Make no mistake, the car industry has problems reusing its designs. Reuse is difficult. The overriding lesson is: reuse doesn’t just happen, you have to arrange for it to happen.

Cusumano and Nokeoka do identify four models of reuse, or rather four models of design, three of which are reuse and I think its worth naming them here:

  • New build: design something new from the start, even if you could reuse something there are good reasons why you might do this.
  • Concurrent: two or more projects running concurrently developing new products, usually one is the lead project
  • Sequential: design something new, leave it alone for a while then try to reuse it for a new product.
  • Design modification: design something new, leave it alone for a bit then come back and tweak the design for a new version.

Four years ago I thought these models were useful in describing software development and I still do. However, the software industry doesn’t think like that. We have four models of our own:

  • Framework: we create a project that has no objective but to create a platform for others to reuse. Usually these projects are expensive and often they fail.
  • Reuse will just happen: made famous by the OO movement, the idea is that if programmers write “objects” (later components, now SOA components) then somehow they will be usable by others.
  • Cut-and-paste: probably the most widely used; our own version of design modification.
  • Packaged: we buy something someone else has written and work with it through an API.

I think only the last of these can really be claim to be a success.

There are lots of reasons why a reuse attempt can fail but mostly they boil down to organization. So, to make reuse happen you need to get the organization right - we’re back to Conway’s Law!

But there are other reasons, e.g. accounting. If project B is six months behind A and reuses their designs then who pays the bill, A or B?

And reuse may not always be a good thing. If you are competing on innovation then continually reusing your existing products may stop you creating innovations. It may also stop you from producing distinctive products - one of the problems Volkswagen had when it got very aggressive about platform sharing.

Yet another problem, not mentioned in the book, is your product life cycle: if all your products use they same platform then they will all age at the same pace and will all need replacing at the same time. So, just when your cash flow is low (because all your products are old) you will need to spend a lot replacing them.

I think the main difference in reading the book four years ago and today is my own scepticism about reuse. Four years ago I still believed we in the software industry could do it, all we needed was the right approach. Now I’m not sure. I think the level of complexity in software is so great trying to product something for reuse isn’t worth the effort in most cases.

That said, if the software industry is to make any headway here we need to take on the issues and lessons described in Thinking Beyond Lean .

Thursday, July 20, 2006

Skills shortage in India

Anyone who believes that all IT and technology jobs in Europe and America are doomed to move to India and China should make sure they read today’s FT. According to this report India may graduate 3 million engineers a year but only 25% are suitable for the IT industry and then only 10% are employable. Staff churn is high and good staff are able to command high salaries - so eroding the price advantage.

Meanwhile, China has a shortage of managers and has to import people from abroad.

I’ve mentioned this point before, in December last year and I still stand by it. I really want to see India (and China) develop, and I don’t have much time for the doom merchants who think IT in the west is doomed, just, I don’t think the hype matches the facts.

On the other hand, the UK could be its own worst enemy on this. According to a recent report the UK is not training enough IT people. And part of the problem is the “all our jobs are going to India" hype!

The part I find most worrying is not the idea that big British firms won’t be able to find IT staff, I think they will. Big existing firms will be able to train their own people, import staff or send work overseas. But, more and more innovation has an IT (specifically software) element and if we don’t have the software engineers available these innovations aren’t going to go anywhere.

In the short run this is probably good new for me and others in the IT industry today. Jobs will remain plentiful. In the longer run, if it remains difficult to hire staff firms will just give up and find other ways of accomplishing their objectives without using any IT staff in the UK.

Friday, July 14, 2006

LinkedIn: good thing? Bad thing?

I’ve got an account on LinkedIn, and I’ve got a whole bunch of connections. If you don’t know LinkedIn it is a social network site with a work focus - believe the hype and you’ll find your next job through it. Once you’ve signed up you can add your “connections” and see who links to who, kind of. (I'm also on OpenBC but I've not spent so much time developing my profile and connections there.)

Based on the old theory that you find jobs and opportunities through who-you-know and who-knows-you then this should be a great success. In reality I don’t think it is ever going to substitute for real networking - and real networking is something I should do more of but is so time consuming.

Yes I’ve had a couple of enquiries through LinkedIn, more often to do with whether I can help someone else rather than if they can help me. There are jobs listed but as usual they are mostly fronted by recruiters/agents so they are as useless as any others.

If your interested here is my link
View allan kelly's profile on LinkedIn

So, why do I play with it? Why do I keep adding contacts? In part, despite my rational above I still imagine it could put me in contact with someone useful.

Part of it is also slightly narcissistic - my network is bigger than your network.

Some of it is also to do with tracking people, although I suppose I should use Plaxo for that. It is supposed to be an online address book but allowing you to update people’s contacts books automatically when you change address. Plaxo’s never really grabbed my interest, and for a while it was Microsoft centric so it wouldn’t interface to my Thunderbird mail.

Also, I don't know if LinkedIn (and similar) will change our world but they might. I would like to understand how this stuff works and the consequences so I think its worth using . Just the same reason as I blog, to understand this stuff it helps to be involved with it.

But I think most of my LinkedIn interest is down right curiosity: Who connects with who? Who else is out there? What are these people doing?

What’s interesting is that something has changed recently. Not with LinkedIn but in people’s perception of this site. I don’t use it much but every so often I invite a bunch of people to connect. People who are already on LinkedIn usually say “Yes” quickly, those who aren’t might join but most just let it pass, I respect that and don’t bug them.

But, last time I sent out some invites, two months ago I think, people started to say: “Why are you asking me?” One friend at Microsoft told me it’s against company policy. Other people queried the nature of the system. I’ve just done another round of invites and I’ve got one or two similar responses. Is this some kind of mock-friendship? Asking people you don’t know that well to “connect” to you?

Could it be that LinkedIn is maxed out? Those who will join have joined, those who haven’t won’t. Are people fed up with social-networking? Or just more protective of their privacy?

Where is the line between people you know and will recommend to others and people you won’t? LinkedIn allows you to “endorse” other people but what happens when you don’t feel you can endorse someone? You risk upsetting them, a new and novel way to loose friends.

So far LinkedIn has been a bit of fun but it raising more and more questions for me.

Maybe thats just the engineer in me, engineers don't like networking; asking someone for a job is embarrassing, little do they know this is how the rest of the business world works.

Wednesday, July 12, 2006

Post EuroPLoP

I was at EuroPLoP in Bavaria most of last week. I returned mentally fired up with lots of ideas and new thoughts but physically shattered - too many late nights and beer. That makes it sound unhealthy but EuroPLoP is kind of healthy for me because I go lake swimming and take lots of saunas.

My paper, Patters for Technology Companies was reviewed in a workshop were I got a lot of very positive comments. The main thing is I need to split this one paper into two, one with the pattern theory and one patterns. I knew I should do this before hand but for some reason I didn’t....

I’ve been thinking that this would draw a line under my business patterns but right now I’m not sure. Part of me feels I’ve taken it about as far as I can, other people need to continue the work but there are still a couple of loose ends, a few requests for more patterns and theory from the workshop. Then this morning I spotted another pattern in the FT....

I also ran a focus group at EuroPLoP on the “Social Economic forces effecting software architecture”. This was a follow up to Conway’s Law group I ran last year - also with Lise Hvatum. This group wasn’t as deep as the previous one but I still got some insights and I’ll write them up before too long.

Finally at EuroPLoP I did face-to-face, one-on-one shepherding for a paper. This is the best type of shepherding. Practicalities mean that most shepherding is done over e-mail but when you get to do it face-to-face it is great. Its also were I see the greatest similarities to business coaching. Trouble is, you just don’t have enough time.

I had some really great conversations at EuroPLoP too. Particularly with James Noble (who an interesting take on Extreme Programming and problems with customer role, and his theories on PostModern Programing.).

The big surprise at the conference was the news from Indian. Some people from the patterns community have been out there and have been talking to Indian academics and practitioners about creating an Indian patterns conference. It seems likely that this will happen next year. To start with it won’t be a PLoP conference because a) it sounds like there are too many people and b) we first need to seed pattern writing.

That, in a nutshell, was EuroPLoP. Already I can’t wait till next year!

Monday, July 03, 2006

The last thing your people need is your strategy

Shortly after taking over IBM Lou Gerstner famously said “The last thing this company needs is a vision.” In an era when businesses men often seem to compete with each other for “vision” this was a brave thing to say – particularly for a technical company. I’ve been thinking about that comment for the last week.

Some years ago I was a developer at a small software company in South London. A few months after I joined they hired a Software Development Manager and charged him with sorting out developement. One of the games I’ve played with myself over the years since then is to ask myself: “In his position what would I do?” – in other words, what would my vision, my strategy be.

Last week two people I know were in the position of taking over a existing group, and my advice to them, well, the last thing you need for your new team is a vision. Sure you need your own strategy for taking over the team but beyond that I don’t think you should have a strategy.

I’d better explain myself...

If I come in with a fully formed vision for my new team, particularly if I spell it out in PowerPoint slides then it is my vision. This might be great if I’m trying to persuade investors to put money into my company, or trying to find like minded people to join me on the quest but when the people are in place it does nothing to get their buy in or address the real problem.

When you take over an existing team there are existing problems, organizational issues and a lot of history. If you come in with a vision you don’t take any of these into account. Sure, being new is a great position to be in, you have a fresh pair of eyes, you can see what others can’t because your not mired in the thick of it. But, your going to need these people to deliver something.

So, you walk into your new team, give them your PowerPoint, and talk them through what you are going to do. Your communicating your vision, your strategy, not theirs. Your task, as you have defined it, is to get your people to execute your strategy. You have to explain the strategy, they will interpret it, they may not have exactly the same interpretation as you, will you ask them to play it back? Or will you assume they got it? And if they don’t quite get it? Will you explain it again, and again until they do, or will you listen to their comments and change?

And once they do understand it your going to have to ensure they do it. You now have a policing action on your hands – make sure they do what you want. (Fortunately management have tool for this, its called MBO – Management By Objective.)

So I don’t think this is a good idea. I do have an alternative, I’ll outline it here, I’ve done most of it although, to be honest, I’ve never done it in the kind of systematic way I’m laying it out here – but then I’ve never laid it out like this before.

First don’t do anything. Listen, watch, learn. Look around you. See what people are doing, specifically see what your team are doing.

Second, expand this into a longer investigation phase. Talk to the team, talk to them one-on-one, talk to their customers, their suppliers and any other interested stakeholders. Find what all these people think of the team, what they should be doing, what they are doing, and how they are performing.

Do you observations for a while, at least a month but maybe as long as three months.

Next get the team together. Find out what they problems they see collectively. Find out what they see as their overall goal. Now this could be tricky, hopefully what they are doing and what they think they are doing matches up with what the other stakeholders think. If they don’t your going to have to correct that, but I think in the broadest sense there will be something everyone can agree on.

Now work back. Get the team to collectively agree on what they should be doing to solve the problems. Don’t tackle all the problems, if possible throw some of them away, i.e. just don’t do them if you don’t have to. Remember people can only focus on so many things so don’t pick too many.

Once the group is in agreement it will probably help to work with everyone one-on-one to find out how they see the team, the aims and their responsibilities.

At no stage should you attempt to tell them a vision or a strategy. Let them work it out. These are bright people – if they aren’t why are they working for you? They are going to be far more motivated when they create the strategy and vision then when you tell them it.

Don’t worry that what they come up with isn’t what you expected, what others want or were the company is heading. You can correct this over time if you find a problem, the trick is to expose your team to the wider picture, make them aware of what the corporate strategy is, give them examples of were it is working and then help your team work back to change what they do.

I honestly believe that when bright people know where everyone is heading and are allowed to work things out for themselves they will a) get it right, b) be very motivated to do it, c) you’ll get a better answer because you used more brains and got collective action.

This may mean eating some humble pie and you don’t get to play with PowerPoint. The point is: it is not your ideas that are important, it is the team’s ideas. It is not important for you to have a big idea, it is important for you to help the team, and the people in it have big ideas.

Do it right and you will get a strategy and vision, and it will be a truely shared vision.