Have We Finished Yet?
by Suzanne Robertson
In his keynote talk on dependable software at the 2005 Requirements engineering conference, Daniel Jackson’s urged us to “move away from infatuation with completeness”. This started me wondering – how often does anyone ever finish anything? In our everyday lives we say we have finished cleaning the bathroom, cooking the dinner, watering the garden, ironing the shirt, cleaning our teeth and a myriad of other things. But we don’t really mean that we have finished. Instead we mean that we do not have any more time to devote to that task and we have done the best that we can within that constraint. We accept the fact that we have limited time and that few of life’s daily tasks are finished to one hundred per cent perfection. Why should building software systems be any different?
A common complaint of software developers is that they don’t have enough time to finish a project. People in other professions for example engineers, architects, doctors, composers have the same problem but they have learnt to treat this as a normal constraint of their profession. They accept that:
- there will always be more to do than fits into the time available
- dynamics of the world mean that there will be changes that necessitate negotiation and replanning
- they need to be able to communicate their plans to their clients.
This perspective is about how software developers can use these principles to free themselves from “infatuation with completeness”.
| Attachment | Size |
|---|---|
| Have We Finished Yet.pdf | 183.88 KB |
Then fix the problem
Instead of just accepting that the contracts aren't ideal, that the business folks will self-impose a working strategy which may not be to the best advantage, that the lawyers/accountants/... aren't agile why don't you try to do something about it? Why not get involved with the contract setting strategy to begin with? Why not help the customer to understand that they have choices, that the fixed-price serial approach actually proves to be rather dysfunctional in practice.
Have you ever stepped back and asked why contracts are written the way that they're written? Is it because everyone involved is stupid? No. Is it because they're evil? No. It's because they don't realize they have better options. It's because they're trying to control risk the best way that they can.
In an agile environment the stakeholders have control over the scope, the budget, and the schedule. If they choose to step up to this challenge they are put in a much better position to manage risk than when they're doing fixed-bid serial with an "iron-clad" contract. As professionals I believe it's our responsibility to help business people understand the options that they have and to provide opportunities to enable them to do that.
- Scott
Scott W. Ambler
Practice Leader Agile Development, IBM
http://www-306.ibm.com/software/rational/bios/ambler.html