Managing Agile Projects

More and more organizations are adopting Agile ways of working. The descriptions of Agile methods give much guidance on how to work agile on the team level. They describe the practices and support the set-up of Agile teams. But there is limited information on changes that are needed in projects to introduce and manage Agile teams. Setting the right project environment is crucial for Agile to succeed. This article provides solutions that help to create and manage Agile projects. 

Difficulties implementing Agile in Project Management

Some of the problems that organizations have that implement Agile in their projects have to do with:

• Fitting agile teams into the existing project management organization
• Communication between and synchronization of Agile (project) teams
• Managing and reporting agile progress in projects 

The problems mentioned here are not really agile problems. They have to do with changes that are needed in the project structure and -processes, and project management for agile to succeed. 

What is Agile?

Agile is a modern methodology to develop software iteratively in teams. The manifesto for agile software development states that the purpose of agile is “to uncover better ways of developing software by doing it and helping others do it”.

The primary purpose of agile teams is to deliver working software. Their focus is on satisfying the needs of their customer, in agile terms the “Product Owner”. All the customer needs are collected in a backlog, described in so-called “User Stories”. At the start of a sprint (a block of time in which software is defined, developed, and delivered), the planning game is used to select the user stories with the highest priority, and to clarify them. The results of this planning game are a set of user stories and acceptance tests, which defines the software that is to be delivered in the next sprint.

The sprint ends with a “demo”, where the software is demonstrated to the product owner and other stakeholders, and a retrospective where the team reflects on their way of working to continuously learn and improve.

Agile Project Teams

To increase the change that agile practices will bring benefits to the organization, management should give attention to the introduction of agile teams into the existing project management organization. Most projects in the non-agile organization already work with teams. So what makes agile teams different?

First difference is the team size. Agile teams consist often 7 people (+/- 2), this since the team members communicate and work together very intensively. I have seen traditional projects where teams were very large up to hundreds of people (one can argue if it really was a team in the first place), and projects with smaller teams of sometimes only 1 or 2 persons (which often are more functions/roles then teams). Agile teams make it easier for project managers to manage on a team level, since interfacing with the team leader only is usually enough to coordinate the ongoing work. So they do not need to stay in contact with all project members. And since teams are also more similar in size, it is easier for project managers to divide their time and attention over the teams.

The second thing that makes agile teams different is that they have the authority and responsibility to agree upon the work to be done, directly with the product owner. This is different from most non-agile projects, where often the project manager is responsible for assigning the work to teams, or even to team members. Since the project manager is still responsible for the end result of the project, the question is how they should deal with agile teams in their project? My experience is that, if the project manager gives attention to a good collaboration and communication between the team(s) and the product owner(s), the project will be able to deliver valuable results to their customers. So they should focus on the relationship between the teams and stakeholders, and solve impediments that are either signaled by one of them, or that they see themselves and consider to be a risk for the project.

Finally, most projects have multiple agile teams. It is the responsibility of the project manager to coordinate the interaction between the teams. Often a scrum of scrums is used for the synchronization of the teams. Also project managers (or in some organizations line managers) can facilitate sharing of knowledge and experiences between the teams, for instance with Communties of Practice.

Agile teams have different needs wrt project management. They expect that project managers understand the agile principles, and support them in their agile way of working. Project managers have to assure that their teams are able to do their work, effectively and efficiently.

Managing and reporting agile progress

Many software development organizations use Prince-2, PMBoK or another project management method to manage their projects. Most often, IT projects are done with fixed time, money and scope. How do this match with the agile approach, that has user stories and planning games, and no fixed scope?

First, fixing time, money and scope is often an illusion. Many IT project fail, resulting in higher costs, insufficient functionality or quality, not meeting the delivery date, or a combination of these. Keeping everything fixed is simply not possible. With agile, it is easy to manage the project costs and end-date. Project costs are mostly the costs of the project team members, and since the size of the agile teams is know, the burn rate can be calculated. When a delivery date is agreed, it is easy to calculate the project costs that will be spend until that date.

What about managing functionality? Agile uses prioritizing of user stories to deliver the most important functionality first. And since agile teams deliver working software in sprints, and continuously improve their way of working, most agile projects actually deliver more functionality then waterfall projects. Techniques like story points and planning poker are used by agile teams to estimate the activities. The product owner uses the backlog to manage the content of project. When reporting project progress, the project manager should show which functionality has been delivered, and (given current priorities) what is expected to be delivered in the reminder of the project. This is different from traditional progress reporting, which is usually based upon milestones or tollgates that are or should be passed. But reporting delivered functionality actually provides better insight in the value delivered to the customers, which makes it easier for project managers and steering groups to manage project results.

Managing projects includes managing the quality of the software. Agile uses the Definition of Done (DoD) to define the required quality of the software. The DoD describes what needs to be done before the software is ready to be delivered, I consider it to be the tailored process description that the team makes and uses to do their work. The acceptance tests, defined during the planning game, state how the software will be validated. Since these acceptance tests are discussed and agreed upon with the product owner, they can also be seen as requirements for the quality of the software.

Summing up, Agile supports managing time, costs, functionality and quality, as required by project management methods.

Conclusions

Managing IT projects with agile teams is different from classical, waterfall projects. With agile, there is still a need for project management, but the role and focus of the project manager changes. When introducing agile in project organizations, enough attention should be given to these changes to assure that teams are to deliver customer value.

More information 

Several articles are available that cover the agile topics mentioned in this blog: 

• Agile Project Management
• Teams, what’s in it for me?
• What Drives Quality: Project Management
• Implementing Agile with the People-CMM