Before we talk about whether agile practices provide any benefits toward risk mitigation or risk reduction, we really need to talk about the nature of risk in a software development project or process.
In any discussion of risks, there are any number of attritbutes by which we can classify or characterize risks, but in order to discuss mitigation, comparing two methodologies side by side, it makes sense to me to use the source or cause of the risk as the primary taxonomy. So I will describe these risk sources, and how agile might offer some advantage in dealing with risk.
Risk Source – Customer: Risks emanating from the customer inevtably involve scope, schedule and money. Sometimes it is that scope cannot be succinctly defined, or understood (requirements), sometimes it is that the buiness need changes more rapidly than expected due to external factors. Sometimes it is simply that the customer for whatever reason cannot make decisions.
Risk Source – Project team: Risks emanating from the project team inevitably involve productivity, skill, or leadership.
Risk Source – Organization: Risk emanating from the company or department producing the software, involve policy, resource management, coordination.
Risk Source – Technology/Environmental: Risk emanating from technical infrastructure or software development technology platform.
I have listed these in the order of frequency or likelihood based purely on my own experience. You can argue with me on the customer risk being the most frequent or likely, and that all scope, schedule and financial risk emanate from the customer, but it’s their scope, it’s their schedule, and it’s their money, and all decisions around those three elements are made by the customer.
So how do agile practices help mitigate risk emanating from the customer?
- By producing working software as early as possible, effectively shortening the feedback and delivery cycles, agile practices actually retire risk of unknown. When you produce working software capabilities that is ready to deploy, any risk of unknown that was attached to those capabilities is effectively retired. This includes risk of incomplete or incorrect requirements, or inaccurate translation between business and technical abstractions.
- By assuming a model that inherently drives down the cost of deferred decisions by eliminating pre-work, the risks of changes to schedule or budget emanating from the customers funding model or the customers market strategy are mitigated.
- By developing a model with a higher frequency of customer interaction, and reducing the scope (size and impact) of customer decisions (one milestone at a time) risks emanating from the customers own organizational decision making process, or internal committment model are mitigated.
- By establishing a value scoping paradigm with finer granularity, agile practices can reduce the scope of customer decisions, and the minimum time span of value delivery. More granular deliverables (stories?), make it easier for the customer to prioritize and sequence, ensuring that key value propositions are delivered as early as possible. Customers have a increased ability to discriminate essential scope from non-essential (apple polishing or lily guilding) scope, and so can defer the non-essential, until all of the essential scope is accepted.
Likewise, how do agile practices help mitigate risk emanating from the project team?
- By increasing the frequency of measurement (of productivity), agile practices give more timely feedback on the productivity from each skill to management, enabling adjustments as early as possible, rather than later.
- By establishing a regular cycle during the project of milestone retrospectives, the project team can adapt and adjust without the permission or engagement of outside leadership.
And for risks emanating from the delivery organization?
- By establishing cross-functional teams, and empowering the team to self-adjust their process, agile practices reduce policy oriented risks, as separate teams forming separate (and un-aligned) policies do not inherently collaborate or coordinate.
- By increasing the frequency of measurement, feedback to resource management is actionable sooner, mitigating risk emanating from resource management.
- Agile practices do not appear to provide distinct advantage in coordinating across delivery teams, or with service providers or vendors. But it also does not appear to disadvantage the team in any material way.
Finally, for risks emanating from the technical infrastructure or development platform?
- Agile practices do not appear to provide distinct advantage in dealing with hardware or software environments or development tools. But it also does not appear to disadvantage the team in any material way.
While I am not suggesting that traditional software development life cycle does not have risk management capabilities, only that they are different, and especially, do not retire risk as early. The basis of the traditional lifecycle is that risk of unknown is mitigated by doing ALL of the analysis and ALL of the design up front, in an effort to optimize the development, which is thought to be the risky portion. I think that modern software tools, paradigms and techniques have made the development less risky, which means that the risk is more likely that the requirements that we captured change over time, or simply were inadequate, and that we cannot retire that risk, until we put software capabilites in front of users. That is where agile practices take us – in exactly that way.
No Comments