Having spent the last year leading a cross-functional team on the development of Historic England‘s new website, supported by a great management team who fought hard to keep the business from switching to a waterfall process for a good portion of that time, I wanted to share the benefits of the agile process with the wider community. The project was a huge success and with a reduced budget for this financial year, the organisation has decided to stick with the agile process for all new digital projects.
The agile Scrum approach to software development marks a dramatic departure from a more traditional waterfall process. Scrum and other agile methods were inspired by waterfall’s shortcomings and emphasises collaboration, functioning software, team self organisation, and the flexibility to adapt to emerging business realities.
This feels like one of the most fun and successful projects I think I’ve worked on.
– Senior Programme Manager, Historic England
Scrum is an iterative process that allows teams to focus on the development of only the absolutely necessary features. At the end of an increment, or sprint, it’s possible to release features early, allowing companies to start generating revenue while development continues.
The traditional project management role has been removed and replaced with a team structure to promote communication and collaboration on key functional requirements. The Product Owner works with the client or stakeholders to understand requirements and their priorities; the Scrum Master does everything they can to empower the development team to self-organise and become as productive as possible, removing any impediments along the way and finally a cross-functional development team that do the work! Agile works best with a team size of 3 to 9 people. Any more than that and it can become difficult to manage.
Working incrementally allows Product Owners to see work that’s been completed by the team and put that work in front of end users to get early feedback; this ensures the output is what the business wants, quality is maintained and stakeholders have clear visibility of progress. Testing is continuous in every sprint and any changes are discussed and prioritised alongside other work items; agile Scrum is a process that embraces change.
Management often ask about how you manage risk within an agile process. Working closely with the Product Owner and the team in small increments helps to identify any risks and issues as they arise; the team will then deal with them at that time. If an issue arises the Product Owner may decide to make it the highest prioritised work item for consideration in the next sprint, it will be refined in the backlog refinement meeting and if the development team think it’s feasible to deliver they will commit to delivering the necessary solution by the end of the next sprint. This ability to be flexible, and respond to change will lead to a better product as issues are dealt with earlier in the project rather than towards the end when traditionally testing takes place.
Within traditional processes time is spent gathering requirements, a plan is created and the features to be created are fixed. The specification stage becomes a contract for the development team to follow. Complex strategies are put in place to deal with any requested changes to that contract. There is always a fear of scope creep and a never ending project; in agile the process is different, it embraces change, as change is inevitable and expected. The timeline for the project is fixed and requirements emerge as the project develops. For this to work effectively the project will require an actively engaged Product Owner who is prepared to make the trade off and prioritisation decisions between existing and new requirements. As the timescale and the resources are fixed for the project the costs are fixed; the scope of the project and the features are the variables.
The active involvement of the Product Owner with the business, high visibility of the project through regular meetings, progress shown through Scrum boards and the ability to change when change is needed create much better business engagement and customer satisfaction. This is a huge advantage over other processes and often creates much more positive enduring working relationships.
60% of features developed in software are never used by end users and 30% of the features they would expect to find are not there.
– Forrester Research
It is often said with more traditional development frameworks that at the end of the project, even if it’s delivered on time it wasn’t what the business wanted; according to the Gartner Group 60% of features developed in software are never used by end users and 30% of the features they would expect to be included are missing, furthermore 80% of the business value comes from only 20% of the functionality. Given that the agile framework allows requirements to emerge and evolve over time, taking into account user feedback, businesses ultimately get a product that suits their specific needs.
The agile environment also creates a better working environment for the workforce. Instead of producing lengthy specifications we hold workshops with the whole Scrum team to discuss how the product will work. The Product Owner is always at hand to answer any queries and keep an eye on The minimum viable product (MVP) or minimum lovable product as I heard it called recently. The focus is always on getting working software out and in front of end users for early feedback; we always tell ourselves if we go wrong it will only be wrong by 2 weeks, i.e. the length of one of our sprints. As communication is so good moral is generally high.
However there are compromises to be made. Agile needs good people to work well and in my experience people are always the biggest challenge! Agile requires a dedicated team and those team members need to be fully engaged with the process; it won’t work if developers are always being pulled off to support other projects, the team is only as strong as its weakest members. However, there is nowhere to hide in agile and conflicts between team members may be resolved quickly or in a multiple agile team environment try swapping team members around until you get the best working combination.
This is the first in a series of insights about the agile process and lessons learnt from being involved in projects using the agile process.