BES Playbook

5.5 Part III - Establish the Team

The following section provides a general overview of the roles required for effective execution of the different agile methodologies presented in this playbook.
Note that these are "roles", and, based on the team size, can be implemented by one or more people. Also, the same person can have multiple roles (i.e. a BA and a Scrum Master) though this might not lend to optimal effectiveness.

5.5.1 Scrum Roles and Responsibilities

The relationship between development team members and the PMO is critical as understanding between the two will breed the trust necessary for successful execution of an agile process.

  1. Product Owners: These are representatives of the PMO with the necessary functional knowledge of the system to be able to collaborate effectively with the development team. One of the key aspects within the government environment is that often, the Product Owner is a collection of individuals representing different perspective (Program Management, Functionality, Engineering, and Cybersecurity are examples of these perspectives). Whether there are 1 or more people representing this position, individual or group must have the ability to make decisions on the requirements to effectively collaborate with the business analyst and the development team. Note that a government Project Manager may fulfill the role of the Product Owner, but they must have the functional knowledge to allow for effective clarification of requirements to the development team. POs are responsible for establishing:

    a. Requirements / Acceptance Criteria
    b. Priorities
    c. Clarification on Requirements for the Development Team
    d. Approval of "Done" for stories.

  2. Development Teams: Formed around the specific projects, their purpose is to create quality code that produces value for the government. They have the following components (the size and composition of each team will vary based on the development requirements within a release):

    a. Scrum Master - They are the Process Advisor to the PO.
    b. Business Analyst(s) - Responsible for gathering the requirements and translating them into documentation which not only reflects the intent of the PObut are also understandable and executable by the developers within the team.
    c. Developers (General) - Responsible for - focus is functionality to the users.
    e. Tester / Quality Assurance (QA) - Responsible for implementation of quality within the team.

5.5.2 Kanban Roles and Responsibilities

For Scrum, the Product Owner, Scrum Master and Development team roles must be assigned. In Kanban, the workflow dictates the role requirements. The refinement work can be done prior to entering the workflow (thus requiring a government Product Owner and a team Business Analyst) or the work can be part of the workflow (i.e. a column for refinement). Depending on the policies of the Kanban board workflow, resources will be allocated which can work on the work items within the column.

Optimally, there would be specialists as necessary for the different workflow aspects and a couple of generalists could work to ease bottlenecks within the workflow.

Additionally, while an Agile Lead familiar with Kanban would maintain the discipline within the system and would also enable faster optimization of the system, a Project Manager could also serve as the team lead for managing the workflow. However, to provide a checklist to begin with in implementing a Kanban team (and to provide flexibility to adapt to or adopt other methodologies), the recommended roles for a Kanban Team startup would be:

  1. Agile Lead / Coach - Similar to Scrum Master above but experienced in the execution of Kanban.
  2. Product Owner - Same as Product Owner in Scrum.
  3. Development Team Members - Determined as necessary to enable the workflow (i.e. business analyst, developers, testers, cybersecurity personnel as necessary based on the different policies of the Kanban Board). Key here is the team is not required to be cross-functional so can be formed around specialists and generalists as necessary.

5.5.3 XP Roles and Responsibilities

Although Extreme Programming specifies engineering practices for the development team to follow, it does not really establish specific roles for the people on the team.?Depending on the reference material on roles in XP, there is either no guidance, or there is a description of how roles typically found in more traditional projects behave on Extreme Programming projects. Here are four most common roles associated with Extreme Programming:? ?

  1. The Customer - The Customer role in XP is almost exactly the same as the Product Owner Role in Scrum (same responsibilities stated above). ? ?
  2. The Developer - Because XP does not have much need for role definition, everyone on the team (with the exception of the customer and a couple of secondary roles listed below) is labeled a developer. ?
  3. The Coach - This role is similar to the Scrum Master role for Scrum. The fundamental difference is that this Agile lead should have experience with XP Practices.? The main value of the coach is that they have gone through it before and can help the team maintain practice discipline and avoid process mistakes.?

5.5.4 Roles and Responsibilities Plays

Since the core roles are essentially the same between the different agile frameworks, there will only be one play for each of the roles common to all frameworks. We will not be discussing developers and testers / quality assurance here as these are roles common to IT development environment. However, when drafting job requirements, the following should be added in the preferred qualifications:

  • Experience in agile development methodologies (Scrum, Kanban, and/or XP)

The following agile related roles have plays associated with them:

  1. Agile Lead (includes Coach and Scrum Master)
  2. Product Owner
  3. Business Analyst

The contents of each role play is the following:

  1. Recommended skill sets
  2. Recommended qualifications
  3. Recommended certifications
  4. General Responsibility Overview

Link: Appendix B: Key Personnel Plays