You might have come to this blog expecting to read all about the Agile Methodology Steps and how to apply them. In that case, this blog is not the right one for you. In fact NO BLOG claiming to have Agile methodology steps would be right! Let me explain why.
The Agile principles and manifesto were developed in 2001 by a small group of people seeking to find a better way of developing computer software. “We are uncovering better ways of developing software by doing it and helping others to do it” they stated. Through their work they claimed, “we have come to value Individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, responding to change over following a plan”. That’s not to say they didn’t value the things ‘on the right’, but they valued the things on the left more.
With this approach the traditional ‘waterfall’ method of delivering software in a single release that may take several months was replaced with a more rapid release of software (value) and further iterative releases every few weeks or days. The approach also incorporated customer feedback and the use of it to decide what to do next.
What was created is clearly applicable beyond software – we inherited a new way of thinking about project management in general. And more than that, Agile provided us with guiding principles for behaviour. The principles enable modern organisations to flourish by instilling a culture of empirical experimentation – learning what works by trying it out rather than by theory – and creating an environment of psychology safety.
Agile Philosophy and Culture
Clearly, some major shifts of mindset may be needed to succeed with Agile working!
The aforementioned Agile pioneers came together through a shared desire to overcome problems in writing software, but also to espouse values and really ‘live and breathe’ excellence and customer centricity. They worked collaboratively to experiment and share information on what was working and what wasn’t, seeking to test out ideas, learn fast and apply the learning. This is the spirit of Agile. Does it remind you of the spirit of your workplace? Any gaps or conflicting attitudes?
Agile working represents the antithesis of bureaucracy. For example, it requires only the minimum necessary documentation rather than excessive amounts and empowers people to be accountable rather than requiring multiple sign offs, so that team members can spend their time on value adding development work. Further, Agile requires people to be comfortable with flexibility and ambiguity – responding to opportunities, challenges and changes rather than following a rigid plan. Agile working necessitates a partnership style of working with customers – it provides them with the opportunity to help shape products (and services) by allowing them to use and test early releases and provide feedback on what does and doesn’t work. These are just some of the features of true Agile working! You might already work this way. If not, what changes are required?
As for a series of Agile methodology steps that can be readily applied, there’s no single solution , but there are some useful frameworks (the most famous of which is known as Scrum), which contain best practices to get us closer to the Agile principles.
The Scrum provides an approach which supports the Agile principles and is used to help bring them to life practically and get the work done. This may come closer to the Agile Methodology Steps you’re looking for – though we prefer to describe it as a framework. The approach precedes the development of the Agile principles and manifesto, but was adopted from manufacturing by developers because it supports flexibility and speed.
Scrum requires specific roles and responsibilities to be established. These help to drive the cultural elements and the philosophy of Agile – it won’t work without them.
A key role in Agile working is that of Scrum Master. The Scrum Master’s role is to teach people about this way of working so that they truly understand it and respect it. Their role is to organise the work and to create an environment of psychological safety within the team. The Scrum Master will empower and enable team members to make their best possible contribution.
A Product Owner is also required. The Product Owner is responsible for ensuring customer views are represented. They are ruthless decision makers, who are well connected individuals who manage stakeholders and make sure the work done next is the most valuable in line with the vision.
Team Members play a vital role. They will understand the practicalities of the work and get it done. Team Members should be ‘T shaped people’ – having both a deep and a broad knowledge. Remember that Agile calls for empowered teams of people who are self-organising rather than micromanaged. Without empowerment there is a real risk of disrupting the flow and delivery of work (i.e. value) – for example if everything has to be signed off by the Leadership team or if approval is required at every step.
The way the work often gets done in a Scrum can be described as follows.
- A backlog of work is generated. It’s the responsibility of the Product Owner to agree and prioritise with customers what goes into the backlog.
- Work is undertaken via a series of Sprints. These require some planning and preparation to make sure the deliverables are clear and tasks required to achieve the deliverables are defined.
- Team members ‘pull’ work from the backlog. During a Sprint, daily Scrum meetings (progress updates) are carried out to share information on the progress being made and any obstacles or changes that might prevent the work (value) from flowing. This is a brief meeting, carried out standing up in the workplace or via a call or video call.
- At the end of the Sprint, a review of progress against the deliverables set out at the start is undertaken. A chunk of value (e.g. a feature of a product or service) can now be delivered to the customer.
- The team carries then out a retrospective review of the working process – what went well during the Sprint and what could be done better at the next Sprint is shared by the team and captured to support best practice for the next iteration.
- And repeat! The next sprint is planned. You may well recognise the application of Plan Do Study Act to Scrum working.
The use of Kanban (which has its origins in the Toyota Production System) as a project management method to support Scrum working is a relatively recent innovation. The system of displaying on a board (either physical or virtual) the tasks required and tracking them through their various stages of completion – Backlog, In Progress, Testing and Done – brings visibility and transparency to project progress, and incorporates Lean principles like ‘pull’ and ‘flow’ to keep the work (value) moving through to the customer. Using Kanban in the Scrum brings a dynamic approach – new features and tasks can be added as they become identified as important, unimportant items are removed, and the team pick work in the sequence that is most appropriate in a changing situation.
So where are the Agile Methodology Steps?
Agile can be applied to any project, process improvement or product development undertaking, and its principles can be applied to entire organisations to provide a powerful boost to performance. While frameworks such as Scrum and Kanban are used to bring us closer to Agile principles, true adoption of Agile requires more than adopting a series of Agile Methodology Steps off the shelf. Unless attitudes, beliefs and behaviours are aligned, frustrating bottlenecks will emerge, choking the flow of work and value, and blocking the real benefits of Agile.
The first step therefore is to recognise what Agile really is – a set of guiding principles, rather than a methodology or template.