Agile Project Management

Introduction

Agile can be traced back to 1991 where agile manufacturing was introduced. It was how- ever 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 [1].

The values of the Agile Manifesto is clearly stated in [2] 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 [3].

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 [4]. The agile values in the Declaration of Interdependence are presented in [5].

The definition of Agile Project Management (APM) is in many cases referred to as a specific agile development methodology, e.g. eXtreme Programming (XP) [6]. 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 don’t separate between development methodology and project management methodology. In many cases agile methodologies doesn’t even use the word project manager or management, which can add to the confusion. [7].

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 [4].

Jim Highsmith presents three critical agile values in [4], 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 [5].

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 [7].

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 un- described, but that doesn’t mean that a particular element should be left out. A good example is, that Scrum doesn’t 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 [8]. However, this doesn’t 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. [7] 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 managers 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. [7] and [9] presents the five principles of APM:

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 being addressed early on in the project. The ”just-in-time” approach should be used when- ever 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 managers 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 [7]. However, every agile technique could in principle be used by the project manager in an agile project 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 [8].

Daily Standup Meetings: This is properly the most well-know 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 managers 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 need 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 [7] 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 an 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 don’t 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 have 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 are 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. Then the speculate phase will develop a feature based release plan based on the vision. In the explore phase the features will be developed through iterative sprints. 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 [4].

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 an 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 managers 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

Discussion of the general application of the method. Description of a specific application example from the author’s own experience. 


Implementation

Discussion of the pros and cons using the method. Specific implementation advice will be given. 


Conclusion

Concluding remarks 


Work templates

Templates for Sprints, Product Backlog, Sprint Backlog. 


References

[1] M. Fowler and J. Highsmith. The agile manifesto [software development]. Software Development, 9(8):28–32, 2001.