/\/\   ___   ___ ___  ___  ___
 /    \ / _ \ / __/ _ \/ __|/ _ \
/ /\/\ \ (_) | (_| (_) \__ \ (_) |
\/    \/\___/ \___\___/|___/\___/

A collection of Joel Chippindale's infrequent reckons

Running an agile principles study group

When I joined Unmade, our Engineering Team had already adopted a number of practices associated with agile software development, for example continuous deployment, daily stand ups and regular retrospectives. However these were being carried out in isolation from other disciplines in the company and so, although many were useful practices, they were not having nearly as much impact as they could have had.

We set out to improve on this by adopting more agile practices across the company. I am really proud of the way in which everyone has embraced the changes involved and of the impact they have had in enabling us to make better decisions and work together more effectively.

There were many elements to making these changes but one important part of this was to make sure that the underlying agile principles were well understood and acted upon by everyone involved in making decisions about our software. This included members of our leadership, sales, customer success and design teams as well as our product and engineering teams.

What we did

One of the ways that we worked to achieve this was by running an agile principles study group which we opened up to the whole company. We based our study group around the excellent Troubleshooting Agile podcast, which includes 12 episodes (1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12) that are dedicated to discussion of each of the agile principles in turn.

We met every fortnight and before each study group session we would listen to the podcast episode about the corresponding agile principle.

Our format for each session developed over time but, thanks to a suggestion from Jeffrey Frederick, we settled on the following format for these sessions - the timings are fairly rough.

  1. Have one member of the study group summarise the key points made in the podcast (5 mins). We did this to make sure the podcast was fresh in everyone’s minds even if they had actually listened to it a few days beforehand or in some cases had not had a chance to listen to it.

  2. Discuss our understanding of the principle (15 mins). This helped us understand how we interpreted the principle, how we understood it to help and where we thought we might disagree with it or see particular challenges in applying it.

  3. Discuss how the principles applied to us at Unmade (15 mins). This helped us try and apply the principle to our experiences within our company. We typically discussed examples of where we were using this principle and where we thought it may have helped us overcome problems we faced.

  4. Identify changes we want to make as a result of our reflections on the principle (15 mins). We did this to help ensure that this was not an abstract intellectual exercise but one that explicitly impacted our behaviour.

    For example, actions taken in response to our discussions of agile principle number 5, “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done” included the following:

    • One of our Project Managers, Sarah, ran a session to help the cross-functional team she was leading support one another better and feel more in control of their work. In that session they worked to make each person’s role within the team more explicit and then she got team members to share how they could help each other in their roles which helped break down barriers between the disciplines and gave team members more confidence to offer one another support.
    • I gave a company wide talk about taking authority for decision making to make our adoption of this principle more explicit.

The impact

It has been really inspiring to see how members of the group, from all disciplines, have gained confidence in their understanding of the agile principles and how to apply these principles in their roles and teams. It has also been gratifying to see that we have been finding it easier each meeting to draw upon positive examples of how we have already been applying these principles in our work.

One of our Product Managers, Katie, shared the following about her experience of being part of the study group:

Since starting the study group, I feel we have become far more confident about guiding our customers to rapid and regular delivery of valuable software that meets their needs, rather than more traditional waterfall methods which they might be more used to. For example, we have phased out the concept of ‘UX/UI design reviews’ which are vastly upstreamed from a software development phase, and instead show our customers real working software as soon as possible, which is iteratively improved. This has meant we can reduce delivery risk and time to launch considerably.

Although I was already familiar with the principles it has been very valuable to regularly discuss them with a range of other disciplines in the team, and to collaboratively decide if and how to action any changes as a result. It has helped me understand how other people experience the challenges and opportunities of working in this way and I feel it has noticeably increased the empathy and understanding of agile product development practices across the company.

We’re coming to the end of our study of the 12 agile principles and given how successful it has been we are wondering what to study next.

Thanks to everyone who took part in our agile principles study group and also to Jeffrey Frederick and Douglas Squirrel of Troubleshooting Agile who not only provided us the source material and a suggested format for this study group but also inspired me to set up my first work study group in a previous role.

Further listening and reading

This is part of a series of talks and articles about the work and practices of my teams and I at Unmade.