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 |
Agile breaks down, when the lawyers aren't agile!
Mike,
I think you brought it to the point.
I think an agile approach can solve some problems we have in the world, especially in a world of trust.
BUT: I have consulted for large companies that are challenged to integrate outsourcers, service providers, product companies. The product life cylce extends far beyond what agile methodologies consider. The contractual framework with these parties in this case dictates the process. If you have to establish a fixed price contract dictating functionality, cost and time - you need to "agree" it, trying to resolve dependecies over multiple organisations!
The cost to establish this contract is not low at all. Hence, you don't want to do this too frequently (here comes the agile lawyer!).
The world would look different if it was a time and material approach resulting in a different contractual framework allowing different processes!
So my point is simply that agile works for certain problems, ... very well. And I think we should adopt things that make a difference .. for the right problem. But I think we cannot let the agile approach redefine the problem to fit the solution.
In this case we will fail. That's lesson number one in the RE / BA camp, isn't it?
Best,
- Thomas