Adapting for Agile:
Lessons from the Frontline
Executive Summary
Agile is a way of working that has penetrated organisations around the world but its long-term benefits remain unclear. That’s because a simple step-change it is not. Gone are governance systems where decisions are made at the top and then filter down the hierarchy; with Agile, a network of teams operate as one, using data to accelerate decision making and, in theory, operate faster and more effectively.
Here, as part of our series of articles examining Digital Transformation, Iain Abernethy shines a light on the practical application of Agile solution engineering, identifying key lessons learnt and highlighting the importance of flexibility, listening to feedback; and delivering as you go.
Data scientists are hot property. That’s not exclusive to the insurance world. But thanks to their ability to uncover all kinds of insight and combat fraud, they’re a particularly valuable asset to insurers.
In order for them to be as valuable as they can be, however, data scientists need to have the right tools and working relationships with the fraud team to turn that insight into something productive.
My role has taken me around the world and into close contact with organisations across the public and private sectors. Similarities abound, trends come and go, and challenges continue to proliferate. One thing that stays the same in cyber security is that you can never sit back. There are always new threats to counter and new issues to address – a quiet life it is not.
Iain Abernethy
Product Manager for National Network Cyber Centre
BAE Systems Applied Intelligence
Advancing Agile
Working on different projects with different organisations has also given me the opportunity to see how they have developed over time. As technologies advance, working practices evolve and processes change, today’s workplaces are very different to those I encountered at the start of my career.
Agile working is an ideal example. While it is no newcomer to the software development arena, solution engineering has struggled to find what Agile means for it. I’ve worked alongside many teams seeking to implement this type of working at the solution level. Some have gone well, others have had steeper challenges to overcome, but all have had their ups and downs. Here are a few reflections from my experiences.
Advancing Agile
Working on different projects with different organisations has also given me the opportunity to see how they have developed over time. As technologies advance, working practices evolve and processes change, today’s workplaces are very different to those I encountered at the start of my career.
Agile working is an ideal example. While it is no newcomer to the software development arena, solution engineering has struggled to find what Agile means for it. I’ve worked alongside many teams seeking to implement this type of working at the solution level. Some have gone well, others have had steeper challenges to overcome, but all have had their ups and downs. Here are a few reflections from my experiences.
The Iterative Impact
The traditional systems engineering approach is for clear requirements driven and fully elaborated design that is reviewed before any implementation starts. If you have time and budget then this is ideal, however I’ve never encountered a customer with that luxury.
Looking at the use of Agile in common application software development suggests large lists of tasks that teams burn through in iterations. Again, this is great if it works, but complex systems are not a collection of mutually exclusive asynchronous components. So we end up having to bang a square peg in to a round hole: complex systems with highly interdependent components and design decisions, and a timeline that demands capability in the customers hands as soon as possible.
Fortunately, my current project has management support to work in a more iterative way. We are designing a complex cyber security solution and are starting significant implementation early. Design work switches between component design and system feature design.
We started with top level system design by component, with just enough detail to enable the implementation teams to get started, and at this stage were focused more on platform and base technology choices. As this work continued, the design team considered the high level system features from the system user point of view (a combination of feature design and use cases) which was suitable for customer design sign off. This point has its challenges as customers will require detail in areas that just don’t exist at this point.
We then moved to end to end system design on a per feature basis. This means that when just one feature is designed there is something for each implementation team (who are arranged by component) to proceed with. This stage had various iterations as we covered all the features, getting each immediately reviewed and issued to the implementation and test teams.
Finally, we returned to a component view, this time in detail, to verify whether the feature iterations had adversely changed the nature or performance of a component since the high level design. Here, although we found some areas that had to be changed, we felt this small inefficiency was worth it given the acceleration to the overall project.
Deliver as you go
Ideally, we aim to deliver to the customer in an incremental way. Although customers cannot always give us incremental acceptance and payment – their procurement rules just won’t allow this – we can agree to have pre-production environments and joint experimental datalab initiatives on their live data (with appropriate security controls, of course), and for their users to make time to try our incremental solutions and feedback to us.
Although initially often reluctant, when they get their hands on some initial capabilities and get to work with our teams to jointly create new techniques that get them ahead of the game in their mission, they quickly find ways to adapt their procurement rules towards Agile solution working.
Looking further forward, I hope to try this approach at the customer design stage, bringing the iterative feature based design from our internal review and approach to the customer design sign off too. This often occurs anyway through ongoing causal design engagement with a customer, and it works well, so we are keen to do it more and more formally.
Deliver as you go
Ideally, we aim to deliver to the customer in an incremental way. Although customers cannot always give us incremental acceptance and payment – their procurement rules just won’t allow this – we can agree to have pre-production environments and joint experimental datalab initiatives on their live data (with appropriate security controls, of course), and for their users to make time to try our incremental solutions and feedback to us.
Although initially often reluctant, when they get their hands on some initial capabilities and get to work with our teams to jointly create new techniques that get them ahead of the game in their mission, they quickly find ways to adapt their procurement rules towards Agile solution working.
Looking further forward, I hope to try this approach at the customer design stage, bringing the iterative feature based design from our internal review and approach to the customer design sign off too. This often occurs anyway through ongoing causal design engagement with a customer, and it works well, so we are keen to do it more and more formally.
Listening and adapting is a
two-way street
There may be no substitute for experience, but it’s important to be not wedded to a pre-conceived approach to Agile solution engineering. For any form of Agile, the younger generations usually have great ideas as they have grown up in a faster paced ‘agile’ world.
For example, I would much prefer design information in well-structured Word documents, yet my team have pushed towards using wiki style Confluence software for solution design documentation as it allows a much freer environment for multiple designers to not only document the design, but also the discussions and key decisions. Having previously been a skeptic, I am now a fully fledged convert to this style of working.
From theory to reality
There is no silver bullet to delivering a systemic change like Agile. The process is constantly in flux, moving and adapting to fresh issues as they emerge – often on a daily basis.
But start by being flexible; listen to the feedback; and deliver as you go. Do these three things and then you will start to turn Agile theory into practical reality.
How we can help
Digital Transformation Services
In today’s digital world, organisations need to be able to use the right data at the right time to make a difference. Digital services must be delivered securely and have the full confidence and trust of their customers.
We understand the challenges you face in the global marketplace – how your organisation needs to be digitally enabled to offer customers, employees, stakeholders and partners the digital interfaces to meet their shifting needs, seamlessly.
Digital transformation is no longer an option – it’s a business imperative.
For more information go to:
baesystems.com/governmentinsights
Profile
Iain Abernethy
Product Manager for
National Network Cyber Centre,
at BAE Systems
Iain Abernethy leads the National Network Cyber Centre proposition within the Government division of BAE Systems Applied Intelligence. He helps governments gain nation scale cyber situational awareness and find threats of national significance across colossal volumes of data.
Iain specialises in very high rate near real time data gathering, processing and displaying complex solutions created by a number of multi-disciplinary teams. His experience spans nation scale cyber mission use cases, complex systems engineering, pragmatic fast paced delivery programmes and a background in high speed electronics design.
How we can help
Rising to the technological challenge
BAE Systems provide business change and consulting services to help organisations evaluate change and preparing, equipping and supporting individuals and organisations to change their behaviour and alter their ways of working in order to successfully achieve business objectives and the realisation of the business strategy.
We also provide expertise in Human Factors which is a discipline of study that deals with human-machine interface, examining the psychological, social, physical, biological and safety characteristics of a user and the system the user is in.
For more information go to:
baesystems.com/
governmentinsights
Profile
Iain Abernethy
Product Manager for National Network Cyber Centre
at BAE Systems
Iain Abernethy leads the National Network Cyber Centre proposition within the Government division of BAE Systems Applied Intelligence. He helps governments gain nation scale cyber situational awareness and find threats of national significance across colossal volumes of data.
Iain specialises in very high rate near real time data gathering, processing and displaying complex solutions created by number of multi-disciplinary teams. His experience spans nation scale cyber mission use cases, complex systems engineering, pragmatic fast paced delivery programmes and a background in high speed electronics design.