Agile Project Management

Developed by Michael Ølund

Introduction

Agile can be traced back to 1991 where agile manufacturing was introduced. It was however not before ”The Agile Manifesto” was introduced, that the approach started to become increasingly popular, especially in the software industry. The Agile Manifesto was developed in 2001 by 17 organisational ”anarchist”. This was the birth of agile in the software industry, and the manifesto serves as the backbone of many of the agile methodologies we know today .

The agile values is clearly stated in "The Agile Manifesto" as: ”We are uncovering better ways of developing software by doing it and helping others do it. We value:

• Individuals and interactions over processes and tools.
• Working software over comprehensive documentation.
• Customer collaboration over contract negotiation.

• Responding to change over following a plan.”

These different value statements are further elaborated in twelve principles. A summary of these can be found in "Twelve principles of agile software" .

The Agile Manifesto was developed specific for software development projects. In 2005, the less know, Declaration of Interdependence was developed which also states agile values, but has focus on the project leader instead of software development . The agile values in the Declaration of Interdependence are presented in .

The definition of Agile Project Management (APM) is in many cases referred to as a specific agile development methodology, e.g. eXtreme Programming (XP) . Therefore, it can be confusing to distinguish between what APM is, and what an Agile development methodology are. The reason behind this is, that the definitions of agile methodologies often do not separate between development methodology and project management methodology. In many cases agile methodologies does not even use the word project manager or management, which can add to the confusion .

However, more recent studies on APM have resulted in a more uniform description, which not only focuses on software development projects. This research has been led by one of the original founders of the Agile Manifesto, Jim Highsmith. This ”new” approach to APM disregards the previous tendencies to explain APM as a specific agile development methodology .

Jim Highsmith presents three critical agile values in "Agile Project Management: Creating Innovative Products" , which summarises the values from the Agile Manifest and the Declaration of Interdependence into three core agile values for agile project managers:

• Delivering value over meeting constraints (Value over Constraints)
• Leading the team over managing tasks (Team over Tasks)

• Adapting to change over conforming to plans (Adapting over Conforming)

These agile values form a system of values, which provides a modern view of managing complex and uncertain projects .

The following section will give a detailed in-depth description of APM.

Detailed method description

One of the core elements in Agile methodologies in general, are being able adapt to a given situation and embrace change. This description of APM, should therefore not be seen as a rigid methodology description, which has to be followed rigorous in order to be agile. It should rather serve as an inspirational framework, which can be adopted and customised in any way to fit a specific project environment.

APM Mindset

There are three essential elements of APM that the project manager need to take into account when managing an agile project; customer value, adapting the methodology and systems thinking

Customer value: Agile projects are in general more flexible and the main focus is to deliver value to the customer. This should therefore also be one of the main concerns for the project manager. In this relation there might be different changes needed for the project manager. He/she needs to establish a sufficient balance between control and agility. This is no simple task, and many factors within an organisation may influence the ability to balance the control and agility. A balanced approach is however crucial for being able to deliver customer value.

Adapt the methodology: Agile methodologies are meant to be customised to fit the project. One important point is, that the method definitions leave some elements undescribed, but that does not mean that a particular element should be left out. A good example is, that Scrum does not describe anything explicit about the project manager role. Instead, some of the project management functions are intended to be done by the Product Owner or Scrum Master . However, this does not mean that no project manager or project management functions are needed. It is up to the single project to define and scope what the role of the project manager should be.

In an agile project environment no single methodology (agile or not) will fit perfectly with all principles and practices. The project manager’s focus should be on adapting and fitting the methodology to fit the project and problem at hand. It can also be necessary and beneficial to combine different methodologies. This will of course set some high requirements to the project manager’s skill and knowledge about other methodologies that could potentially be used.

Systems thinking: Systems thinking can be interpreted in different ways depending on the context. C. G. Cobb describes it from a project management perspective as: ”... not getting lost in the mechanics of how a particular methodology (agile or non-agile) works, being able to see the big picture, and being able to understand the principles and practices that are behind methodologies at a deeper level”. Basically this means that a methodology should be viewed and understood as a whole system. The most important part is that the system is working, and not which mechanics (principles and practices) are used in the system.

APM Practices

The APM practises are based on a set of principles and techniques. The description mainly focuses on understanding the principles and techniques. It is the agile project manager's responsibility to interpret the descriptions and implement the elements that gives value to the project.

APM Principles

The APM principles are a further development of the ones presented in the Agile Manifesto and the Declaration of Interdependence. APM consist of five principles:

Rolling wave planning: The initial planning of the project should be limited to a minimum. As in most agile methodologies, the concept ”just-in-time” planning should be applied, in order to avoid doing most of the planning in the beginning of the project. Instead the planning should be done collaborative by the team on a more regular basis and whenever needed. The planning will be highly influenced by the time horizon and risks in the project. It is up to the project manager to define the frequency and detail of the planning. However, the project sponsor and other relevant stakeholders should be taken into account since they might have specific requirements to this issue.

The requirements or functionality in the project should be divided into iterations. The requirements or functionality should be prioritised, in order for the most important aspects to be addressed early on in the project. The ”just-in-time” approach should be used whenever the next iteration will be planned.

Customer collaboration: As explained in the APM Mindset, delivering customer value is the most essential thing in an agile project. The customer, or a representative from the business, should therefore be an important part of the project team. In order for a project to deliver customer value, it is crucial to have a close collaboration with the customer. The customer should ideally be collocated together with the project team, in order to be present for urgent issues etc. In addition, the customer should be part of all team activities in the project, and feel as much responsible for delivering value as the developers. In general, the customer should be included as much as possible in the project in order to secure the value will be delivered.

Collective ownership: The project should be the responsibility of the whole team, and not just the project manager. There need to be a collective ownership in the project, where everyone feels responsible for the project outcome. This gives a new task to the project manager, who need to make the team feel empowered instead of controlled. Several limiting factors can influence the ability to empower the team members, e.g. need for project control, organisational culture and whether the team is capable of making decisions. It is however the project manager's job to empower the team members as much as the limiting factors allows.

Emphasis on validation: APM put emphasis on validation, meaning that the project should deliver the right product. This means that the project should deliver a product, which corresponds to what the customer actual needed. The focus should be on validating the requirements continuously, in order to make sure that it still is, the right product the project are developing.

Continous Improvement: The project should ideally be split into short iterations or increments. In this way, it will be possible to evaluate and adjust processes or practices after each iteration. Retrospective meeting sessions will make the project team understand what worked well and what could be improved. This way of organising a project will help the project team to continuously improve processes and practises to maximise the performance.

Techniques

This section describes three examples of the most commonly used techniques (or practises) used in APM; Daily Standup Meetings, Consensus Builing and Timeboxing . However, the project manager in an agile project could in principle use any agile technique from other agile methodologies, if he/she finds it beneficial. Due to the scope of this paper only the three most common techniques will be described. Further inspiration to agile techniques can be found in "PMI: Agile Certified Practitioner" .

Daily Standup Meetings: This is properly the most well known and used agile technique, and used in many agile methodologies, e.g. Scrum. The Daily Standup Meeting is a short 15 minutes meeting in the beginning of each day of work. The project team will all be present at the meeting, and each team member will answer the following questions during the meeting:

• What did I do yesterday?
• What will I do today?
• Are there any barriers or obstacles in my way?

It will be the project manager's responsibility to help out removing the barriers or obstacles which are hindering the team members work.

Consensus building: It is important that the project team are able to reach consensus when making decisions. This builds on the collective ownership principle, which means that every team member needs to commit to decisions. This gives the project manager some challenges, since he/she needs to be sure that all team members are able to obtain consensus. In "Making Sense of Agile Project Management" several exercises are proposed which can help the project manager in highlighting whether consensus is obtained or not .

Timeboxing: The practise of timeboxing is to set an fixed length of an iteration. The size of a timebox is determined by the velocity of the project team. Since the length of the iteration is fixed, the project team can decide how much functionality can be implemented in the given amount of time. When the decision on which functionality should be implemented in a given iteration has been made, it can’t be changed. If some functionality does not gets implemented in the iteration due to time constraints, it will simply be moved to next iteration instead of delaying the current iteration. This approach has several benefits, e.g. it will increase focus and productivity when you work on specific tasks for a limited time period.

APM Model

The APM model’s structure is mainly focused on delivery and execution. The model consists of five phases: Envision, Speculate, Explore, Adapt and Close. The Envision phase will establish the vision of the project. The speculate phase will develop a feature based release plan based on the vision. In the explore phase the features will be developed. The adapt phase will review the completed features and adapt if necessary. The speculate, explore and adapt phases are the basis of one iteration, and will continue until the product is finished. The close phase marks the end of the project where the final product gets handed over to the customer . The flow of the APM model is shown in Figure 1.

Figure 1 - APM model based on

Envision phase: In this phase the team creates an overall vision which clearly states; what needs to be delivered, who will be involved and how are the team is supposed to work together.

Speculate phase: The speculate phase starts out by gathering the overall requirements for the project. Then a feature backlog will be created which defines the work to-be-done. When this is complete, an iterative release plan will be created including risk mitigation strategies. At the end of the phase, estimation will be done in order to determine the project cost.

Explore phase: In the explore phase the product is coming to life. The project manager's role in this phase is to manage the teams workload in order for them to perform optimal. He/she also need to create a self-organising project team where all team members takes responsibility towards the output. Lastly, the project manager needs to manage the different stakeholders surrounding the project, such as customers and the steering committee.

Adapt phase: In the adapt phase the results obtained in the explore phase are reviewed from a broad range of perspectives. The results of the adaption are then used to begin the planning of next iteration in the speculate phase. This loop of speculate - explore - adapt will continue to refine the product until it is considered done.

Close phase: When the product is completely done it should be handed over to the customer, and a formal celebration of the end of the project should be made. It is also important to use the lessons learned in the project to pass on to other relevant project teams.

Application and Implementation

APM can be applied in almost any project due to the adaptable and flexible nature of the methodology. If it is a complex project with a lot of uncertainties, APM will be beneficial to use . APM is also best implemented in matrix or project organisations, due to the need of self-organised teams. If a team needs approval higher up in the hierarchy every time a decision is made, the APM approach would not perform as intended. However, if it is a repetitive project with very low complexity and uncertainty it might be sufficient to use a more traditional project management approach.

APM can be tailored to any project size. However, increasing team or project size will also mean a need for more practices and control in order to coordinate all stakeholders and outputs of the project. Since APM mainly consists of values and principles it will be possible to adopt these to large projects.

Organisations can use an iterative approach when implementing APM. First of all, an organisation needs to be familiar with the APM framework. Then they need to develop short- and long term initiatives, in order to slowly implement the methodology over time. However, it is suggested than an organisation use a small project with one team as a pilot project for implementing APM in an organisation. The team should be experienced and formally trained in agile methodologies before starting the project. In addition to the practices used, ”reflection workshops” will be conducted with both the project team and organisation representatives. In these workshops lessons learned will be discussed, and as all stakeholders get more information about APM, new projects can be initiated using the approach .

A common mistake for all project managers are to use a particular methodology and apply it mechanically without taking the specific project context into consideration. APM provides a series of values and principles, which the project manager has to adapt to the specific project in order to gain value. This minimises the risk of applying APM on a project where it is not suited .