DTU ProjectLab - User contributions [en-gb]

Agile Project Management

2014-11-27T11:47:50Z

Username111: /* Techniques */

[[Category:Agile]] [[Category:Project Management]] [[Category:Agile Project Management]] [[Category: Complexity]] [[Category: Uncertainty]]

= 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 <ref> Project Management Journal. ''Agile Project Management: Essentials from the Project Management Journal.'' Jossey-Bass, 2013. </ref>.

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.”<ref> Fowler, Highsmith et. al. ''The Agile Manifesto''. Software Development, 9(8):28– 35, 2001. </ref>

These different value statements are further elaborated in twelve principles. A summary of these can be found in "''Twelve principles of agile software''" <ref> K. Schwaber et. al. ''Twelve principles of agile software'', February 2001. Retrieved from http://agilemanifesto.org/principles.html </ref>.

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 <ref name=four> J. Highsmith. ''Agile Project Management: Creating Innovative Products''. Agile Software Development Series. Pearson Education, 2009. </ref>. The agile values in the Declaration of Interdependence are presented in <ref name=five>D. Anderson et. al. ''Declaration of interdependence'', February 2005. Retrieved from http://pmdoi.org/ </ref>.

The definition of Agile Project Management (APM) is in many cases referred to as a specific agile development methodology, e.g. eXtreme Programming (XP) <ref>E. C. Conforto et. al. ''Can agile project management be adopted by industries other than software development?'' Project Management Journal, 45(3):21–34, 2014.</ref>. 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 <ref name=seven>C. G. Cobb. ''Making Sense of Agile Project Management: Balancing Control and Agility''. John Wiley and Sons, 2011.</ref>.

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 <ref name=four/>.

Jim Highsmith presents three critical agile values in "''Agile Project Management: Creating Innovative Products''" <ref name=four/>, 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 <ref name=five/>.

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 <ref name=seven/>

'''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 <ref name=eight>S. Chandramouli and S. Dutt. ''PMI: Agile Certified Practitioner''. Pearson Education India, 2012.</ref>. 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''”<ref name=seven/>. 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<ref name=seven/><ref>P. Dinsmore and J. Cabanis-Brewin. ''The AMA handbook of project management''. AMACOM Div American Management Association, 2006.</ref>:

'''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 <ref name=seven/>. 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''" <ref name=eight/>.

'''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 <ref name=seven/>.

'''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 <ref name=four/>. The flow of the APM model is shown in Figure 1.

[[File:APM.jpg|400px|right|thumb| Figure 1 - APM model based on <ref name=four/>]]

'''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 <ref name=eight/>. 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 <ref>ESI International. ''Successful solutions through Agile Project Management''. ESI International White Paper, 1(1):1–16, 2014</ref>.

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 <ref name=seven/>.

= References =
<references />

Agile Project Management

2014-11-27T11:46:35Z

Username111: /* Techniques */

[[Category:Agile]] [[Category:Project Management]] [[Category:Agile Project Management]] [[Category: Complexity]] [[Category: Uncertainty]]

= 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 <ref> Project Management Journal. ''Agile Project Management: Essentials from the Project Management Journal.'' Jossey-Bass, 2013. </ref>.

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.”<ref> Fowler, Highsmith et. al. ''The Agile Manifesto''. Software Development, 9(8):28– 35, 2001. </ref>

These different value statements are further elaborated in twelve principles. A summary of these can be found in "''Twelve principles of agile software''" <ref> K. Schwaber et. al. ''Twelve principles of agile software'', February 2001. Retrieved from http://agilemanifesto.org/principles.html </ref>.

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 <ref name=four> J. Highsmith. ''Agile Project Management: Creating Innovative Products''. Agile Software Development Series. Pearson Education, 2009. </ref>. The agile values in the Declaration of Interdependence are presented in <ref name=five>D. Anderson et. al. ''Declaration of interdependence'', February 2005. Retrieved from http://pmdoi.org/ </ref>.

The definition of Agile Project Management (APM) is in many cases referred to as a specific agile development methodology, e.g. eXtreme Programming (XP) <ref>E. C. Conforto et. al. ''Can agile project management be adopted by industries other than software development?'' Project Management Journal, 45(3):21–34, 2014.</ref>. 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 <ref name=seven>C. G. Cobb. ''Making Sense of Agile Project Management: Balancing Control and Agility''. John Wiley and Sons, 2011.</ref>.

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 <ref name=four/>.

Jim Highsmith presents three critical agile values in "''Agile Project Management: Creating Innovative Products''" <ref name=four/>, 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 <ref name=five/>.

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 <ref name=seven/>

'''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 <ref name=eight>S. Chandramouli and S. Dutt. ''PMI: Agile Certified Practitioner''. Pearson Education India, 2012.</ref>. 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''”<ref name=seven/>. 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<ref name=seven/><ref>P. Dinsmore and J. Cabanis-Brewin. ''The AMA handbook of project management''. AMACOM Div American Management Association, 2006.</ref>:

'''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 <ref name=seven/>. 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''" <ref name=eight/>.

'''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 <ref name=seven/> 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 <ref name=four/>. The flow of the APM model is shown in Figure 1.

[[File:APM.jpg|400px|right|thumb| Figure 1 - APM model based on <ref name=four/>]]

'''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 <ref name=eight/>. 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 <ref>ESI International. ''Successful solutions through Agile Project Management''. ESI International White Paper, 1(1):1–16, 2014</ref>.

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 <ref name=seven/>.

= References =
<references />

Agile Project Management

2014-11-27T11:45:34Z

Username111: /* APM Principles */

[[Category:Agile]] [[Category:Project Management]] [[Category:Agile Project Management]] [[Category: Complexity]] [[Category: Uncertainty]]

= 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 <ref> Project Management Journal. ''Agile Project Management: Essentials from the Project Management Journal.'' Jossey-Bass, 2013. </ref>.

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.”<ref> Fowler, Highsmith et. al. ''The Agile Manifesto''. Software Development, 9(8):28– 35, 2001. </ref>

These different value statements are further elaborated in twelve principles. A summary of these can be found in "''Twelve principles of agile software''" <ref> K. Schwaber et. al. ''Twelve principles of agile software'', February 2001. Retrieved from http://agilemanifesto.org/principles.html </ref>.

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 <ref name=four> J. Highsmith. ''Agile Project Management: Creating Innovative Products''. Agile Software Development Series. Pearson Education, 2009. </ref>. The agile values in the Declaration of Interdependence are presented in <ref name=five>D. Anderson et. al. ''Declaration of interdependence'', February 2005. Retrieved from http://pmdoi.org/ </ref>.

The definition of Agile Project Management (APM) is in many cases referred to as a specific agile development methodology, e.g. eXtreme Programming (XP) <ref>E. C. Conforto et. al. ''Can agile project management be adopted by industries other than software development?'' Project Management Journal, 45(3):21–34, 2014.</ref>. 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 <ref name=seven>C. G. Cobb. ''Making Sense of Agile Project Management: Balancing Control and Agility''. John Wiley and Sons, 2011.</ref>.

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 <ref name=four/>.

Jim Highsmith presents three critical agile values in "''Agile Project Management: Creating Innovative Products''" <ref name=four/>, 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 <ref name=five/>.

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 <ref name=seven/>

'''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 <ref name=eight>S. Chandramouli and S. Dutt. ''PMI: Agile Certified Practitioner''. Pearson Education India, 2012.</ref>. 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''”<ref name=seven/>. 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<ref name=seven/><ref>P. Dinsmore and J. Cabanis-Brewin. ''The AMA handbook of project management''. AMACOM Div American Management Association, 2006.</ref>:

'''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 <ref name=seven/>. 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 <ref name=eight/>.

'''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 <ref name=seven/> 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 <ref name=four/>. The flow of the APM model is shown in Figure 1.

[[File:APM.jpg|400px|right|thumb| Figure 1 - APM model based on <ref name=four/>]]

'''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 <ref name=eight/>. 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 <ref>ESI International. ''Successful solutions through Agile Project Management''. ESI International White Paper, 1(1):1–16, 2014</ref>.

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 <ref name=seven/>.

= References =
<references />

Agile Project Management

2014-11-27T11:45:00Z

Username111: /* APM Principles */

[[Category:Agile]] [[Category:Project Management]] [[Category:Agile Project Management]] [[Category: Complexity]] [[Category: Uncertainty]]

= 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 <ref> Project Management Journal. ''Agile Project Management: Essentials from the Project Management Journal.'' Jossey-Bass, 2013. </ref>.

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.”<ref> Fowler, Highsmith et. al. ''The Agile Manifesto''. Software Development, 9(8):28– 35, 2001. </ref>

These different value statements are further elaborated in twelve principles. A summary of these can be found in "''Twelve principles of agile software''" <ref> K. Schwaber et. al. ''Twelve principles of agile software'', February 2001. Retrieved from http://agilemanifesto.org/principles.html </ref>.

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 <ref name=four> J. Highsmith. ''Agile Project Management: Creating Innovative Products''. Agile Software Development Series. Pearson Education, 2009. </ref>. The agile values in the Declaration of Interdependence are presented in <ref name=five>D. Anderson et. al. ''Declaration of interdependence'', February 2005. Retrieved from http://pmdoi.org/ </ref>.

The definition of Agile Project Management (APM) is in many cases referred to as a specific agile development methodology, e.g. eXtreme Programming (XP) <ref>E. C. Conforto et. al. ''Can agile project management be adopted by industries other than software development?'' Project Management Journal, 45(3):21–34, 2014.</ref>. 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 <ref name=seven>C. G. Cobb. ''Making Sense of Agile Project Management: Balancing Control and Agility''. John Wiley and Sons, 2011.</ref>.

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 <ref name=four/>.

Jim Highsmith presents three critical agile values in "''Agile Project Management: Creating Innovative Products''" <ref name=four/>, 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 <ref name=five/>.

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 <ref name=seven/>

'''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 <ref name=eight>S. Chandramouli and S. Dutt. ''PMI: Agile Certified Practitioner''. Pearson Education India, 2012.</ref>. 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''”<ref name=seven/>. 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:<ref name=seven/><ref>P. Dinsmore and J. Cabanis-Brewin. ''The AMA handbook of project management''. AMACOM Div American Management Association, 2006.</ref>

'''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 <ref name=seven/>. 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 <ref name=eight/>.

'''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 <ref name=seven/> 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 <ref name=four/>. The flow of the APM model is shown in Figure 1.

[[File:APM.jpg|400px|right|thumb| Figure 1 - APM model based on <ref name=four/>]]

'''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 <ref name=eight/>. 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 <ref>ESI International. ''Successful solutions through Agile Project Management''. ESI International White Paper, 1(1):1–16, 2014</ref>.

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 <ref name=seven/>.

= References =
<references />

Agile Project Management

2014-11-27T11:43:06Z

Username111: /* APM Mindset */

[[Category:Agile]] [[Category:Project Management]] [[Category:Agile Project Management]] [[Category: Complexity]] [[Category: Uncertainty]]

= 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 <ref> Project Management Journal. ''Agile Project Management: Essentials from the Project Management Journal.'' Jossey-Bass, 2013. </ref>.

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.”<ref> Fowler, Highsmith et. al. ''The Agile Manifesto''. Software Development, 9(8):28– 35, 2001. </ref>

These different value statements are further elaborated in twelve principles. A summary of these can be found in "''Twelve principles of agile software''" <ref> K. Schwaber et. al. ''Twelve principles of agile software'', February 2001. Retrieved from http://agilemanifesto.org/principles.html </ref>.

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 <ref name=four> J. Highsmith. ''Agile Project Management: Creating Innovative Products''. Agile Software Development Series. Pearson Education, 2009. </ref>. The agile values in the Declaration of Interdependence are presented in <ref name=five>D. Anderson et. al. ''Declaration of interdependence'', February 2005. Retrieved from http://pmdoi.org/ </ref>.

The definition of Agile Project Management (APM) is in many cases referred to as a specific agile development methodology, e.g. eXtreme Programming (XP) <ref>E. C. Conforto et. al. ''Can agile project management be adopted by industries other than software development?'' Project Management Journal, 45(3):21–34, 2014.</ref>. 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 <ref name=seven>C. G. Cobb. ''Making Sense of Agile Project Management: Balancing Control and Agility''. John Wiley and Sons, 2011.</ref>.

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 <ref name=four/>.

Jim Highsmith presents three critical agile values in "''Agile Project Management: Creating Innovative Products''" <ref name=four/>, 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 <ref name=five/>.

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 <ref name=seven/>

'''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 <ref name=eight>S. Chandramouli and S. Dutt. ''PMI: Agile Certified Practitioner''. Pearson Education India, 2012.</ref>. 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''”<ref name=seven/>. 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. <ref name=seven/> and <ref>P. Dinsmore and J. Cabanis-Brewin. ''The AMA handbook of project management''. AMACOM Div American Management Association, 2006.</ref> 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 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 <ref name=seven/>. 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 <ref name=eight/>.

'''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 <ref name=seven/> 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 <ref name=four/>. The flow of the APM model is shown in Figure 1.

[[File:APM.jpg|400px|right|thumb| Figure 1 - APM model based on <ref name=four/>]]

'''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 <ref name=eight/>. 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 <ref>ESI International. ''Successful solutions through Agile Project Management''. ESI International White Paper, 1(1):1–16, 2014</ref>.

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 <ref name=seven/>.

= References =
<references />

Agile Project Management

2014-11-27T11:41:58Z

Username111: /* Introduction */

[[Category:Agile]] [[Category:Project Management]] [[Category:Agile Project Management]] [[Category: Complexity]] [[Category: Uncertainty]]

= 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 <ref> Project Management Journal. ''Agile Project Management: Essentials from the Project Management Journal.'' Jossey-Bass, 2013. </ref>.

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.”<ref> Fowler, Highsmith et. al. ''The Agile Manifesto''. Software Development, 9(8):28– 35, 2001. </ref>

These different value statements are further elaborated in twelve principles. A summary of these can be found in "''Twelve principles of agile software''" <ref> K. Schwaber et. al. ''Twelve principles of agile software'', February 2001. Retrieved from http://agilemanifesto.org/principles.html </ref>.

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 <ref name=four> J. Highsmith. ''Agile Project Management: Creating Innovative Products''. Agile Software Development Series. Pearson Education, 2009. </ref>. The agile values in the Declaration of Interdependence are presented in <ref name=five>D. Anderson et. al. ''Declaration of interdependence'', February 2005. Retrieved from http://pmdoi.org/ </ref>.

The definition of Agile Project Management (APM) is in many cases referred to as a specific agile development methodology, e.g. eXtreme Programming (XP) <ref>E. C. Conforto et. al. ''Can agile project management be adopted by industries other than software development?'' Project Management Journal, 45(3):21–34, 2014.</ref>. 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 <ref name=seven>C. G. Cobb. ''Making Sense of Agile Project Management: Balancing Control and Agility''. John Wiley and Sons, 2011.</ref>.

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 <ref name=four/>.

Jim Highsmith presents three critical agile values in "''Agile Project Management: Creating Innovative Products''" <ref name=four/>, 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 <ref name=five/>.

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 <ref name=seven/>

'''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 <ref name=eight>S. Chandramouli and S. Dutt. ''PMI: Agile Certified Practitioner''. Pearson Education India, 2012.</ref>. 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. <ref name=seven/> 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. <ref name=seven/> and <ref>P. Dinsmore and J. Cabanis-Brewin. ''The AMA handbook of project management''. AMACOM Div American Management Association, 2006.</ref> 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 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 <ref name=seven/>. 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 <ref name=eight/>.

'''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 <ref name=seven/> 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 <ref name=four/>. The flow of the APM model is shown in Figure 1.

[[File:APM.jpg|400px|right|thumb| Figure 1 - APM model based on <ref name=four/>]]

'''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 <ref name=eight/>. 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 <ref>ESI International. ''Successful solutions through Agile Project Management''. ESI International White Paper, 1(1):1–16, 2014</ref>.

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 <ref name=seven/>.

= References =
<references />

Agile Project Management

2014-11-27T11:40:28Z

Username111: /* Introduction */

[[Category:Agile]] [[Category:Project Management]] [[Category:Agile Project Management]] [[Category: Complexity]] [[Category: Uncertainty]]

= 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 <ref> Project Management Journal. ''Agile Project Management: Essentials from the Project Management Journal.'' Jossey-Bass, 2013. </ref>.

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.”<ref> Fowler, Highsmith et. al. ''The Agile Manifesto''. Software Development, 9(8):28– 35, 2001. </ref>

These different value statements are further elaborated in twelve principles. A summary of these can be found in "Twelve principles of agile software" <ref> K. Schwaber et. al. ''Twelve principles of agile software'', February 2001. Retrieved from http://agilemanifesto.org/principles.html </ref>.

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 <ref name=four> J. Highsmith. ''Agile Project Management: Creating Innovative Products''. Agile Software Development Series. Pearson Education, 2009. </ref>. The agile values in the Declaration of Interdependence are presented in <ref name=five>D. Anderson et. al. ''Declaration of interdependence'', February 2005. Retrieved from http://pmdoi.org/ </ref>.

The definition of Agile Project Management (APM) is in many cases referred to as a specific agile development methodology, e.g. eXtreme Programming (XP) <ref>E. C. Conforto et. al. ''Can agile project management be adopted by industries other than software development?'' Project Management Journal, 45(3):21–34, 2014.</ref>. 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 <ref name=seven>C. G. Cobb. ''Making Sense of Agile Project Management: Balancing Control and Agility''. John Wiley and Sons, 2011.</ref>.

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 <ref name=four/>.

Jim Highsmith presents three critical agile values in "Agile Project Management: Creating Innovative Products" <ref name=four/>, 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 <ref name=five/>.

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 <ref name=seven/>

'''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 <ref name=eight>S. Chandramouli and S. Dutt. ''PMI: Agile Certified Practitioner''. Pearson Education India, 2012.</ref>. 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. <ref name=seven/> 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. <ref name=seven/> and <ref>P. Dinsmore and J. Cabanis-Brewin. ''The AMA handbook of project management''. AMACOM Div American Management Association, 2006.</ref> 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 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 <ref name=seven/>. 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 <ref name=eight/>.

'''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 <ref name=seven/> 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 <ref name=four/>. The flow of the APM model is shown in Figure 1.

[[File:APM.jpg|400px|right|thumb| Figure 1 - APM model based on <ref name=four/>]]

'''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 <ref name=eight/>. 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 <ref>ESI International. ''Successful solutions through Agile Project Management''. ESI International White Paper, 1(1):1–16, 2014</ref>.

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 <ref name=seven/>.

= References =
<references />

Agile Project Management

2014-11-27T11:36:24Z

Username111: /* Introduction */

[[Category:Agile]] [[Category:Project Management]] [[Category:Agile Project Management]] [[Category: Complexity]] [[Category: Uncertainty]]

= 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 <ref> Project Management Journal. ''Agile Project Management: Essentials from the Project Management Journal.'' Jossey-Bass, 2013. </ref>.

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.”<ref> Fowler, Highsmith et. al. ''The Agile Manifesto''. Software Development, 9(8):28– 35, 2001. </ref>

These different value statements are further elaborated in twelve principles. A summary of these can be found in "Twelve principles of agile software" <ref> K. Schwaber et. al. ''Twelve principles of agile software'', February 2001. Retrieved from http://agilemanifesto.org/principles.html </ref>.

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 <ref name=four> J. Highsmith. ''Agile Project Management: Creating Innovative Products''. Agile Software Development Series. Pearson Education, 2009. </ref>. The agile values in the Declaration of Interdependence are presented in <ref name=five>D. Anderson et. al. ''Declaration of interdependence'', February 2005. Retrieved from http://pmdoi.org/ </ref>.

The definition of Agile Project Management (APM) is in many cases referred to as a specific agile development methodology, e.g. eXtreme Programming (XP) <ref>E. C. Conforto et. al. ''Can agile project management be adopted by industries other than software development?'' Project Management Journal, 45(3):21–34, 2014.</ref>. 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 <ref name=seven>C. G. Cobb. ''Making Sense of Agile Project Management: Balancing Control and Agility''. John Wiley and Sons, 2011.</ref>.

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 <ref name=four/>.

Jim Highsmith presents three critical agile values in <ref name=four/>, 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 <ref name=five/>.

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 <ref name=seven/>

'''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 <ref name=eight>S. Chandramouli and S. Dutt. ''PMI: Agile Certified Practitioner''. Pearson Education India, 2012.</ref>. 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. <ref name=seven/> 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. <ref name=seven/> and <ref>P. Dinsmore and J. Cabanis-Brewin. ''The AMA handbook of project management''. AMACOM Div American Management Association, 2006.</ref> 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 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 <ref name=seven/>. 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 <ref name=eight/>.

'''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 <ref name=seven/> 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 <ref name=four/>. The flow of the APM model is shown in Figure 1.

[[File:APM.jpg|400px|right|thumb| Figure 1 - APM model based on <ref name=four/>]]

'''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 <ref name=eight/>. 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 <ref>ESI International. ''Successful solutions through Agile Project Management''. ESI International White Paper, 1(1):1–16, 2014</ref>.

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 <ref name=seven/>.

= References =
<references />

Agile Project Management

2014-11-27T11:35:45Z

Username111: /* Introduction */

[[Category:Agile]] [[Category:Project Management]] [[Category:Agile Project Management]] [[Category: Complexity]] [[Category: Uncertainty]]

= 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 <ref> Project Management Journal. ''Agile Project Management: Essentials from the Project Management Journal.'' Jossey-Bass, 2013. </ref>.

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.”<ref> Fowler, Highsmith et. al. ''The Agile Manifesto''. Software Development, 9(8):28– 35, 2001. </ref>

These different value statements are further elaborated in twelve principles. A summary of these can be found in <ref> K. Schwaber et. al. ''Twelve principles of agile software'', February 2001. Retrieved from http://agilemanifesto.org/principles.html </ref>.

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 <ref name=four> J. Highsmith. ''Agile Project Management: Creating Innovative Products''. Agile Software Development Series. Pearson Education, 2009. </ref>. The agile values in the Declaration of Interdependence are presented in <ref name=five>D. Anderson et. al. ''Declaration of interdependence'', February 2005. Retrieved from http://pmdoi.org/ </ref>.

The definition of Agile Project Management (APM) is in many cases referred to as a specific agile development methodology, e.g. eXtreme Programming (XP) <ref>E. C. Conforto et. al. ''Can agile project management be adopted by industries other than software development?'' Project Management Journal, 45(3):21–34, 2014.</ref>. 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 <ref name=seven>C. G. Cobb. ''Making Sense of Agile Project Management: Balancing Control and Agility''. John Wiley and Sons, 2011.</ref>.

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 <ref name=four/>.

Jim Highsmith presents three critical agile values in <ref name=four/>, 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 <ref name=five/>.

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 <ref name=seven/>

'''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 <ref name=eight>S. Chandramouli and S. Dutt. ''PMI: Agile Certified Practitioner''. Pearson Education India, 2012.</ref>. 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. <ref name=seven/> 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. <ref name=seven/> and <ref>P. Dinsmore and J. Cabanis-Brewin. ''The AMA handbook of project management''. AMACOM Div American Management Association, 2006.</ref> 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 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 <ref name=seven/>. 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 <ref name=eight/>.

'''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 <ref name=seven/> 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 <ref name=four/>. The flow of the APM model is shown in Figure 1.

[[File:APM.jpg|400px|right|thumb| Figure 1 - APM model based on <ref name=four/>]]

'''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 <ref name=eight/>. 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 <ref>ESI International. ''Successful solutions through Agile Project Management''. ESI International White Paper, 1(1):1–16, 2014</ref>.

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 <ref name=seven/>.

= References =
<references />

Agile Project Management

2014-11-27T11:35:11Z

Username111: /* Introduction */

[[Category:Agile]] [[Category:Project Management]] [[Category:Agile Project Management]] [[Category: Complexity]] [[Category: Uncertainty]]

= 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 <ref> Project Management Journal. ''Agile Project Management: Essentials from the Project Management Journal.'' Jossey-Bass, 2013. </ref>.

The agile values is clearly stated in "The Agile Manifesto" <ref> Fowler, Highsmith et. al. ''The Agile Manifesto''. Software Development, 9(8):28– 35, 2001. </ref> 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 <ref> K. Schwaber et. al. ''Twelve principles of agile software'', February 2001. Retrieved from http://agilemanifesto.org/principles.html </ref>.

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 <ref name=four> J. Highsmith. ''Agile Project Management: Creating Innovative Products''. Agile Software Development Series. Pearson Education, 2009. </ref>. The agile values in the Declaration of Interdependence are presented in <ref name=five>D. Anderson et. al. ''Declaration of interdependence'', February 2005. Retrieved from http://pmdoi.org/ </ref>.

The definition of Agile Project Management (APM) is in many cases referred to as a specific agile development methodology, e.g. eXtreme Programming (XP) <ref>E. C. Conforto et. al. ''Can agile project management be adopted by industries other than software development?'' Project Management Journal, 45(3):21–34, 2014.</ref>. 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 <ref name=seven>C. G. Cobb. ''Making Sense of Agile Project Management: Balancing Control and Agility''. John Wiley and Sons, 2011.</ref>.

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 <ref name=four/>.

Jim Highsmith presents three critical agile values in <ref name=four/>, 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 <ref name=five/>.

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 <ref name=seven/>

'''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 <ref name=eight>S. Chandramouli and S. Dutt. ''PMI: Agile Certified Practitioner''. Pearson Education India, 2012.</ref>. 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. <ref name=seven/> 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. <ref name=seven/> and <ref>P. Dinsmore and J. Cabanis-Brewin. ''The AMA handbook of project management''. AMACOM Div American Management Association, 2006.</ref> 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 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 <ref name=seven/>. 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 <ref name=eight/>.

'''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 <ref name=seven/> 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 <ref name=four/>. The flow of the APM model is shown in Figure 1.

[[File:APM.jpg|400px|right|thumb| Figure 1 - APM model based on <ref name=four/>]]

'''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 <ref name=eight/>. 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 <ref>ESI International. ''Successful solutions through Agile Project Management''. ESI International White Paper, 1(1):1–16, 2014</ref>.

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 <ref name=seven/>.

= References =
<references />

Talk:Agile Project Management

2014-11-27T11:32:50Z

Username111: /* Review by secna */

== Review by secna ==
'''''Answers to review by author (Username111) is written below bullet points in bold/italic.'''''

Overall a good article, which gives a good overview into what agile PM is and relevant within the topics of PM.

* It would improve the understanding of agile if you start out with a very short intro to what is agile PM is before you start the history of the method it will make it easier to follow.
** '''''I don't quite agree. If the reader don't know what agile is, I believe that it is important to start by understanding what agile is, before moving into what APM is. In addition, there is no simple way to describe APM in a single sentence, and therefore i will leave the definition of what APM is in the detailed method description'''''

*The amount of references that you have found is good, and when you read the article it really shows that it have been carefully investigated. But when you just write “it can be found in [x], then atleast I thought it was ruining the reading flow, I think it would help if you also added the name of the article that your referring to in the text.
** '''''I agree. I have added the name of the article where it made sense.'''''

*Is there any related methods/standards that can be used together with agile PM?
** '''''Yes. Due to the flexible and adaptable nature of APM in can in principle be used with any method if it makes sense. If a project is run by a traditional plan-based project management approach, and there is no complexity or uncertainty, it might not make much sense to use it. However, as soon as a project is experiencing complexity or uncertainty, APM can be introduced, no matter which method is being used. The main barrier for implementing APM to any project is more the organisational structure and culture, not the method or standard used.'''''

*Its nice figure which gives a good overview of the APM model, remember to refer to the figure in the text.
** '''''Figure reference added to the text.'''''

== Review by Dunseiz ==
'''''Answers to review by author (Username111) is written in bold/italic'''''

This article is very well disposed and well argued. Good job! I have therefore focused my review on technical and formal stuff that in my opinion could lift the article. Enjoy :)

'''REFERENCES'''

The references are done manually as far as I can see. I have taken the liberty and made reference 1 to 4 "linked" for you. No. 4 differs slightly in coding due to the multiple usage. They can be copied/pasted and modified to fit the rest of the references.

'''''Thank you for the example. I have corrected the referencing to be linked.'''''

'''LAYOUT'''

There are many short sections in the introduction which can be a bit difficult to separate. This is mainly due to the line spacing when jumping to next line. Maybe you could use more sub-sub titles to separate these short sections or maybe just make an extra space between them?

'''''I agree that the short sections can be difficult to separate due to the formatting of linespacing in the wiki setup. If I introduce subsub(sub) headings it will will give me sub headings with four numbers, e.g. 2.2.1.1 Rolling wave planning, which I believe also will confuse the reader. I looked at some of the other articles and the linespacing seems to be a common issue due to the wiki setup. I will therefore leave it as it is, in order for it to fit the general style of all the articles in this wiki.'''''

'''GRAMMAR'''

''word contractions'' are usually not used in written language.
"...agile methodologies often don’t separate between..." should be "...agile methodologies often do not separate between..."
"In many cases agile methodologies doesn’t even use..." should be "In many cases agile methodologies do not even use..."

'''''I have corrected all the word contractions to be separate words now'''''

Talk:Agile Project Management

2014-11-27T11:31:32Z

Username111: /* Review by secna */

== Review by secna ==
Comments to review by author (Username111) is written below bullet points.

Overall a good article, which gives a good overview into what agile PM is and relevant within the topics of PM.

* It would improve the understanding of agile if you start out with a very short intro to what is agile PM is before you start the history of the method it will make it easier to follow.
** I don't quite agree. If the reader don't know what agile is, I believe that it is important to start by understanding what agile is, before moving into what APM is. In addition, there is no simple way to describe APM in a single sentence, and therefore i will leave the definition of what APM is in the detailed method description

*The amount of references that you have found is good, and when you read the article it really shows that it have been carefully investigated. But when you just write “it can be found in [x], then atleast I thought it was ruining the reading flow, I think it would help if you also added the name of the article that your referring to in the text.
** I agree. I have added the name of the article where it made sense.

*Is there any related methods/standards that can be used together with agile PM?
** Yes. Due to the flexible and adaptable nature of APM in can in principle be used with any method if it makes sense. If a project is run by a traditional plan-based project management approach, and there is no complexity or uncertainty, it might not make much sense to use it. However, as soon as a project is experiencing complexity or uncertainty, APM can be introduced, no matter which method is being used. The main barrier for implementing APM to any project is more the organisational structure and culture, not the method or standard used.

*Its nice figure which gives a good overview of the APM model, remember to refer to the figure in the text.
** Figure reference added to the text.

== Review by Dunseiz ==
'''''Answers to review by author (Username111) is written in bold/italic'''''

This article is very well disposed and well argued. Good job! I have therefore focused my review on technical and formal stuff that in my opinion could lift the article. Enjoy :)

'''REFERENCES'''

The references are done manually as far as I can see. I have taken the liberty and made reference 1 to 4 "linked" for you. No. 4 differs slightly in coding due to the multiple usage. They can be copied/pasted and modified to fit the rest of the references.

'''''Thank you for the example. I have corrected the referencing to be linked.'''''

'''LAYOUT'''

There are many short sections in the introduction which can be a bit difficult to separate. This is mainly due to the line spacing when jumping to next line. Maybe you could use more sub-sub titles to separate these short sections or maybe just make an extra space between them?

'''''I agree that the short sections can be difficult to separate due to the formatting of linespacing in the wiki setup. If I introduce subsub(sub) headings it will will give me sub headings with four numbers, e.g. 2.2.1.1 Rolling wave planning, which I believe also will confuse the reader. I looked at some of the other articles and the linespacing seems to be a common issue due to the wiki setup. I will therefore leave it as it is, in order for it to fit the general style of all the articles in this wiki.'''''

'''GRAMMAR'''

''word contractions'' are usually not used in written language.
"...agile methodologies often don’t separate between..." should be "...agile methodologies often do not separate between..."
"In many cases agile methodologies doesn’t even use..." should be "In many cases agile methodologies do not even use..."

'''''I have corrected all the word contractions to be separate words now'''''

Talk:Agile Project Management

2014-11-27T11:03:18Z

Username111: /* Review by Dunseiz */

== Review by secna ==

Overall a good article, which gives a good overview into what agile PM is and relevant within the topics of PM.

* It would improve the understanding of agile if you start out with a very short intro to what is agile PM is before you start the history of the method it will make it easier to follow.

*The amount of references that you have found is good, and when you read the article it really shows that it have been carefully investigated. But when you just write “it can be found in [x], then atleast I thought it was ruining the reading flow, I think it would help if you also added the name of the article that your referring to in the text.

*Is there any related methods/standards that can be used together with agile PM?

*Its nice figure which gives a good overview of the APM model, remember to refer to the figure in the text.

== Review by Dunseiz ==
'''''Answers to review by author (Username111) is written in bold/italic'''''

This article is very well disposed and well argued. Good job! I have therefore focused my review on technical and formal stuff that in my opinion could lift the article. Enjoy :)

'''REFERENCES'''

The references are done manually as far as I can see. I have taken the liberty and made reference 1 to 4 "linked" for you. No. 4 differs slightly in coding due to the multiple usage. They can be copied/pasted and modified to fit the rest of the references.

'''''Thank you for the example. I have corrected the referencing to be linked.'''''

'''LAYOUT'''

There are many short sections in the introduction which can be a bit difficult to separate. This is mainly due to the line spacing when jumping to next line. Maybe you could use more sub-sub titles to separate these short sections or maybe just make an extra space between them?

'''''I agree that the short sections can be difficult to separate due to the formatting of linespacing in the wiki setup. If I introduce subsub(sub) headings it will will give me sub headings with four numbers, e.g. 2.2.1.1 Rolling wave planning, which I believe also will confuse the reader. I looked at some of the other articles and the linespacing seems to be a common issue due to the wiki setup. I will therefore leave it as it is, in order for it to fit the general style of all the articles in this wiki.'''''

'''GRAMMAR'''

''word contractions'' are usually not used in written language.
"...agile methodologies often don’t separate between..." should be "...agile methodologies often do not separate between..."
"In many cases agile methodologies doesn’t even use..." should be "In many cases agile methodologies do not even use..."

'''''I have corrected all the word contractions to be separate words now'''''

Talk:Agile Project Management

2014-11-27T11:02:58Z

Username111: /* Review by Dunseiz */

== Review by secna ==

Overall a good article, which gives a good overview into what agile PM is and relevant within the topics of PM.

* It would improve the understanding of agile if you start out with a very short intro to what is agile PM is before you start the history of the method it will make it easier to follow.

*The amount of references that you have found is good, and when you read the article it really shows that it have been carefully investigated. But when you just write “it can be found in [x], then atleast I thought it was ruining the reading flow, I think it would help if you also added the name of the article that your referring to in the text.

*Is there any related methods/standards that can be used together with agile PM?

*Its nice figure which gives a good overview of the APM model, remember to refer to the figure in the text.

== Review by Dunseiz ==
'''''Answers to review by author (Username111) is written in bold/italic'''''

This article is very well disposed and well argued. Good job! I have therefore focused my review on technical and formal stuff that in my opinion could lift the article. Enjoy :)

'''REFERENCES'''

The references are done manually as far as I can see. I have taken the liberty and made reference 1 to 4 "linked" for you. No. 4 differs slightly in coding due to the multiple usage. They can be copied/pasted and modified to fit the rest of the references.

'''''Thank you for the example. I have corrected the referencing to be linked.'''''

'''LAYOUT'''

There are many short sections in the introduction which can be a bit difficult to separate. This is mainly due to the line spacing when jumping to next line. Maybe you could use more sub-sub titles to separate these short sections or maybe just make an extra space between them?

I agree that the short sections can be difficult to separate due to the formatting of linespacing in the wiki setup. If I introduce subsub(sub) headings it will will give me sub headings with four numbers, e.g. 2.2.1.1 Rolling wave planning, which I believe also will confuse the reader. I looked at some of the other articles and the linespacing seems to be a common issue due to the wiki setup. I will therefore leave it as it is, in order for it to fit the general style of all the articles in this wiki.

'''GRAMMAR'''

''word contractions'' are usually not used in written language.
"...agile methodologies often don’t separate between..." should be "...agile methodologies often do not separate between..."
"In many cases agile methodologies doesn’t even use..." should be "In many cases agile methodologies do not even use..."

'''''I have corrected all the word contractions to be separate words now'''''

Talk:Agile Project Management

2014-11-27T10:53:20Z

Username111: /* Review by Dunseiz */

== Review by secna ==

Overall a good article, which gives a good overview into what agile PM is and relevant within the topics of PM.

* It would improve the understanding of agile if you start out with a very short intro to what is agile PM is before you start the history of the method it will make it easier to follow.

*The amount of references that you have found is good, and when you read the article it really shows that it have been carefully investigated. But when you just write “it can be found in [x], then atleast I thought it was ruining the reading flow, I think it would help if you also added the name of the article that your referring to in the text.

*Is there any related methods/standards that can be used together with agile PM?

*Its nice figure which gives a good overview of the APM model, remember to refer to the figure in the text.

== Review by Dunseiz ==
'''''Answers to review by author (Username111) is written in bold/italic'''''

This article is very well disposed and well argued. Good job! I have therefore focused my review on technical and formal stuff that in my opinion could lift the article. Enjoy :)

'''REFERENCES'''

The references are done manually as far as I can see. I have taken the liberty and made reference 1 to 4 "linked" for you. No. 4 differs slightly in coding due to the multiple usage. They can be copied/pasted and modified to fit the rest of the references.

'''''Thank you for the example. I have corrected the referencing to be linked.'''''

'''LAYOUT'''

There are many short sections in the introduction which can be a bit difficult to separate. This is mainly due to the line spacing when jumping to next line. Maybe you could use more sub-sub titles to separate these short sections or maybe just make an extra space between them?

'''GRAMMAR'''

''word contractions'' are usually not used in written language.
"...agile methodologies often don’t separate between..." should be "...agile methodologies often do not separate between..."
"In many cases agile methodologies doesn’t even use..." should be "In many cases agile methodologies do not even use..."

'''''I have corrected all the word contractions to be separate words now'''''

Agile Project Management

2014-11-27T10:48:30Z

Username111: /* APM Model */

[[Category:Agile]] [[Category:Project Management]] [[Category:Agile Project Management]] [[Category: Complexity]] [[Category: Uncertainty]]

= 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 <ref> Project Management Journal. ''Agile Project Management: Essentials from the Project Management Journal.'' Jossey-Bass, 2013. </ref>.

The values of the Agile Manifesto is clearly stated in <ref> Fowler, Highsmith et. al. ''The Agile Manifesto''. Software Development, 9(8):28– 35, 2001. </ref> 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 <ref> K. Schwaber et. al. ''Twelve principles of agile software'', February 2001. Retrieved from http://agilemanifesto.org/principles.html </ref>.

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 <ref name=four> J. Highsmith. ''Agile Project Management: Creating Innovative Products''. Agile Software Development Series. Pearson Education, 2009. </ref>. The agile values in the Declaration of Interdependence are presented in <ref name=five>D. Anderson et. al. ''Declaration of interdependence'', February 2005. Retrieved from http://pmdoi.org/ </ref>.

The definition of Agile Project Management (APM) is in many cases referred to as a specific agile development methodology, e.g. eXtreme Programming (XP) <ref>E. C. Conforto et. al. ''Can agile project management be adopted by industries other than software development?'' Project Management Journal, 45(3):21–34, 2014.</ref>. 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 <ref name=seven>C. G. Cobb. ''Making Sense of Agile Project Management: Balancing Control and Agility''. John Wiley and Sons, 2011.</ref>.

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 <ref name=four/>.

Jim Highsmith presents three critical agile values in <ref name=four/>, 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 <ref name=five/>.

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 <ref name=seven/>

'''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 <ref name=eight>S. Chandramouli and S. Dutt. ''PMI: Agile Certified Practitioner''. Pearson Education India, 2012.</ref>. 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. <ref name=seven/> 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. <ref name=seven/> and <ref>P. Dinsmore and J. Cabanis-Brewin. ''The AMA handbook of project management''. AMACOM Div American Management Association, 2006.</ref> 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 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 <ref name=seven/>. 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 <ref name=eight/>.

'''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 <ref name=seven/> 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 <ref name=four/>. The flow of the APM model is shown in Figure 1.

[[File:APM.jpg|400px|right|thumb| Figure 1 - APM model based on <ref name=four/>]]

'''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 <ref name=eight/>. 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 <ref>ESI International. ''Successful solutions through Agile Project Management''. ESI International White Paper, 1(1):1–16, 2014</ref>.

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 <ref name=seven/>.

= References =
<references />

Agile Project Management

2014-11-27T10:14:56Z

Username111:

[[Category:Agile]] [[Category:Project Management]] [[Category:Agile Project Management]] [[Category: Complexity]] [[Category: Uncertainty]]

= 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 <ref> Project Management Journal. ''Agile Project Management: Essentials from the Project Management Journal.'' Jossey-Bass, 2013. </ref>.

The values of the Agile Manifesto is clearly stated in <ref> Fowler, Highsmith et. al. ''The Agile Manifesto''. Software Development, 9(8):28– 35, 2001. </ref> 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 <ref> K. Schwaber et. al. ''Twelve principles of agile software'', February 2001. Retrieved from http://agilemanifesto.org/principles.html </ref>.

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 <ref name=four> J. Highsmith. ''Agile Project Management: Creating Innovative Products''. Agile Software Development Series. Pearson Education, 2009. </ref>. The agile values in the Declaration of Interdependence are presented in <ref name=five>D. Anderson et. al. ''Declaration of interdependence'', February 2005. Retrieved from http://pmdoi.org/ </ref>.

The definition of Agile Project Management (APM) is in many cases referred to as a specific agile development methodology, e.g. eXtreme Programming (XP) <ref>E. C. Conforto et. al. ''Can agile project management be adopted by industries other than software development?'' Project Management Journal, 45(3):21–34, 2014.</ref>. 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 <ref name=seven>C. G. Cobb. ''Making Sense of Agile Project Management: Balancing Control and Agility''. John Wiley and Sons, 2011.</ref>.

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 <ref name=four/>.

Jim Highsmith presents three critical agile values in <ref name=four/>, 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 <ref name=five/>.

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 <ref name=seven/>

'''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 <ref name=eight>S. Chandramouli and S. Dutt. ''PMI: Agile Certified Practitioner''. Pearson Education India, 2012.</ref>. 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. <ref name=seven/> 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. <ref name=seven/> and <ref>P. Dinsmore and J. Cabanis-Brewin. ''The AMA handbook of project management''. AMACOM Div American Management Association, 2006.</ref> 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 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 <ref name=seven/>. 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 <ref name=eight/>.

'''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 <ref name=seven/> 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 <ref name=four/>.

[[File:APM.jpg|400px|right|thumb| APM model based on <ref name=four/>]]

'''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 <ref name=eight/>. 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 <ref>ESI International. ''Successful solutions through Agile Project Management''. ESI International White Paper, 1(1):1–16, 2014</ref>.

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 <ref name=seven/>.

= References =
<references />

Agile Project Management

2014-11-27T10:12:57Z

Username111:

[[Category:Agile]] [[Category:Project Management]] [[Category:Agile Project Management]] [[Category: Complexity]] [[Category: Uncertainty]]

= 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 <ref> Project Management Journal. ''Agile Project Management: Essentials from the Project Management Journal.'' Jossey-Bass, 2013. </ref>.

The values of the Agile Manifesto is clearly stated in <ref> Fowler, Highsmith et. al. ''The Agile Manifesto''. Software Development, 9(8):28– 35, 2001. </ref> 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 <ref> K. Schwaber et. al. ''Twelve principles of agile software'', February 2001. Retrieved from http://agilemanifesto.org/principles.html </ref>.

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 <ref name=four> J. Highsmith. ''Agile Project Management: Creating Innovative Products''. Agile Software Development Series. Pearson Education, 2009. </ref>. The agile values in the Declaration of Interdependence are presented in <ref name=five>D. Anderson et. al. ''Declaration of interdependence'', February 2005. Retrieved from http://pmdoi.org/ </ref>.

The definition of Agile Project Management (APM) is in many cases referred to as a specific agile development methodology, e.g. eXtreme Programming (XP) <ref>E. C. Conforto et. al. ''Can agile project management be adopted by industries other than software development?'' Project Management Journal, 45(3):21–34, 2014.</ref>. 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 <ref name=seven>C. G. Cobb. ''Making Sense of Agile Project Management: Balancing Control and Agility''. John Wiley and Sons, 2011.</ref>.

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 <ref name=four/>.

Jim Highsmith presents three critical agile values in <ref name=four/>, 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 <ref name=five/>.

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 <ref name=seven/>

'''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 <ref name=eight>S. Chandramouli and S. Dutt. ''PMI: Agile Certified Practitioner''. Pearson Education India, 2012.</ref>. 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. <ref name=seven/> 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. <ref name=seven/> and <ref>P. Dinsmore and J. Cabanis-Brewin. ''The AMA handbook of project management''. AMACOM Div American Management Association, 2006.</ref> 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 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 <ref name=seven/>. 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 <ref name=eight/>.

'''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 <ref name=seven/> 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 doesn'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 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 <ref name=four/>.

[[File:APM.jpg|400px|right|thumb| APM model based on <ref name=four/>]]

'''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 <ref name=eight/>. 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 <ref>ESI International. ''Successful solutions through Agile Project Management''. ESI International White Paper, 1(1):1–16, 2014</ref>.

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 <ref name=seven/>.

= References =
<references />

Agile Project Management

2014-11-27T09:55:06Z

Username111:

[[Category:Agile]] [[Category:Project Management]] [[Category:Agile Project Management]] [[Category: Complexity]] [[Category: Uncertainty]]

= 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 <ref> Project Management Journal. ''Agile Project Management: Essentials from the Project Management Journal.'' Jossey-Bass, 2013. </ref>.

The values of the Agile Manifesto is clearly stated in <ref> Fowler, Highsmith et. al. ''The Agile Manifesto''. Software Development, 9(8):28– 35, 2001. </ref> 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 <ref> K. Schwaber et. al. ''Twelve principles of agile software'', February 2001. Retrieved from http://agilemanifesto.org/principles.html </ref>.

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 <ref name=four> J. Highsmith. ''Agile Project Management: Creating Innovative Products''. Agile Software Development Series. Pearson Education, 2009. </ref>. The agile values in the Declaration of Interdependence are presented in <ref name=five>D. Anderson et. al. ''Declaration of interdependence'', February 2005. Retrieved from http://pmdoi.org/ </ref>.

The definition of Agile Project Management (APM) is in many cases referred to as a specific agile development methodology, e.g. eXtreme Programming (XP) <ref>E. C. Conforto et. al. ''Can agile project management be adopted by industries other than software development?'' Project Management Journal, 45(3):21–34, 2014.</ref>. 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 <ref name=seven>C. G. Cobb. ''Making Sense of Agile Project Management: Balancing Control and Agility''. John Wiley and Sons, 2011.</ref>.

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 <ref name=four/>.

Jim Highsmith presents three critical agile values in <ref name=four/>, 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 <ref name=five/>.

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 <ref name=seven/>

'''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 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 <ref name=eight>S. Chandramouli and S. Dutt. ''PMI: Agile Certified Practitioner''. Pearson Education India, 2012.</ref>. 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. <ref name=seven/> 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. <ref name=seven/> and <ref>P. Dinsmore and J. Cabanis-Brewin. ''The AMA handbook of project management''. AMACOM Div American Management Association, 2006.</ref> 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 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 <ref name=seven/>. 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 <ref name=eight/>.

'''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 <ref name=seven/> 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 doesn'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 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 <ref name=four/>.

[[File:APM.jpg|400px|right|thumb| APM model based on <ref name=four/>]]

'''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 <ref name=eight/>. 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 <ref>ESI International. ''Successful solutions through Agile Project Management''. ESI International White Paper, 1(1):1–16, 2014</ref>.

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 <ref name=seven/>.

= References =
<references />

Talk:Risk management strategy

2014-11-25T15:33:55Z

Username111: /* Review from Username111 */ new section

== Review from Username111 ==

First of all, it doesn't look like the article is complete yet. Therefore, I will only give a review based on the abstract, structure and the risk processing chapter (doesn't seem complete either but I'll use what is produced so far) which is currently produced (November 25th 15:00). However, the topic seems interesting and very relevant for any project manager (or student within project management). It seems clear that the article is under in-depth method description category, due to each of the proposed chapters will have method descriptions.

I like the proposed structure of the article. I believe that it will create a good flow with a clear red thread.

These are my specific questions and suggestions:

* Maybe you could add a general example to each of the chapters. This could further strengthen the arguments of using the methods. E.g. you could give an example of an identified risk in "risk identification", analyze this specific risk in "risk analysis", assess the risk in "risk assessment", and finally propose mitigation action for the risk in "risk processing". This would give the reader a clear understanding of how to use the proposed methods in each of the chapters.
* There seems to be a lack of proper referencing.
** In the first sentence you reference to (Machiavelli, 1514), but there is no bibliography were I can find the actual article/journal/book.
** In the second paragraph in the abstract there is a lot of interesting statements of risk management. I guess most of them are not something you have created out of your own thoughts, and therefore they need referencing to the correct sources. E.g. the definition of risk: "''A risk can be defined as the product of the probability of the risk and the impact of the risk''" needs referencing. Maybe some of the statements are common sense for a project manager, but I would still suggest using some references to academic resources in order to improve the quality of the article.
** Your dice example needs need a reference as well, unless you came up with it yourself of course.
* In the second paragraph you give two examples; when a problem is likely to happen but no impact, and when a problem is unlikely to happen and high impact. Maybe you could add a few more examples, in order to introduce scenarios were risk mitigation action is required.
* You talk about "injuries" in relation to the impact of a given risk. I consider an injury something that can occur to an person. E.g. Bendtner sustained an injury after scoring his 6th goal. I would propose to use: consequence, damage, etc., since it often will be the impact in the project/company, not the person.
* This sentence is very hard to read: "''If there is no certain way to determine a risk’s impact or probability or multiple risks are compared without having similar impact type (e.g. comparing human casualties against monetary loss) a qualitative approach can be used, where the risk is rated from e.g. 1-5.''". Please consider revising, in order to make it more understandable.
* Since you already mention there are several other apppm wikis about risk management, you could use these as potential references, instead of just saying they might be similar.
* The risk processing chapter: It seems like the chapter is not completely done. I would suggest to begin this chapter with describing the different methods/strategies (accept, mitigate, transfer, avoid, improve), and then follow by when you would use these different methods/strategies. Ideally you could give an example in the end of a risk that has been mitigated using one of the methods/strategies. Remember proper referencing for this chapter as well.

Other than these few comments, good job. Just fill in the chapters and make sure to use proper referencing, and the article will be great :)

Good luck!

Talk:SWOT matrix

2014-11-25T15:25:32Z

Username111: /* Review from Username111 */ new section

== Review from Username111 ==

The topic seems relevant even though it is a very common used method. But many project managers (or student within project management) may neglect some aspects of what seems to be a simple method, and therefore I believe that a compressive description of the method is interesting. It seems like to topic lies under the "introduction and overview" category, since no specific guidelines for using the method is described.

I will start by some overall considerations:

'''Structure'''

The overall structure of the article seems very throughout. Personally, I'm not a fan of 3 x sub headings (e.g. 1.1.1.1 Walmart example). I don't believe it is necessary to divide it this much in a short article like this. I would consider to skip the 3 x sub headings.

This will make the table of content a bit more easy to grasp.

'''Referencing'''

I don't see any references anywhere, other than your bibliography in the end. You need to show where you use the different sources in your text. I know that the SWOT matrix is a proportional simple method, and you properly would be able to describe it without any use of references. However! This should be an academic article, and therefore it is very important part of the article. There is lot of different ways of referencing correct, find inspiration in the other articles. In addition, you could add to the quality of your article by using more than the 3 online sources you use today, preferably journal articles, books etc.

My more specific questions and suggestions in chronological order (starting from the top):

'''Abstract:'''
* There are some spelling errors in the abstract, e.g. Acronym and Areas are not spelled with a capital letter.
* The purpose of the SWOT matrix is very vague described: "to get the data, and get some ideas". I believe you could elaborate on what the purpose is. What data do the company get? You could also divide the purpose into two: What is the purpose for identifying strengths and weaknesses? What is the purpose of identifying opportunities and threats? Please consider these questions and add a bit more to the purpose description.

'''Introduction chapter:'''
* First of all, please fix the picture so it fits the text, right now there are letters flying around which is confusing.
* In the first paragraph, you could add a bit more information about when, or in which situations, a SWOT matrix is beneficial to use.
* "''You don't have to necessarily work for a particular company, to obviously conduct a SWOT analysis but there are a lot of different benefits''". Maybe you could add a few concrete examples of benefits a company or project could have in using the SWOT matrix.

'''Strength, Weakness, Opportunities and Threats chapters:'''
* It is really nice with examples, but I think 1 or 2 examples for each chapter is sufficient. If you disagree, then please make sure to provide the same amount of examples for all chapters in order for the chapter to be coherent.
* You could add a bit more describing text in the introduction of each of the chapters. An idea could be, to write some guidelines on how a company could find its own s/w/o/t's - write down the questions a company would have to ask themselves in order to identify s/w/o/t's.

'''Type of factors:'''
* I find this chapter unnecessary. You could use the content of this chapter in the general introduction chapter instead. In case you want to keep it I would suggest to add more descriptions to each of the subchapters, right now it looks very unfinished when there is only one line pr. sub chapter.

'''How does the SWOT analysis work and goal statement:'''
* Unfinished chapters (as of November 26th 16:00) and therefore not reviewed.
* I would however suggest, that instead of making a list of ideas, then make an description of an example where the SWOT analysis has been applied. Otherwise you should rename the chapter to something other than "how does the SWOT analysis work"

'''Summary:'''
* Please revise this chapter after you're done with all the chapters. Right now it is very hard to understand, and doesn't fit as a nice ending of the article. E.g. this sentence is hard to understand: "''There need to be done some good analysis, if you’re doing a cursory review of some of these different categories are not going to find the truly valuable things''"

Good luck!

Agile Project Management

2014-11-24T13:00:20Z

Username111: /* Application and Implementation */

[[Category:Agile]] [[Category:Project Management]] [[Category:Agile Project Management]] [[Category: Complexity]] [[Category: Uncertainty]]

= 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 [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 undescribed, 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 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. [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 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 [7]. 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 [8].

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

[[File:APM.jpg|400px|right|thumb| APM model based on [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, 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 [8]. 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 [10].

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

= References =
[1] Project Management Journal. ''Agile Project Management: Essentials from the Project Management Journal.'' Jossey-Bass, 2013.

[2] Fowler, Highsmith et. al. ''The Agile Manifesto''. Software Development, 9(8):28– 35, 2001.

[3] K. Schwaber et. al. ''Twelve principles of agile software'', February 2001. Retrieved from http://agilemanifesto.org/principles.html

[4] J. Highsmith. ''Agile Project Management: Creating Innovative Products''. Agile Software Development Series. Pearson Education, 2009.

[5] D. Anderson et. al. ''Declaration of interdependence'', February 2005. Retrieved from http://pmdoi.org/

[6] E. C. Conforto et. al. ''Can agile project management be adopted by industries other than software development?'' Project Management Journal, 45(3):21–34, 2014.

[7] C. G. Cobb. ''Making Sense of Agile Project Management: Balancing Control and Agility''. John Wiley and Sons, 2011.

[8] S. Chandramouli and S. Dutt. ''PMI: Agile Certified Practitioner''. Pearson Education India, 2012.

[9] P. Dinsmore and J. Cabanis-Brewin. ''The AMA handbook of project management''. AMACOM Div American Management Association, 2006.

[10] ESI International. ''Successful solutions through Agile Project Management''. ESI International White Paper, 1(1):1–16, 2014.

Agile Project Management

2014-11-24T12:58:47Z

Username111: /* APM Model */

[[Category:Agile]] [[Category:Project Management]] [[Category:Agile Project Management]] [[Category: Complexity]] [[Category: Uncertainty]]

= 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 [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 undescribed, 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 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. [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 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 [7]. 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 [8].

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

[[File:APM.jpg|400px|right|thumb| APM model based on [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, 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 [8]. 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 out- puts 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 [10].

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

= References =
[1] Project Management Journal. ''Agile Project Management: Essentials from the Project Management Journal.'' Jossey-Bass, 2013.

[2] Fowler, Highsmith et. al. ''The Agile Manifesto''. Software Development, 9(8):28– 35, 2001.

[3] K. Schwaber et. al. ''Twelve principles of agile software'', February 2001. Retrieved from http://agilemanifesto.org/principles.html

[4] J. Highsmith. ''Agile Project Management: Creating Innovative Products''. Agile Software Development Series. Pearson Education, 2009.

[5] D. Anderson et. al. ''Declaration of interdependence'', February 2005. Retrieved from http://pmdoi.org/

[6] E. C. Conforto et. al. ''Can agile project management be adopted by industries other than software development?'' Project Management Journal, 45(3):21–34, 2014.

[7] C. G. Cobb. ''Making Sense of Agile Project Management: Balancing Control and Agility''. John Wiley and Sons, 2011.

[8] S. Chandramouli and S. Dutt. ''PMI: Agile Certified Practitioner''. Pearson Education India, 2012.

[9] P. Dinsmore and J. Cabanis-Brewin. ''The AMA handbook of project management''. AMACOM Div American Management Association, 2006.

[10] ESI International. ''Successful solutions through Agile Project Management''. ESI International White Paper, 1(1):1–16, 2014.

Agile Project Management

2014-11-24T12:53:33Z

Username111: /* APM Principles */

[[Category:Agile]] [[Category:Project Management]] [[Category:Agile Project Management]] [[Category: Complexity]] [[Category: Uncertainty]]

= 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 [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 undescribed, 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 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. [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 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 [7]. 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 [8].

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

[[File:APM.jpg|400px|right|thumb| APM model based on [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, 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 [8]. 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 out- puts 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 [10].

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

= References =
[1] Project Management Journal. ''Agile Project Management: Essentials from the Project Management Journal.'' Jossey-Bass, 2013.

[2] Fowler, Highsmith et. al. ''The Agile Manifesto''. Software Development, 9(8):28– 35, 2001.

[3] K. Schwaber et. al. ''Twelve principles of agile software'', February 2001. Retrieved from http://agilemanifesto.org/principles.html

[4] J. Highsmith. ''Agile Project Management: Creating Innovative Products''. Agile Software Development Series. Pearson Education, 2009.

[5] D. Anderson et. al. ''Declaration of interdependence'', February 2005. Retrieved from http://pmdoi.org/

[6] E. C. Conforto et. al. ''Can agile project management be adopted by industries other than software development?'' Project Management Journal, 45(3):21–34, 2014.

[7] C. G. Cobb. ''Making Sense of Agile Project Management: Balancing Control and Agility''. John Wiley and Sons, 2011.

[8] S. Chandramouli and S. Dutt. ''PMI: Agile Certified Practitioner''. Pearson Education India, 2012.

[9] P. Dinsmore and J. Cabanis-Brewin. ''The AMA handbook of project management''. AMACOM Div American Management Association, 2006.

[10] ESI International. ''Successful solutions through Agile Project Management''. ESI International White Paper, 1(1):1–16, 2014.

Agile Project Management

2014-11-24T12:53:06Z

Username111: /* APM Principles */

[[Category:Agile]] [[Category:Project Management]] [[Category:Agile Project Management]] [[Category: Complexity]] [[Category: Uncertainty]]

= 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 [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 undescribed, 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 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. [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 to be 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 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 [7]. 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 [8].

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

[[File:APM.jpg|400px|right|thumb| APM model based on [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, 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 [8]. 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 out- puts 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 [10].

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

= References =
[1] Project Management Journal. ''Agile Project Management: Essentials from the Project Management Journal.'' Jossey-Bass, 2013.

[2] Fowler, Highsmith et. al. ''The Agile Manifesto''. Software Development, 9(8):28– 35, 2001.

[3] K. Schwaber et. al. ''Twelve principles of agile software'', February 2001. Retrieved from http://agilemanifesto.org/principles.html

[4] J. Highsmith. ''Agile Project Management: Creating Innovative Products''. Agile Software Development Series. Pearson Education, 2009.

[5] D. Anderson et. al. ''Declaration of interdependence'', February 2005. Retrieved from http://pmdoi.org/

[6] E. C. Conforto et. al. ''Can agile project management be adopted by industries other than software development?'' Project Management Journal, 45(3):21–34, 2014.

[7] C. G. Cobb. ''Making Sense of Agile Project Management: Balancing Control and Agility''. John Wiley and Sons, 2011.

[8] S. Chandramouli and S. Dutt. ''PMI: Agile Certified Practitioner''. Pearson Education India, 2012.

[9] P. Dinsmore and J. Cabanis-Brewin. ''The AMA handbook of project management''. AMACOM Div American Management Association, 2006.

[10] ESI International. ''Successful solutions through Agile Project Management''. ESI International White Paper, 1(1):1–16, 2014.

Agile Project Management

2014-11-24T12:49:09Z

Username111: /* APM Mindset */

[[Category:Agile]] [[Category:Project Management]] [[Category:Agile Project Management]] [[Category: Complexity]] [[Category: Uncertainty]]

= 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 [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 undescribed, 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 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. [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 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 [7]. 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 [8].

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

[[File:APM.jpg|400px|right|thumb| APM model based on [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, 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 [8]. 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 out- puts 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 [10].

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

= References =
[1] Project Management Journal. ''Agile Project Management: Essentials from the Project Management Journal.'' Jossey-Bass, 2013.

[2] Fowler, Highsmith et. al. ''The Agile Manifesto''. Software Development, 9(8):28– 35, 2001.

[3] K. Schwaber et. al. ''Twelve principles of agile software'', February 2001. Retrieved from http://agilemanifesto.org/principles.html

[4] J. Highsmith. ''Agile Project Management: Creating Innovative Products''. Agile Software Development Series. Pearson Education, 2009.

[5] D. Anderson et. al. ''Declaration of interdependence'', February 2005. Retrieved from http://pmdoi.org/

[6] E. C. Conforto et. al. ''Can agile project management be adopted by industries other than software development?'' Project Management Journal, 45(3):21–34, 2014.

[7] C. G. Cobb. ''Making Sense of Agile Project Management: Balancing Control and Agility''. John Wiley and Sons, 2011.

[8] S. Chandramouli and S. Dutt. ''PMI: Agile Certified Practitioner''. Pearson Education India, 2012.

[9] P. Dinsmore and J. Cabanis-Brewin. ''The AMA handbook of project management''. AMACOM Div American Management Association, 2006.

[10] ESI International. ''Successful solutions through Agile Project Management''. ESI International White Paper, 1(1):1–16, 2014.

Agile Project Management

2014-11-24T12:46:48Z

Username111: /* Introduction */

[[Category:Agile]] [[Category:Project Management]] [[Category:Agile Project Management]] [[Category: Complexity]] [[Category: Uncertainty]]

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

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

[[File:APM.jpg|400px|right|thumb| APM model based on [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, 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 [8]. 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 out- puts 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 [10].

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

= References =
[1] Project Management Journal. ''Agile Project Management: Essentials from the Project Management Journal.'' Jossey-Bass, 2013.

[2] Fowler, Highsmith et. al. ''The Agile Manifesto''. Software Development, 9(8):28– 35, 2001.

[3] K. Schwaber et. al. ''Twelve principles of agile software'', February 2001. Retrieved from http://agilemanifesto.org/principles.html

[4] J. Highsmith. ''Agile Project Management: Creating Innovative Products''. Agile Software Development Series. Pearson Education, 2009.

[5] D. Anderson et. al. ''Declaration of interdependence'', February 2005. Retrieved from http://pmdoi.org/

[6] E. C. Conforto et. al. ''Can agile project management be adopted by industries other than software development?'' Project Management Journal, 45(3):21–34, 2014.

[7] C. G. Cobb. ''Making Sense of Agile Project Management: Balancing Control and Agility''. John Wiley and Sons, 2011.

[8] S. Chandramouli and S. Dutt. ''PMI: Agile Certified Practitioner''. Pearson Education India, 2012.

[9] P. Dinsmore and J. Cabanis-Brewin. ''The AMA handbook of project management''. AMACOM Div American Management Association, 2006.

[10] ESI International. ''Successful solutions through Agile Project Management''. ESI International White Paper, 1(1):1–16, 2014.

Agile Project Management

2014-11-24T12:44:42Z

Username111: /* Introduction */

[[Category:Agile]] [[Category:Project Management]] [[Category:Agile Project Management]] [[Category: Complexity]] [[Category: Uncertainty]]

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

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

[[File:APM.jpg|400px|right|thumb| APM model based on [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, 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 [8]. 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 out- puts 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 [10].

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

= References =
[1] Project Management Journal. ''Agile Project Management: Essentials from the Project Management Journal.'' Jossey-Bass, 2013.

[2] Fowler, Highsmith et. al. ''The Agile Manifesto''. Software Development, 9(8):28– 35, 2001.

[3] K. Schwaber et. al. ''Twelve principles of agile software'', February 2001. Retrieved from http://agilemanifesto.org/principles.html

[4] J. Highsmith. ''Agile Project Management: Creating Innovative Products''. Agile Software Development Series. Pearson Education, 2009.

[5] D. Anderson et. al. ''Declaration of interdependence'', February 2005. Retrieved from http://pmdoi.org/

[6] E. C. Conforto et. al. ''Can agile project management be adopted by industries other than software development?'' Project Management Journal, 45(3):21–34, 2014.

[7] C. G. Cobb. ''Making Sense of Agile Project Management: Balancing Control and Agility''. John Wiley and Sons, 2011.

[8] S. Chandramouli and S. Dutt. ''PMI: Agile Certified Practitioner''. Pearson Education India, 2012.

[9] P. Dinsmore and J. Cabanis-Brewin. ''The AMA handbook of project management''. AMACOM Div American Management Association, 2006.

[10] ESI International. ''Successful solutions through Agile Project Management''. ESI International White Paper, 1(1):1–16, 2014.

Agile Project Management

2014-11-24T12:43:23Z

Username111: /* Introduction */

[[Category:Agile]] [[Category:Project Management]] [[Category:Agile Project Management]] [[Category: Complexity]] [[Category: Uncertainty]]

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

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

[[File:APM.jpg|400px|right|thumb| APM model based on [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, 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 [8]. 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 out- puts 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 [10].

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

= References =
[1] Project Management Journal. ''Agile Project Management: Essentials from the Project Management Journal.'' Jossey-Bass, 2013.

[2] Fowler, Highsmith et. al. ''The Agile Manifesto''. Software Development, 9(8):28– 35, 2001.

[3] K. Schwaber et. al. ''Twelve principles of agile software'', February 2001. Retrieved from http://agilemanifesto.org/principles.html

[4] J. Highsmith. ''Agile Project Management: Creating Innovative Products''. Agile Software Development Series. Pearson Education, 2009.

[5] D. Anderson et. al. ''Declaration of interdependence'', February 2005. Retrieved from http://pmdoi.org/

[6] E. C. Conforto et. al. ''Can agile project management be adopted by industries other than software development?'' Project Management Journal, 45(3):21–34, 2014.

[7] C. G. Cobb. ''Making Sense of Agile Project Management: Balancing Control and Agility''. John Wiley and Sons, 2011.

[8] S. Chandramouli and S. Dutt. ''PMI: Agile Certified Practitioner''. Pearson Education India, 2012.

[9] P. Dinsmore and J. Cabanis-Brewin. ''The AMA handbook of project management''. AMACOM Div American Management Association, 2006.

[10] ESI International. ''Successful solutions through Agile Project Management''. ESI International White Paper, 1(1):1–16, 2014.

Agile Project Management

2014-11-21T14:59:26Z

Username111: /* References */

[[Category:Agile]] [[Category:Project Management]] [[Category:Agile Project Management]] [[Category: Complexity]] [[Category: Uncertainty]]

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

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

[[File:APM.jpg|400px|right|thumb| APM model based on [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, 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 [8]. 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 out- puts 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 [10].

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

= References =
[1] Project Management Journal. ''Agile Project Management: Essentials from the Project Management Journal.'' Jossey-Bass, 2013.

[2] Fowler, Highsmith et. al. ''The Agile Manifesto''. Software Development, 9(8):28– 35, 2001.

[3] K. Schwaber et. al. ''Twelve principles of agile software'', February 2001. Retrieved from http://agilemanifesto.org/principles.html

[4] J. Highsmith. ''Agile Project Management: Creating Innovative Products''. Agile Software Development Series. Pearson Education, 2009.

[5] D. Anderson et. al. ''Declaration of interdependence'', February 2005. Retrieved from http://pmdoi.org/

[6] E. C. Conforto et. al. ''Can agile project management be adopted by industries other than software development?'' Project Management Journal, 45(3):21–34, 2014.

[7] C. G. Cobb. ''Making Sense of Agile Project Management: Balancing Control and Agility''. John Wiley and Sons, 2011.

[8] S. Chandramouli and S. Dutt. ''PMI: Agile Certified Practitioner''. Pearson Education India, 2012.

[9] P. Dinsmore and J. Cabanis-Brewin. ''The AMA handbook of project management''. AMACOM Div American Management Association, 2006.

[10] ESI International. ''Successful solutions through Agile Project Management''. ESI International White Paper, 1(1):1–16, 2014.

Agile Project Management

2014-11-21T14:57:23Z

Username111:

[[Category:Agile]] [[Category:Project Management]] [[Category:Agile Project Management]] [[Category: Complexity]] [[Category: Uncertainty]]

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

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

[[File:APM.jpg|400px|right|thumb| APM model based on [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, 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 [8]. 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 out- puts 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 [10].

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

= References =
[1] Project Management Journal. ''Agile Project Management: Essentials from the Project Management Journal.'' Jossey-Bass, 2013.

[2] Fowler, Highsmith et. al. ''The Agile Manifesto''. Software Development, 9(8):28– 35, 2001.

[3] Schwaber et. al. Beck. ''Twelve principles of agile software'', February 2001. Retrieved from http://agilemanifesto.org/principles.html

[4] J. Highsmith. ''Agile Project Management: Creating Innovative Products''. Agile Software Development Series. Pearson Education, 2009.

[5] Anderson et. al. ''Declaration of interdependence'', February 2005. Retrieved from http://pmdoi.org/

[6] Edivandro C. Conforto et. al. ''Can agile project management be adopted by industries other than software development?'' Project Management Journal, 45(3):21–34, 2014.

[7] C. G. Cobb. ''Making Sense of Agile Project Management: Balancing Control and Agility''. John Wiley and Sons, 2011.

[8] Subramanian Chandramouli and Saikat Dutt. ''PMI: Agile Certified Practitioner''. Pearson Education India, 2012.

[9] Paul C Dinsmore and Jeannette Cabanis-Brewin. ''The AMA handbook of project management''. AMACOM Div American Mgmt Assn, 2006.

[10] ESI International. ''Successful solutions through Agile Project Management''. ESI International White Paper, 1(1):1–16, 2014.

Agile Project Management

2014-11-21T14:55:58Z

Username111:

[[Category:Agile]] [[Category:Project Management]] [[Category: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 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. [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 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 [7]. 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 [8].

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

[[File:APM.jpg|400px|right|thumb| APM model based on [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, 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 [8]. 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 out- puts 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 [10].

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

= References =
[1] Project Management Journal. ''Agile Project Management: Essentials from the Project Management Journal.'' Jossey-Bass, 2013.

[2] Fowler, Highsmith et. al. ''The Agile Manifesto''. Software Development, 9(8):28– 35, 2001.

[3] Schwaber et. al. Beck. ''Twelve principles of agile software'', February 2001. Retrieved from http://agilemanifesto.org/principles.html

[4] J. Highsmith. ''Agile Project Management: Creating Innovative Products''. Agile Software Development Series. Pearson Education, 2009.

[5] Anderson et. al. ''Declaration of interdependence'', February 2005. Retrieved from http://pmdoi.org/

[6] Edivandro C. Conforto et. al. ''Can agile project management be adopted by industries other than software development?'' Project Management Journal, 45(3):21–34, 2014.

[7] C. G. Cobb. ''Making Sense of Agile Project Management: Balancing Control and Agility''. John Wiley and Sons, 2011.

[8] Subramanian Chandramouli and Saikat Dutt. ''PMI: Agile Certified Practitioner''. Pearson Education India, 2012.

[9] Paul C Dinsmore and Jeannette Cabanis-Brewin. ''The AMA handbook of project management''. AMACOM Div American Mgmt Assn, 2006.

[10] ESI International. ''Successful solutions through Agile Project Management''. ESI International White Paper, 1(1):1–16, 2014.

Agile Project Management

2014-11-21T14:53:51Z

Username111: /* Application and Implementation */

[[Category:Agile]] [[Category: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 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. [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 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 [7]. 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 [8].

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

[[File:APM.jpg|400px|right|thumb| APM model based on [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, 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 [8]. 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 out- puts 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 [10].

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

= References =
[1] Project Management Journal. ''Agile Project Management: Essentials from the Project Management Journal.'' Jossey-Bass, 2013.

[2] Fowler, Highsmith et. al. ''The Agile Manifesto''. Software Development, 9(8):28– 35, 2001.

[3] Schwaber et. al. Beck. ''Twelve principles of agile software'', February 2001. Retrieved from http://agilemanifesto.org/principles.html

[4] J. Highsmith. ''Agile Project Management: Creating Innovative Products''. Agile Software Development Series. Pearson Education, 2009.

[5] Anderson et. al. ''Declaration of interdependence'', February 2005. Retrieved from http://pmdoi.org/

[6] Edivandro C. Conforto et. al. ''Can agile project management be adopted by industries other than software development?'' Project Management Journal, 45(3):21–34, 2014.

[7] C. G. Cobb. ''Making Sense of Agile Project Management: Balancing Control and Agility''. John Wiley and Sons, 2011.

[8] Subramanian Chandramouli and Saikat Dutt. ''PMI: Agile Certified Practitioner''. Pearson Education India, 2012.

[9] Paul C Dinsmore and Jeannette Cabanis-Brewin. ''The AMA handbook of project management''. AMACOM Div American Mgmt Assn, 2006.

[10] ESI International. ''Successful solutions through Agile Project Management''. ESI International White Paper, 1(1):1–16, 2014.

Agile Project Management

2014-11-21T14:52:56Z

Username111: /* APM Model */

[[Category:Agile]] [[Category: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 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. [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 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 [7]. 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 [8].

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

[[File:APM.jpg|400px|right|thumb| APM model based on [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, 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 [8]. 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 out- puts 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 need to be familiar with the APM framework. Then they need to develop short- and longterm 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 [10].

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

= References =
[1] Project Management Journal. ''Agile Project Management: Essentials from the Project Management Journal.'' Jossey-Bass, 2013.

[2] Fowler, Highsmith et. al. ''The Agile Manifesto''. Software Development, 9(8):28– 35, 2001.

[3] Schwaber et. al. Beck. ''Twelve principles of agile software'', February 2001. Retrieved from http://agilemanifesto.org/principles.html

[4] J. Highsmith. ''Agile Project Management: Creating Innovative Products''. Agile Software Development Series. Pearson Education, 2009.

[5] Anderson et. al. ''Declaration of interdependence'', February 2005. Retrieved from http://pmdoi.org/

[6] Edivandro C. Conforto et. al. ''Can agile project management be adopted by industries other than software development?'' Project Management Journal, 45(3):21–34, 2014.

[7] C. G. Cobb. ''Making Sense of Agile Project Management: Balancing Control and Agility''. John Wiley and Sons, 2011.

[8] Subramanian Chandramouli and Saikat Dutt. ''PMI: Agile Certified Practitioner''. Pearson Education India, 2012.

[9] Paul C Dinsmore and Jeannette Cabanis-Brewin. ''The AMA handbook of project management''. AMACOM Div American Mgmt Assn, 2006.

[10] ESI International. ''Successful solutions through Agile Project Management''. ESI International White Paper, 1(1):1–16, 2014.

Agile Project Management

2014-11-21T14:51:03Z

Username111: /* APM Practices */

[[Category:Agile]] [[Category: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 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. [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 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 [7]. 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 [8].

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

[[File:APM.jpg|400px|right|thumb| APM model based on [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 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 [8]. 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 out- puts 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 need to be familiar with the APM framework. Then they need to develop short- and longterm 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 [10].

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

= References =
[1] Project Management Journal. ''Agile Project Management: Essentials from the Project Management Journal.'' Jossey-Bass, 2013.

[2] Fowler, Highsmith et. al. ''The Agile Manifesto''. Software Development, 9(8):28– 35, 2001.

[3] Schwaber et. al. Beck. ''Twelve principles of agile software'', February 2001. Retrieved from http://agilemanifesto.org/principles.html

[4] J. Highsmith. ''Agile Project Management: Creating Innovative Products''. Agile Software Development Series. Pearson Education, 2009.

[5] Anderson et. al. ''Declaration of interdependence'', February 2005. Retrieved from http://pmdoi.org/

[6] Edivandro C. Conforto et. al. ''Can agile project management be adopted by industries other than software development?'' Project Management Journal, 45(3):21–34, 2014.

[7] C. G. Cobb. ''Making Sense of Agile Project Management: Balancing Control and Agility''. John Wiley and Sons, 2011.

[8] Subramanian Chandramouli and Saikat Dutt. ''PMI: Agile Certified Practitioner''. Pearson Education India, 2012.

[9] Paul C Dinsmore and Jeannette Cabanis-Brewin. ''The AMA handbook of project management''. AMACOM Div American Mgmt Assn, 2006.

[10] ESI International. ''Successful solutions through Agile Project Management''. ESI International White Paper, 1(1):1–16, 2014.

Agile Project Management

2014-11-21T14:43:04Z

Username111: /* References */

[[Category:Agile]] [[Category: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].

[[File:APM.jpg|400px|right|thumb| APM model based on [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 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 [8]. 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 out- puts 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 need to be familiar with the APM framework. Then they need to develop short- and longterm 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 [10].

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

= References =
[1] Project Management Journal. ''Agile Project Management: Essentials from the Project Management Journal.'' Jossey-Bass, 2013.

[2] Fowler, Highsmith et. al. ''The Agile Manifesto''. Software Development, 9(8):28– 35, 2001.

[3] Schwaber et. al. Beck. ''Twelve principles of agile software'', February 2001. Retrieved from http://agilemanifesto.org/principles.html

[4] J. Highsmith. ''Agile Project Management: Creating Innovative Products''. Agile Software Development Series. Pearson Education, 2009.

[5] Anderson et. al. ''Declaration of interdependence'', February 2005. Retrieved from http://pmdoi.org/

[6] Edivandro C. Conforto et. al. ''Can agile project management be adopted by industries other than software development?'' Project Management Journal, 45(3):21–34, 2014.

[7] C. G. Cobb. ''Making Sense of Agile Project Management: Balancing Control and Agility''. John Wiley and Sons, 2011.

[8] Subramanian Chandramouli and Saikat Dutt. ''PMI: Agile Certified Practitioner''. Pearson Education India, 2012.

[9] Paul C Dinsmore and Jeannette Cabanis-Brewin. ''The AMA handbook of project management''. AMACOM Div American Mgmt Assn, 2006.

[10] ESI International. ''Successful solutions through Agile Project Management''. ESI International White Paper, 1(1):1–16, 2014.

Agile Project Management

2014-11-21T14:41:45Z

Username111: /* References */

[[Category:Agile]] [[Category: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].

[[File:APM.jpg|400px|right|thumb| APM model based on [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 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 [8]. 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 out- puts 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 need to be familiar with the APM framework. Then they need to develop short- and longterm 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 [10].

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

= References =
[1] Project Management Journal. Agile Project Management: Essentials from the Project Management Journal. Jossey-Bass, 2013.

[2] Fowler, Highsmith et. al. The Agile Manifesto. Software Development, 9(8):28– 35, 2001.

[3] Schwaber et. al. Beck. Twelve principles of agile software, February 2001. Retrieved from http://agilemanifesto.org/principles.html

[4] J. Highsmith. Agile Project Management: Creating Innovative Products. Agile Software Development Series. Pearson Education, 2009.

[5] Anderson et. al. Declaration of interdependence, February 2005. Retrieved from http://pmdoi.org/

[6] Edivandro C. Conforto et. al. Can agile project management be adopted by industries other than software development? Project Management Journal, 45(3):21–34, 2014.

[7] C. G. Cobb. Making Sense of Agile Project Management: Balancing Control and Agility. John Wiley and Sons, 2011.

[8] Subramanian Chandramouli and Saikat Dutt. PMI: Agile Certified Practitioner. Pearson Education India, 2012.

[9] Paul C Dinsmore and Jeannette Cabanis-Brewin. The AMA handbook of project management. AMACOM Div American Mgmt Assn, 2006.

[10] ESI International. Successful solutions through Agile Project Management. ESI International White Paper, 1(1):1–16, 2014.

Agile Project Management

2014-11-21T14:33:30Z

Username111:

[[Category:Agile]] [[Category: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].

[[File:APM.jpg|400px|right|thumb| APM model based on [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 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 [8]. 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 out- puts 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 need to be familiar with the APM framework. Then they need to develop short- and longterm 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 [10].

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

= References =
[1] Project Management Journal. Agile Project Management: Essentials from the Project Management Journal. Jossey-Bass, 2013.

[2] Martin Fowler and Jim Highsmith. The agile manifesto. Software Development, 9(8):28– 35, 2001.

[3] Schwaber et. al. Beck. Twelve principles of agile software, February 2001.

[4] J. Highsmith. Agile Project Management: Creating Innovative Products. Agile Software Development Series. Pearson Education, 2009.

[5] Anderson et. al. Declaration of interdependence, February 2005.

[6] Edivandro C. Conforto et. al. Can agile project management be adopted by industries other than software development? Project Management Journal, 45(3):21–34, 2014.

[7] C. G. Cobb. Making Sense of Agile Project Management: Balancing Control and Agility. John Wiley and Sons, 2011.

[8] Subramanian Chandramouli and Saikat Dutt. PMI: Agile Certified Practitioner. Pearson Education India, 2012.

[9] Paul C Dinsmore and Jeannette Cabanis-Brewin. The AMA handbook of project management. AMACOM Div American Mgmt Assn, 2006.

[10] ESI International. Successfull solution through agile project management. ESI International White Paper, 1(1):1–16, 2014.

File:APM.jpg

2014-11-21T14:13:04Z

Username111:

Agile Project Management

2014-11-21T14:12:16Z

Username111:

[[Category:Agile]] [[Category: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.

Agile Project Management

2014-11-14T20:41:30Z

Username111: Created page with "Category:Agile Category:Project Management = Abstract = Agile methodologies have been increasingly popular since the introduction of the Agile Manifesto in 2001. In..."

[[Category:Agile]] [[Category:Project Management]]

= Abstract =
Agile methodologies have been increasingly popular since the introduction of the Agile Manifesto in 2001. In general, the methodologies provide a set of different principles and practices for software development projects, which aims at satisfying the customer through iterative development [1]. The agile methodologies for software development are very well described in literature, but not all authors agree on the specific content of the different methodologies. This can cause a lot of confusing for any new project manager wanting to adopt the benefits of an agile approach to a project. The focus in this paper is on Agile Project Management in general, and does not describe a single specific agile methodology. This paper seeks to provide a comprehensive description of Agile Project Management, along with an application example and implementation advice. This will be done through an in-depth literature study of the state-of-the-art within this area. The aim is to provide detailed and easy to understand instructions for using the method. The goal is, that this paper can be used as a guideline for any project manager wanting to adopt an agile approach to the project management.

= Introduction =
Brief introduction to The Agile Manifest and to agile in general. Description of the basic agile principles, and introduction to the history of Agile Project Management. Introduction to the typical application context and requirements.  

= Detailed method description =
Detailed description of the Agile Project Management principles, practices and roles. Detailed description of the agile framework and terminology. Short description and brief overview of specific agile methodologies.

= 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.