Agile Portfolio Project Management

Roles and Responsibilities

Now that you know the challenges of traditional project management and the key principles of the PMDOI, it is time to focus directly on agile project managers—who they are and what their duties are. The following roles and responsibilities define what agile project managers are.

Roles

There are primarily two roles in agile project management: the project manager and lead business analyst. Scrum has developed the de facto standard for many agile project managers. I decided to provide a definition for both terminologies.

Project Manager

The term project management is deeply rooted in our professional world. Even though in the agile world the project manager would be better described as a project leader, I’ll go along with this widely used term. The distinction between manager and leader, however, is still important for defining the role of an agile project manager. Instead of managing projects, the project leader steers the project team and constantly shapes the vision. The definition of the Agile Project Leadership Network (APLN) reflects this fact. An agile project manager creates a team-managed platform, which encourages the values of the PMDOI. In addition, the project manager applies the key practices for agile development.

Becoming a project manager is often falsely seen as receiving a promotion. Yes, someone with special skills, which we will discuss in more detail soon, was appointed to play this role, but the role is as specialized as any other role taken on by team members. In traditional projects, the team often sees the project manager as an outsider who controls the team’s progress and gives out work assignments. Good project managers who follow the agile project management approach are part of the team and are within the team’s social boundary. Instead of having a command-control role, the agile project manager collaborates with the team as part of a unit.

The difference between manager and leader might appear to be subtle, but it has a significant impact on team morale. As a result, the agile project manager’s role is probably best described as facilitator or moderator.

In Scrum, the scrum master assures that the rules of scrum are correctly interpreted. In this case, the scrum master executes the daily scrum meeting, conducts the retrospectives, and plans the iteration with other roles by using the project backlog. Chapter 11 takes a closer look at Scrum and how scrum principles are implemented for portfolio management. It also includes an explanation of the terms used in Scrum.

Scrum Master

In Scrum, the role of a project manager is gone. Instead of managing and leading the development effort of the project, the scrum master implements the rules of Scrum in a project and makes sure the team’s path is clear so that the team can stay productive. This emphasis on leading becomes clear in what is known in Scrum as sprint backlog planning, where the project team is empowered to plan and schedule its own work. The sprint backlog contains a list of tasks to be tackled throughout the upcoming sprint, which represents in Scrum a fixed-length iteration of 30 days. The backlog contains a to-do list of activities and deliverables the team needs to tackle. Once the team has entered the sprint, the scrum master facilitates the daily scrum meeting and removes impediments for the team, such as environmental, administrative, or team-related hurdles. Especially in large organizations in which a large project spans organizational hierarchies, the scrum master must be an influential mediator and determined to facilitate the project across departmental boundaries. In such projects, the scrum master must also stand up for the team so that its requests are met; a compromised resolution is often the least desirable outcome.

The role of a scrum master translates probably best to that of a change agent or servant leader who works for the team so that it becomes more productive and effective over time. In Scrum, the responsibilities of traditional project management are divided among three different roles: the product owner, the scrum master, and of course the team.

Business Analyst

Remember the principle of shared ownership and engaging customers at frequent intervals? In internal and large-scale projects, business analysts often serve as the voice of the customer. Agile projects are so dependent on them that they are an integral part of any agile process. In an ideal world, the business analyst works full-time on the project, also inside the team boundary.

Based on my experience, defining this role in an organization is the most challenging of all. Because of the structure of the organization, the business analyst is often part of a different reporting chain. In situations like that, the business analyst is part of or reports to product management, marketing, accounting, and so on, whereas the project team reports to the chief information officer (CIO) or chief technology officer (CTO). This separation creates a gap between these two parties that has to be bridged during the project. The challenge for the project manager is to make the business analysts feel comfortable around all the technical specialists. Sharing the same project room and having direct communication channels is a major element in the agile success story.

Still today, I see so-called agile projects where requirements are handed over from the business analysts to the software development team for implementation. Organizations interested in offshore development even have to deal with language, time, and cultural barriers. In situations like this, the interpretation of agile is often just a little too loose.

Think about the difference in time and money consumed when a developer has a quick question to clarify a requirement. Asking the person on the other side of the table versus writing an e-mail message and waiting until the other person has time to reply. Often e-mail threads introduce more confusion than initially existed. Globally distributed development, where project team members work more anonymously and in a more isolated way, need wise project organization to overcome these challenges. We’ll take a closer look at this topic in Part III of this book.

One technique, which is out of the ordinary but extremely powerful, is that the development team is allowed to work only when the business analysts are present in the room. Part-time and casual assignments immediately bounce back to the business as an impediment.

Product Owner

Scrum has a different view with regard to the business representation as well. Instead of requirements being written and clarified by team members, they are written by the product owner. This person is a highly visible figure in a scrum project and in the organization. The product owner is primarily responsible for the project’s success. The product owner is also responsible for planning each release and works on the specifications for and refinement of the features for the team to develop.

The product owner sits in the driver’s seat in terms of authority and prioritization of features. This role is the primary go-to person from a project portfolio management perspective, but it is also the point of contact for the entire project team when questions about the features of the current sprint emerge.

Project Team

Especially for Scrum projects, the team itself takes over many project management activities we know from traditional projects. A self-organized and empowered project team plans the work and assigns work to themselves. If the team prefers to work in pairs, team members sign up and form pairs on their own.

From a reporting perspective, the project team members derive the metrics of the project from their own daily activities, and they broadcast the metrics among the team, product owner, scrum master, and other external project stakeholders. That mechanism keeps the metrics and reports unfiltered and unmassaged.

Responsibilities

The following tasks are typically performed by an agile project manager during or in between iterations, or they are co-performed by an agile project manager and other project team members, such as business analysts, developers, or sponsors. Most commonly the team and business analyst work hand-in-hand with the agile project manager.

Removing Impediments

Every project usually has plenty of impediments—small, unforeseen issues here and there, major problems, and organizational obstacles. Even worse, they can pop up anytime, most commonly at the worst moment. I’ve seen plenty of teams that have had difficulties getting started because of unknown passwords, insufficient server rights, lack of software licenses, lack of access to rooms, and other internal administrative procedures. Official escalation procedures are commonly used to resolve these issues, but even those procedures can take weeks and sometimes months to clear the issue.

In addition to administrative issues, challenges related to technologies and requirements commonly arise. There are two mechanisms in agile projects that deal with these impediments. First, the daily stand-up meeting, where issues are expressed and captured for resolution, and second, the role of the project manager (scrum master), who is responsible for tackling issues that impede team progress. Therefore, the agile project manager must be willing to go the extra mile within the organization and serve the team. You can see here that the role of a project manager can be quite different from a development role. An introverted brilliant test engineer might not like becoming an agile project manager.

During the daily meetings, the team repeatedly expresses an issue until it is resolved. In return, the project manager reports progress on resolving impediments back to the team. So everyone should have at least a little progress to report on—the team reports development activities, and the project manager reports about impediments.

If other stakeholders participate occasionally in one of the daily stand-up meetings, everyone should sense the urgency and importance of certain open issues. Just to be clear, paving the path for a project and removing impediments could be a full-time job in itself.

Iteration Planning

Iterations are usually between 2 and 6 weeks long. The shorter the better, especially in the early stages of the project. Many times, I’ve been asked if the iteration length can vary. In my experience, fixed-length iterations throughout the entire project work best. I have seen projects in which project managers started with two 4-week iterations and then switched to a 2-week rhythm. There are several good reasons why this can be a good idea. One reason is that it can reduce the pressure of a 2-week iteration for new agile teams. Once the team gets more familiar with iterative-incremental development, a reduction to shorter iterations might be beneficial. Changing the length of iterations (for example, 2, 3, 4, 2, and then 5 weeks) based on the intensity of the planned stories is, however, not recommended and not needed. There are great books available that assist you with assigning requirements (stories, use cases, and nonfunctional requirements) to iterations instead of the other way around. Stories documented on index cards are common among agile developers, as are the techniques for iteration planning.

If an agile project uses use cases instead of stories, the procedure of iteration planning remains similar. A use case represents a collection of start-to-end business scenarios. Some of them are common and typical; other scenarios might be alternatives or exceptional cases and less frequently executed. The challenge with use cases is that some of them are long and complex, whereas others are easier. In addition, dependencies exist between them. If you look closer at use cases, you’ll notice that they usually consist of an abundance of scenarios. Therefore, instead of tackling the entire use case, the team must focus on individual scenarios. With that approach, even dependencies between the scenarios can be resolved. A positive aspect of documenting requirements with use cases is that identifying and documenting these scenarios in this format flows naturally with the work that business analysts perform regularly. Figure 3-4 (which abbreviates use case as UC) shows how the implementation of a use case is done incrementally, scenario by scenario.

Figure 3-4. Iteration plan with use-case (UC) scenarios

Although a rough outline and the high-priority requirements are determined by the customer, the project manager facilitates the iteration planning session with the rest of the team. That way, dependencies between requirements can be considered and the best possible plan for the upcoming iteration can be assembled, according to the wish list of the customer.

In the second part of this book, when I outline the agile portfolio management approach, you’ll see how essential iteration planning is. We will then apply the practice of iterative development to the organizational level and get the entire organization into a rhythm.

Retrospectives

Retrospectives are not lessons learned. They are much more. Traditional lessons-learned sessions are scheduled at the end of a project. Not only is it too late at that point for the team to rectify behavior and remember all the “lessons,” it is also challenging to get all the people at a table together when the project is over. Agile teams perform retrospectives in between iterations. The project manager facilitates the retrospective, which includes iteration review and iteration planning (preview). Psychologically, the term lessons learned also implies that there was something to learn. That is not always the case and can lead to a negative impression that something else could have been done instead by changing the project and the process.

Estimation

There are two famous questions that customers ask project managers: “How long will the project take?” and “How much will the project cost?” Especially at the beginning of a project, these questions are extremely difficult, if not impossible, to answer. If you ask a team to estimate the answers to these questions based on a few index cards or use-case scenarios, the likelihood of getting a good estimate turned around is higher. If you ask a team after a few iterations to estimate the time and cost of completing tasks on a few new cards, the accuracy of the estimate gets better and better. Why?

With every retrospective, the team reflects on the past iteration. Some requirements might have been underestimated; others might have been overestimated. The team’s estimate of upcoming requirements takes the experience from previous estimations into consideration.

Traditional project managers, who have usually been transitioned from an engineering role to a project manager role, tend to produce estimates themselves or influence the estimation of others. This heroic attitude of “I could get it done in two days instead of four” does not really help if team members cannot get it done in two days. There is also no proof that the manager could get it done anyway. This kind of assistance does not add any value to the team. Sometimes project managers influence the team through a backdoor approach such as, “Do you agree that this task takes about two days?” Do estimation practices like that really help your project, your customer, and the expectations?

To prevent this issue, agile project managers stay out of the estimation exercise unless they play both roles on the team. In agile projects, the development team, and only the development team, produces the estimates. The agile project manager captures and tracks the estimation results and, of course, the actual results. Remember, the project manager should “lead” the project and connect with the customer and sponsors, rather than micromanaging people. The selected estimation technique should be easy and quick to adopt—for example, a Wide-Band-Delphi (discussed in Chapter 5). Another effective method is having team members hold up a certain number of fingers for estimated efforts and size and then averaging the results.

For example, a project team gets together and publicly estimates the effort. Everybody’s input has been heard, a quick average is taken, and the process is continued for the next estimation. Even if a story was underestimated or overestimated, it will balance out over time, just like the calls from umpires in baseball. An alternative, but more time-consuming, method is to collect the estimate from the team members anonymously. That reduces the chances that, especially during early estimating sessions, team members are unduly influenced by their colleagues.

By the way, the planning poker game (which you can learn more about at http://www.planningpoker.com) is a variation of the Wide-Band-Delphi estimation technique.

Reporting

As with estimating, the quality of the reporting gets better over the course of the iterations. An agile project manager has extremely powerful tools to report status almost in real time. But to keep the team focused on its deliverables, the exchange of these metrics is suggested in between iterations only. Considering that the iterations are only 2–6 weeks long, it is still a very frequent exchange of reliable information. Reporting in agile projects is extremely powerful because teams can always share internally and externally the requirements that have been completed (stories), the progress (size of stories) of the project, and the quality (defects) of the system. When asked, the project manager can accurately answer the following questions: “What has been done?” “How are we doing?” and “How good is the system?” This is enough information to judge whether the past iteration was a success.

Remember, all the data is naturally created by the agile developers and business analysts while they are working. No extra effort is necessary to generate the data.

Daily Stand-Up Meeting

The agile project manager facilitates the daily stand-up meeting, ensures that the meeting starts on time, and ensures that it is conducted in a timely manner, usually no longer than 15 minutes. If the team is geographically dispersed, the meeting time needs to be synchronized and resources need to be synchronized and prepared. Facilitation of this meeting includes ensuring that team members report status to each other in a collegial way and side discussions are eliminated. Impediments that might be expressed during the meeting are captured as a to-do list for the project manager. The challenges of this activity are to keep the team on track and the meeting on time. To simplify the logistics of this meeting, it is usually conducted at the same time each day and within the team room. Because the daily stand-up meeting is open to the public, bystanders can receive additional ad hoc status updates from the project team.

Leading

During the iteration, leadership skills are needed to keep the team moving. Typical issues within the team are that trivial or very challenging defects have not been tackled, a build broke and no developer took ownership to resolve the issue, two developers pair up too much and need to mix more with the rest of the team, and requirements need to be negotiated. The agile project manager reminds team members to get things done, asks for status updates for critical items throughout the day, and captures completion.

The agile project manager also represents the team to the outside world and also protects the team from the outside world. Too much interference can distract the team from its goals. Agile project managers report to the executive manager and portfolio managers, as we will see in the second part of this book.