Risk Based Development

When we look at quite a few ideas that we use in agile, if we rub a little bit to get under the surface we find that the driving reason for why we want to behave in a particular way is down to risk – or more importantly managing risk. However before accepting that statement blindly we probably need to understand what is risk and how does it manifests itself. Then we can talk about some of the parts in our agile tool kit that enable us to manage or balance our risk

So let’s think about some risks

 

  • Risk inherent in creating complex solutions
  • Risk in not creating the customer’s needs  -a flip side or part of business value engineering – customer is asking for feature x, what is the risk to the business if we decide not to create it?
  • Risk in not creating the customer’s needs – because we haven’t properly understood their requirements
  • Risk in our development methods or tools
  • Risk represented by technical debt or software defects

There are many more…

So looking at some basic agile thought patterns we can quickly see that what we should be developing a culture in which risk is understood and managed. The managing of risk then defines what we do day to day. Let’s expand on some of those risks I noted.

  • Risk inherent in creating a complex solution – so we mitigate this risk by iteration, and test. Short iterations enable us to quickly reveal where the most complex parts of the system are and we can concentrate on conquering those or, if necessary make a better judged decision to change track.
  • Customer intimacy and also iteration enables us to reduce risk in delivering what the customer needs, demonstration of delivered vertical slices of product, that is prioritized to customer need enables very fast closure on the loop regarding ‘are we building the right thing?’. Good customer intimacy also enables the discussions around ‘this bit of function is very risky due to complexity’ or ‘this bit of function will probably not give good ROI’, these issues can be worked more effectively with the customer.
  •  Prioritising the highest risk items, whether they are risk due to complexity or risk due to customer need, enables us to ensure that those risks are worked and mitigated first, while lower priority items or risks are delivered later
  • Risks in development methods or tools, again are surfaced very clearly by short iterations and/or queue monitoring. For example a scrum team may quickly identify where a test framework has issues or kanban team may identify issues that are causing inconsistent flow.
  • Agile has an innate belief in quality of delivery – every item delivered is delivered customer ready, it’s reviewed, demoed and tested, ready to go. In Scrum this is driven by a combination of Definition of Done and Acceptance Criteria ((for old school engineers these can equate to the ‘did we build the thing right?’ – verification part of testing and to the ‘did we build the right thing?’ – validation part of testing). In our company Kanban teams also use a Definition of Done looking at whether they have completed appropriate activities.

Understanding risk is there, underlying much of what we do and how Agile methods can mitigate risk is an important part of achieving a good agile culture in your company. It still amazes how many people don’t consider this part of being agile, risk is inherent in creating complex systems, driving our development based around risk is a part of agile that many do without thinking about, it but for those that don’t, discussing risk driven development as part of agile can often create an ‘ah-ha’ moment.