At the fifth ‘Agile on the Beach’ conference, held in Cornwall, UK, several leading practitioners of agile software delivery presented the state-of-the-art and emerging trends within this domain. Key messages included the need for the more rigorous application of the scientific method and ‘hypothesis-driven design’ throughout the software delivery lifecycle, the need for the implementation of agile principles and continuous improvement to the product development process, and the benefits provided by informed decision-making when choosing methodology and practices for developing software within a rapidly changing ecosystem.
Dave Farley, co-author of ‘Continuous Delivery’, began the first day of conference by presenting a keynote guide to continuously delivering valuable software, with a particular focus on the failings of human observational skills, decision-making and intuition. “Farley’s Three Laws” were introduced, which can be paraphrased as: (1) people are flawed; (2) stuff is more complicated than you think it is; and (3) all stuff is interesting (if you look at it in the right way).
Farley provided a tour de force of inherent weaknesses and failings of human decision-making by presenting a series of optical illusions, brainteaser puzzles, and case studies that demonstrated how our decision-making heuristics can lead to incorrect choices being made within the software delivery lifecycle. A key message presented was the need to apply rigorous experimentation when designing and delivering software. Quoting Richard Feynman, Farley suggested that it is all too easy to fool ourselves when making software design decisions without experimental evidence:
It doesn’t matter how intelligent you are, if you guess and that guess cannot be backed up by experimental evidence then it is still a guess
During the exploration of Farley's second law, a series of failed computing projects case studies were explored, such as Pentium CPU chips shipping with a floating-point math error, the Ariane 5 space mission that exploded 40 seconds after launch, and Knight Capital’s $440 Million loss. Farley argued that the complexity of these projects was often underestimated, and accordingly the use of agile practices, rigorous scientific experimentation and continuous delivery should be encouraged within software development projects, as this minimises feedback cycle time and exposes complexity early within a product's lifecycle, when the least information is known.
The conference breakout sessions began after the keynote, and of the five tracks available, InfoQ first attended the ‘Product’ track in order to listen to Melissa Perri, founder of ProdUX Labs, talk about ‘Continuous Product Improvement’. Perri opened the talk by questioning that with the widely implemented technical practices of continuous integration and continuous deployment, why is it that continuous product development is not yet mainstream? Perri argued that without the use of continuous product development, it is all too easy to become very efficient at building the wrong thing.
It doesn’t matter how well you make at unwanted feature, it will always be unwanted...
After introducing the ‘four steps to continuous improvement’ Toyota Kata, Perri strongly recommended that product managers and owners within a business follow the lead of the technical teams, and implement an agile methodology to product design. The typical approach to generating and grooming feature lists may be inappropriate, as many users do not realise what they want or need until they have seen a tangible product or an MVP (and at this point users often realise what they don’t want). Perri suggested that the use of a continuous improvement ‘Product Kata’ is a good way to scientifically and systematically build better products.
A detailed case study of the successful implementation of the product kata was provided, and Perri cautioned that 'buy-in' must be gained from the implementation team, the design of experiments is not trivial, and establishing (and measuring) metrics of success is often challenging. Additional details and guidance on the product kata approach to product development can be found on Perri’s ‘Product & UX’ blog.
Steve Smith, agile consultant at Always Agile Consulting, presented ‘The Death of Continuous Integration’ within the next slot of the 'Continuous Development' conference track, and suggested that although most people agree that the increasingly popular approach to continuous delivery of software relies on continuous integration, many teams are adopting development practices, such as release feature branching, that hinder the implementation of continuous integration. Smith also posited that tracking local development metrics (such as team ‘velocity’) when working with a globally shared codebase is foolish, and can lead to perverse incentives:
Measuring team velocity [with a shared codebase] is rubbish. We need a global metric to track progress at the system level
Smith opened that talk by stating the continuous integration (CI) is not implemented by simply running a Jenkins-powered CI build server that integrates the codebase and runs tests once a day. Instead CI is a mind-set and philosophy, where developers are continually integrating their code to the master or trunk branch, any breakage in the build pipeline results in an immediate fix, and developers take care to address issues that affect the whole team’s ability to receive rapid integration feedback, such as slow-running tests.
A series of approaches to integrating code were presented and evaluated, such as release feature branching, trunk-based development and build feature branching. Smith stated that although trunk-based development is often the most effective approach to CI (and can make beneficial practices mandatory that are optional when using branch by feature), in reality this takes a lot of skill and discipline, and is not easy to implement. Build feature branching is often a good way of working, but the use of this practice (and indeed all development practices) should be an informed decision. In closing, Smith harked back to his early statement about the use of Jenkins being considered as ‘doing CI’, and cautioned that tools should follow practice, and not the other way around.
After a lunch break that provided good food and plenty of opportunities for discussions with speakers and fellow attendees, James Lewis, principal consultant at Thoughtworks, presented “Building systems that are #neverdone” in the ‘Craftsmanship' track. Lewis began the talk by referencing “my families axe” within “The Fifth Elephant” novel from the late Terry Pratchett, and stated that several high-performing companies are developing software using a modular (microservice) approach with clearly defined bounded contexts and APIs. Much like the axe in Pratchett’s story, which has the handle and blade modified and replaced many times throughout its lifetime, these software systems are conceptually thought of as the same throughout their lifetime, even though entire subsystems will be improved and replaced as the associated business grows and changes.
A core premise from Lewis’ talk was that many (enterprise) organisations believe the future is scary, unpredictable and vulnerable to rapid disruption, and software systems should be designed to be allow organisations ‘to go as fast as possible’ with software development. Properties of software systems, such as being cheap to replace, quick to scale and able to withstand failures, are vital. Lewis argued that old maxims such as “don’t repeat yourself (DRY)” may need to be revisited with this new development style, as when implementing a microservice architecture it is perfectly acceptable to repeat yourself between bounded contexts, although care should be taken to not repeat yourself within a context. Principles revolving around the just-in-time style of software development will also have to be ‘pulled up’ from the code level to the architectural design level:
The YAGNI [“you ain't gonna need it”] design principle has jumped from the code design to the level of systems architecture when using microservices
In closing, Lewis suggested that developers must now learn to ‘craft my families axe’ and build modular/replaceable systems, deploy small (micro)services independently, and also test services in isolation. Due to the complexity and emergent behaviour of microservice-based systems, it is best to test within production environments, and therefore the continuous integration environment may be going the way of the dinosaur. Additional details on Lewis’ talk can be found in Tony Edward’s live blog of the session on the ‘Agile on the Beach’ website.
Stefan Smith of Thoughtworks presented “Escape the integration syrup with contract tests” within the afternoon slot of the 'Continuous Development' track. Smith suggested that when developing modular systems (parts of which may evolve separately and in isolation), care must be taken when integrating subsystems together, and the anti patterns of ‘release train’ or stage-gate 'rubber stamp' approval of collaborating versions must be avoided in order to maintain developer (and business) productivity.
Smith stated that when any two systems communicate, there is always a contract in place between them, even if this is implicit. By making the contract explicit, for example, using consumer-driven contracts, the communicating components can be validated for adherence to the contracts, and a development team conversation can be triggered if breaking changes are required. A series of case studies were presented that examined the range of enforcement option for contracts, for example, providing executable stubs and contract tests to the development team responsible for external components, running contract tests within a build pipeline, or executing contract tests throughout the testing environments to which new versions of components are deployed.
Smith cautioned that as with nearly all things within software development, there is ‘no free lunch’ provided by contract testing, and in particular there is often a learning curve to implementing this approach, difficulties in establishing ‘golden data’ for test verification, and challenges when creating infrastructure for sharing contracts:
The final talk of the day in the ‘Craftsman’ track was presented by Benji Weber and Alex Wilson from Unruly, and the topic of how software-based products are developed by the ‘Unruly mob’ was discussed. Wilson opened the talk by stating that the majority of developers working within Unruly are ‘Pro Dev Ops’. This doesn’t necessarily relate to the DevOps philosophy, and instead means that developers are responsible for product, development (including quality assurance) and operations. Accordingly, there are no handoffs within the Unruly team, and developers are responsible for the operational running of software systems. Wilson stated that this leads to shared responsibility and shared accountability across the entire team.
Weber discussed that Unruly has also recently embraced the notion of ‘mob programming’, which is an evolution of pair programming, where one developer will be ‘driving’ the development via a single computer, and a group of between 3 - 8 developers (the ‘mob’) will act as ‘navigators’. Within mob programming the driver role is less about implementing a solution, and more about creating the code - the mob are responsible for designing, discussing and evaluating the code and architecture written. Weber commented that through the use of mob programming, he has seen the most accurate realisation of an ‘ideal’ day that is used to estimate how long a piece of work will take to implement:
The closest I’ve got to a realisation of an ideal [estimation] day is through mob programming.
Wilson and Weber stated that not all software developed at Unruly is created in this way, but after an initial ‘day per week’ experimentation with ‘mob Fridays’, this methodology has spread virally throughout the company, including to non-development teams. Good agile practices such as continual coaching and the running of retrospectives is required to ensure that everyone is contributing and happy with this approach, and the Unruly team occasionally bring in external parties to the organisation to teach them the methodology and also expose unneeded practices through the questions of the mobbing novices.
Additional information on Unruly’s mob programming practices can be found in a ‘Mob Programming: What works, what doesn’t” talk presented at the XP2015 conference, and an accompanying paper written by Wilson. This session was also live-blogged by Tony Edwards on the Agile on the Beach conference website.
The first day of the 'Agile on the Beach' conference was closed by a series of informative, funny and inspiring lightning talks from members of the audience, and this covered a range of topics from within the domain of agile software development. In the evening all delegates were invited to a ‘party on the beach’ in Falmouth, where the agile-inspired discussions with fellow delegates and speakers continued well into the early morning.
Additional information about ‘Agile on the Beach’ can be found on the conference website, and by following the 'agileotb' Twitter hashtag.