What is Agile and why do we want to ensure the product development at Vertu follows this methodology?
At the heart of agile is a mindset that aims to constantly evolve requirements and solutions through the collaborative effort of self-organising and cross-functional teams which include their customers. In other words, if we aim for early and continuous delivery, focusing on a minimum viable product alongside a desire to constantly revisit and improve, we are able to receive rapid feedback and ensure we focus on delivering value to the products and processes we create.
In agile, working output is the primary measure of success. Responding to change over following a plan ensures we can build and maintain a competitive advantage. This also helps to eliminate waste and having to un-develop something that wasn’t required or didn’t turn out to be what the stakeholder was thinking.
Agile builds teams around motivation with support and trust. We encourage teams to be self-managed and cross functional, we ensure team members are empowered to use their skills and make decisions for themselves to help achieve the agreed goal. We trust them to get the job done and it is known that the best architectures, requirements and designs come from self-organising teams. This also means there’s a better chance that we remove bottlenecks and impediments because silos are discouraged; stakeholders and developers must work together for agile to be a success.
In agile we deliver working increments often. This in itself helps to promote simplicity and high quality, we need to focus on technical excellence to enhance agility and minimise waste such as technical debt and high levels of defects. Another positive side effect is that we can reflect on how to become more effective regularly too, then actively modify behaviours, product backlogs and processes accordingly.
This also promotes a sustainable pace of development which helps to ensure forecasting delivery for future product releases can be realistic. Guesswork is replaced with science, in scrum we use velocity and the inspection of the known, the past, to assist with predicting the future.
On a final note I’d like to recognise that there is a common misconception in and around the premise that documentation is not required in agile. Whilst working software is valued over comprehensive documentation, all of the traditional stages of a defined process such as waterfall are all still incorporated in an agile workflow. Only rather than being fixed from the outset, agile aims to ensure options are always open. Rather than scope and plan a huge project, we focus on specifying only on the top 20% of work and priorities. There is visibility of the whole, a product backlog, but at the bottom the items can be very vague. Generally from past experience, creating a hefty upfront technical specification has always resulted in some kind of waste. I don’t think many people really even reads them. Then as development starts inevitably something we didn’t plan for crops up, it could be a change in market condition, a new technology, a discovery that a better or easier way exists and not too far down the timeline things are changing and the spec is becoming more and more irrelevant. As the time spent on the spec cost so much up front, sponsors and developers can become rigid and invested to avoid wasting the time already spent, and the value of the product may be compromised as a result.
If we focus on the top, and meet a definition of ready, which signals its ready for prioritisation/ for it to be worked on, we can respond and adapt better. All items ready for development should have a business value, concise description, development team estimate and order alongside an acceptance criteria to ensure work doesn’t go off track.
In terms of release planning, agile teams again follow all of the same steps and processes as more traditional teams, only rather than separating concerns for testing and QA, it is ingrained within the whole process, within each and every task we carryout. With a shared definition of done, each increment marked as complete has undergone testing (a test plan is actually ticked off), code review, linting/validation and stakeholder acceptance. This incremental approach actually minimises delivery risk and brings value to the product and organisation sooner/ continuously… Arguably at a lower cost.
In summary Agile aims to deliver maximum ROI by creating transparency and frequent opportunities for inspection and adaption so that we can change as quickly as possible if and when required at the least possible cost.