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.

Categories Uncategorised

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.

Categories Uncategorised

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).

Categories Uncategorised

Yes I Blog – second Blog entry in one day

Maybe it’s odd that I’m writing a second Blog entry in one day – I’ve just finished the first! – but I have something else to say.

I’m just in the process of updating my website to refer to my Blog, which means I have to take down a page that said:

  • “Strange but true. OK maybe not strange to you but some people have asked me if I keep a Blog and I say No. I then go home, think about it and decide it would be a good idea but I still don’t do it. Why not?”

Well, as you can see I do now. So I should answer the two reason’s I gave for not Blogging:

  • “Firstly I keep a work diary, by keeping it closed I can think more freely. I think it was Dag Hammarskjold (second secretary general of the UN) who advocated “open agreements arrived at by secret means”; (In contrast to Wood Wilson who called for “open agreements openly arrived at”.) His logic was that sometimes you needed to change your position, and this was easier done in secret. I feel the same way.”

Well, maybe I’m making a rod for my own back and I’ll regret it later. For the moment I’d like to try Blogging, lets see what happens.

  • “Secondly, my writing is too poor to keep a Blog. I do publish – on this website and elsewhere – a lot of writing. But this has usually been much edited and changed before it sees the light of day. This allows me to exercise my thoughts and get them into clear(er) English.”

In writing this Blog I’m going to attempt to address this problem. Hopefully, I can keep my ideas to “bite sized chunks” which don’t need much editing. Secondly, I beg the readers forgiveness.

Lets see what happens.

Categories Uncategorised

Flexibility, design and process

Software is, in theory, infinitely flexible. I can take the software from my toaster and, with enough modification, get it to run a nuclear power station. OK, I’d have to be pretty odd to want to do this, and one could argue whether it is the same software (does it pass the Mary Rose test?*) but you get my point.

(*The Mary Rose Test, the Mary Rose, is a wooden battleship from Henry VIII’s navy that is preserved in Portsmouth. Imagine I decide to renovate the ship, so every day I replace one of the aging planks of wood with an identical replacement. Now, further imagine that I use the planks I remove to build a copy of the Mary Rose. When I am finished which is the original? And at one point, if any, did it change?)

Much of software design is concerned with removing your flexibility: encapsulation, data hiding, cohesion. Sometimes you actually improve things by removing the option. (Less is more.)

The same is true in development processes. Often a company cries, “We need a flexible development process” because… we need to respond to anything a customer can throw at us, all our projects are different, etc. But I wonder how many of the organizations that say this actually do vary their process? In my experience companies like to say this but the only real variation that occurs is the number of people on the project. The actual project process is left vague and ill defined “for flexibility.”

If there really is no similarity in the projects that organizations do then I wonder if the organization really exists for a particular reason. What is the core competency if no two projects are the like? Far more likely there is similarity in some way.

So, what we need is to cut off some options to ourselves. I’m not saying we need to document our process – heaven forbid! Nor am I saying that we need to call in process experts to advice us on how to do the project. What I’m saying is we need some kind of process base line we can talk about, some reference point. For if we can’t talk about it we can’t describe it and can’t modify it. Within that we need to give ourselves some constraint, leaving all our options open makes for too much uncertainty.

With all that said its important to note that process must come from the bottom up. It is for the people who live and breath the process to decide what they are doing. That doesn’t mean they can’t be influenced in their decisions, nor does it mean they can’t be lead or challenged to do better. It may just boil down to showing them that things can be different and providing them with the tools and options to do it differently.

And when they find a better way of doing things the people above them should use their leadership to support it, and to help others see the benefits and change too.

The worst thing we can do is to just assume that tomorrow will be a repeat of today. We should ask teams to do better, to change, to improve but we should also give ourselves boundaries and rules to work within. And we should, from time to time, question those boundaries and rules.

Categories Uncategorised

Blog entry 1: What do I hope to achieve by Blogging?

As some people know I’ve not been particularly keen on blogging, so, since this is a blog, indeed my blog, that raises the question: Why?

In a future entry I’ll write about why I don’t like the word why but for now lets rewrite the question: What do I hope to achieve by writing a blog?

Well, I first got thinking about blogging about 18 months ago when I was at XTC (Extreme Tuesday Club) when Chris Matts asked “Do you blog?”

So, I’ve spent 18 months thinking about this and now I have a need. For about 5 or 6 years now I’ve been writing magazine pieces. Mainly these have appeared in ACCU Overload. They started with technical pieces and moved through an enquiry phase and into a research based new paradigm phase (influenced by my MBA course). Lately have become more opinion pieces.

After six years its time I tried something new, a forum that is more opinion based may just be what I’m looking for.

Next I’m quite taken with the idea of personal journals, or diaries if you prefer, or learning diaries if you want to give them a longer title. My interest in these was started when I kept one as part of my MBA course. Since then I’ve kept a professional diary quite regularly. I use it as a sense making and thinking mechanism in work.

I’ve always said that the advantage of a private diary over a public blog is that I can say things privately that I can’t say publicly, e.g. my boss is ??? However, I’ve also noticed a tendency in my own diary to sometimes become a frustration vent that can be less than constructive. So, this blog is an experiment: What advantages does a public blog have? Well, I’m about to find out.

(I suppose a legitimate question is: what makes me think that anyone would want to read my ramblings? Well my website is now taking over 10,000 hits a month so maybe some people are interested in my views.)

So now I blog. This is Entry One.

What is this blog to be about?

I’ve been politically active in the past but I’m not any more so I don’t think this will be a political blog.

There will be lots of software development stuff in here, that’s my background, although its something I’m trying to get away from – I’ll write another entry about this and identity sometime. When I write about software development I’ll probably be writing about Agile development and Lean software, I’m a big fan of both of these.

There will be some business stuff – I’m interested in business so I’ll pull that in.

Now there is an intersection here. Two in fact.

The first is Change. This is the real problem that both software developers and businesses face. How do I change my development team to Agile practices? How do my customers need to change? How must my business change?

Second, there will be a lot of stuff about Patterns. I came to patterns through software development (you know, Gang-of-four stuff) but my current interest is in applying pattern techniques to the business domain. When I say “business patterns” I don’t mean the kind of “IT business patterns” that some people propose as “business patterns” – I mean IT free patterns of business strategy, operations, etc. Take a look at my business patterns page if you want to know more.

There you have it, another blog is born.


Categories Uncategorised