McKinsey endourses Lean Software Development

I think most regular reader of this blog will know that when it comes to flavours of Agile Software Development I’m a strong supporter of Lean.  In fact I’ve argued before that “Agile” is a type of “Lean” – and I’ll argue it again in my book.

Now it appears that non-other than McKinseys consultancy has seen the sense in Lean software development – see this piece from their online journal (registration required).  Perhaps not surprisingly McKinsey’s also identifies “the change problem” as the challenge facing organizations which want to benefit from Lean Software Development.

As I said, its not a surprise, McKinsey’s make their money from advising companies on “change” so anything that creates fees is good for them.

Second it is not surprising because that is the problem I see! – hence the forthcoming book.  Naturally it goes without saying that I’m a lot cheaper than McKinseys!  (You know where I am.)

Introducing: Software Inside

I’m going through some notes from the ACCU conference in April and note I made after a conversation with someone – I forget who so sorry for not crediting you properly but I want to capture these thought….

We write software but we seldom write software for the sake of it.  We write software as part of something else.  Perhaps we write embedded software for a mobile phone, or we write an enterprise application for an account department – you get the idea.

The thing the software goes into – devices, process, etc.  – is itself a system.  A mobile phone is an electronics system, which is part of the cellular communications system; an accounts ledger is part of a business systems which tracks accounts.

Increasingly it is software that makes all of these systems possible.  You could do a lot of this in hardware, albeit specialist hardware but doing it in software is easier and cheaper.  Despite all the problems with writing a software application to manage a cell phone it is still a lot simpler, cheaper and faster than creating dedicated hardware.

Software allows you to use commodity hardware, commodity manufacturing and commodity infrastructure to create your product.  The truly unique bit rests in the software.  While you can copy the binary code or application for virtually nothing the creation of that software is unique.  Knowledge is embedded within the software.

Ultimately all software systems are simply part of a bigger system.  Systems have software inside.

This idea isn’t new.  I’ve said it myself before, what is new is the term: Software Inside. I guess we can credit Intel with providing the inspiration for the term – thanks Intel!

This term allows us to focus not so much on the software but on the greater system: the phone, the accounts system, the car, the washing machine, the moon-landing, etc.  The fact that we know about software can take us (the software developers) into many different and strange domains. 

And once in them we ourselves, the software experts, need to adapt and learn these new domains.  We need to be soft ourselves.  Software developers need to be cameleons.

Coming up for air - thoughts on writing

This blog has become noticeably less active lately.  Thats a sign that I've been very active myself.  What with Software Strategy, clients and the book to work on things have been busy and blogging has had to give.

Well a funny thing has happened.  The creative stuff is now done.  I'm now waiting on other people for things before I can continue.  It will be a month or two before the manuscript is completed and it won't be until January 2008 till you can buy a copy but now its all loose ends and minor editing.

The big gap is due to typesetting: it takes the best part of 6 months to get a book typeset.  Decidedly un-lean.)

Here are a few thoughts on what I have learned while I've been writing, and working with a publisher.

Diagram and pictures are a pain:

Problem 1: I have no artistic ability, some of my diagrams are OK but others I want redrawn.  I've now found someone to do this for me but I shouldn't have left this so late in the process.

Problem 2: I've used at least 4 different tools for drawing my diagrams so things are inconsistent.  I won't do this again.

Problem 3: Permissions.  Apart from the diagrams I've invented I have to get permission for everything else.  This seems silly to me because I can quote other authors without permission but I need permission for every diagram.  Probably isn't silly but it feels it.  This leads to more problems.

Firstly I've dropped illustration which aren't essential to reduce this problem.  This is a shame, I would like to break the text up some more but its practical.

Secondly some diagrams I can't source, I know I've seen them, and I can even find similar ones on the internet but I simply don't know where the original was.  Guess this is my own fault, I should have stayed on top of this.

Third few of my diagrams are exactly like they are in the original, so we have to make a judgement call on whether or not I need permission.

And fourth, if I get it wrong its me who gets sued and has to pay up.
All in all I've really increased my respect for authors who use a lot of images, and in particular Tom Peters Re-imagine! book.

I should have got more feedback earlier

I wish I'd shown more of the work to people earlier on and got more comments.  As it was most of the text was written by the time I started to show it to people and publishers.

Things you can't say

Turns out my publisher has a dispute with a well known CEO.  Therefore I can't mention him by name.  I think there was only one CEO I mention in the entire book and it turns out to be the one who is in dispute with my publisher.  What luck!

Its been an interesting exercise so far and I've learned a lot.  If I ever write another book there is a lot of things I will do differently.  For now I just want to get this one finished.

Post-Agile

I’ve written before about the Agile backlash I see coming.  But what I’ve been wondering is: what comes next?

One idea comes from James Noble and others who have suggested Post-Modern Programming.  I like the idea, it helps us understand the world better and it helps reposition our view of software development but it doesn’t tell us to do anything differently.  Post-Modern programming is more a philosophical understanding than a prescription.

Myself I’m a big proponent of Learning Based Software Development.  While this changes the emphasis on in software development I’ve yet to develop the ideas into a proposal for anything more than … well ideas.

Actually Learning Based Software Development (yes I just invented the term so lets invent the abbreviation LBSD) can be seen as a software specific version of Knowledge Based Product Development.  (Sorry, one of the entries with messed up formatting.)

This week I stumbled across a blog by Jason Gorman in which he discusses Post-Agile.  This is the first time I’ve heard the term and it seems I’m a little late to the party.  (Also a sign that I need to get to XTC a bit more regularly.)

It appears from what Jason says that opinion is divided on what “Post Agile” means yet but one possible explanation is: Being informed by the Agile/Lean movement but not following any prescribed methodology.  If that is what it means than good, it could be what I’m looking for.

But boy, Post-Agile is such a pretentious title.

 

Chance favours the prepared mind

First an apology: I’ve been very busy the last few weeks so I’ve not been blogging so much.  Naturally the creation and launch of Software Strategy has kept me busy and so has the company’s first client where I am far busier than I have been for a long time.  Add to this friends and family visiting from abroad and a few things have had to give….

Despite this I wanted to capture a quote I read this week which I think is very wise.

Last weeks Economist carried a profile of Gerald Grinstein, no I hadn’t heard of him before either.  Turns out he is the boss of Delta Airlines and what he said was this:

“Chance favours the prepared mind”

Which when you think about it is so true.  If you spend time thinking about where you are, what needs doing, what options are available and how things might unfold then when chance occurs you know whether to grasp it or not.

This is what worries me about being so very busy.  When I’m busy busy, and when see companies who are busy “doing stuff” I find so often that opportunities are missed and much of the stuff that gets done isn’t necessarily the right stuff.

For example: I often advise people to keep a work diary (or journal as some would call it.) Writing a journal is not really about recording what happened but thinking about what the implications are and what might happen next.  As such it is an act of reflection.  I find that when I get busy my journal (and blogging!) get squeezed, but when this happens I loose direction and although I’m busy I am less effective.

So this is a reminder that in the middle of this very busy period I still need to find time to think and prepare my mind.

Still, a big apology to all those people who are waiting for replies to e-mails, letters and such.  I’m hoping to break out of this cycle real soon now!

More Agile failure modes

A couple of weeks ago I raised the topic of How Agile Teams fail.  Well in recent conversations and observations I’ve been reminded of two more modes of Agile failure.  (Maybe reminded is the wrong word, maybe I could say I’ve spotted patterns, having one or two cases logged in my mind some more examples have focused my thoughts.)

One mode is where the developers simply state they are doing Agile.  We can call this Fake-Agile.  By simply stating they are Agile the team can then ignore documentation, avoid project management, and generally hack.

Frankly this isn’t Agile and it gives Agile a bad name.  I’m sure some examples of this are genuine attempts to become Agile but without real understanding or experience it is difficult.

The lesson here is: Simply stating you are Agile does not make you Agile.

I’ve also been reminded of this by recent TDD experiences.  A team I am working with has decided they want to start doing Test First Development.  However nobody has done it before and three weeks after voting to do this there is little sign of it being done.  This isn’t necessarily the team’s fault, although they want to do it they don’t really know how.

Think about it.  When I decided I wanted to drive a car I hard to learn to do it.  The same with skiing, wine tasting, and lots of academic subjects.  Sure I can pick some of it up by just doing it, and if I’m really clever, lucky or something else I might just succeed – like the way I first learned to programme. 

But generally, wanting to do something isn’t enough to actually do it.  You need help and advice.

My solution is to arrange some training and coaching for the team to help them start doing TDD.  Once we have that in place I expect things will change.

The second Agile failure mode is a bit more complicated.  I’ve seen it a couple of times now and I suspect its behind many Agile failure.  It happens like this…

A team are trying to adopt Agile, but they are also working with new technology.  The new technology could be technology new to the team, it could be technology new on the market (perhaps a beta release from a vendor) or it could be newly introduced technology.  Whatever, the team need to learn the technology.

So we have New Process and New Technology.

The first sign is exploding cards.  Teams write cards to represent the work they are doing to do at the start of the iteration but when the iteration gets underway it turns out the cards were vast understatements, both in terms of the time required and the work required.

(By the way, you need a card and board system to spot exploding cards, a software tool will simply hide the problem.)

In some cases progress is slow and few, if any cards are complete.  Perhaps people say things like “the card is 80% complete.”  In Agile iterations 80% counts as zero.  It is either done or it is not done.

In other cases, where teams recognise the extra work involved they may write more cards – hence the expression exploding cards.  Here developers start work on a card and realise/find there is far more work than they anticipated.  They break this down into several smaller tasks and the number of cards multiply.  In one case I saw developers took to folding the cards in half to fit them on the white board.

There are techniques for dealing with this situation.  Writing cards to represent the extra work is one, and you may need to add more frequent re-prioritisation.

Another technique is time-boxing: where developers have to guillotine their activities at some point and just go with the best they know so far.

And another is investigation: where an investigation task (probably time-boxed) is conducted before the actual work itself.  This can help split tasks down.

But, all these extra techniques for dealing with this situation are relatively advanced.  An advanced Agile team may simply take these problems in their stride.  For a team new to Agile this situation can be off putting, some people may take it as evidence that Agile does not work and it may even lead to project collapse.

Such projects were probably going to end up in a mess whether they are run Agile or not.  Because of the new technology the project is uncharted waters and the amount of learning and investigation needed is very high.  Therefore, even with traditional project management techniques the project will probably hit problems. 

Here the advantage of Agile is that you know the problems are happening much earlier and not just at the end.  But, if they team is new to Agile then you may loose the project and the Agile practices too.

The solution here...  Not sure I know one.  Some projects will always slip and even fail no matter how well you try to manage them. 

If there is a solution it lies in seeking help, involving people who have done these things before – either Agile or the technology.  Training and coaching can help too, whether in the new technology or new process.

What is the lesson from all of this?  Well if there is one it is simply that Agile Software Development may look easy but it isn’t.  Getting to be Agile is not simply a case of reading one book, it is a case of reading many books, talking to many people, working with experienced practitioners, having training, coaching and trying again when things don’t work out.

It isn’t easy being Agile.