Goal driven projects

With great timing (coinciding with my presentation to the BA conference and Jax London) the RQNG (Requirements Network Group) newsletter has published a little piece by me entitled:

Time for Goal Driven Projects.

Jax and BA conference presentations

Two new presentations from the two conferences I’ve been to this week.

From Jax London, Return to Requirements, this includes my “Agile 10 Step” requirements model. This is something I’m increasingly using and I’ll be writing (and presenting) more about in the near future.

And from the IIBA Business Analysis conference: Objective Agility - what does it take to be an Agile company?

Let me know what you think.

Moving pictures (of me!)

The next few weeks contains more conference for me than is healthy. While most of these are in London (Jax and IIBA BA conferences next week and Agile Business Conference the week after), or just up the road (Agile Cambridge), the interesting one is Agile Eastern Europe in Kiev the week after next.

Alexey and the other cunning minds in Kiev have decided to put the speakers on video. He’s my bit, explaining why you should come to my talk on the role of the Business Analyst.

This is going to be fun, while I’ve been to Russia and Moscow a few times, this will be the first time I’ve been to Ukraine and Kiev. Should be interesting. Interestna, as they say.

Unfortunately, in this blaze of conferences I’m not going to get to go to LESS 2010 (Lean Enterprise Software and Systems) in Helsinki. Which is a shame, not just because it promises to be an interesting conference but because I quite like Helsinki.

Now, can someone explain why there are so many conferences in the late-September early-October period?

For a bonus point, please explain why this period is also extremely busy with work for me: Agile coaching in Cornwall this week, several training days between the conferences and then back to Cornwall to give more coaching before the month ends?

Factory Physics and software factories

For the last few months I’ve been wading through Factory Physics. That might sound very negative but actually this book is highly recommended. The reason its difficult to read is nothing to do with the writing - which is actually quite easy going - but more down to the size and the maths. It is over 600 pages long and was originally written as a text book so can be a little tedious at times. Add in a bunch of mathematical proofs - essential - which even if you skim can be hard going and you get the picture.

That said its a great book to read with lots of important facts and implications. I have been reading it because I had some loose ends. The operations management module in my MBA all those years gave lots of suggestions and advice but left me wanting to know more. I finally found what I was looking for in Factory Physics. (Specifically queuing, variation and optimisation, but that will wait for another post.)

Now, to get back to the title of this blog post.

Every so often I come across managers who liken their software development teams to factories. They talk about the “software factory” or what happens “in the engine room.”

I think this analogy shows a fundamental misunderstanding of what goes on in software development groups. The idea that you can liken the development of software to a factory line process, with repeatable inputs, defined outputs, known processes, and repeatable activities just isn’t the case.

The difference shouldn’t need pointing but I will: as commonly understood the factory production line repeats again and again, it constructs one (or a limited number of) product(s) many times. There is little innovation or problem solving in the process (as commonly understood).

Whereas, software development constructs one product, for the first time ever; entailing a lot of innovation and problem solving in the first place; and never constructs it again. (After the first time a simply digital copy suffices.)

Now, having digested a lot of Factory Physics there is another reason I dislike this metaphor. Now I have a better understanding of the complications of making a factory efficient it is clear to me that making a factory effective is damn hard work.

Software managers who like to think of their development group as a “software factory” not only have no real understanding of the development process, neither do they have an understanding of how to organise and manage a real factory producing physical things.

In fact, one of the arguments in Factory Physics is that most factory managers don’t have such an understanding either. The authors argue, convincingly, that a lot of factory organisation and management is fashion, or fad driven and not based on a good understanding or science principles.

So I suppose in that way it is like managing software development.

Now before anyone rushes recommend, or attack, Fredrick Taylor and the ideas of Scientific Management the authors of Factory Physics are clear. Yes we should apply scientific thinking to management but, they point out, Fredrick Taylor was not scientific. His studies - from a scientific point of view - do not stand up. They are full of holes.

Just in case I’ve not been clear, lets repeat:

1. It is a mistake to think of software development as a factory line process.
2. Anyone who insists on using the metaphor should find out what is actually involved in running a factory.
3. There are insights from running a factory - to be found in Factory Physics - which apply to software development and many people will benefit from learning them. That doesn’t mean you should run your software development process like a factory though.

Japanese translation of Changing Software Development out now

The Japanese translation of “Changing Software Development: Learning to be Agile” is now out and you can buy it from Amazon Japan right now.

And just in case you don’t believe me here is the cover:

Agile is like...

In the software development world there are, broadly speaking, two groups of people: those who create the software (coders, testers, etc.) and those who manage the process (project managers, development managers, etc.). When discussing “Agile” I find that both sides think the problem is with the other.

To put it another way, if I’m talking to developers they think its managers who are the block to adopting more Agile techniques. But when I’m talking to managers they say its the developers who resist Agile.

This always reminds me of the old Philip Crosby quote:

“Quality has much in common with sex. Everyone is for it. (Under certain conditions of, course.) Everyone feels they understand it. (Even though they wouldn't want to explain it.) Everyone thinks execution is only a matter of following natural inclinations. (After all, we do get along somehow.) And, of course, most people feel that all problems in these areas are caused by other people.”

(OK, so this blog just got filtered out of lots of feeds and stopped by lots of firewalls but lets continue.)

Lets bring it up to date and make it Agile specific, substitute the work ‘Agile’ for ‘Quality’:

“Agile has much in common with sex. Everyone is for it. (Under certain conditions of, course.) Everyone feels they understand it. (Even though they wouldn't want to explain it.) Everyone thinks execution is only a matter of following natural inclinations. (After all, we do get along somehow.) And, of course, most people feel that all problems in these areas are caused by other people.”