BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Perfect Software, Measuring Continuous Delivery, and Exploring the Future: Agile on the Beach 2017

Perfect Software, Measuring Continuous Delivery, and Exploring the Future: Agile on the Beach 2017

Bookmarks

At the Agile on the Beach 2017 conference, run in Cornwall, UK, several hundred speakers and attendees gathered to discuss the latest developments within the field of agile and post-agile software development methodologies. Key takeaways from the final afternoon of the conference included: delivery teams can add value more rapidly by embracing lean, iterative and continuous deployment methodologies; although highly beneficial, implementing continuous delivery is hard - there are a lot of tooling and cultural changes to be applied in your context; measuring continuous delivery metrics, such as build stability, deployment throughput and code throughout, is vital to allow continuous improvement; and that we, as software delivery professionals, have a lot of responsibility for shaping the future we will live in.

Sally Goble, head of quality at the Guardian News & Media, began the Friday afternoon breakout sessions with a talk titled "Perfect Software: The Enemy of Rapid Delivery". Goble stated that in the 80s and 90s the delivery of software as a discrete event - one that typically consisted of using a physical medium to install a compiled artefact on a customer's machine - meant that a "non negotiable rhythm of delivery of software dictated the need for perfection. The adoption of the Internet in the late 90s and 2000s changed all of this. Organisations could now continually and incrementally deploy and update software that was delivered via the world-wide web. New methodologies and processes sprung up to take advantage of this new capability, which is typified in the approaches that we now take for granted: lean product development, agile methodologies, continuous delivery, automate-all-the-things, and DevOps.

Goble continued by discussing how the Guardian have adopted their software delivery processes for the effective delivery of value to their readers. The first transition was shifting the mindset of releasing software as "bug free", to "not wrong for long". The Guardian have invested extensively in delivering single feature releases, canary releases, feature switches, and monitoring and alerting. All of these techniques allow rapid detection and fix of any issues that inevitably slip through the usual quality assurance process.

Goble - Test after release

In regards to the user experience, the Guardian team has swapped "perfect prototypes" for "lean UX", and "track everything" to "minimal tracking". Design sprints are timeboxed to a week, involve the whole team, and must target solving a specific and well-defined business problem. Prototypes are rough, allowing rapid iteration, and making it easy to reject bad ideas. Even with a well-defined hypothesis, not everything can be A/B tested, and relying on measuring impact in a volatile environment is too complicated. To supplement traditional approaches to the evaluation of functionality, the Guardian have created and cultivated a large beta-testing program consisting of actual users, and their behaviour and feedback are used to evaluate new features. Goble concluded the talk by stressing that it is essential to closely and continually measure the impact on customers and stakeholders in order to deliver value over the long-term.

In the penultimate talk of the day Steve Smith, a continuous delivery consultant, presented "Measuring Continuous Delivery". The talk began with a reminder of the core principles of continuous delivery, as captured in the seminal book by Dave Farley and Jez Humble: continuous delivery is achieved for an organisation when software can be delivered with the stability and speed that can satisfy business demand. Smith cautioned that continuous delivery (CD) is a large topic, and consists of many subtopics. The biggest challenge is applying the principles, tooling and cultural changes required within the context of the organisation attempting to embrace CD.

Continuous delivery is hard. There are a lot of tooling and cultural changes to be applied in your context.

Smith continued by stating that following The Improvement Kata is essential for embracing the principles associated with CD. Key measures of continuous delivery can be defined as follows: stability is equal to the sum of the change failure rate and the failure recovery time; and throughout is equal to the sum of lead time and frequency.

Smith - Continuous Delivery

Smith presented a series of insightful graphs that contained CD metrics taken from a range of teams working on a large scale UK government department software delivery project. Data on deployment stability and throughput, build stability, and code throughput (mainline commit lead time plus mainline commit interval) were presented alongside a discussion of how Smith and his team identified and worked with the associated teams to improve their ability to continuously delivery software, and ultimately improved their ability to deliver business value. Additional detail on this topic can be found in a Leanpub book by Smith, titled "Measuring Continuous Delivery".

Smith - Deployment Throughput

The conference closed in style, with a thought-provoking keynote by James Lewis, principal consultant at Thoughworks. Quoting from the book from The Cathedral & The Bazaar, Lewis shared with the audience "every good work of software starts by scratching a developer's personal itch". Over the next thirty minutes Lewis provided a retrospective of Thoughtwork's Technology Radar - something he has participated in the creation of for many years - and discussed the impact of technologies like JavaScript, microservices and containers on the capability of the software industry to rapidly deliver innovation and provide value to end-users.

Halfway through the talk Lewis changed gears, and shared his predictions of the future - and usages - of technology. Paraphrasing William Gibson, author of seminal science fiction books like Neuromancer, Lewis mused that "we are living in the future (it's just not evenly distributed)".

Lewis - We are living in the future

Sharing current research and future industry predictions across a range of topics - such as automated cars (by 2045 automotive automation could be at 100% penetration in Global North), robotics and blockchain - the audience of software delivery professionals was treated to a narrative that was simultaneously inspirational and intimidating: "we are moving to a(n even) more connected, more automated, more augmented world. And software is taking us there".

Additional information on the Agile on the Beach conference can be found on the conference website, and videos of the presentations will be uploaded on the AotB YouTube channel over the coming weeks.

Rate this Article

Adoption
Style

BT