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 on day two of the conference included that workplace stress can be managed and conditions created for success by applying agile methodologies in an incremental manner, self-organising teams that embrace ‘autonomy, purpose and mastery’ create a successful and resilient culture, there is need for technical leadership that encompasses programming, people and processes, and being truly agile involves working with ‘an ever evolving set of ever evolving practices’ that create the conditions and opportunities to allow people to be ‘awesome’.
Jenni Jepsen, partner at goAgile, opened the second day with a keynote exploring ‘Agile Leadership and Teams’. With the initial goals of convincing business stakeholders of the benefits of agile methodologies, Jepsen explored the research findings connected with the cognitive abilities of people under pressure, information processing and stress management. A key takeaway presented by Jepsen was the need to manage the levels of stress people are placed under, and in particular issues related to the feeling of not being in control with workloads or autonomy in how to solve problems.
Whenever an individual feels stressed or threatened their body may enter into ‘fight or flight’ mode, and accordingly the prefrontal cortex in the brain, which is associated with ‘system 2’ thinking and long-term memory, shuts down. Jepsen suggested that support and encouragement of team members is far more effective than placing yet more pressure on them, and that interactions between between people should be designed to allow flexible and optimal performance. The use of an agile methodology can achieve both of these goals
The keynote concluded by examining why it is often difficult to introduce agile methodologies into an organisation. Jepsen suggested that any kind of change leads to novelty, which in turn can lead to uncertainty. People are often suspicious of new ways of working, and may naturally resist less regimented approaches to work when they are first presented. Accordingly it is beneficial to introduce agile methodologies in a gradual and chunked approach, and allow plenty of time for people to retrospect, and discuss the challenges and benefits discovered.
Additional details on Jepsen’s talk can be found in Tony Edward’s live blog of the ‘Agile Leadership and Teams’ session on the ‘Agile on the Beach’ website, and the video recording of the session is available on YouTube.
Ricardo Mestre, an agile coach at HERE (a Nokia company), began the breakout sessions in the ‘teams’ track, and discussed the lessons learnt during the ‘Magellan’ project that he recently worked on. Mestre stated that the project consisted of 40 employees, and began with a mature agile implementation and good engineering practices, such as continuous integration and build pipelines. However, the organisation was keen to increase productivity, and Mestre helped the teams develop new ways of working with autonomy, purpose and mastery.
Core principles introduced to the teams were self-organising teams, the creation of measureable and time-boxed (SMART) project objectives, collective ownership of the entire delivery process, “review don’t specify”, “done means done”, and end-to-end verification. Twice per week the teams undertook product stand ups to ensure the current work was aligned with the overarching strategy, to ensure the forecasts were up-to-date, and review what had been delivered.
Key lessons learnt during project Magellan by Mestre included the inherent culture clash of moving to a new way of working (in which some people do not want to work autonomously), dashboards must be created and be readily available for all key performance indicators (KPIs) across all the team (transparency is vital), automated regression and performance tests provide high value to the verification process, and that time to work on action items that resulted from team retrospective must be blocked out in the team’s calendar otherwise issues may not get worked on.
In the second breakout session of the day Patrick Kua, principal consultant at Thoughtworks and author of “Talking with Tech Leads”, presented “The Geek’s Guide to Leading Teams”. Kua opened the talk by asking why we need the position of technical lead on a software development team. After discussing several suggestions received from the audience, consensus was reached that a tech lead can help maintain shared understanding and consistency (where appropriate) within a team. Kua suggested that a tech lead’s role can be categorised into ‘three Ps’: programming, people and process.
Programming in an essential skill for a tech lead, and regular interaction with the project codebases a lead to build and understanding of the challenges presented, and develop an empathy with struggles being faced by the rest of the development team. Technical leads should strive for ‘consistency over cleverness’, and assist in establishing and communicating a shared architectural and technical vision.
People skills are also vital for a tech lead role, and growing and maintaining a good team culture is vital. Indicators of technical team health include how long a broken build remains broken, the desire to avoid conflict, the rate at which new ideas are offered, and how easy team members find asking for help. Kua suggested that helping to grow the team is also a key area of responsibility, and books such as “Strengths Finder 2.0”, “The Difference” and “Growing People” are useful resources.
The final section of the talk examined process, and began with an exploration of whether it is acceptable for a tech lead to tell people what to do. The answer of ‘yes, but only sometimes’ was offered, and the use of the situational leadership model for help in determining the appropriate actions for a given context was presented. Tuckman’s stages of group development were also discussed, and Kua stated that he has found this model useful for identifying appropriate actions to take depending where on the model a team is currently operating at. Kua concluded the talk by stating that it is essential for a tech lead to make time for themselves, or otherwise it is easy to operate in a purely reactive mode.
Rachel Picken, director at MPAD, presented “Further Adventure with Agile Communication” in the third breakout session of the ‘business track’. A core message presented within this talk was that creating a shared understanding is essential for success when working with customers, and interrogating project objectives is vital in order to build strong foundations when using an agile methodology. The requirement to provide long-term forecasting of work (and associated plans) within an industry unaccustomed to agile methodologies can also extremely challenging, for example within the domain of public relations where stories and trends change rapidly, which directly impacts the ability to plan too far into the future.
Pickens shared a story of a failed project, where the lack of opportunity for collaboration with a customer prevented the team working successfully in an agile fashion. The key lessons learned included that “responding to change, over following a plan” is vital within a project, it is useful to apply a 'maturity-based' scoring matrix for new clients in order to assess whether they will be capable of working in a agile manner, and retrospecting with the team and client is essential (although often difficult).
The closing conference keynote, “Continuous Discovery: The Power of Pure Agile” was presented by the inimitable Woody Zuill, and began by postulating that operating in a truly agile manner involves the use of “an ever evolving set of ever evolving practices”. Zuill examined the wording of the original Agile Manifesto, and suggested that although the original intention of the manifesto values may have been a one-to-one mapping between the items on the left and the items on the right (e.g. ‘working software over comprehensive documentation’), it would be better to believe that “any item on the right MUST NOT detract from ANY item on the left”.
Quoting John Gall, Zuill continued the talk by discussing how software systems typically evolve from simple to complex, and ineffective (but common) working practices can lead to a ‘cycle of continuous no-improvement’. Often when building software systems it is in the doing of the work that we discover the work we must do (“doing exposes reality”), and therefore it is beneficial to approach work in an agile fashion by creating “recognisable, understandable, cohesive, potentially valuable chunks of stuff”, so that tasks can be decoupled, worked on and deployed in order to provide feedback.
Zuill concluded the keynote by stating that true leadership is defined by creating an environment where everyone can excel in their work, and by providing the opportunities for people to be 'awesome'.
Additional details from the ‘Agile on the Beach’ conference can be found at the event website, and videos of the presentations are gradually being uploaded to the conference YouTube account.