What consultants don’t tell you before you begin an agile transition – Part 2: Impact on some of the traditional roles
As a follow up to my previous post, this second post in a series of 4 short articles written in collaboration with my colleagues Stéphane Lécuyer, Jean-René Rousseau, Sylvie Trudel, Joël Grenon, and Eric Laramée, addresses the impact an Agile transition typically has on some of the traditional software development roles: the project manager, the architect, the business analyst, and the QA specialist.
One of the first obstacle we routinely encounter in coaching teams through their Agile transition is the mapping of the Scrum roles to the traditional roles. Since Scrum only has three roles (product owner, scrum master, and scrum team), what happens to the project manager, to the architect, to the business analyst, and to the QA specialist after the transition?
Based on our experience, here are possible strategies to properly map the traditional roles to the three roles defined by Scrum.
The Project Manager
Traditionally, the project manager is responsible for determining who, what, and when activities need to be performed and then to ensure the team complies with the plan that was prepared to meet the budget, time and scope constraints.
With the traditional approach, project management is based on compliance with the plan while Agile and Scrum propose a different approach where maximizing the business value is the main vector of project management. Under this new approach, the product manager needs to collaborate with the team members and delegate to them some of his traditional responsibilities since they will determine who does what, and when within the constraints of the project.
In this context, the role of the Scrum Master is to enforce the process and seeks to build an efficient self-organized team. To the question “do we still need a project manager in Agile?”, experience shows us that in most organizations, the answer is yes.
The need for accountability, regulatory compliance and alignment with the framework and IT governance are not covered by the role of the Scrum Master and as such remain the responsibility of the project manager.
However, the project manager needs to adapt its management style and use leadership rather than authority with the team to get things done. In the context of a multi-team organizational structure, the presence of a project manager is also valuable, where he is coordinating the teams and the synchrony between them and between entities external to the project teams.
From our experience, some project managers are more willing to become product owners while others will feel challenged by the role of Scrum Master. In the end, it will be the responsibility of the organization to determine how to redefine the roles and their associated responsibilities.
The Architect
Similar to the project manager, the architect is known to play a different role post-transition compared to that required in traditional development teams. He must act as a consultant to the teams and provide them with the necessary support instead of dictating the rules and guidelines to be followed. The architect should also be familiar with the concepts of emerging architecture, where just enough architecture is planned to allow the team to innovate and find the optimal solutions.
The architect then acts as a catalyst for sharing best practices within the organization. Here is a list of practices summarizing the changes of behavior for the architect:
- Is an active member of the development teas, helping to build the right software and acting as consultant;
- Does not attempt to predict the future, he provides a coherent vision but knows that tomorrow’s problems will be easier to solve tomorrow;
- Is changing its architecture in an incremental way, leaving room for emergence;
- Does not seek to document everything to perfection, he focuses on a few relevant diagrams and documents the best practices based on his audience;
- Seeks to validate its concepts through concrete experiences.
Once again, although the role of the architect does change after an agile transition, it remains an important role to be filled.
The Business Analyst
The business analyst is another role that seems neglected by Scrum. To ensure close collaboration between the team and the Product Owner, Scrum ensures that the necessary elements are effectively communicated directly to the team without a formal and complex documentation. However, to ensure continuity of information, we know that functional documentation that is adequate and representative of the software to be developed is essential.
The business analyst becomes a valuable contributor to the Product Owner. The responsibilities of the business analyst are as follows:
- Supports the Product Owner in gathering and writing the required stories;
- Does just enough analysis for the functionality to be carried out during the next iteration;
- Prepares and updates documentation used at the end of each iteration;
- In collaboration with the QA Specialist, helps determine the quality assurance strategy.
In a multi-team context, the business analyst may be called upon to play the role of Product Owner. He then becomes responsible for core components of the product within the various sub-teams.
The Quality Assurance Specialist
Quality is a fundamental concern in Agile project management and each iteration should produce an increment of quality software. To do this, we recommend incorporating a quality assurance specialist within the Scrum teams, and right from the start of the project. A QA specialist assigned to a Scrum team has the following responsibilities:
- Participates in planning sessions to raise issues relating to quality;
- Helps clarify the definition of “Done”‘;
- Prepares plans for acceptance testing;
- Validates the increments of product delivered.
Other Roles
As will be presented next week in “Part 3: Impact on the functional and people managers”, managers also get impacted by an Agile transition.
