Learning About Risk Management at YOW! Conference 2012 | The ...

This year was my first attendance at the YOW! Conference, and I am very happy I was able to go. The conference was well-organised with great speakers and thought-provoking presentations.

Fascinating to me was that several themes recurred in different presentations?at?YOW!, with each speaker giving it a unique angle. Watching several presentations from different experts in this conference setting lent itself to a meta-analysis of these themes. One that I found particularly interesting is risk management for software projects; specifically, how development processes can help businesses manage the risks.

Embracing Uncertainty

Dan North?s presentation ?Embracing Uncertainty? went right to the core problem of taking risks: businesses ? or, more generally, people ? are afraid to take risks because of the impact that failure may have. There are many risks involved in software projects ? for example the risk of delivering the wrong software, the risk of being over time and over budget, or the risk of introducing a bug that breaks the software.

Not all risks are the same. Risks differ in their impact to the project; the consequences of failing ? i.e. the costs involved with the failure ? are different for each risk. Businesses may be willing to take on risks if the impact of those risks are low. Classifying risks according to their impact allows businesses to make conscious decisions on the risks they take.

Impact is not the only classification for risks. Risks should also be assessed according to their likelihood of occurrence. Risks that are highly unlikely to result in failure can be tolerated more easily that those with a greater likelihood. As with the impact classification, classifying risks according to their likelihood allows businesses to make conscious decisions on the risks they take.

Likelihood and impact together allow us to map a risk on a plane, with likelihood defining the X axis, and impact the Y axis. The two-dimensional plane is a more accurate model for the risks and gives businesses more ways to manage these risks.

Risk Map

The risk map changes with every decision the business makes, and the aim is to make decisions that minimise the risk involved in terms of impact, likelihood, or both.

Programmer Anarchy

One of the major decisions altering the risk map is the development methodology used. A waterfall methodology with its heavy structure will have different risks than an agile methodology that embraces flexibility.?The risk map shifts even more if we go beyond agile.

The topic of Fred George?s presentation was ?Programmer Anarchy?, a term he uses to describe the culture at Forward Internet Group, the company he works for.?Forward needed to gone beyond agile methods because of the uniqueness and complexity of their projects.

Agile methods loosen the process around software development to allow more flexibilty and faster results. Even though it is Software Development Process Light, there is still some process there: the team consisting of software developers, customer, and testers decide the best way to deliver the features wanted. There is some control over the direction of the project in the form of customer supervision and team decisions, and there is some structure in the form of stand-ups, Kanban boards, showcases and retrospectives.

Programmer Anarchy does away with any process around software development: no structure, no obligatory team decisions and no customer supervision. Every developer has full authority to pursue any solution he proposes to a problem. Developers can join forces and pursue a common solution, or each go separate ways if no consensus can be found.

At first glance it is not apparent why Programmer Anarchy should produce results. The reason Forward is using this approach is that the software projects Forward tackles are so complex and new that maximum creativity and freedom are needed to find a good solution. With every project Forward is entering uncharted territory, and agile methods are just not flexible enough for such uncharted territory.

Forwards projects are therefore very risky. Their strategy to deal with this risk is to embrace risk, but find out quickly what doesn?t work. Finding out quickly what doesn?t work is the key to reducing risk. The first thing Forward therefore does when starting a project is to develop a metric to determine the quality of a solution: they find out how to measure how good a solution is.

A simple example might be to find ad keywords to lead potential customers to a product. The metric would then be the rate of sales conversion. Once the metric has been established the solutions Forward comes up with can be compared, and bad ones can quickly be abandoned. The risk of failure in trying different solutions is therefore reduced.

Pushing Our Buttons: REA & Hooroo?s Journey to The Cloud

Forwards projects are so unique that they need maximum freedom to find a good solution. Most software projects are not in this area, and Forward?s risk management ideas can therefore not be applied easily. Peter Moran and Ben Hogan from Hooroo and REA talked about a different kind of risk-reduction: reliably delivering small changes using Continuous Delivery.

Their presentation was about implementing Continuous Delivery at REA and Hooroo. Continuous Delivery is the practice of being able to deploy to a production environment at any time. This is achieved by extending the use of a Continuous Integration server. ?Continuous Integration focuses on integration, compilation, and deployment of the code base on a separate build server with subsequent automated unit testing.?Continuous Delivery goes beyond the build server and allows promotion of artifacts through different stages all the way into the production environment with minimal manual overhead. ?Continuous Delivery is about the ability to easily and reliably push out code using automated push-button deployment and automated integration tests. Once code pushes can be done easily and reliably, releases can be done at any time.

The advantage of Continuous Delivery is the minimisation of the risk involved in deployment to Production. We reduce the risk of each deployment until there is virtually no risk at all. Two features are key to the management of risk: automation of deployment and delivery of small changes. Automation of deployment includes both automated integration testing and automated promotions to different environments. Automating these steps alone reduces the risk in deploying artefacts to production considerably.

Delivering small changes reduces the impact of deployment, because the more changes are deployed into production, the greater the risk is that something goes wrong. Less changes are therefore is less risky, so deploying small changes frequently only?leaves you with the risk that a small change may cause problems. Even though the likelihood that a change may break something goes up because of the increase in frequency of deployment, the impact of such an incident is greatly reduced. Continuous Delivery therefore is a strategy for risk management.

Conclusion

The three presentations looked at risk management from different angles, with different take-aways each:

• Classify risks according to impact and likelihood; make decisions to minimise impact, likelihood or both
• Define metric of success, measure early, and abandon bad solutions quickly
• Favour delivering small changes quickly and reliably

Together they give a set of guidelines applicable to a wide variety of situations.

Like this:

Be the first to like this.

Source: http://blog.shinetech.com/2012/12/03/learning-about-risk-management-at-yow-conference-2012/

Happy 4th of July 4th Of July Desserts fireworks fireworks 4th of July Andy Griffith joe johnson