When transitioning to Agile methodologies it can be easy to gloss over the fundamental knowledge, skills, and abilities (KSA’s) required to compose a successful team. I’d like to cover the roles and KSA’s of typical Agile projects. This is not meant to be a strict guideline but rather a road map to inform your decision making when forming your teams and assigning roles within those teams.
An Agile project is typically comprised of the following roles:
- Product Owner
- Scrum Master / Coach
- Team Member(s)
- Stakeholders
Each of these roles have their own desired KSA sets, as they serve different functions within the team and provide different value to the agile process. However, one of the attributes that all team members should share is the ability to effectively communicate. This is outlined in the Agile Manifesto as ‘Individuals and Interactions Over Processes and Tools.’ This value sets a framework for developing a successful team and trickles down into the rest of the core values of Agile.
Below is a breakdown of Agile project roles and their respective KSA’s:
Product Owner
The Product Owner represents the voice of the customer and is accountable for ensuring that the Team delivers value to the business. They are the authoritative decision-maker on what needs to be built and must have control to make those decisions.
A Product Owner:
- is an active project participant,
- is the only product owner for the team,
- writes customer-centric items (typically user stories), and adds them to the product backlog,
- prioritizes the product backlog,
- selects user stories for sprints,
- decides when user stories met the “Definition of Done”, and
- accepts the product and associated user stories
They do not:
- assign work/tasks to team members,
- act as the Scrum Master, or
- tell the team how to accomplish work or make implementation decisions.
It is important that the Product Owner (PO) is able to define work and when it is completed. This requires the PO to analyze requirements and distill them into tasks. This role is NOT a managerial role; the PO should be able to allow the team to work as it see’s fit (self-organize), instead of dictating a process. This role is critical in guiding the project work and it is recommended that before taking this role, a PO has exposure to Agile methodologies. This can be either experience working in agile, or through a class provided by a certified Agile instructor or a certified Agile coach. I would recommend that the Product Owner takes a hands-on course such as the following:
- Agile Fundamentals (Certified by ICAgile)- https://training.coveros.com/training/course/fundamentals-agile-certification-icagile
- Agile Team Facilitation – https://training.coveros.com/training/course/agile-team-facilitation
Scrum Master / Coach
The Scrum Master / Coach is a facilitator who is accountable for removing impediments to the ability of the team to deliver the sprint deliverables.
The Scrum Master / Coach:
- acts as a buffer between the team and any distracting influences,
- ensures that the agile process is being followed as intended,
- enforces all software development rules, and
- acts as a servant-leader to make the team run as effectively as possible.
The Scrum Master does not “manage” the team. As such, they do not:
- act as a line manager for the team,
- assign work,
- make decisions other than those related to adhering to team norms or agile rules, and
- tell team how to do/accomplish work.
The Scrum Master / Coach should have experience in agile before taking this role. This role is the glue that binds the team together. This role requires a person who can digest information and determine where and what is useful to the progress of the project. Because they serve as an intermediary to other parts of the organization that may pose as blockers, they should possess high levels of organization and communication skills. I would recommend that the Scrum Master takes a hands-on course such as the following:
- Agile Fundamentals (Certified by ICAgile) – https://training.coveros.com/training/course/fundamentals-agile-certification-icagile
- Agile Team Facilitation – https://training.coveros.com/training/course/agile-team-facilitation
Agile Team Member
The Agile Team Member is responsible for delivering work by completing user stories against the prioritized product backlog.
The Agile Team Member:
- delivers working software for each user story,
- decomposes PBIs and estimates work,
- determines how work is implemented,
- test the work to make sure it meets the “Definition of Done”,
- makes commitments and delivers on those commitments, and
- is willing to be a team player and collaborate with other team members (including the PO, SM, and other teams).
Typically made up of 8 (plus or minus 2) people with cross-functional skills who do the actual work (analysis, design, develop, test, technical communication, documentation, etc.). The team should be self-organizing and self-led but often work with some form of project or team management and/or coach. I would recommend that any agile team members takes a hands-on course such as the following:
- Agile Fundamentals (Certified by ICAgile) – https://training.coveros.com/training/course/fundamentals-agile-certification-icagile
The Agile Team Member does not:
- prioritize Product Backlog, or
- decide if a user story is “Done”.
Having topic-relevant knowledge and having a good mentality for design are key qualities that a team member should possess, especially in a senior role. Aside from this, the team should, in general, exude a willingness to learn and adapt to an Agile mindset. Regardless of how talented someone is, if they are unwilling to work as a team, they will become a blocker for producing quality and regularly delivered work.
Stakeholders
Stakeholders are the people who enable the project and for whom the project will produce the agreed-upon benefits, which justify its production. They can include: customers, vendors, and those with an interest in the project or that provide feedback to the team. The stakeholder should be knowledgeable about the desired function of the project’s goal and how it fits into the system it is being designed for.
Creating Agile teams can be daunting at first especially when expanding expectations of team members to fit certain roles. With the ‘Roles and KSA’s of Agile’ framework, you can hopefully start to identify candidates to start building your teams and as they get more exposure to Agile methodologies their KSA sets will grow.
