As part of my role as enterprise architect at Companies House, I work closely with agile development (Scrum) teams. While working a new extractives service, I developed a technique that is especially suited to the discovery phase of a new system. It’s an idea borrowed from physics and avionics – but don’t be put off, it’s not that technical.
As you may know, wind tunnels are used to determine ways to reduce the power required to move a vehicle at a given speed. In such studies, the interaction between the road and the vehicle plays a significant role, and this interaction is taken into consideration when interpreting the test results.
In an actual situation the roadway is moving relative to the vehicle but the air is stationary relative to the roadway. In the wind tunnel the air is moving relative to the roadway, while the roadway is stationary relative to the test vehicle. This modelling technique does not exactly replicate the live environment but comes close enough to give valuable feedback on the design very early in the process.
Working on the extractives project, I took these same principles and applied them to the agile approach of building software systems. It promotes adaptive planning, evolutionary development, early delivery, continuous improvement, and encourages rapid and flexible response to change.
Here at Companies House development is split into three phases based on the Government Digital Services (GDS) approach to building systems: discovery, alpha and beta. A 'wind tunnel' can be used at any point within this life cycle. I tried an experimental combination of artefacts and resources to generate an agile version of the wind tunnel that engineers have been using for many years to get insights into their designs.
So, much like in a real wind tunnel, where the stationary model replaces the real artefact, I replaced the finished system with existing test systems, prototype screens, and a first cut business process – a model of the proposed system.
Outside the immediate actors and artefacts chosen for this scenario, I invited other key stakeholders who sat in the audience and watched the model system perform its functions.
Just to give a flavour of the roles: I had someone playing our CEO, who is ultimately responsible for complying with legal restrictions and regulations, and I played an angry customer with a complaint. I also had someone play the director of a large multinational company whose data had caused the complaint and who had to respond. The administrator was played by someone from an appropriate team, and I also had a scribe, whose sole purpose was to record all of the points raised for later analysis and discussion.
What was the outcome? The agile wind tunnel showed where the business flow wasn’t smooth, like the air flow in a real wind tunnel should be. It exposed holes in the system, business processes that needed fleshing out and some that had been missed. Importantly, it highlighted various legal points for investigation. It also confirmed that despite the missing bits and bobs, the discovery phase had indeed generated an outline for progressing and producing a more functional alpha version of the system.
In conclusion, I believe that this technique is very useful for exploring complex user interaction and legal constraints, or where there exists any complex calculation that can have a variety of outcomes, with possibly serious consequences. As an experimental technique using the agile approach, it was successful. The cost in time (about an hour preparation plus an hour workshop) is well worth the investment for the project.
To keep in touch, sign up to email updates from this blog, or follow us on Twitter.
