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.

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.

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.

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.