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. Takeaways included: as the majority of companies work within a complex adaptive system everyone within an organisation must be encouraged to learn and co-evolve; cultivating an environment that promotes psychological safety is vital, and people must feel safe in order to experiment, fail and learn; the use of maps, for example user story mapping, is essential for developing shared understanding throughout an organisation; teams should focus on continuously delivering business value; and we must learn how to effectively adopt and exploit new technologies.
The opening keynote, "Learning Leaders Learn Always", was presented by Diana Larsen, co-founder of FutureWorks Consulting LLC, and focused on the premise that as software development is knowledge work, and knowledge work is learning work, effective learning leads to agility and resilience, which is vital when working within a complex environment. Quoting W. Edwards Deming with "learning is not compulsory, neither is survival", Larsen discussed how the majority of modern business environments are inherently Volatile, Uncertain, Complex and Ambiguous (VUCA) and therefore leaders require courage, compassion and confidence in order to be effective.
Courage can be demonstrated by "learning out loud", and by being willing to be curious and wrong at times. Leaders should attempt to remove obstacles to learning: individually it is not selfish to make time to learn, and people must give themselves "permission to suck" before becoming adept at a new skill. At a team level, psychological safety is vital. Quoting Matt Sakaguchi's recent keynote at QCon New York, Larsen discussed Amy Edmondson's study of the effectiveness of Google's teams, and stated that leaders must cultivate a shared belief that the team is safe in order to allow interpersonal risk taking.
Learning should be iterative, building on what comes before, and this takes confidence. Larsen discussed her Five Rules of Accelerated Learning: keep it alive - this is about the feeling of energy and collaboration; setting first - create an environment that promotes learning; strive for fluency - create simulations that challenge and allow learners to exercise or enhance learning; start obvious and stay obvious; and focus on achieving flow with a good balance between current skill level and the challenge presented. As a closing remark, Larsen recommended the audience strive to continuously learn and give back, with the ultimate goal of encouraging and enabling others to learn effectively.
The first break out session of the day was an interactive workshop on story mapping by Jason Bootle. The workshop began with an introduction to the User Story Mapping technique that was created by Jeff Patton with Peter Economy. Bootle, a freelance product and service designer, stated that "shared documentation does not mean shared understanding" and user story mapping is a collaborative technique to help achieve a consistent vision of the thing being created, a backlog with prioritisation, and a roadmap for future iterations. Pains and opportunities can also be highlighted, allowing user research and design activities to be applied appropriately, and user story mapping also helps in establishing a common language across an organisation.
Shared documentation does not mean shared understanding.
Before a team starts with user story mapping, Bootle suggested that the value proposition be defined, along with core vision and goals, personas or proto-personas, and hypotheses to be validated. For the interactive section of the workshop these key elements were provided up-front, and the attendees formed into small groups to work through several iteration of story mapping. The workshop was fast-paced and contained much opportunity for learning the basics of the technique. The session was concluded with attendees sharing their experiences, and Bootle provided further references for offline exploration.
The afternoon sessions began with "Team Design for Continuous Delivery", presented by John Clapham, a director and consultant at cotelic. Clapham began by proposing that it could appear that the formula for creating great engineering teams is well-known; they must be "cross functional, T-shaped, pizza-sized and manifesto enabled". However, this is not the reality for many, and the remainder of the talk focused on how to cultivate team traits for effective continuous delivery:
- A strong desire to learn and co-evolve
- An understanding of business imperative, and the autonomy to act on it
- Safety - to take risk, succeed and fail
- Ability to manage a high level of interactions
- Self measurement of achievement
Co-evolution can be witnessed in nature, where animals flourish based on symbiotic relations, and this trait is vital in companies that leverage software to deliver business value, as the ability to learn must be present and evolving throughout all parts of the organisation. Quoting The Lean Enterprise, Clapham suggested "use continuous delivery to reduce the risk of releases, decrease cycle time, and make it economic to work in small batches", and for this to be effective everyone must understand the overall vision and goals that the company is attempting to reach.
In addition to understanding the business imperative, people must be given the autonomy to implement changes. Modern businesses increasingly operate within a complex environment, and Clapham recommended attendees read "Team of Teams", an account of how General Stanley McChrystal -- operating as Joint Special Operations Command (JSOC) throughout the US-led counter-insurgency operation in Iraq -- discarded a century of management wisdom and pivoted from a pursuit of mechanical efficiency to organic adaptability.
Clapham also referenced Google's Project Aristotle, an extensive study of employees at Google, which concluded that psychological safety -- the ability to take risks without feeling insecure -- within teams is highly correlated with effectiveness. Other important factors included dependability of team members, structure and clarity of goals and roles, and meaning and impact of work. Clapham also discussed various experiments that utilised sociometric badges to gauge the number, type and quality of interactions. The results frequently demonstrated that a high level of social interactions were correlated with effective results - for example, Bank of America generated a $15 million dollar increase in annual productivity after measuring interactions and modifying break schedules to maximise interaction.
Key takeaways from Clapham's talk included: ask for feedback on your work; be curious and welcome questions; reward (the right) behaviour; ignore your job title, and focus on delivering business value; and think small.
Ilan Kirschenbaum presented "7 Dangerous Things You Should Let Your Teams Do", which was inspired by the popular TED talk "5 Dangerous Things You Should Let Your Kids Do" (and corresponding book). Kirschenbaum's core thesis was that as we now operate in a complex world in which it is most effective to probe-sense-respond; we must encourage teams to experiment, and also make it safe to fail. Kirschenbaum discussed the benefits of encouraging hypothesis creation, experimentation and retrospecting, and cited examples of experiments, such as developers from a command and control-led enterprise meeting the customer face-to-face, developers installing code on live (with appropriate safety), encouraging teams to create a FOSS project, and organising a company-wide hackathon. The final twenty minutes of the session was run as an interactive workshop, where attendees formed into groups and designed experiments they could run within their organisation.
The final keynote of the day was presented by Dan North and James Lewis, and discussed "How to Break the Rules". Quoting Eliyahu Goldratt's work in the seminal book "The Goal", North stated that "technology can bring benefits if, and only if, it diminishes a limitation", and discussed how we are really quite bad a adopting and exploiting new technology. A series of rules were presented on how to effectively adopt a technology:
- What is the power of the technology?
- What limitation does the technology diminish?
- What rules enabled us to manage this limitation?
- What new rules will we need?
Discussing technologies such as Material Requirement Planning (MRP) and Enterprise Resource Planning (ERP), North and Lewis suggested that rules for coping with old/existing process and technology often become policy or law, such as planning monthly and buying in big batches, or maximising utilisation and using cost accounting. Accordingly, when adopting new technology in these areas, organisations will need to adapt in order to re-plan frequently and order for shorter timeframes, and use throughput accounting to measure flow of value holistically. Old rules for coping when adopting cloud or continuous delivery, such as the centralised enforcement of governance and compliance, or the need for manual validation often become part of the structure or culture, and accordingly the organisation must learn how to run inexpensive experiments autonomously, and automate all the stages within a continuous delivery build pipeline.
The first day at the Agile on the Beach conference concluded with a Beach Party at Gyllynvase Beach, during which attendees reflected on the day and shared experiences, stories and Cornish sea shanties over a beach BBQ. Additional information on the conference can be found on the Agile on the Beach website, and videos of the presentations will be uploaded on the AotB YouTube channel over the coming weeks.
