I’ve just finished reading IT Success! (yes, there is an exclamation mark there) by Michael Gentle and I’m glad I did.
Before I write on, and before you read on, I should declare a connection. I share a publishing house (John Wiley & Sons) and and editor with this book so you might consider my opinions biased. However I had no idea this book was being written and produced at about the same time as mine. The first I knew about this books’ existence was a mention in the FT. That said I think it supports a lot of the arguments I make in Changing Software Development.
IT Success isn’t about Agile development but it does assume that you can deliver software in an iterative, Agile, fashion. With that assumption in place the author spends most of the book considering the business side of software development and project management. The book is really concerned with in-house and bespoke software projects so don’t bother with reading it if you work on the ISV side of things.
Although the book is not about Agile development I think it says a lot that can help organizations looking to improve their delivery by using Agile techniques. Most writing about Agile concerns itself with the software development process, some goes as far as project management but little goes further. This is where Gentle starts really, as such he fills in a lot of the missing bits about (strategically) managing iterative based development.
Gentle starts from the same assumption as I usually do: corporate IT, specifically software development, is fundamentally broken. He ascribes this to the use of the construction metaphor to IT project management. That is, the idea that one party can specify what they want and contract with another party (in house or external) to supply it. In this I completely agree with him for two reasons: first you can’t know what you want in advance because learning takes place during development what you want changes and usually increases.
Secondly: you can’t write down everything you want. Suppose for a moment you could, then you would have to write down a lot of detail, however this much information would overwhelm the person reading it. Either way you can’t communicate what yo want.
But back to Gentle...
He also identifies a mismatch in supply and demand: because most IT is funded centrally there is always more demand than there is supply. Think about it, if you are not paying for something, or you get it cheap, then you will want more. Cost acts as a demand regulator.
Gentle solution is two fold. Firstly to properly apportion costs to reduce demand and secondly to change the funding model for corporate IT projects. Instead of the current budget allocation process he suggests using a model more like ISVs use with the venture capital backers.
To do this each project produces a business case with defined benefits. This is funded for a short period, at the end of it the cost-benefit analysis is repeated - or rather it is continual - and if the benefit is still present more funding is allocated. In effect we move funding onto an iterative model as well as development.
Of course there is more to it than this but I’ll leave you to read the book. The book is short and written in a casual style so is quite readable. Personally I would have preferred a slightly more formal style, I don’t like the frequent citing of what could be casual observations or asides at conferences. I would have liked more research and cross-referencing but that may be personal preference and it would have detracted from readability.
I would also have likes more evidence that pieces of the solution suggested work. I’m sure Gentle has seen them work but too often they come across as ‘good ideas’ and it is not clear to what degree this has been tried and tested.
There are a couple of points I disagree with Gentle on too. To take one, his calls for the extensive use of time keeping by development staff as part of his billing policy. I find his description naive. For starters there is some evidence that time tracking by all staff - not just developers - is hopelessly inaccurate, on study I saw (sorry, reference lost) said it was 150% inaccurate.
More to the point if staff must keep track of their time it assumes they are working on more than one project at a time, this in itself is hugely inefficient. It is better to assign someone to a project for a week, a month, a year so they get to know it and they are not task switching. After that you can block book all their time to that one project and be done with it.
Anyway, I still recommend this book, especially to those people who are charged with commissioning and managing corporate IT projects. It is another contribution to changing the current, broken, model.
Before I write on, and before you read on, I should declare a connection. I share a publishing house (John Wiley & Sons) and and editor with this book so you might consider my opinions biased. However I had no idea this book was being written and produced at about the same time as mine. The first I knew about this books’ existence was a mention in the FT. That said I think it supports a lot of the arguments I make in Changing Software Development.
IT Success isn’t about Agile development but it does assume that you can deliver software in an iterative, Agile, fashion. With that assumption in place the author spends most of the book considering the business side of software development and project management. The book is really concerned with in-house and bespoke software projects so don’t bother with reading it if you work on the ISV side of things.
Although the book is not about Agile development I think it says a lot that can help organizations looking to improve their delivery by using Agile techniques. Most writing about Agile concerns itself with the software development process, some goes as far as project management but little goes further. This is where Gentle starts really, as such he fills in a lot of the missing bits about (strategically) managing iterative based development.
Gentle starts from the same assumption as I usually do: corporate IT, specifically software development, is fundamentally broken. He ascribes this to the use of the construction metaphor to IT project management. That is, the idea that one party can specify what they want and contract with another party (in house or external) to supply it. In this I completely agree with him for two reasons: first you can’t know what you want in advance because learning takes place during development what you want changes and usually increases.
Secondly: you can’t write down everything you want. Suppose for a moment you could, then you would have to write down a lot of detail, however this much information would overwhelm the person reading it. Either way you can’t communicate what yo want.
But back to Gentle...
He also identifies a mismatch in supply and demand: because most IT is funded centrally there is always more demand than there is supply. Think about it, if you are not paying for something, or you get it cheap, then you will want more. Cost acts as a demand regulator.
Gentle solution is two fold. Firstly to properly apportion costs to reduce demand and secondly to change the funding model for corporate IT projects. Instead of the current budget allocation process he suggests using a model more like ISVs use with the venture capital backers.
To do this each project produces a business case with defined benefits. This is funded for a short period, at the end of it the cost-benefit analysis is repeated - or rather it is continual - and if the benefit is still present more funding is allocated. In effect we move funding onto an iterative model as well as development.
Of course there is more to it than this but I’ll leave you to read the book. The book is short and written in a casual style so is quite readable. Personally I would have preferred a slightly more formal style, I don’t like the frequent citing of what could be casual observations or asides at conferences. I would have liked more research and cross-referencing but that may be personal preference and it would have detracted from readability.
I would also have likes more evidence that pieces of the solution suggested work. I’m sure Gentle has seen them work but too often they come across as ‘good ideas’ and it is not clear to what degree this has been tried and tested.
There are a couple of points I disagree with Gentle on too. To take one, his calls for the extensive use of time keeping by development staff as part of his billing policy. I find his description naive. For starters there is some evidence that time tracking by all staff - not just developers - is hopelessly inaccurate, on study I saw (sorry, reference lost) said it was 150% inaccurate.
More to the point if staff must keep track of their time it assumes they are working on more than one project at a time, this in itself is hugely inefficient. It is better to assign someone to a project for a week, a month, a year so they get to know it and they are not task switching. After that you can block book all their time to that one project and be done with it.
Anyway, I still recommend this book, especially to those people who are charged with commissioning and managing corporate IT projects. It is another contribution to changing the current, broken, model.
It's a Small World.
ReplyDeleteI've just finished it and I agree with your points. His background as a consultant does tend to slip through, and I'm not sure he really understands technical people (or house building), but it gives us a language to reframe the discussion from the usual "on-time, on-budget" mantra.
More case studies would have been really nice.