Agile Coach Online

Expert support on demand

Agile Coach Online Logo

Roles in Agile - from old to new

People worry a lot about roles and responsibiities. In hierarchical organisations titles matter a lot because they often relate to pay grades and people want to progress up a ladder of ‘titles’ or ‘grades’. Agile changes things a lot, because the hierarchy of decision making and responsibility changes. It defines its own roles, but maintains a lot of flexibility in those roles. There is no such thing as ‘this is not my problem’ - so you cannot pass off responsibility by getting something signed off by another (normally more senior) person. It remains your responsibility. Similarly, decision-making is devolved so that the best people to make a decision make the decision (‘best’ here normally means best informed and most competent – it varies for every decision, and is certainly not related to hierarchy)

When implementing Agile in a large organisation there are some important things to get right:

1. What are ‘roles’ in Agile?

An Agile team is self-organising and (largely) self-managing. There is no-one in charge. This is why it sometimes looks like anarchy from the outside, but in fact it is joint decision-making and joint responsibiity. The way things are done is very well organised, but an outsider does not necessarily see this because when things are working well it looks a lot like ‘making it up as you go along’ since everyone manages their own work. One way to tell if a team is Agile is seeing what happens when something goes wrong. At that point, the methods and structure become more obvious – things like replanning happen and the underlying mechanism asserts itself. So, it is exceptions that show the non-Agile how things really work.

Agile is Agile, so truthfully there are no roles. I prefer to refer to them as ‘specialisms’. The important thing to realise is that while you might specialise in a certain area, you are part of a team that is delivering together. That means you need to understand the overall objectives, appreciate other specialisms, be prepared to make boundaries fuzzy and actively participate in ensuring the team delivers its overall goals. A fundamental part of Agile is breaking down the boundaries between roles and responsibilities. The idea of 'silos' (where each person/team gets something to do, does their bit, gets it signed off and then forgets it) is the opposite of Agile.

Having said that, there is one role that people agree must exist. Any Agile team must have a Product Owner.

Product Owner

The Product Owner is the interface between the ‘business’ and the team. We do not expect every member of the team to fully understand the business – though we want them to have a good awareness of it. The Product Owner takes responsibility for representing the business to the team and vice-versa. This includes:

A Product Owner is the key link between the team and the larger business. Individuals in the business will normally interact with the team via the Product Owner. There are times when direct interaction is appropriate (e.g. Subject Matter Expert talking to relevant team member) but it must be agreed and sactioned by the Product Owner. In particular, there is no way that a member of the business can be allowed to interact directly with the team to change planned work, change priorities or add and remove work. That would be breaking the Agile model and could easily have catastrophic consequences.

Scrum Master

Most of the time, most teams that are using Scrum approaches to Agile need a Scrum Master. If you are not using Scrum you will still benefit from an equivalent role.

Despite what some people think, a Scrum Master is not there to 'do Agile' for the team. They are there to help the team be Agile and keep improving. Some of the time (particularly in the early days of a team aiming for Agile maturity) the Scrum Master will be 'doing' the Agile processes - such as managing ceremonies and so on - but the aim is to transfer ownership and responsibility for these things to the team as soon as possible. More importantly, they will be mentoring individuals and helping the team find appropriate Agile responses to new situations.

When we are talking about working with non-agile systems outside the team, the Scrum Master is key. They have to represent the team (and particularly its Agileness) to the organisation. This involves working closely with the Product Owner (who will normally have better business knowledge than the Scrum Master) to ensure that the Agility of the team is not impeded by external factors.

Everyone else

In most Agile approaches, everyone team member who is not a Product Owner or Scrum Master is equivalent. This is important for breaking down boundaries and ensuring joint responsibility and decision-making in the team. We would expect everyone to be involved (to some degree) in: requirements, design and specification (typically through writing items for the backlog); user research (including capturing information and collecting feedback from users and stake-holders); development; testing; deployment. That does not mean everyone is completely interchangeable or has identical skills, but it important to remember that they should not be defined by 'roles' with fixed boundaries and responsibilities.


It would be nice to have all the skills and specialisms available within the core team at all times. Sadly, that is unlikely. Some skills (e.g.content designers, user researchers, specialists in certain technologies - like Cobol programmers) are shared across the organisation as needed. While not desirable, we accept this as reality. Having said that, we must understand that these 'visitors' to the team can cause issues.

The most obvious is that the visitors may not share the core values of the team. They have not been part of it so this is understandable. We should expect some overhead on 'educating' these people to the team values and approaches.

The other big issue I have observed is that these visitors are often 'owned' by a person external to the teams who is managing things like prioritising and sharing these resources across different teams. This means we are dealing with a resource which is not under team control and can cause issues. There are ways to deal with this, but the important thing is to realise that it is a potential problem.

2. What changes?

There are some roles ‘outside’ the team that are significantly affected by a move to Agile. Done properly, it is all good, but it is essential to understand and embrace these changes if Agile is going to work and deliver real benefits to the organisation.

Project Managers and PMOs

If you get it right, then Project Managers do not exist within Agile. That does not mean that the same work is not getting done, but that it is redefined in quite significant ways. This is a big change in the way we think about the work. Much of the role shifts to the team themselves and to the Product Owner in particular. A Product Owner is not just another name for a Project Manager though.

Here is where some of that work will be found:

Business Analysts

In many ways, Business Analyst is the role that sees the most change. While the skills needed in capturing the requirements of the business, users and stake-holders are mostly the same, the way that knowledge is used and communicated with the team is very different.

The "complete requirements and specification" document is dead. There are many reasons why it did not fulfil the purpose for which it was intended. We replace it with a much more incremental, interactive approach which minimises production of documentation and emphasises direct and effective communications. Is is desirable for the Business Analyst role to be handled within the team, and preferably among the team members. This is not always possible. To clarify, let's suppose we have an official 'Agile Business Analyst' in a team and understand what they do.

An Agile Business Analyst is still (as they always were) responsible for understanding the needs, processes and requirements of the business and stake-holders. This includes understanding users, who have a much more central role in Agile. We do not expect most team members to have a detailed understanding of the business. The BA is typically supported by specialist 'user researchers' and 'Subject Matter Experts' but not always. They must be able to answer questions from the team about any of these issues, preferably on-demand, but if they cannot solve a query immediately then they should have the appropriate knowledge to know who to ask about the question. The big difference is that there is no attempt to write all this stuff down in a single, comprehensive document. Instead, the BA is an 'oracle' for advice about requirements, priorities and decisions. Instead of looking at a document, team members can 'ask the BA'. Conversations and effective communications are much preferred over large and complex documents.

This is a very important role which is central to the success of the work. The BA needs to know 'enough' at all times but, happily, not everything. Just as Agile is dynamic and responsive, so is the knowledge of the BA. It is important to have the 'big picture' and interact with the business and the teams about that. It is important to have a detailed understanding of requirements (and what constitutes 'acceptance' of a solution) for a reasonable amount of work in the future. However, it is a mistake (and un-productive) to try and know too much detail, too far ahead. Agile is responsive can can adapt according to feedback, so it is only necessary to know enough detail to be able to stay a reasonable distance ahead of development work.

In Agile, a Business Analyst will typically:

A Business Analyst (where they exist) is often a key support for the Product Owner and sometimes we have to utilise the BA as a proxy Product Owner when the organisation has not assigned and supported the product owner correctly. It is important to note that if you give the Business Analyst this responsibility then you must also give them the authority to access the appropriate people and make relevant decisions.

Where there is no actual person fulfilling the Business Analyst role, it is still essential that all the things above are csomehow covered for the team.

Business Owner

A Business Owner is traditionally a person in the business who has overall responsibility for ensuring that the solution meets the business needs. In old working models they often have little relationship to the day-to-day operation of project but take responsibility for 'signing it off' - with advice from other people.

A Business Owner is never a Product Owner in Agile terms - though some people try to make that equivalence and think that adding 'Product Owner' to the titles of a Business Owner somehow makes them Agile. Product Owner requires certain skills and is effectively a full-time job within an Agile Team. Most Business Owners do not have the skills or the time to work like that - they have other responsibilities and other objectives than being a full member of the team

While accepting that most organisations will assign Business Owners to different pieces of work, the Business Owner must understand that most of their role will be filled by the team and the Product Owner. They have to learn to trust these people and take their advice.

Subject matter experts

Subject Matter Experts have knowledge of the business and needs which members of the team do not necessarily have. Historically, SMEs worked via BAs to provide requirements at the start of a project.

It is good to embed SMEs in an Agile team if it is possible, so they can provide constant and instant feedback to the team on what is being developed and how it does or does not fit business needs. If this is not possible, then there is still a very close tie between the team and the SMEs. They must be involved on a frequent basis, interacting directly with team members (with the overall guidance of the Product Owner) to help create andelaborate stories or other backlog items to the point where they are ready to develop, and engage with developers during development to have conversations that clarify details which were not included in the stories.


The worst way to think about a developer is as a 'code monkey'. That is a derogatory term which implies that a developer takes a specification, builds something that satisfies that specification and then moves on to something else. They are, in many senses, the lowest branch on the tree, just doing what they are told. Even in traditional waterfall models this was not a good way to think about a developer. People did that though and it led to things like out-sourcing development to external companies (often overseas and cheaper) who built to specification without knowing what they were doing or why and having no responsibility other that that the code they wrote should satisfy the specification.

An Agile developer is a very different thing. We appreciate that they are intelligent people who can make a significant contribution to the overall project at evey stage. We involve them at every point from initial concept to deployment and maintenance of live systems. We expect them to actively participate in planning and decision-making and that their voices are heard. We should also expect them to 'push back' on things, questioning requests and decisions (where appropriate and with justification) to inform management of the consequences and implications of the desires which they express.

Testers and Quality Assurance

As discussed elsewhere, testing and QA is not a bit of a project added on at the end. These are ongoing processes which happen in small, iterative steps. Developers must create automated tests for their own code and larger scale tests must be integrated into the Agile work cycle. Testers are an integral part of the team and should be wordraft1king on the same short cycles as everyone else. Manual testing is not a way to be Agile because it cannot work effectively on the timescales and deployment patterns involved. Testers should be part of the team and involved from the beginning in every sprint and every piece of work. It is reasonable to assume that a 'story' is not ready unless ways of testing it and ensuring it meets the known needs is included within it.

This has many advantages, including integrity of the solution, continuous checking of new deployments and ensuring that testing is not compromised because a project seems to be running behind schedule.


In the old model, stake-holders were involved with business analysts at the start of a project to support collection of requirements and again at the end to confirm that the final solution met their needs (which they often did not). A stake-holder with an Agile team should expect much more frequent (but often shorter) interaction. It is a much more active role. Expect to be invited to demos (show and tell sessions) on a regular basis. This is an opportunity to see what the team has done so far and see if it fits what you were expecting. It is also a way for the team to show you options and possibilities which you may not have considered or been aware of. Using these sessions well enables you to change your objectives and requirements on a regular basis (but in a structured way). The biggest single advantage is that you should never get to the end of a project and find it has not delivered what you need. It gives you much more control and influence over what is being developed and delivered.