
An introduction to self-management
Self-management isn’t chaos. It requires management to set guardrails that define the boundaries for team-level actions,
Agile’s roles tend to be sourced from the Scrum framework [1]. They consist of the following:
The Product Owner is accountable for maximising the value of the product resulting from the work of the agile team.
The Product Owner is also accountable for effective Product Backlog management, which includes:
The Product Owner is responsible for:
The Product Owner needs the authority to make decisions about what the team should do and when. They are responsible for the budget and how much of the team’s time should be invested in producing product solutions and delivering services to the rest of the organisation.
Some organisations feel that Product Owners should write all the backlog items (“user stories”) and, because those activities are similar to those of a traditional Business Analyst (who writes requirements), a Business Analyst should become the Product Owner. In most organisations, though, requirements require approval. This results in a Business Analyst / Product Owner seeking sign-off of backlog items, producing delays in decision-making regarding what the team should focus on in any given Sprint.
This anti-pattern is called the Proxy Product Owner. This should be avoided.
Product Owners are a strategic role acountable for connecting the organisation's strategy into an implementable product vision through to execution and delivery. This is not just a traditional B.A. role.
Using the stakeholder as the Product Owner comes from the agile framework Extreme Programming (XP). This can work well, so long as:
In the latter instance, the Product Owner tends to become a committee instead of a single person. Avoid this anti-pattern.
The Scrum Master isn’t an “agile project manager”. They’re not responsible for making the team deliver. Their responsibility begins and ends with establishing Scrum (as defined in the Scrum Guide) and ensuring its effectiveness.
While the Scrum Master is a leader and facilitator, they aren’t the team’s secretary. Many teams get their Scrum Master to book Sprint events, write reports, and manage the Scrum board. This anti-pattern is often referred to as the Secretary and should be avoided.
The Scrum Master is not there to book meetings, invite participants, and take notes. This anti-pattern is called the Secretary and should be avoided.
Scrum calls the people who do the work “Developers”. This is because these people are the ones who develop the product (or service) by doing the work.
Developers are self-managing, meaning that they work within the guardrails of Scrum, and from a single Product Backlog. No one from outside of the team should be telling them how to do their work. Ultimately, Developers are committed to creating a usable Increment each Sprint.
When a Scrum Master or Product Owner contributes to the Sprint Goal by doing work, they’re also referred to as a “Developer”.
While the specific skills needed by the Developers are often broad and will vary with the domain of work, Developers are always accountable for:
Self-management isn’t chaos. It requires management to set guardrails that define the boundaries for team-level actions,
Developers are the people in the Scrum Team that are committed to creating any aspect of
What does it take to lead an Agile Release Train as its Product Manager?
What does it take to lead an Agile Release Train as its Product Manager?
Build stronger teams through prioritising and serving the greater good.
What are the opportunities for Project Managers as the organisation moves to Scrum?
An activity is designed to help improve awareness of agile roles.
1. Schwaber, K. and Sutherland, J. (2020) The Scrum Guide. The Definitive Guide to Scrum: The Rules of the Game. November, 2020.
2. Overeem, B. (2016). The 28 characteristics of a great Scrum Master. Online at: https://www.scrum.org/resources/blog/28-characteristics-great-scrum-master
All fields are required.