Thursday, September 29, 2011
Agile Cambridge: Cornwall Case Study online
The slides from my presentation at Agile Cambridge are now on my website: Agile County, Making Cornwall Agile (a case study)
Wednesday, September 28, 2011
Propogation delays
Propagation delays occur when there is a chain reaction, a sequence of reactions which take time to work down the chain. Think of a line of traffic waiting at the red light. The light turns green: the driver of the first car doesn’t move instantaneously, it takes a moment to registers the change, perhaps move the car into gear or take the hand break off, moment to press the accelerator and a moment for the engine to start moving the car.
The second car in the line might be watching the traffic light but they are also watching the car in front. Only when the break lights (if on) go off and the car begins to move can they move. And so on.
It takes time for the change to work its way down the line.
The same thing happens in integrated circuits, silicon chips. Even electrons take time to move. Reducing propagation delays is one of the ways chips get to go faster.
Once you know about propagation delays you start seeing them everywhere. Increasingly I not only see them in software development teams but I talk about them. But not everyone knows the concept, hence this blog.
Propagation delays occur when one team, or one developer, changes some code, or perhaps a database schema, and it takes time for all the other team members to update their code base and make any resulting changes.
Propagation delays occur when a company decides to start doing something, or stop doing something, and it takes time to work down the chain and to actually stop or start.
Propagation delays cause tension because different people, or teams, are working to different assumptions.
As with chips and traffic reducing propagation delays can speed things up.
The second car in the line might be watching the traffic light but they are also watching the car in front. Only when the break lights (if on) go off and the car begins to move can they move. And so on.
It takes time for the change to work its way down the line.
The same thing happens in integrated circuits, silicon chips. Even electrons take time to move. Reducing propagation delays is one of the ways chips get to go faster.
Once you know about propagation delays you start seeing them everywhere. Increasingly I not only see them in software development teams but I talk about them. But not everyone knows the concept, hence this blog.
Propagation delays occur when one team, or one developer, changes some code, or perhaps a database schema, and it takes time for all the other team members to update their code base and make any resulting changes.
Propagation delays occur when a company decides to start doing something, or stop doing something, and it takes time to work down the chain and to actually stop or start.
Propagation delays cause tension because different people, or teams, are working to different assumptions.
As with chips and traffic reducing propagation delays can speed things up.
Friday, September 23, 2011
Updates for Dialogue Sheets
Two dialogue sheet updates today.
Firstly I’ve created a mailing list to make announcements about dialogue sheets and for discussions about the use of dialogue sheets. This list is open to all and is hosted on Google groups (so you need a Google account).
Second, I’ve uploaded a new dialogue sheet. Another retrospective sheet this one is designed for use at the end of training course. I’ve used it at the end of several Software Strategy Agile training course and it has been well received. This sheet fulfils three purposes:
As usual, all this is at www.dialoguesheets.com.
Firstly I’ve created a mailing list to make announcements about dialogue sheets and for discussions about the use of dialogue sheets. This list is open to all and is hosted on Google groups (so you need a Google account).
Second, I’ve uploaded a new dialogue sheet. Another retrospective sheet this one is designed for use at the end of training course. I’ve used it at the end of several Software Strategy Agile training course and it has been well received. This sheet fulfils three purposes:
- It allows participants to experience a retrospective
- It provides for a retrospective on a training course at the end of the course
- It introduces dialogue sheets as a technique for retrospectives
As usual, all this is at www.dialoguesheets.com.
Cover for Business Patterns for Software
My new book, Business Patterns for Software Developers, now has a cover. Here it is:
The Business Patterns is available for pre-order, it will be published until early in the new year, I’m guessing February but it could move either way.
The Business Patterns is available for pre-order, it will be published until early in the new year, I’m guessing February but it could move either way.
Tuesday, September 20, 2011
Dialogue Sheets in Methods & Tools
The latest issue of Methods and Tool (Fall 2011) contains an article about Retrospective Dialogue Sheets. If you are new to Dialogue Sheets it will make a good introduction, and if you’ve used them already thenI’d love to hear your feedback.
Thursday, September 15, 2011
Dear client, the truth about software development
Dear Customer,
I think its time we in the IT industry came clean about how we charge you and why our bills are sometimes a bit higher than you might expect.
The truth is, when we start and IT project we just don’t know how much time and effort it will take. Consequently we don’t know how much it will cost. This isn’t a message you like to hear, particularly since you can be absolutely certain that you know what you want.
Here in lies another truth, I’ll try and put it as politely as I can, you are, after all, a customer and really I shouldn’t offend you. The thing is, you don’t know what you want. O yerh, you know in general (usually) but the devil is in the detail. And the more you try and give us the detail before hand the more likely it is to change. Each time you give us more detail you are offering more hostages to fortune.
Just to complicate matters the world in uncertain. Things change, companies go out of business, customer tastes change, fashion changes, Governments change and competitors do their damnedest to make life hard.
Yes it is true we can sometimes gold plate things. Yes some of our engineers like to do more than needed, and yes we have vested interest in getting things added so we can charge you more.
It is also true that you have add things: you quite legitimately think of things after we’ve begun, you quite naturally assume something is “in” when we assumed it was “out” and you also try and put one over too.
(Lets not even talk about bugs right now, it just complicates everything.)
Frankly, given all of this it is touching that you have so much faith in IT to deliver. But then, when IT does deliver, boy, does it deliver big. Look what it did for Bill Gates and Larry Page, or Jeff Bezos of Amazon, or FedEx, the list goes on.
So how do we ever talk you into this?
Well, we package up this unsightly mess and try and sell it to you. To do this we have to hide all this unpleasantness. We estimate how much time we think the work will take, actually these “estimates” are little better than guesses; human’s can’t estimate, most companies don’t have historical data and for those that do have data most of it is worse than useless.
So we get this guess, sorry estimate, and double it. Well maybe we double it, we might treble it, and when we see the new number, if it looks too much we might reduce it. And then we work out whether you will pay it.
That might sound awful but remember: we could have guessed higher in the first place.
Anyway, we don’t know which number is “right” but to make it acceptable to you we pretend it is certain and we take on the risk. We can only do this if the number is sufficiently padded. And even then we go wrong.
If the risk doesn’t happen then we get a fat profit, if the risk comes to pass we don’t get any profit, maybe we make a loss, and if its really bad you don’t get anything and we end up in court.
Really its all a question of risk: we try to present a clean, low-risk solution to your problem, and in doing so we take on a lot of risk. The alternative is that you take on the risk - and the mess - and do it yourself. (Unfortunately, another sad truth, is that as far as anyone can tell in-house IT is generally not as good as specialist providers so if you do decide to take on the risk you actually increase it.)
There really isn’t a nice simple solution to this, you have to work with us on this.
Thats the first part of the solution: you, the customer, have to be prepared to work with us, the supplier, and work with us again and again. This will reduce the risk.
The second part of the solution is: you need to be prepared to accept the mess and share the risk with us. If you aren’t prepared to take on any risk then we will take it on, and we will charge you for it, and since the risk is a lot we will charge you a lot.
Sharing the risk also has the effect of reducing the risk. Once you share the risk you have a motivation to reduce it.
If you are prepared to accept those two suggestions then lets press reset on our relationship and talk some more.
I think its time we in the IT industry came clean about how we charge you and why our bills are sometimes a bit higher than you might expect.
The truth is, when we start and IT project we just don’t know how much time and effort it will take. Consequently we don’t know how much it will cost. This isn’t a message you like to hear, particularly since you can be absolutely certain that you know what you want.
Here in lies another truth, I’ll try and put it as politely as I can, you are, after all, a customer and really I shouldn’t offend you. The thing is, you don’t know what you want. O yerh, you know in general (usually) but the devil is in the detail. And the more you try and give us the detail before hand the more likely it is to change. Each time you give us more detail you are offering more hostages to fortune.
Just to complicate matters the world in uncertain. Things change, companies go out of business, customer tastes change, fashion changes, Governments change and competitors do their damnedest to make life hard.
Yes it is true we can sometimes gold plate things. Yes some of our engineers like to do more than needed, and yes we have vested interest in getting things added so we can charge you more.
It is also true that you have add things: you quite legitimately think of things after we’ve begun, you quite naturally assume something is “in” when we assumed it was “out” and you also try and put one over too.
(Lets not even talk about bugs right now, it just complicates everything.)
Frankly, given all of this it is touching that you have so much faith in IT to deliver. But then, when IT does deliver, boy, does it deliver big. Look what it did for Bill Gates and Larry Page, or Jeff Bezos of Amazon, or FedEx, the list goes on.
So how do we ever talk you into this?
Well, we package up this unsightly mess and try and sell it to you. To do this we have to hide all this unpleasantness. We estimate how much time we think the work will take, actually these “estimates” are little better than guesses; human’s can’t estimate, most companies don’t have historical data and for those that do have data most of it is worse than useless.
So we get this guess, sorry estimate, and double it. Well maybe we double it, we might treble it, and when we see the new number, if it looks too much we might reduce it. And then we work out whether you will pay it.
That might sound awful but remember: we could have guessed higher in the first place.
Anyway, we don’t know which number is “right” but to make it acceptable to you we pretend it is certain and we take on the risk. We can only do this if the number is sufficiently padded. And even then we go wrong.
If the risk doesn’t happen then we get a fat profit, if the risk comes to pass we don’t get any profit, maybe we make a loss, and if its really bad you don’t get anything and we end up in court.
Really its all a question of risk: we try to present a clean, low-risk solution to your problem, and in doing so we take on a lot of risk. The alternative is that you take on the risk - and the mess - and do it yourself. (Unfortunately, another sad truth, is that as far as anyone can tell in-house IT is generally not as good as specialist providers so if you do decide to take on the risk you actually increase it.)
There really isn’t a nice simple solution to this, you have to work with us on this.
Thats the first part of the solution: you, the customer, have to be prepared to work with us, the supplier, and work with us again and again. This will reduce the risk.
The second part of the solution is: you need to be prepared to accept the mess and share the risk with us. If you aren’t prepared to take on any risk then we will take it on, and we will charge you for it, and since the risk is a lot we will charge you a lot.
Sharing the risk also has the effect of reducing the risk. Once you share the risk you have a motivation to reduce it.
If you are prepared to accept those two suggestions then lets press reset on our relationship and talk some more.
Tuesday, September 06, 2011
Business Patterns for Software Developers on Amazon for pre-order
Milestones in the writing on Business Patterns for Software Developers are coming think and fast this week.
Monday saw me reviewing book covers - the proposals look really good. Like many other patterns books the cover will feature architecturally significant buildings. Unlike most other patterns books these three are also a World Heritage site.
Now the book is listed on Amazon for pre-order - order now!
Which means, it also has an ISBN number - 978-1119999249 is Business Patterns for Software Developers - or if you like the old style number 1119999243 - spot the difference :)
(Amazon are listing the release date as May but I’m pretty confident we’ll better that, I also suspect the page count and price will be higher than currently listed.)
I’m pretty close to the final text, mainly images I need to fix now.
The keen eyed among my readers will notice the words “Agile” and “Lean” are absent from the book title. Indeed, the words are largely absent from the text. They are in there, somewhere, they are difficult to ignore, but this isn’t a book about Lean or Agile. Yes it contains lots of advice for Lean and Agile companies but it isn’t just about them.
Read my lips: Its not about Agile, its about Business. Thats all it has ever been about, really.
In the meantime, the business patterns which form the book are still available on my website and will continue to be so. The versions which will appear in the book are a lot more polished and professionally edited, plus the book will have a lot of other new material.
Monday saw me reviewing book covers - the proposals look really good. Like many other patterns books the cover will feature architecturally significant buildings. Unlike most other patterns books these three are also a World Heritage site.
Now the book is listed on Amazon for pre-order - order now!
Which means, it also has an ISBN number - 978-1119999249 is Business Patterns for Software Developers - or if you like the old style number 1119999243 - spot the difference :)
(Amazon are listing the release date as May but I’m pretty confident we’ll better that, I also suspect the page count and price will be higher than currently listed.)
I’m pretty close to the final text, mainly images I need to fix now.
The keen eyed among my readers will notice the words “Agile” and “Lean” are absent from the book title. Indeed, the words are largely absent from the text. They are in there, somewhere, they are difficult to ignore, but this isn’t a book about Lean or Agile. Yes it contains lots of advice for Lean and Agile companies but it isn’t just about them.
Read my lips: Its not about Agile, its about Business. Thats all it has ever been about, really.
In the meantime, the business patterns which form the book are still available on my website and will continue to be so. The versions which will appear in the book are a lot more polished and professionally edited, plus the book will have a lot of other new material.
Monday, September 05, 2011
'Objective Agility' & 'What is Agile' presentations online now
Last week I presented a revised version of “Objective Agility: What does it take to be an Agile company?” at Skills Matter in London. The presentation is now on my website (Objective Agility: What does it take to be an Agile company?) and Skills Matter have a PodCast available too (Objective Agility PodCast), so you can here my words too!
By the way, I will be teaching my Agile for Business Analysts course at Skills Matter in November if you like what you see and would like to see more of this.
I’ll be presenting Objective Agility again at Agile On The Beach in Falmouth in a couple of weeks. There are still a few tickets available for the conference but the early bird rate is about to expire.
As part of the build up to Agile On The Beach I did a webcast a few weeks ago entitled “What is Agile?”. The slides for this are also on my website (previous link) and the AgileOTB folks hope to have a podcast available soon.
By the way, I will be teaching my Agile for Business Analysts course at Skills Matter in November if you like what you see and would like to see more of this.
I’ll be presenting Objective Agility again at Agile On The Beach in Falmouth in a couple of weeks. There are still a few tickets available for the conference but the early bird rate is about to expire.
As part of the build up to Agile On The Beach I did a webcast a few weeks ago entitled “What is Agile?”. The slides for this are also on my website (previous link) and the AgileOTB folks hope to have a podcast available soon.
Subscribe to:
Posts (Atom)