Agile for teams who don’t build software

Agile ways of working has its roots in software development and looks to get working software in the hands of end users as quickly as possible. This offers teams rapid feedback and helps to ensure the final result has value to the end user. I recently worked with a couple of agile teams looking for different outcomes. We wanted to understand how services could be arranged around user need and explore how digital solutions could help. We also had to show how digital teams worked together and with others in the organisations. We weren’t building software but we did adopt an agile way of working.  There are lots situations where working software is not a core outcome for a team and agile ways of working would help so I thought I’d share my experience.

Principles are transferable 

I found it helpful to start with the agile manifesto and think about swapping the term ‘software’ with ‘outcomes’. It needs a little poetic licence but I found it really helps to translate the intent and make it meaningful for teams who are not building software. In my experience, adopting an agile approach to software development works well when there are high levels of uncertainty and complexity and this isn’t just reserved for building software; the same is true for most problems. The teams I worked with had to wade their way through vast amounts of information in order to frame the user needs, determine where the problems were and what needed to be fixed. It’s difficult to know where to start (or even stop…) but applying an agile mindset to the problem allowed the team to deal with the complexity in an open, collaborative and iterative way.

Clear goals linked with day-to-day tasks are important 

Both teams I worked with recently were running over a very short time, 12 weeks in total, so it was really important to stay on track. Setting goals helps teams stay focused on what they need to achieve, but to really keep focus there needs to be a direct connection between the things you do on a day-to-day basis and the value the team is looking to unlock. There’s a lot of good stuff written about the use of the Objectives and Key Results (OKRs) and how to ensure everyone can make a measurable contribution to strategic goals and we applied the same principles. We;

• defined a core vision for the 12 weeks
• agreed how we would get there by describing the deliverables
• created a high-level roadmap
• understood all tasks involved

At sprint planning sessions we agreed acceptance criteria to help us determine when we’d done enough and stop us going down rabbit holes – a challenge for any time bound project! At the sprint review sessions we shared what we achieved and reviewed our progress against the roadmap, deliverables and vision, iterating where necessary. The vision and deliverables didn’t really change, but the journey to getting them done was fluid.  Regularly reviewing our tasks against the roadmap, deliverables and vision as we moved through each sprint was a big part of keeping us on track and making sure each thing we did was adding value.

Burndown charts help to make the effect of changing priorities visible  

I used a simple, task-based burndown chart to track progress throughout the sprint but for a slightly different purpose. Given the nature of the project the team were constantly discovering new things that would lead to unplanned worked. Sometimes the unplanned work had more value than the things we’d committed to at the start of the sprint. We couldn’t exclude these tasks because of the potential they had in helping realise the vision, but we also had to make sure we didn’t head off down into one of those rabbit holes. The sprint burndown chart provided an opportunity to reflect on the value of the unplanned tasks, the sprint commitment as a whole and the impact this had on our deliverables and vision. It was a constant, visual reminder to keep that assessment at the forefront of our minds. It didn’t really matter how the chart looked at the end of the sprint as long as the team were happy with the value delivered, the tasks were adjusted for the next sprint and, most importantly, we moved closer towards our goals.

Prototype and iterate everything  

Prototyping and iterating software based on user feedback is at the heart of agile software development. Prototyping a new service provides the opportunity to get a feel for the thing when the finer detail is less understood. Iterating this based on feedback from users allows teams to work their way through a process of ‘trial and error’, incrementally improving the value of the service to the end user until it hits the mark. This also works when teams are not building software.

Most people see things in a linear way. We map things out in our heads to get it right first time.  When we aren’t part of agile teams that build software we revert back to this way of working and load a lot the ‘building’ work to the back end of the project. This means if things are not quite working out there’s little time to fix them. The team recognised this early and set time aside for regular ‘hack days’. The aim was to leave the room with actual things that could be shared with the wider team and organisation, discussed and iterated. This didn’t mean lines of code. What started out as spreadsheets, diagrams and hypotheses turned into the final data visualisations, reports and recommendations and allowed us to test our thinking with internal and end users throughout the project.

Achieving results

As a result we completed the project with something that was understood by users and stakeholders across the organisation and built a solid foundation for the next phase. The agile principles we adopted were critical in providing focus and keeping us on track in a complex and uncertain environment. It also built a team culture that was transparent, collaborative and not afraid to question and iterate. As a delivery manager seeing the teams come together and looking back on what we were able to achieve is what it is all about. And, without a doubt, agile ways of working helped us get there.