Agile Coach Online

Expert support on demand

Agile Coach Online Logo


Everything you always wanted to know about Agile but were afraid to ask

This is a concise summary aimed primarily at people who are working with Agile teams, but are outside them. Loosely speaking, these are "stakeholders" such as change owners in the business, separate UAT teams or Subject Matter experts. This includes managers, planners and senior management to one degree or another.

Audience

You are probably part of a large organisation, have requirements to satisfy business needs, and need a development team to make this happen. The organisation has Agile teams but you are not part of the Agile thing (yet). You most likely work to budgets, deadlines and resource commitments. It is quite likely that you understand traditional “project management” but do not see how it relates to this Agile stuff.

Contents:

  1. Introduction
  2. What is an Agile team?
  3. Organising work
  4. Interacting with the team

1. Introduction

Agile works brilliantly in small companies or companies which have always worked that way (e.g. Google, Spotify). A big company can often see the advantages of Agile and will move their developers that way, but they commonly fail to recognise that this means other parts of the company also have to change in the way they work with these teams. Agileness will expand from the developers but, until you become Agile across the organisation, it is important to understand the relationship between agile and non-agile people.

Agile is a way of working which is efficient, continuously improving, and responsive to change (among other things). It delivers the solutions people actually need. My experience is that people who are 'anti-agile' are often reacting against what they think Agile is – not what it actually is.

First, let's get rid of some mis-conceptions

Mis-conceptions are explored more in another article, but these are probably the most common ones.

2. What is an Agile team?

An Agile team is not a team of developers. If you are still thinking about capturing requirements, specifying solutions, then 'throwing them over the wall' to a team of developers, you are missing the point (and the benefits) of Agile. One common example of this is people who try to get all the 'stories' for a project written in advance (often by a third party) and then hand them over to the team. This is just a traditional approach done in smaller pieces. The stories must evolve and change as the team progresses. This is part of the fluidity that makes agile effective.

The core of an Agile team is:

  1. Product Owner(PO) - A key role. The Product Owner is the primary interface between the development team and the Business. They need skills and knowledge on both sides. They take the lead in co-ordinating requests from the business, planning work (both short and long-term), prioritising activities, escalating issues from the team to the business and more. They are not a Project Manager (because the team is self-managing) but they are as close as it gets
  2. Developers - In the simplest model, everyone who is not the Product Owner is a developer. These are not developers as you might think of them traditionally. You do not give these people specifications and they program them like a bunch of monkeys. These people are active participants in requirements capture, specification, development and testing. They are also all expert in the agile processes and in contributing to the management and improvement of the team

In addition to these people, you are quite likely to find:

  1. Scrum Master - Helps the team be Agile. This includes ensuring everyone knows and follows the appropriate processes, advising how to be agile in novel situations, reflecting the behaviour of the team back to the team to assist continuous improvement, helping to unblock any blocked issues. In an organisation this scope needs to extend beyond the Agile team itself to help set the expectations of the business, push back on unreasonable requests, create dashboards to enable people outside the team to see appropriate information and advise them on how to interpret this information. The scrum master will work closely with the Product Owner to ensure interaction between the business and the team is working smoothly and appropriately
  2. Technical Lead – Often useful is to have one senior developer who represents the others. They may have more expertise (particularly at the architectural level) than the other members of the team, or it may simply be that the team find it useful to have a single technical touchpoint. The Lead helps resolve architectural decisions, ensures consistency across the team approach, works to provide technical advice to the Product Owner and the business, plus drives the unblocking of items which are blocked for technical reasons

These are not essential in a mature team because these roles will be shared between all team members. They are very useful in developing teams.

3. Organising work

Work is broken down into small pieces which are kept, in a prioritised order, in the 'backlog'. This is reviewed continuously (or at least once per sprint) to make sure it remains current. Work can be added, removed or modified. Although the backlog idea is slightly different, you can think of it as a plan. I encourage teams to tentatively allocate backlog items into sprints up to 3 ahead of the current sprint. If you allocated more than that then you would be going back to waterfall and become unresponsive. This process is called "Backlog Maintenance" or "Backlog Grooming" and is led by the Product Owner.

You may hear these things in the backlog referred to by many names - tasks, stories, issues, items, PBI (Product Backlog Item), ticket, Jira. They are not all the same. The three most important are:

Epics, stories and tasks will be created, modified, removed or implemented over the course of a project. The complete set of epics and stories will not exist until the project is over. Many items in the backlog will not be "Ready". That is natural because developing the stories to readiness is a collaborative process and so 'skeleton' and 'partial' stories are an integral part of that backlog. Helping to bring stories into a state of readiness is an important part of what members of the business do to support successful Agile.

For planning and progress tracking, I recommend using higher level groupings of epics (such as Feature Sets). These can generally be mapped out at the start of the project and should remain fairly stable. They satisfy the progress and reporting needs of most people outside the team. They can also be used for high level estimation as well as managing deadlines and dependencies. They are monitored and updated as the project progresses to ensure that they are as accurate as they can be given the information available at any given time.

We can also group these stories in various other ways. Choosing the best way to group them is an important aspect of setting up a project.

4. Interacting with the team

The Product Owner is the primary interface between the Agile team and the business. Do not approach other members of the agile team directly to ask for work to be done, to change priorities or to get updates on progress. These should all go via the Product Owner, who has overall responsibility for these things. We need to maintain this agile model if we are going to work in a controlled, systematic and effective way. This does not mean that there cannot be direct interaction between members of the business (e.g. Subject matter experts) and the developers about other things. Discussions, conversation, clarification are all part of the Agile process and should be done as directly as possible and with as little overhead as possible - though with the awareness of the Product Owner. Creating stories and making them "ready" is the key platform where these direct discussions can take place.

Almost all Agile teams work on the "Scrum" approach – though this is not the only one. The key to Scrum is the idea of a "sprint".

A sprint is a fixed time period. The team agree what work will be achieved during a sprint and commit to delivering it. They then do that work and (hopefully) achieve it all by the end of the sprint. A sprint:

It is not generally acceptable to ask the team to take on new work within a sprint, or to change the requirements for something which is already in the sprint. If this is essential (which does happen occasionally) then technically the sprint is stopped and re-planned. The Product Owner leads in justifying why the new work is necessary and deciding what should be removed from the sprint so the team can still deliver within capacity. Directly approaching the team members with changes is never acceptable.

You will not participate in Sprint Planning sessions. The Product Owner acts as your representative during those sessions.

You do not need to know what goes on inside a sprint. Trust the team. If something happens that will affect you, then the Product Owner and/or Scrum Master will flag it up to you