Hello, I am a tech bod who has been working for the Student Loans Company for 8 years, and I’ve been fortunate to be involved in our first truly agile programme - Digital Delivery. As an organisation, we’ve committed to Department of Business, Innovation & Skills (BIS) and Government Digital Services (GDS) to transform our technical landscape, our business architecture and ultimately the structure of our organisation. The benefits of this will be that we can deliver policy change and capabilities faster and more efficiently.
Our current technical architecture is a mish-mash of old (and older!) technologies, approaches and frameworks. This has two major downfalls – first, it hinders ICT being able to deliver change quickly for our stakeholders, and secondly, it affects how our customers experience their journey with SLC. We’re looking forward to the complete transformation of this. Meantime, working in an agile methodology, we want to deliver projects and benefits now as we work towards transformation. So we need to deliver change iteratively within the current technical architecture. As we do this, there are stages in the process where our technical architects and developers need to carefully consider technology choices for a new system or integration point.
This is where a Spike has become a key activity.
Spike: a short, time boxed exercise, the purpose of which is to prove an approach, validate a technology, or better understand a requirement so that a more accurate estimate can be provided. You may be familiar with this kind of work as ‘proof of concept’.
Within an agile project, a spike can be technical or functional. So far, I’ve been involved in two spikes, both technical, but each slightly different. The first spike arose out of a common agreement that the current UI framework was causing development pain. There was a steep learning curve with the framework, which led to varying levels of knowledge within the development team, and ultimately a lack of common approach. This slowed our velocity, as each time a UI component was required, refactoring was often needed.
In discussions with the project manager and architects, we talked about alternatives. We decided on a spike to test other front-end frameworks which were lighter, required no configuration and came complete with features such as inbuilt containers. We agreed that 2 programming pairs would take 2 weeks to develop a simple front-end, each pair using a different technology. The pairs were given a set of Acceptance Criteria, to ensure focus and to give confidence that we would reach the right decision for our project. The criteria were a combination of integration requirements with dev tools and databases, must-haves that our current UI framework could perform, and comparative benefits over the existing framework.
At the end of the 2 weeks, it became clear that both frameworks could meet all the Acceptance Criteria. However, the pairs agreed there was a winner. It was chosen because it was more intuitive to use, was supported well by the online communities, provided a large variety of plug-ins, and the language used was close enough to our current skill set that up skilling would be achievable without too much cost to the project.
Following this decision, since May 2013 the UI framework has been used to successfully deliver front-end functionality into Live, and the developers, Product Owner, and the rest of the team are still enjoying the benefits of increased productivity and sleeker code.
In conclusion, spikes are a valuable part of our methodology. Ensuring these spikes take place is beneficial to both our projects and our architecture. We are identifying risk early, talking to the system experts to ensure we don’t miss key functionality, and generating discussions with the architects and developers about when the right time is to implement a new approach or technology.