Implementing Agile
At Techniche we have historically used a traditional waterfall-based approach to software development on our Urgent product. In January, however, that all changed, and we adopted an agile-based approach.
Agile was popularised within software development in 2001 when seventeen developers published their view on how they could work better, entitled the Manifesto for Agile Software Development. They propose that the following should be valued:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
We have chosen to use a particular implementation of agile known as scrum, characterised by short iterative cycles of work, known as 'sprints' – in our case two weeks. By utilising agile and the scrum framework we believe that we can bring greater value to our customers in the following areas.
Quicker Development Lifecycle
We currently utilise a quarterly release cycle in which the developers will work on a version of the software for 3 months, before we put in place a code freeze and it is tested by the QA team. Only once it has been through thorough regression testing, with any bugs that are found having been fixed can it be released to staging, and ultimately production. Using agile scrum, however, means that we have a potentially releasable product every two weeks. Whilst we aren't currently planning to move away from our quarterly release schedule, agile gives us the flexibility to introduce this in the future and enables us to create a situation in which a change could be in production two weeks after it was first suggested.
Agility
It's well established that in the world of IT, things move fast, and that by standing still, you'll end up going backwards. It is therefore important for us to be continually open to change and to not fear failure.
Success is stumbling from failure to failure with no loss of enthusiasm.
Sir Winston Churchill
Only committing to two weeks' worth of work at a time gives us the ability to do this – we can adjust our plans based on an outlook that is no more than a fortnight old and we only take on risk at the value of one sprint at a time.
Increased customer feedback
Our increased agility and ability to change means we can be far more open to customer feedback at all stages of development and by demonstrating working functionality to customers regularly we have the ability to develop features in collaboration with real world users of the system. Additionally, if we build something that it turns out does not precisely meet our customers' needs, we have only spent, at most, two weeks' worth of effort on that.
Improved quality
Breaking down our work into small, manageable units, our development team can more effectively deliver high quality software. This is achieved through frequent testing and reviews, meaning where a defect is identified it can be fixed rapidly with minimal impact.
We are what we repeatedly do. Excellent, therefore, is not an act but a habit.
Aristotle
Focus on delivering value
As part of the Scum methodology we have appointed a Product Owner. It is their responsibility to maximise the value of the product from the work of the development team. They are empowered to set the priority of the development teams work based on customer needs and business value, meaning we can focus our efforts where they will have the most impact.
Focus on users
The product owner we have appointed does not sit within the development team – this is to ensure that their priority is always about customer value and user experience, without getting tied up with technical implementation. As part of this we are using user stories to bring define our development work. User stories shift focus away from withing about requirements, to talking about users and their experiences. User Stories typically follow the same format and describe who a user is, what they want to do, and why – they may look something like the following:
As a management user, I would like to filter invoices by ones that I can refer so that I can find them more easily
Rather than describing user interface elements or implementation details, we start talking about what users want to achieve, why and for what purpose. This allows more creative thinking and, critically, a focus on those real-world users – additionally it allows a developer to see the impact of their work, who it's benefiting and in what way.
Get closer than ever to your customers. So close that you tell them what they need well before they realize it themselves.
Steve Jobs
Avoiding FrAgile
The term FrAgile tends to get used a lot when Agile goes wrong – and it often can. We've identified some top reasons why we agile can fail and therefore have put plans in place to mitigate these.
Loss of momentum
Many development teams who aren't currently using an agile methodology have in the past, but it ‘fizzled out' – Techniche is among that number. The typical experience is something along the lines of it having started well, but once the initial phase of greenfield work was complete, the requirements became less clear, the quality of the work items dropped and therefore scrum, and it's associated processes came to be seen as more of a hinderance than a help. The general attitude of the team shifts away from scrum, and it fades into the distance with the team falling back to the familiarity of a waterfall process.
We are confident, however, that that won't happen – our approach this time is fundamentally different, in that we are introducing Agile for our roadmap work, rather than a new project. Crucially that means the process doesn't need to go through the greenfield to business-as-usual (BAU) transition that often sees scrum implementations fail, as it is set up for BAU from day one.
Lack of scrum knowledge
Another reason that was identified to cause agile to fail was a lack of understanding of the process. Whilst the scrum guide is great as a reference tool, experience is invaluable. We realised that the scrum experience within the team was limited and therefore we were at risk of not really knowing what we're doing or making easily avoidable mistakes and assumptions. Our solution to combat this to send individuals on approved training courses. Both our appointed scrum master and product owner attended relevant training courses which gave them a wealth of both theoretical and practical ideas. They came back energised and enthused about scrum with a clear picture of how and why we should implement it.
Not being agile with implementation
One of the biggest reasons I've personally seen cause scrum to fail, seems so obvious that it's almost unbelievable that it would even occur. Forget talking to yourself, or hairy palms, failing to be agile with your implementation of agile is truly the first sign of madness. I lost count of the number of times in my junior dev days I heard the excuse “but the scrum guide says…” – and they're correct, it may well say that, but the scrum guide is after all, a guide – otherwise it would be called the scrum rules. Doing something just because you think you should, doesn't make you smart, it makes you the sixth monkey.
We are, therefore, very keen to ensure that whilst we use the scrum guide as a baseline, we won't allow ourselves to be constrained by it and ensure we remain open to change. This must be implemented through a top down attitude that allows the team to be truly self-organising and empowers them to adapt and change in the interest of continual improvement. The agility applied to our product also extends here, however, in that we can make a change to the process with a commitment to try it for two weeks (one sprint) and review its effectiveness thereafter. If it has made an improvement, lets keep it, if not let's not. Thus, the impact of a bad change is, as with the product, limited to only two weeks in scope.
Summary
We have identified, in scrum, a methodology that enables us to deliver better value to our customers, whilst creating a more empowered, driven and continually improving development team. Challenges have been recognised but we are confident that we understand these and have appropriate plans in place to reduce their impact.