You might be forgiven for thinking that those who provide Risk Management software must be cautious and plan out their product and their activities to the finest detail before setting out to develop quality product. In fact, I would argue that an agile approach to software development is the only way to fulfil client expectations in general and is perfectly aligned with a risk management culture in particular.
Agile software development is a way of thinking about the challenges you face and constantly adjusting your plan to best fit the reality of the situation, communicating updates to all of your stakeholders, and always allowing for negotiation. It is also about empowering the team to make commitments and accept responsibility for outcomes.
This is a kind of risk management.
Burn-down charts provide a visual representation of sprint completion.
The red line represents remaining effort required while the green line represents the completion rate of tasks in the sprint.
The development team defines its own risk appetite – how much work is sustainable for the team and what it can deliver. It can estimate the size of new features, the complexity, how best to work on each piece, and how to ensure that the work is complete (quality assurance) so that it adds value to the product. The project backlog contains a prioritised collection of activities that have been understood, elaborated, and estimated by the team and ordered by the product owner, so that the team commits to what it expects to deliver and what provides the best business value in each development cycle.
The team can also measure its own risk indicators – progress in fulfilling its commitments, activities or dependencies that are delayed or need to be re-assessed, or even the viability or usability of a new feature (through prototyping). Each daily stand-up is an opportunity to see what is and isn’t progressing, who needs help, or what needs to be escalated as a risk to the project. The sprint burn-down chart precisely measures the rate of task completion – the rate of delivery of business value.
An important aspect of an agile methodology is ensuring that the team reviews the state of all current activities – through daily stand-up and sprint retrospectives – and adjust its own expectations, so that a conversation can open up with stakeholders. If sprint planning sets the expectation, then that’s the mark the team can measure itself against throughout the sprint. In the bigger picture, a product roadmap is broken down into progressively smaller and better understood pieces of work that can be scheduled to minimise the impact of unknowns and to meet release deadlines. Standard project management techniques can be used to see if milestones are achievable or if schedules need to be adjusted.
Developers gather at the sprint boards to share updates & task progress, and to check on priorities for the day.
But a sign of maturity in an agile team is when they review their processes on a regular basis and adjust the way that they can best fulfil their promises or make process improvements that directly benefit the team and can only have a positive flow-on effect with their stakeholders.
It should be obvious that, just as risk management is not about avoiding risk, but about understanding it and taking advantage of the opportunities and rewards, agile software development is not about planning to minimise the chance of failure, but about pro-actively delivering the best possible business outcomes that the team is capable of.
Agile Culture at Protecht
At Protecht, the product that we deliver is just one aspect of our risk management offering, but it takes the largest part of our resources – team members committed to providing the best risk management experience to our customers. As Development Manager, I’m proud of the team and the solutions that we provide our customers.