According to the out-of-the-box Scrum framework, there is no Agile Project Manager (Agile PM) role. There are other Agile methodologies, such as Feature Driven Development (FDD), that rely on the role of a Project Manager (PM), but still, the PM role is reduced to someone responsible for the administrative aspects of the project, and not necessarily helping to coordinate the development team and their activities or dealing with resource issues (and also far from the complete traditional PM described in the Project Management Body of Knowledge). For example, according to FDD (Feature Driven Development), these are responsibilities of the Development Manager, not necessarily the PM. An Agile PM goes above the tactical PM role, entering into project coordination and strategy. The Agile PM takes the multidisciplinary skills of the traditional PM, and brings a unique familiarity with the fast-paced, change-embracing context of Agile projects and frameworks.
The Agile PM can be better understood as a unique professional with a very particular set of skills that allows him/her to own part the responsibilities of two or more roles at the same time, as needed. Considering the Scrum framework, these roles can include client Product Owner (PO) and Scrum Master, i.e. in one project the Agile PM can act more as a Scrum Master and switch to a stronger PO role in the next engagement, according to each project’s needs, not fully replacing, but instead complementing the job of the Scrum Master or PO. The Agile PM uses project management expertise to assist both sides (client PO and Scrum Master plus development team), filling in the gaps while always aiming for the best outcome for the project and walking the extra mile.
During the course of an Agile software project, the Scrum Master is typically viewed as the ''Agile Process Owner,'' making sure that the team is using the Scrum and Agile frameworks correctly. Yet when considering nearshore projects, the leadership role is most beneficial when it is held by more than one person because most of the time the development team and PO are based in different countries, and working with leaders in each location can ensure the parties stay on track to meet the project’s goals. For example, a Scrum Master and an Agile PM can work collaboratively to lead a project and direct the geographically distant teams, with the Agile PM taking ownership of some of the tasks that are typically owned by the business partner to ensure the project moves along smoothly when the client is not physically present to meet with the development team. By taking on these responsibilities on behalf of the client, the job of the Agile PM becomes critical in ensuring the progress and success of a nearshore development project. The presence of an Agile PM also works well with collocated groups. However, because distributed teams do not always benefit from ''osmotic communication'', since not everyone is sitting in the same room, having the Agile PM helping to fill in this communication gap is crucial for the success of the initiative.
Tasks that the Agile PM can be responsible for include (but are not limited to): allocating team members (staffing), providing mentoring and coaching, coordinating the development of the product backlog with the PO and the sprint backlog creation process with the project team, developing, executing and monitoring the project's schedule cost/budget, project cash flow/invoicing, communications and risk response plans and procurement management.
Specifically on the PO side, the Agile PM can be responsible for holding the kickoff meetings and also for scheduling and facilitating other project meetings as needed. In this situation, the Agile PM will take charge of preparing and communicating written and verbal status reports for the team members and stakeholders, as well as for updating and archiving the project documentation as needed (e.g. if a company’s PMO requires certain documents to be generated for the project to be compliant, there will be stories in the backlog for creating such documents).
The Agile PM is capable of assisting the client PO in properly conveying the client vision to the development team (e.g. by creating/maintaining a prioritized product backlog using Value Engineering techniques), while helping the Scrum Master ensure that the project has someone playing the appropriate Project Owner role, and that the Agile process is being followed on the client side, and not only within the development team.
An Agile Project Manager at Work
To fully understand the job of the Agile PM, consider a recent project for a Fortune 50 pharmaceutical company. The company undertook a software development and migration initiative with a nearshore development team consisting of a Scrum Master and the team responsible for burning the backlog items towards the sprint goals. The team included three programmers with different backgrounds (strong coding, strong web designing, strong database knowledge, etc.), one tester and one software architect. In addition to the remote development team, the Product Owner and the Agile PM, both onsite, were also part of the ''core project team''. The project lasted 66 days and consisted of five cycles.
The project began with a four-day warm up that the team referred to as ''Sprint 0.'' During this phase, the team reviewed the requirements created by the client and established the estimated timeline while the application’s infrastructure was discussed and outlined. One goal of Sprint 0 was to include the client in discussions to clarify questions associated with the business rules so that the client, the Agile PM and the development team were on the same page.
While working through the 16-day sprints, the Agile PM played the critical role of facilitating constant communications, including arranging daily meetings with the team, morning meetings with the client and checking the backlog to ensure on-time completion of the project segments at the ''theme'' level, while also coaching the Scrum Master to try to anticipate unknown roadblocks. Traditional Scrum practitioners believe that the development team is capable of tracking the backlog and bringing tasks to completion. However, this nearshore team has learned from experience that with geographical distance separating the client and team, the process is better streamlined with a manager in place to track all tasks .
It’s important to mention that the Agile PM did not have to take on specific task assignment during the project, as the development the team was self-organized enough to handle that. For example, some of the backlog tasks were very complex and the developers alone did not feel comfortable handling these activities, and they requested the software architect’s assistance themselves. Also, even though the developers were performing additional tasks besides coding, such as unit tests and system and regression tests (testing each other’s code), they were always assisted by the tester who was naturally requested to work on these activities. This scenario strengthened the ''buy in'' of the team members and reinforces the ''power to the edge,'' which is aimed at achieving organizational agility.
The first day of each sprint included planning sessions, during which the development team worked on the breakdown of the user stories (from the Product Backlog) into tasks, estimated them into hours and assigned team members to each task (creation of the Sprint Backlog). The client worked with the Agile PM and development team to discuss and define each sprint goal, which was then written on the whiteboard in the room where the development team worked.
During the next 14 days, the development team moved forward with implementation and participation in daily, 15-minute morning stand-up Scrum meetings. During these meetings, the Agile PM, through a web cam, participated with the team in the review of what was done the day before, what was going to be done that day and communicated any impediments to the sprint goal. The Agile PM also participated in a separate daily, 30-minute call with the PO to discuss any impediments discussed in the daily meeting and to find solutions. The last day of each sprint was marked by a one-hour demonstration session. The development team presented the working functionalities developed during the sprint to the client and any other stakeholders within the organization.
Bridging Geographical Boundaries & Enabling Communication
With the development team and client in different geographies (in this case, the development team was in Brazil while the PO was located in New Jersey), final responsibility for each sprint fell to the Agile PM. It’s worthwhile to note that the Agile PM’s job was made easier during this project because the development team was in a nearshore location, only one time zone away from the client, as opposed to the eight-plus hour time difference often associated with offshore projects. To better facilitate communication, the teams set up several Live Meeting and GoToMeeting sessions, as well as utilized a 1-800 conference number provided by the client organization.
The constant communication facilitated by the Agile PM complemented the work style of the development team. A high-performance team, the developers placed priority on regular communication with the client, ensuring both parties were focused on the most current business goals throughout the duration of the project. Combining the communication priorities of the high-performance team and the strong presence of the Agile PM as the go-between for the two parties, the nearshore team was able to stay on track through sprints, delivering projects on time and within desired specifications.
Learning from Past Sprints & Building Reputations
Throughout the project, the team held retrospective sessions at the end of each sprint, led by the Agile PM, who was in charge of coaching the Scrum Master and the development team. The goal of these sessions was to uncover ways that they could work better together, with a focus on what specifically went right and wrong during the sprint. In the Scrum framework, learning from the project is just as important as delivering the final product.
As a result of these sessions, the development team solidified its reputation with the client, providing a framework for exemplary work processes and serving as a benchmark for other teams that were working with the client on other software development initiatives. In addition, due to the constant retrospective views into each sprint, the development team needed less time to prove its case to the client prior to making a decision, which led to less overhead – and reducing overhead is critical in a highly competitive development market.
As the development team built its reputation with the client, it also built team morale, which is very important for Agile and high-performance teams. The team began to feel more confident in its work and ability to try new ways to perform certain tasks, including suggesting improvement in the business processes related to building the software.
Realizing Success
Beyond satisfying the client, the development team also achieved internal successes. Through utilizing Scrum and following the lead of the Agile PM, the team spent less time ''behind the curtains'' developing, and getting faster feedback on its work. It was also able to focus on the most important elements of the project, placing priority on delivering the parts that brought business value. With the short, daily interactions, the client knew what was going to be delivered and when and knew that the result would provide value. The Agile PM also assisted the PO in preparing executive reports for upper management, to communicate the project value.
Looking back at this project, the development team realized that its success would likely have not been possible without the Agile PM to lead the process. Without constant communication, there could have been a greater cost to the project because issues would have not been detected immediately, leading to larger problems, rework and project delays. Without the Agile PM ensuring that the development team and client were focused on the same business goals, the two parties could have ended up on divergent paths, leading to the team delivering a less-effective product that did not meet customer needs.
Above all, the use of Scrum and the presence of the Agile PM ensured transparency during the project. The stakeholders were able to track the project on a daily basis and valued the ability of the team to rapidly react to necessary changes to circumvent potentially impassible impediments. The transparency served to increase the confidence of the client in the development team. This combination of a high-performance team and Agile PM instilled confidence and produced a truly value-generating product for the client.
About the Author
Leonardo Abdala Leonardo Abdala is a Project Manager, responsible for Agile Projects involving Amazon Cloud (AWS), Microsoft, Drupal as well as mobile apps and mobile-friendly websites; developed by Ci&T for their international clients, including a Fortune 50 pharmaceutical company, a Fortune 200 marketing & advertising corp. and a Fortune 500 organization in the healthcare LOB. He is responsible for leading Ci&T’s geographically dispersed development and creative teams based in Brazil, Argentina and China and has been working with Agile for more than 5 years and with the PMI framework for more than 9 years. Leonardo holds several Microsoft Certifications (MCP, MCTS, MCPD, MCITP) as well as 'Certified Scrum Master (CSM)' and 'Certified Scrum Professional (CSP)' from Scrum Alliance and 'Project Management Professional (PMP)' from PMI. Leo is also a College Professor, currently on a leave, in Belo Horizonte, Brazil. He holds a bachelor’s of science (BSc) and post-graduate degree in Management Information Systems.
