We talk to Active Risk’s Chief Technology Officer, Darren Thorpe, to learn more about some of the important changes that happened behind the scenes in the run up to the release of the company’s latest release of its Enterprise Risk Management solution – ARM 7.
How do you decide what should go into a new release?
So, before we talk about specific processes, it’s important to understand how we work and what’s changed. We now use Agile methodologies across the business here at Active Risk. This is a way of working that literally enables us to be fresher in our thinking, more responsive, communicative and open in the way we develop, respond to issues, get feedback and go to production.
What does that involve?
Well, when assessing the functional requirements for the release, we draw up a list of problems that need to be solved. These come from customers, sales, support and from within the product teams. Interestingly, when these come from non-technical people, they tend to be described as solutions; for example: "it would be really good if we could…" For us, the work is then to try and work out what the real issue is and to identify how best to achieve this and, indeed, to work out if the proposed solution is really the best way to resolve the problem.
This plain language approach is really fundamental to the Agile methodology too. It makes development meaningful to everyone. Our rule is that we should be able to put the list of problems in front of a customer and they totally understand what we are trying to achieve.
So, how do you prioritise the requirements?
Once we have this list, we ask the development team to score each item. They look at the list and work out the most time consuming fix, least time consuming – and everything in between. From this we are able to attribute time and cost to the development schedule.
It’s then passed over to the commercial teams to work out the priorities. Of course, looking at our customer’s needs is a major factor, as well as market analysis and ensuring that the platform is up to date and performing as it should.
On top of that, we then prioritise based on the combination of time to fix, cost to fix and relative importance to the market. And because we have used the customers’ language to describe the problem being fixed, it’s easy for the non-technical areas of the business to understand the potential benefit. So, they go through the same prioritisation exercise – scoring most important through to least.
That, at a very high level is how things get into the product roadmap.
Is collaborative working across the business important in this process?
Absolutely. It’s a fundamental role of the product management team to get consensus in product direction. This means that everyone understands where we are headed, has been consulted and can get behind the release schedules to effectively communicate where we are going and the benefits we will be delivering.
Once you have the priority requirements, what happens next?
Development is no longer a linear process. It’s more collaborative than that, with pieces of work being turned around quickly in development windows that we call "sprints". We have a daily ‘stand up’ meeting, which involves the entire development team and the Product Manager. We go through the developments that happened the previous day, and run through the developments that are going to happen on that day too.
Why is that a better approach?
Oh, there are many reasons. During the development stage, this considerably reduces the feedback loop. It gives the Product Manager a really clear picture of progress – a view on any delays or issues that have arisen. They see work pretty much the minute it is completed and are able to make changes before any further work is started.
There was an IBM study that attributed cost to the moment in which you make changes to software whilst in development. It said that if you make changes during initial development, the cost is 1; during Quality Assurance, the cost is 10; and if made during final production, the cost is 100. So you not only get faster development, but also more cost effective development using Agile.
How long have you been running Agile?
We’ve been building our knowledge of Agile methodologies for a while now, but ARM 7 is the first product release built entirely using the Agile approach.
Have customers felt the benefit yet do you think?
Most definitely. As an example, we took on a project in close collaboration with a customer. We agreed the requirements using the old functional approach, but then switched to AGILE at the start of development, which is an entirely different way of working.
When we completed the project, we compared what we had built to the functional specification and the two were quite different. That was very serious, and we were obviously concerned. However, when we reviewed it with the customer, we found that what we had actually delivered was entirely correct from a user perspective, rather than what the technically focused functional requirements document had outlined.
This is a really good example of how our Agile approach had enabled us to work in a much more customer and user focused way. In this example, it allowed us to react to the user issues as we went along, in consultation with the client. The result was the solution that was right for the users.
Are there broader benefits?
Oh yes! This process ensures that we optimise development time and involves a much wider audience of stakeholders, which breaks down barriers between development and commercial. It has actually changed our culture as a business.
What’s coming next?
Well, we are in the first phase for ARM 8 and are starting to pull together some detailed problem definitions. We know we will be adopting new technologies, which will have exciting impact on the product, we should be able to take different parts of the platform mobile. We’ll be sharing sneak peeks well before release date – with the first of these previews taking place at the forthcoming user conference in June.