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:

• A title is not enough. Calling someone ‘Product Owner’(for example) does not make it so. You need to ensure that you understand what the role involves, that the person allocated to fulfilling the role understands it, and that you give them the resource, training and control needed for the role. It is quite common for organisations to change people’s titles so it appears more Agile without actually making the associated changes in working practice
• Agile is not just for 'development teams'. Although this is the most common (and generally the best) place to start, simply changing the way these teams behave will not realise all the available benefits. Ultimately, we would like the whole organisation to become Agile, but the reality is that we must plan for a period (possibly quite extended) when we have Agile teams operating within an organisation which is not, in itself, Agile. It is essential that we spend time helping people outside the team learn to work effectively with the new working practice of the teams - including how to interact with the team, what to expect from the relationship and how existing practices need to be modified or restructured. The articles in this section of this site are intended to address these things in general. It is also a significant part of the Scrum Master role to support these changes beyond the immediate team with which they are working
• Adoption is an ongoing process of change and improvement. You cannot 'become Agile' overnight. Becoming Agile is, in itself, an Agile process. Try not to think of it as based on 'deliverables' and 'deadlines'. We can identify and prioritise changes and innovations, monitor progress and adapt our adoption process accordingly. A good way to start is looking for changes which add maximum value for minimum effort. This does not mean we cannot have objectives, metrics for adoption and so on. These are all fine as long as we accept that they may be modified as we learn more
• You cannot 'impose' Agile. Effective Agile involves devolution of as much decision-making and responsibility as possible. Everyone needs to have ownership of their part of the Agile processes - and that only happens if they believe in them, value them and actively seek to improve them. This may seem to take longer than imposing Agile top down, but ultimately it is much more effective. Of course, the reality requires some high level commitment from the organisation, but the details must be allowed to evolve
• Your Agile is part of your organisation - you cannot simply copy it from somewhere else. For example, it is not uncommon to see people saying 'we use the Spotify model'. The truth is that good Agile evolves as a product of the organisation, the situation, the teams and the advice and support that is available. There is no problem with borrowing ideas from other places or basing your approach on something else - but for it to be effective it must be adapted (over time) to fit the specific context in which you are working

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:

• Communicate business objectives to the team in an appropriate manner
• Turn business goals into work the team can achieve
• Confirm that work by the team satisfies business needs
• Use Business Knowledge to prioritise work for the team
• Identify changes from the business which impact upon the work of the team
• Inform the Business about progress within the team
• Escalate any issues the team cannot resolve to the appropriate people within the business in the appropriate manner

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.

Visitors

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:

• Planning - In the backlog. The name can be mis-leading but the backlog embodies everything to be done by the team - including detailed planning, big picture planning and forward planning for things such as managing dependencies, deliverables and resources. We do not plan in too much detail or too far ahead (except for essentials), but all that planning is in the backlog. This work is overseen by the Product Owner - with input from elsewhere in the business and the team as appropriate. Small scale planning (e.g. sprint to sprint) is ultimately managed by the team themselves based on what is in their backlog
• Progress tracking - The team track and manage their own progress - generally with the support of a scrum master. Normally this means committing to do certain work in a certain time period, then looking to resolve any deviations from that commitment. A mature team reviews this on a daily basis and supports each other in achieving the planned progress. There is a 'bigger picture' to be shared with the business and stake-holders. Providing and explaining that view is the overall responsibility of the Product Owner and is done through regular demonstration sessions and other mechanisms as appropriate
• Issue management - Issues and problems arise. It is inevitable. There are very clear ways of dealing with them. First line of defence is the team stand-ups (or similar frequent meetings). Since the team take joint responsibility for delivery, they use this daily oppoprtunity to identify any problems or potential problems at the earliest opportunity. This gives us rapid reaction times and prevents issues progressing unchecked. Once such an issue is raised, it is dealt with as:
  • Resolved within team if possible (generally with help of Scrum Master, Product Owner as appropriate)
  • Resolved with team and stake-holders together (via a PO and SM)
  • Escalated within the conventional organisation if it cannot be resolved as above

  Like many things in Agile this approach is not, in itself, anything new. It is a variation on "Management by exception" - a technique that goes back to the 1940's and is also part of Prince2

• Re-planning - It is worth mentioning re-planning as a separate entity. The team runs planning sessions frequently (typically once per sprint, so every few weeks). The fuel for these planning sessions is the backlog, which should be constantly maintained and updated by the Product Owner - reflecting changes in business priorities, requirements etc. If all this is working well, then re-planning should never (well, rarely) happen. We do have a mechanism for handling in though. It provides a system for handling urgent changes which escaped the normal process. It is run and led by the Product Owner, but the whole team decide when a re-plan is necessary
• Reporting - We avoid 'writing reports' because this is time-consuming and the reports will be out of date by the time they get to relevant levels of management. Instead we work towards dynamic presentation of progress using things like 'live dashboards' so a clear link to facts and empirical evidence of progress is visible. Direct engagement with relevant parties using these tools is the preferred way to 'report' what is happening

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:

• Interact with the Business and team to develop overall goals, objectives and acceptance criteria for a solution
• Work continously on taking high level requirements and turning them into backlog items which are at a sufficient level of detail for the team to pick up and develop
• Clarify details of items on which the team are working by providing advice and facilitating interaction with specific Subject Matter Experts and stake-holders as appropriate
• Participate in planning to ensure business priorities and needs are represented
• Work with testing, QA and deployment processes to ensure that the delivered solution meets the business needs

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.

Developers

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.

Stake-holders

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.