My Agile Journey | Part 1
Kevin is product strategist and web software leader for the Advanced Digital Engineering (UK) Software team at @Arup.
Having managed geospatial, data, design and software teams for ~10 years I have developed a passion for looking for ways to maximise the impact my teams have.
Many years ago I started developing a growing interest in agile methods. Considering 3 particular pain points, would agile be helpful? I wanted to explore:
1) How do you influence delivery to focus on outcomes rather than outputs?
2) How do you move away from delivery cultures that are transactional, and towards a more collaborative culture that is inspiring not only for teams, but also for clients?
3) How do you deliver digital solutions in a project, rather than product, based environment?
Driven by an interest in how might we use agile principles and methods, I started to experiment with these techniques.
It is true to say that there has been much testing, experimenting and learning along the way! Including the realisation early on that much of what you read about agile comes from the perspective of working in a software house. What I needed was a way to make agile work in a consulting and project based organisation. The impact? How we deliver work today is substantially different to 8 years ago and even 1 year ago for that matter, because we are always evolving.
I will not go into every peak and trough of my agile journey here, but I will mention two areas that I have found particularly useful in progressing the way we work.
Firstly, I have found great utility in the work published by the UK Government Digital Service (GDS). In particular the Service Toolkit and its other associated artefacts. The simplicity in how Agile Delivery is presented (manifested in the phases of Discovery, Alpha, Beta and Live) is a great way to discuss agile delivery with those who are less familiar with the practice. In fact, we have found the methods so effective that we often use this for engagements with non-public sector clients, not just those in the public sector for whom the guidance was developed.
If you are thinking of procuring digital development services I would encourage you to read the wealth of GDS materials available. In short, familiarisation of the phases and assessments will help you understand how a digital project can be governed, placing emphasis on the continuous validation and verification of new services as you pass through each phase.
The GDS Service Standard also helps place an emphasis on the (often forgotten) importance of understanding users and testing your ideas before you jump feet first into development. Testing prototypes and learning from them can often be interpreted as being costly and “slowing things down”. But in my experience, when this isn’t done we end up delivering a service that has less impact than we would have hoped (see pain point 2 above!).
These methods all seek to de-risk your project, requiring you to take the sometimes difficult decision to abort a project, or a component of your project at an early stage if you need to. When we are emotionally involved in projects it can be hard to do this. Having a GDS-like Agile Delivery process is a structured way to assist you with this.
I mentioned at the start of this article that there were two areas I wanted to share in terms of my agile journey. Part two will come in a second article in the near future- the spoiler is that if you are a practitioner of Scrum you may well be interested.
Find out more
If any of the content in this article is of interest, please get in touch via ADESoftware@arup.com.
If you would like to learn about Digital at Arup meet the team, and read more about our work here.
You may also be interested in reading more in our sister blog The (Arup) City Modelling Lab.
