Everyone wants to be more agile, but no one agrees what that means. For some people, agile refers to an attitude or set of behaviours that individuals need to adopt to be responsive and resilient in the face of change and uncertainty. For others it’s about flexible working – flexible hours, working from home, remote working, Activity Based Working – essentially bringing a degree of flexibility into the way that individuals within organisations work.

At The Pioneers, when we talk about agile we’re referring to the working practices developed in the tech industry and we have a specific definition in mind…

Agile is a set of principles about how to structure and progress work. It enables teams to deliver value incrementally in short cycles of plan, do, review, plan etc. Products/services/strategy are developed iteratively and the direction is informed by user behaviour and data.

The rise of agile…

Most agile methodologies were developed by the software industry in the 1970s and 80s as advancements in new technologies ratcheted up the pace of product development. Today agile is the default operating principle in technology businesses.

As technology has permeated the core of more and more businesses, agile ways of working have come in their wake. Non-tech teams have become intrigued not just by the technology being developed in the businesses they work in, but also by the way in which it’s being produced. Increasingly non-tech teams and businesses are turning to agile practices in an attempt to build more customer centric products in an increasingly complex environment.

A word of caution here – agile is best suited to situations where there is high uncertainty in cause and effect. It is not appropriate for all teams and organisations. For example, engineering and construction teams that rely on the laws of physics to govern the work they do are likely to cause more harm than good if they tried to introduce agile practices to the way they work.

What should you know about agile?

One of the simplest and most widely used agile frameworks is scrum. If you’re exploring whether agile might be appropriate for your team or organisation then you should be aware of these basic principles and practices of scrum…

Key principles

  • Transparency and trust. Agile relies on having an environment where everyone has access to the information they need, the progress of other team members and any issues they’re facing. Agile teams surface issues that might be getting in the way of their success.
  • Inspection and evidence based judgements. In agile, frequent inspection points are built into the way teams work, allowing them to regularly reflect on how work is progressing and to keep reconnecting to the value they’re creating. 
  • Adaptation and eliminating waste. Agile teams continually reflect on how they’re working and revise what they’re doing in response to frequent inspections. Redundant work is stopped as soon as possible. 

Key events

  • A sprint – a fixed period of time (less than a month) in which a team produces a potentially ‘shippable’ increment of product/service/strategy.
  • Sprint planning – discussion to determine what to get done during the sprint. The team determine how they will successful deliver the agreed output including breaking it down into specific tasks if necessary.
  • Daily stand-ups – a short conversation (usually limited to 15 minutes) in which the team coordinate their activities for the day. 
  • Sprint review – meeting at the end of the sprint with the entire team and stakeholders of the output. The purpose of this is to discuss, demonstrate and potentially give the stakeholders a chance to give feedback.
  • Sprint retrospective – team discussion after the sprint review to reflect on how things went during the sprint and identify adjustments the team could make to the way they work going forward.

Key roles

  • Scrum team – includes everyone who is delivering something to what’s being built in that sprint. In agile organisations the team is the primary unit, not the individual. Teams collaborate and self-organise to do the work. The team takes collective responsibility for successes and failures.
  • Product owner – person responsible for ensuring the value of what’s being produced. The product owner prioritises and frames the problems to be solved by the team. They also have final decision on sign off and release of the sprint output – does this iteration deliver on the brief?. 
  • Scrum master – person responsible for how the team works together: the process, interactions, values and behaviour. The scrum master tries to make the scrum team more effective over time. They help ensure value is created and released in small increments. 
  • Developers – these are the problem solvers on the team: what’s the most effective way of delivering this brief? Developers deliver iterative releases. They are ‘subject matter’ experts. 

For people unfamiliar with it, agile comes with a baffling array of new terminology. I’ve stuck to the most basic principles and cornerstone practices above. There are tools and practical skills that support agile ways of working which I’ll come back to another time. 

I personally believe that agile can be of enormous value in non-tech environments, it’s about understanding the principles and testing different practices to find your own rhythm and way of working. If you’d like to explore what this could look like for your team then please do get in touch.