"If a project has no risks don't do it" - that's what Tom DeMarco and Timothy Lister state on the very first page of chapter one of "Waltzing with Bears", one of the better books written on risk management.
Initially this statement may seem counterintuitive but actually most techniques applied in Agile software development and its management are about controlling risk. Timeboxing? Reduce the risk of overengineering or overanalyzing. Test Driven Design/Development? Reduce the risk of untestable, tangled, unstructured software. Pair Programming? Reduce the risk of poor code quality and lost focus. Daily Standups? Reduce the risk of uncoordinated (or duplicated) work. And so on. On the other hand a different kind of risk is seldom mentioned: the risk of not reaching the project's goals!
If no one – not even the owner of the project – sees "not reaching the project goal" as a quantifiable risk, what does that mean? Primarily two ideas come to mind: either the project is not really important and nothing bad is going to happen if it doesn't succeed or no one even considers the possibility that the project might fail due to yet unknown reasons. Neither of these scenarios seems particularly appealing to me.
So the message from Tom DeMarco and Timothy Lister is twofold in my perception:
- Don't take on a project that doesn't matter to anyone. (i.e. where there is no risk in failure)
- Don't take on a project where there is no intention to address common risks (i.e. a project where good practices – like those from lean and agile software development are not even aspired)
Untill next time
Michael Mahlberg
P.S.: And yes, this is also a recommendation for the book "Waltzing with Bears: Managing Risk on Software Projects"
No comments:
Post a Comment