Agile Project Management - Revision history

MadsMohlenberg: /* APM Model */

2021-02-11T14:18:15Z

APM Model

← Older revision		Revision as of 14:18, 11 February 2021
Line 80:		Line 80:
	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.		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\| Figure 1 - APM model based on <ref name=four/>]]		[[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.		'''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.

MadsMohlenberg: /* APM Model */

2021-02-11T14:17:53Z

APM Model

← Older revision		Revision as of 14:17, 11 February 2021
Line 80:		Line 80:
	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.		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/>]]		[[File:APM.jpg\|400px\|right\| 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.		'''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.

Tkokotas at 11:26, 20 December 2018

2018-12-20T11:26:15Z

← Older revision		Revision as of 11:26, 20 December 2018
Line 1:		Line 1:
	~~[[Category:Agile Project Management]] [[Category:Project Management]] [[Category:Agile Project Management]] [[Category: Complexity]] [[Category: Uncertainty]]~~		''Developed by Michael Ølund''


	= Introduction =		= Introduction =
Line 102:		Line 103:
	= References =		= References =
	<references />		<references />



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

Tkokotas at 16:34, 23 October 2018

2018-10-23T16:34:52Z

← Older revision		Revision as of 16:34, 23 October 2018
Line 1:		Line 1:
	[[Category:Agile]] [[Category:Project Management]] [[Category:Agile Project Management]] [[Category: Complexity]] [[Category: Uncertainty]]		[[Category:Agile Project Management]] [[Category:Project Management]] [[Category:Agile Project Management]] [[Category: Complexity]] [[Category: Uncertainty]]

	= Introduction =		= Introduction =

Username111: /* Techniques */

2014-11-27T11:47:50Z

Techniques

← Older revision		Revision as of 11:47, 27 November 2014
Line 72:		Line 72:
	It will be the project manager's responsibility to help out removing the barriers or obstacles which are hindering the team members work.		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.		'''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.		'''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.

Username111: /* Techniques */

2014-11-27T11:46:35Z

Techniques

← Older revision		Revision as of 11:46, 27 November 2014
Line 62:		Line 62:

	=== Techniques ===		=== 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/>.		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:		'''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:

Username111: /* APM Principles */

2014-11-27T11:45:34Z

APM Principles

← Older revision		Revision as of 11:45, 27 November 2014
Line 47:		Line 47:

	=== APM Principles ===		=== 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>		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.		'''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.

Username111: /* APM Principles */

2014-11-27T11:45:00Z

APM Principles

← Older revision		Revision as of 11:45, 27 November 2014
Line 47:		Line 47:

	=== APM Principles ===		=== 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:~~		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.		'''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.

Username111: /* APM Mindset */

2014-11-27T11:43:06Z

APM Mindset

← Older revision		Revision as of 11:43, 27 November 2014
Line 41:		Line 41:
	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.		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.		'''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 ==		== APM Practices ==

Username111: /* Introduction */

2014-11-27T11:41:58Z

Introduction

← Older revision		Revision as of 11:41, 27 November 2014
Line 2:		Line 2:

	= Introduction =		= 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>.		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:		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.		* Individuals and interactions over processes and tools.
Line 11:		Line 11:
	* Responding to change over following a plan.”<ref> Fowler, Highsmith et. al. ''The Agile Manifesto''. Software Development, 9(8):28– 35, 2001. </ref>		* 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>.		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 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>.
Line 19:		Line 19:
	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/>.		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:		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)		* Delivering value over meeting constraints (Value over Constraints)