Building an Agile Organisation

Establishing a new software company through continuous improvement and by anticipating future challenges.

Much is written about agile transformation, but how do you go about building a mature agile software business from the ground up? As we reach Audiogum’s second birthday, it seemed a good time to reflect on what we’ve done here and to share some ideas that could benefit startups going through the same journey.

Expectations of an agile process

When we talk about Agile at Audiogum, we mean a mindset and set of practices that help us achieve the following:

• Embrace change
• Maximise value delivered to our clients
• Minimise risk by ensuring we fail fast (in time to correct) or not at all
• Continuously improve
• Practice technical excellence

Map out your approach

Being prepared to embrace change shouldn’t prevent you from considering the challenges you will likely face in the future and how you might tackle them. At a high level, we think of our ongoing development in different phases:

We’ve identified certain drivers that require dedicated effort to ensure our business stays on track, although reaching these trigger points does not mean that the previous stages should be thought of as being complete. Established practices will continue to evolve over time as we strive to find ways to improve any part of our business.

We feel we're currently between the third and fourth stage. We’re improving the way we manage our work and although we can’t be sure what comes next, we’ve explored ideas to anticipate how we can scale the organisation further as we grow.

We've taken the approach of building an agile org in the way we would build an agile product. Although we feel we have a good idea of where we want to get to, we’re creating it incrementally, adding new capabilities and complexity only when required. But just as with a product feature, each piece of the puzzle we add must be high quality and ready for prime-time. And what you learn along the way may subsequently lead you in a different direction.

Phase 1: People, tools and processes

Recruit, Establish relationships, Build shared vision

The challenge of bringing people together from different backgrounds can be easily underestimated. We were in a fortunate position that Audiogum was founded with an experienced team, with many years of working in similar domains that allowed us to almost entirely bypass this phase.

While we brought different experiences to Audiogum, we also had the advantage of a long history of working closely together, an unwritten set of common values and a shared vision of what a successful software company looks like.

For many, addressing this only begins in this first stage and may take years to establish with the potential for lots of personnel changes along the way.

Identify ways of working

You may start out with no software methodology at all, or a proven, widely understood agile process such as Scrum or Kanban. Between us we have many years’ experience in successfully delivering software using practices such as XP, Scrum, Kanban and Lean and have gone through various training and certification courses. Over the years, and in the spirit of continuous improvement, our approach has evolved. We don’t currently claim to be doing any specific agile process, instead we continue to borrow, learn from and be inspired by many different practices.

We typically put Agile principles ahead of any specific methodology. In addition, themes of collaboration, autonomy, fast feedback, transparency and eliminating waste come up repeatedly. A key objective of ours is to stay as lean as possible, for as long as possible. In practice this means keeping things simple and not introducing tools or process until they are actually needed to address an existing problem. When action is required, we strive to limit the impact of the change through automation or by absorbing it into an existing activity.

Choose technologies

Being too quick out of the blocks can lead to problems further down the road if you make poor technology choices early on. It’s not easy to strike the right balance between getting started quickly and taking enough time to be confident of your choices. Arguments over individual preferences can also slow down progress unnecessarily.

This was the one part of this initial phase that we did invest some time in. Although we had a good idea of what we wanted to adopt, we took this opportunity to investigate some emerging tech and to re-consider our preferred toolchain. Our resulting architecture is one that we are all solidly behind.

Phase 2: Create high performing teams

Being quick-to-market will be the priority for many new ventures, but it is important to consider the implication of going too fast on your future productivity. As we built our platform and app development capability to serve our initial customers, we introduced many practices which are typically associated with high performing agile teams.

Enable high productivity

Giving everyone the opportunity to do a productive day’s work involves creating the right environment and eliminating waste such as unnecessary ceremony or meetings where possible. We look to employ people who given the right conditions will naturally make the most of it. The focus is on enabling this behaviour, not trying to enforce it.

But there is little value in being productive if people are not delivering the most important things for our clients and business. We currently review the priority of our backlog items every two weeks and our high-level strategy every six weeks. We don’t work in fixed iterations with upfront commitment. Instead daily discussion means that we are comfortable with changing direction at any time.

Set a sustainable pace

A sustainable pace isn’t just about the load placed on the workforce. As well as providing flexibility, time and support for training, it is crucial that we are building high-quality software assets for the future. This means taking the time to think about the design and architecture of our solutions, to refactor code and address technical debt. The engineering team is trusted to invest time in these areas as they deem it necessary to do so and to take a pragmatic view on such activities. They don’t have to ask permission or trade-off these efforts against feature development.

Close interaction

Fast feedback and close collaboration are cornerstones of the way we operate. At this stage if your company is small enough to operate effectively as a single cross-functional team, many of the problems of communication that occur in larger companies are eliminated. This constant alignment and efficiency of communication is one of the things that makes us able to adapt to change. In later phases, maintaining this advantage as the business grows is one of the key objectives.

In addition to working closely throughout the day, we currently have daily stand-up meetings but like anything we only continue to do them as long as they provide value and a return on the time taken. Weekly Show and Tell sessions give regular opportunity for people to demonstrate completed tasks through working software, to present design concepts or share knowledge or information. Retrospectives help to stop us getting complacent, encourage frank discussion and allow us to frame experiments in an attempt to improve any part of our working life.

We prioritise, plan work and break it down into small, deliverable slices as a group. Working in small batches increases the throughput of work and greatly reduces the need for estimation or velocity tracking as well as ensuring we can re-prioritise at short notice. As a group, we have lots of leadership and agile experience and so we jointly facilitate and share responsibilities that would be typically thought of as belonging to a Scrum Master or Agile Coach.

Practice continuous delivery

To realise value from these small batches of work, we adopt practices that allow us to deliver software updates regularly throughout the working day. Building on continuous integration, automated tests and platform monitoring. We push small changes to production multiple times each day. A change to our APIs can be tested and live in minutes.

We generate multiple release candidate mobile app builds a day. Each one a small improvement on the last and a vital source of feedback on whether we are going in the right direction. We look for opportunities to streamline the whole flow of work. A designer can change an icon and have it built into a tested, release candidate app within 10 minutes.

Minimise defects

For all of our projects, defect counts are kept at or around zero. When a defect is raised, it is triaged, then either fixed quickly, recategorised as a backlog item or identified as not important enough to fix. Manual testing is kept to a minimum through a culture of automated testing, using our own software in anger and knowing our products inside out.

Low defect counts also tend to lead to less obvious benefits, such as quicker identification & resolution of new issues, easier root cause analysis, less interruption and faster decision making.

Phase 3: Manage the flow of work

As a functioning platform and apps have opened up the opportunity to work on a wider range of projects and explore new ideas, we continue to focus on improving how work moves through the system and how it is prioritised.

Align strategy

As more work starts to come into the system, it is useful to be able to measure how the projects that are being undertaken or proposed align with the strategy and goals of the company. This kind of discussion can drive thinking about limiting the work in progress, whether we are prioritising the right things and whether our company goals are right in the first place.

Harness innovation

We want innovation and creative thinking to be a part of our everyday culture. Rather than having one-off scheduled hackathons, we have regular opportunities for people to share ideas and get help in fully forming them. Building some natural slack time in the system gives the opportunity for us to progress such ideas.

Filter opportunities

A regular Product Forum gives everyone the opportunity to be involved in shaping ideas and influencing priority. We find that exploring ideas as a group works well. Possible avenues to explore are filtered down by referring to the strategy, assessing their value and prioritising accordingly.

Measure, don’t guess

We prefer to use data over opinions or guesswork where we can. To some extent we’ve always done this, but with more work coming through the system in this phase of our development, it is more important to ensure that we are making the right decisions.

For example, analytics and UX Testing give us insight into how users perceive our products. Monitoring of our platform allows us to see how it is performing in real time. Gathering and publishing data on all parts of our business becomes more important.

Possible future phase: Scale the organisation

What will come next? We feel that while we should anticipate change, it is useful to consider what challenges may come up in the future and how we might address them.

Many of the benefits of working together in a small group will start to erode as we grow. While we are already taking on new staff, there may come a time when we grow to an extent that it requires a significant change in how we work.

Publish values

Something we’ve already started doing is to better communicate our values. In a small group who collaborate well, values tend to be implicit, but replicating those same behaviours across larger distributed groups requires a clearer definition of what we stand for.

Increase transparency

Transparency happens by default in a small organisation, but to empower teams to make decisions, information has to be widely circulated. This is not only about making that information available, but actively publishing it throughout the business so that people know what is out there and don’t have to ask or look for it. Giving everyone a clear picture enhances decision making at all levels.

Cross-functional teams

We’ve had success in the past allowing teams to own business or customer problems and challenge them to solve them with their own creativity. In future, we anticipate that we’ll need to draw on our experience of this and work in cross-functional, goal-oriented teams.

These teams are short-lived, coming together to achieve a specific goal before disbanding as people move on to the next challenge. This fluid movement of people helps to retain the close knit feel of a smaller organisation and spread a consistent set of values. Communities of practice for different disciplines, skill sets and interests help maintain and define best and emerging practices.

Team autonomy

In order to empower these cross-functional teams to be able to deliver, they need the autonomy to make whatever decisions and changes are required to meet the challenge in hand. This may mean a range of different disciplines on those teams.

A high-level of trust in the organisation and setting the right conditions to allow teams to fail safely is necessary to encourage the right balance of risk taking to drive innovation without unduly damaging the business. Servant leader roles may be required to help facilitate teams.

You’re never done

If you fully adopt the idea that you embrace change and are improving continuously, the current status of your org can only ever be a snapshot of a larger, constantly changing picture. However, embracing change shouldn’t stop you from anticipating future needs and thinking about how you might tackle them. Just like an agile product, keep it working, prioritise and deliver the changes that get a high return on investment as and when you need them.

Two years on from the founding of Audiogum, we’ve come along way, but we appreciate that as we grow as a company, things will need to change. Whatever the future throws at us, we are confident that our principles and experience will help us to figure out how to adapt when the time comes.