Agile project management

From apppm
(Difference between revisions)
Jump to: navigation, search
(XP)
 
(42 intermediate revisions by one user not shown)
Line 1: Line 1:
 +
''Developed by Hoda Vazirinasab''
 +
 +
 
==Abstract==
 
==Abstract==
” Agility means the ability to balance between flexibility and stability.
+
'''''” Agility means the ability to balance between flexibility and stability.'''''
 
The 21st Century's market and business environment is more turbulent, unstable and full of tension than any other time and in view of investors unpredictable and dangerous.
 
The 21st Century's market and business environment is more turbulent, unstable and full of tension than any other time and in view of investors unpredictable and dangerous.
 
In this new century, the emergence and development of technological ideas and designs in the form of commercial products will not give you enough time to manage affairs and projects in a traditional way and you need to be more agile, in order to ensure the growth, development, continuation and survival of your business in competition with leading companies in various industries.
 
In this new century, the emergence and development of technological ideas and designs in the form of commercial products will not give you enough time to manage affairs and projects in a traditional way and you need to be more agile, in order to ensure the growth, development, continuation and survival of your business in competition with leading companies in various industries.
Line 6: Line 9:
 
Increasing pressures and stress caused, the speed of production of other companies, development and transfer of information, as well as increasing participation of customers and their more emphasis on various aspects of project outputs, have led project managers and custodians to seek more agile and aggressive approaches to project management.
 
Increasing pressures and stress caused, the speed of production of other companies, development and transfer of information, as well as increasing participation of customers and their more emphasis on various aspects of project outputs, have led project managers and custodians to seek more agile and aggressive approaches to project management.
 
So that, in addition to obtaining customer’s satisfaction and other project stakeholders, they can make proper decisions and take actions as soon as possible .
 
So that, in addition to obtaining customer’s satisfaction and other project stakeholders, they can make proper decisions and take actions as soon as possible .
These developments have been so wide spread and universal in the last two decades that agile management has completely replaced traditional and waterfall approaches in managing many projects in industries and especially in Hi-Tech industries.
+
These developments have been so wide spread and universal in the last two decades that agile management has completely replaced traditional and waterfall approaches in managing many projects in industries and especially in Hi-Tech industries.<ref name="agile"/>
  
Agile is a way to manage projects which can be used for virtually anything, but it was founded in software development.
 
Agile breaks down larger projects into small, manageable chunks called iterations. At the end of each iteration (which generally takes place over a consistent time interval) something of value is produced. The product produced during each iteration should be able to be put into the world to gain feedback from users or stakeholders. agile has designers, developers and business people working together simultaneously.
 
<ref>Emerson Taymor. Agile Handbook. [ONLINE] Available at: "http://agilehandbook.com/agile-handbook.pdf"</ref>.
 
 
==Big idea==
 
==Big idea==
Agile project management, was first discussed in depth in the 1970s by Software developers is a style of project management that focuses on
+
''I want to start my discussion with an '''example''' to make it much clear.:''
early delivery of business value, continuous improvement of the project’s
+
product and processes, scope flexibility, team input, and delivering well tested
+
products that reflect customer needs.
+
Although agile approaches have roots in software development, you can use them for other types of products.
+
In February 2001, a group of 17 software and project experts got together to discuss about their experiences, ideas and to suggest ways to improve the world of software development.
+
This group created the Agile Manifesto which is an expression of core
+
development values and 12 Principles behind it which
+
help support the values in the Agile Manifesto and support agile project
+
teams in implementing agile techniques and staying on track.<ref name="APM" > Mark C. Layton and
+
Steven J Ostermiller | 2017 | "Agile Project Management For Dummies®, 2nd Edition"</ref>
+
  
The text of the original 12 principles by the Agile Alliance is:
+
Let’s say, you are working in a company and you have your own piece of software for your business as usual and you are earning money using it.
 +
There is a business section in your company as sales, marketing and IT department that adds new feature to the existing software and maybe creates new pieces of software or maintaining and something like that.
 +
One day, one of the staff  from the business section comes to you and says that they need something new. They want to start a new project to create for example a mobile application to increase sales in a way.
 +
First you do not know exactly what they want and how you would proceed with it. What would you do?
 +
The commonest way for the technical and management staff is to start a conversation with the business people, to ask them questions about what they have in mind, the needs and something like that. We keep doing that until we have a complete understanding of their expectations and when we are sure that we know their expectations, then we consider a product that can meet those expectations. Now we have the product and we create a plan that can help us create that product. Then we start the project and throughout the project, our goal is to follow the plan. Because that is probably, the best way we can realize that product.
 +
You usually have some deviations that it is completely normal and is ok. you have to have a monitoring and controlling system to understand the deviations and remove them and get back on track.
 +
After a while you get to the end and create a product as it was planned and designed  upfront. You will show it to the business people. in certain cases, in some projects, when you do that, you realize the expectations for something else that you could not understand the expectations before.
  
# Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
+
It does not happen in every project. When you want to construct a building or when you want to build a bridge, you can understand the expectation from the beginning and then plan everything and create the product and everyone will be happy. But in some projects, such as IT development, it does not usually happen. Cases are different. As it is very common, how can we prevent it from happening? how can we solve this problem?.
# Welcome changing requirements, even late in development Agile processes harness change for the customer’s competitive advantage.
+
At the beginning of the project, you don’t know enough about the expectations of the customer. But instead of trying to make it precise in the beginning, you just go on with the project. In a short period of time you think about different ways of approaching the project and you pick one that seems to be the best, the one that you believe will bring those closest to the expectations as you know them. So, you run the project for a couple of weeks, create a small piece of product and show it to the customer. The fact is that you realize that maybe the only thing that is in common between technical people and business people is the product and that is the only way you can really understand each other. In this approach you will have multiple products during the project. So,you spend a few weeks and you create a very small piece of product. you show what you have worked on to the customer or the business side and receive their feedback. Using that feedback and new understanding you have from the way the business works within a small piece of product ,you have better understanding of the expectations. So you can take the next step, using the new understanding you will think about different alternatives, pick one that seems to be the best , create the second version of the product, show it to the customer again, receive more feedback and you go on like this,until you realize all the expectations. this approach is called adaptive,because you go on and let the environment help you adapt yourself and find your way through the project. So one common problem is that people think in adaptive approaches you just go on with the project and you don’t care about planning or designing or anything else. no, that is not the case.
# Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
+
There is a special approach that helps you use the environment to find your way. So, this approach is what we call '''''agile'''''.
#Business people and developers must work together daily throughout the Project.
+
#Build projects around motivated individuals Give them the environment and support they need, and trust them to get the job done.
+
#The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
+
#Working software is the primary measure of progress.
+
#Agile processes promote sustainable development The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
+
#Continuous attention to technical excellence and good design enhances agility.
+
#Simplicity — the art of maximizing the amount of work not done — is essential.
+
#The best architectures, requirements, and designs emerge from self-organizing Teams.
+
#At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.<ref> Mark C. Layton and
+
Steven J Ostermiller | 2017 | "Agile Project Management For Dummies®, 2nd Edition" page 26-27</ref>
+
  
 +
'''''Agile project management''''', was first discussed in depth in the 1970s by software developers, is a style of project management that focuses on early delivery of business value, continuous improvement of the project’s product and processes, scope flexibility, team input, and delivering well tested products that reflect customer needs.
 +
Although agile approaches have roots in software development, you can use them for other types of products.
 +
In February 2001, a group of 17 software and project experts got together to discuss about their experiences, ideas and to suggest ways to improve the world of '''''software development'''''.
 +
This group created the '''''Agile Manifesto''''' which is an expression of core development values and '''''12 Principles''''' behind it which
 +
help support the values in the '''''Agile Manifesto''''' and support agile project teams in implementing agile techniques and staying on track.
 +
According to these'''''12 principles''''', agile methods focus on '''''customer satisfaction''''', '''''quality in every product''''', '''''teamwork''''' and '''''project management'''''<ref name="agile"/>
  
Therefore according to these 12 principles, agile methods focus on customer satisfaction, quality in every product, teamwork and project management.<ref name="APM" > Mark C. Layton and
+
'''''In a comparison, we can see the differences between Agile Project Management and Historical Project Management :'''''
Steven J Ostermiller | 2017 | "Agile Project Management For Dummies®, 2nd Edition"</ref>
+
# In '''''agile project management''''' we need to create a '''''product backlog''''' in terms of priority and importance, quickly update the product backlog as requirements and priorities change, whereas in '''''Historical Project Management''''' we must create a complete list of project requirement document at the beginning of the project and all changes must be controlled.
===Comparing historical project management with APM===  
+
# In '''''agile project management''''' the '''''development team''''' convene quickly, at the start of each day, for no longer than 15 minutes, to coordinate and synchronize that day’s work and any obstacles, whereas in '''''Historical Project Management''''' weekly status meetings, conduct with all project stakeholders and developers. After each meeting, they send out detailed meeting notes and status reports.
 +
# In '''''Historical Project Management''''', at the beginning of the project a detailed project schedule with all tasks should be created and the '''''project manager''''' tries to keep the project tasks on  schedule and updates the schedule on a regular basis, whereas in '''''agile project management''''', specific tasks identify for the active sprint.
 +
# In '''''agile project management''''', the '''''development team''''' should be supported by helping it remove impediments. In this way, '''''development teams''''' define their own tasks, whereas in '''''Historical Project Management''''', tasks should be assigned to the '''''development team'''''.
 +
# In order to produce products, we have to go through a long way. In this path there is some factors lead us to produce great products. '''''Making Changes''''' is one of the most important and valuable factors to achieve these great products. '''''End-users''''' can be provided by project teams and the market is able to supply relevant, useful products that people need. In '''''agile project management''''', changes are adopted systematically. The '''''flexibility''''' of '''''Agile system''''' is very helpful and can increase project ability because '''''changes''''' in an '''''agile project''''' make it '''''predictable''''' and '''''manageable'''''. By contrast, Unfortunately, in '''''Historical Project Management''''' methods change the way they manage procedures and budget structures that can’t improve new product requirements. Therefore, sometimes we can see negative affects appear, for instance historical project teams see that they are following a plan automatically and blindly. it makes them lose opportunities to produce more valuable products.<ref name="agile"/>
  
Historical Project Management compare to Agile Project Management:
 
 
Since Agile approach is now being increasingly adopted by companies worldwide for software development, The traditional methods is rapidly losing its popularity.
 
 
Here is some differences between historical and agile approach to the project management task:
 
 
#In agile project management we need to Create a product backlog as a simple list of requirements by priority . Quickly update the product backlog as requirements and priorities change overall the project in case in historical Project Management, a fully detailed project requirement document need to be created at the beginning of the project and trying to control requirement changes throughout the project.
 
# In agile project management the development team meets quickly, at the start of each day, for no longer than 15 minutes, to coordinate and synchronize that day’s work and any roadblocks, in case in in historical Project Management weekly status meetings, conduct with all project stakeholders and developers. Send out detailed meeting notes and status reports after each meeting.
 
# In agile project management, works is within sprints and identify only specific tasks for the active sprint, in case in  historical Project Management a detailed project schedule with all tasks  should be created at the beginning of the project and the project manager tries to keep the project tasks on  schedule and Updates the schedule on a regular basis.
 
# In agile project management, the development team should be Supported by helping remove impediments and distractions. In this approach, development teams define and pull their own tasks, in case in historical Project Management, tasks should be assigned to the development team.
 
# Creating products is a long procedure and there are some factors lead up to have great products. Chang is one of the most important and valuable tools to reach these great products. Product users can be respond as soon as possible by project teams and the market are able to expand relevant, helpful products that people want to use. In agile project management, changes accommodate systematically. The flexibility of agile approaches is very useful and could increases project stability because changes in an agile project make it, predictable and manageable, by contrast, Unfortunately, in historical project management methods, change how they manage procedures and budget structures that can’t modify new product requirements make changes difficult. Therefore, sometimes we can see negative affects appear, for instance historical project teams often find themselves blindly following a plan and it can cause missing opportunities to construct more valuable products.<ref name="APM" > Mark C. Layton and
 
Steven J Ostermiller | 2017 | "Agile Project Management For Dummies®, 2nd Edition"</ref>
 
 
==Application==
 
==Application==
Agile approaches are based on an empirical control method. This approach helps making decisions based on the realities observed in the project. In the context of software development methodologies, an empirical approach can be effective in both new product development and enhancement and upgrade projects. You can make immediate adjustments, by using frequent and firsthand inspection of the work to date, if necessary.
+
Decision making in '''''Agile approaches''''', are based on an '''''empirical control method''''' and the real observation during the project. This method can affect project to improve and upgrade projects. In this method, project manager, by using frequent and inspection of the project to date, can make immediate adjustments, if necessary.
Agile projects work in iterations (smaller segments of the whole project), to accommodate frequent inspection and immediate adaptation.
+
In '''''Agile projects''''', whole project should be divided in smaller segment called '''''iterations''''' to accommodate frequent inspection and immediate adjustments.
This approach, involves the same type of work as in a traditional waterfall project: You create requirements and designs, develop the product, document it, and if necessary, integrate the product with other products. You test the product, fix any problems, and deploy it for use. However, instead of completing these steps for all product features at once, as in a waterfall project, you break the project into iterations, also called sprints.
+
This approach, involves the same type of work as in a '''''traditional waterfall project''''' : creating requirements and designs, improving the product, documenting it and if necessary, integrating the product with other products. After that, testing the product, solving any problems, and deploying it for use.
Since the creators of the Agile Manifesto worked in the IT industry, they originally focused on software development.
+
But in '''''Agile approach''''' project manager need to break these steps for all product features in the project into iterations, also called '''''sprints''''',
. However, extension of agile project management techniques, has gone beyond software development and even outside computer related products. Today, agile approaches are used by project management to create products in a variety
+
instead of completing these at once, as in a waterfall project.
of industries, including manufacturing, biotech, engineering, marketing, aerospace, nonprofit work, and even building construction.  
+
Since the creators of the '''''Agile Manifesto''''' worked in the IT industry, they originally focused on software development.
If you want early empirical feedback on the product or service you’re providing, agile methods can help you.<ref name="APM" > Mark C. Layton and
+
However, extension of agile project management techniques has gone beyond software development and even outside computer related products. Today, '''''agile approaches''''' are used by '''''project management''''' to create products in a variety of industries, including manufacturing, biotech, engineering, marketing, aerospace, nonprofit work, and even building construction.  
Steven J Ostermiller | 2017 | "Agile Project Management For Dummies®, 2nd Edition"</ref>  
+
If you want early empirical feedback on the product or service you’re providing, '''''agile methods''''' can help you.<ref name="agile"/>
 
===Agile Planning===
 
===Agile Planning===
Planning happens at a number of points in an agile project. A great way to look at the planning activities in agile projects is with the Road map to Value.
+
'''''The Roadmap To Value''''' is a great approach to look at the '''''planning tasks''''' in '''''Agile Projects''''', which occurs at a number of points.  
Following figure shows the roadmap as a whole.
+
  
[[File:The Road map to value.png|frame|center|1000*1000px|Stages of agile planning and execution with the Roadmap to Value.. Adapted from <ref name="agile"/>]]
+
[[File:The Road map to value.png|frame|center|1000*1000px|Stages of agile planning and execution with the Roadmap to Value.. Adapted from <ref > Mark C. Layton and
 +
Steven J Ostermiller | 2017 | "Agile Project Management For Dummies®, 2nd Edition" page 118 </ref>]]
  
  
-In stage 1, the product owner identifies the product vision. The product vision is your project’s destination or end goal. The product vision includes the outer boundary of what your product will be, how the product is different from the competition, how the product will support your company or organization’s
+
-In stage 1, as we can see in the figure, the '''''product vision''''' which is the end goal and destination for your project, need to be identified by the '''''product owner'''''.  
strategy, who will use the product, and why people will use the product. On longer projects, revisit the product vision at least once a year.
+
The '''''product vision''''' can help you to indicate how your company or organization’s strategy will be supported with the product.  
 +
The '''''product vision''''' needs to be revisited at least once a year.
  
-In stage 2, the product owner creates a product road map. The product road map is a high-level view of the product requirements, with a general time frame for
+
-In stage 2, '''''the product road map''''' which is the holistic view of product requirements need to be created by the '''''product owner'''''. The product vision is created by showing the product features during the project.  
when you will develop those requirements. It also gives context to the vision by showing the tangible features that will be produced during the project.
+
This stage should be revised the at least biannually by the product owner.
Identifying product requirements and then prioritizing and roughly estimating the effort for those requirements allow you to establish requirement themes and identify requirement gaps. The product owner, with support from the development team, should revise the product road map at least biannually.
+
  
-In stage 3, the product owner creates a release plan. The release plan identifies a high-level timetable for the release of working functionality to the customer. The release serves as a mid-term boundary against which the scrum team can mobilize. An agile project will have many releases, with the highest-priority features appearing first. You create a release plan at the beginning of each release, which is usually at least quarterly.  
+
-In stage 3, '''''the release plan''''' which identifies a timetable for the release of specific product functionality to the customer, need to be created by the '''''product owner'''''.
 +
There are many releases with the highest-priority features in an agile project and at least quarterly, a release plan should be created at the beginning of each release.  
  
-In stage 4, the product owner, the development team, and the scrum master will plan iterations, also called sprints, and start creating the product functionality in those sprints. Sprint planning sessions take place at the start of each sprint. During sprint planning, the scrum team determines a sprint goal, which establishes the immediate boundary of work that the team forecasts to accomplish during the sprint, with requirements that support the goal and can be completed in the sprint. The scrum team also outlines how to complete those requirements.  
+
-In stage 4, '''''the sprint planning''''' which is establishment of specific iteration goals and tasks in the sprint, need to be created by the '''''product owner''''' and '''''the development team''''', at the start of each sprint.
  
-In stage 5, the development team has daily scrum meetings during each sprint to coordinate the day’s priorities. In the daily scrum meeting, you discuss what you completed yesterday, what you will work on today, and any roadblocks you have, so that you can address issues immediately.  
+
-In stage 5, '''''the scrum meetings''''' are hold every day during each sprint by '''''the development team'''''. This is establishment and coordination priorities for the day and discussion about what you completed the day before, what you will work on today, and any barriers you meet in your planning, therefore you can solve these barriers immediately.
  
-In stage 6, the scrum team holds a sprint review at the end of every sprint. In the sprint review, you demonstrate the working functionality to the product
+
-In stage 6, '''''the sprint review''''' need to be done by '''''product owner''''' and '''''development team''''' at the end of each sprint to demonstrate the working functionality to the product stakeholders.  
stakeholders.  
+
  
-In stage 7, the scrum team holds a sprint retrospective. The sprint retrospective is a meeting where the scrum team discusses the completed sprint with regard to their processes and environment, and makes plans for process improvements in the next sprint. Like the sprint review for inspecting and adapting the product, a sprint retrospective is held at the end of every sprint to inspect and adapt your processes and environment.
+
-In stage 7, '''''the sprint retrospective''''' need to be held by the '''''scrum team''''' at the end of each sprint. In this stage, the scrum team discusses about  their processes and environment during the sprint . It can help them to improve their process for the next sprint.
Each stage in the Road map to Value is repeatable, and each stage contains planning activities.<ref name=agile> Mark C. Layton and
+
 
Steven J Ostermiller | 2017 | "Agile Project Management For Dummies®, 2nd Edition" page 118-120</ref>  
+
'''''The Roadmap To Value''''' can be repeated in each stage which contains planning activities.<ref name=agile> Mark C. Layton and
 +
Steven J Ostermiller | 2017 | "Agile Project Management For Dummies®, 2nd Edition" </ref><ref>Emerson Taymor. Agile Handbook. [ONLINE] Available at: "http://agilehandbook.com/agile-handbook.pdf"</ref>.
  
 
===Control schedule in agile approach===
 
===Control schedule in agile approach===
  
In agile approach control schedule is concerned with:
+
In agile approach, '''''control schedule''''' tries:
 
+
*Determining the current status of the project schedule by    comparing the total amount of work delivered and accepted against the estimates of work completed for the elapsed time cycle.
+
*To compare the total amount of work delivered with the amount of the work completed in the given time to assess the present status of the project schedule of the work completed.
*Conducting retrospective reviews (scheduled reviews to record lessons learned) for correcting processes and improving, if required,
+
*To improve the process by reviewing what has been learned
*Re-prioritizing the remaining work plan (backlog),
+
*To prioritize the rest of the work plan again
*Determining the rate at which the deliverable are produced, validated, and accepted (velocity) in given time per iteration (agreed work cycle duration, typically two weeks or one month),
+
*To assess the velocity of producing a product in given time
*Determining that the project schedule has changed, and
+
*To assess how well the project schedule has changed and to control the actual changed as they occur<ref> Project Management Institute | 2013 | "A Guide to Project Management Body of Knowledge" | (5th Edition)</ref>  
*Managing the actual changes as they occur.<ref> Project Management Institute | 2013 | "A Guide to Project Management Body of Knowledge", Chapter 6.7 | (5th Edition)</ref>  
+
===Common agile techniques===
+
Common agile techniques used:
+
  
  
  
 +
===Common agile techniques===
  
 +
Common agile techniques used:
  
 
====SCRUM====
 
====SCRUM====
 
[[File:Scrum11.jpg|200px|thumb|The Agile Scrum Framework at a glance] Available at  <ref>[''AGILE SCRUM FOR WEB DEVELOPMENT '']  [ONLINE] Available at''https://www.neonrain.com/agile-scrum-web-development/'' This picture is under the following creative commons license: https://creativecommons.org/licenses/by-nd/3.0/nz/</ref> ,]]
 
[[File:Scrum11.jpg|200px|thumb|The Agile Scrum Framework at a glance] Available at  <ref>[''AGILE SCRUM FOR WEB DEVELOPMENT '']  [ONLINE] Available at''https://www.neonrain.com/agile-scrum-web-development/'' This picture is under the following creative commons license: https://creativecommons.org/licenses/by-nd/3.0/nz/</ref> ,]]
  
This model known for agile project management that uses fixed-length repetition of work, which is named sprints.
+
This model known for agile project management that uses fixed-length repetition of work, which is named '''''sprints'''''.  
+
 
The four ceremonies of scrum that bring structure to each sprint are :
 
The four ceremonies of scrum that bring structure to each sprint are :
*Sprint Planning: It is a planning meeting that specify for a team what to do in the coming sprint.
+
*'''''Sprint Planning''''': It is a planning meeting that specify for a team what to do in the coming sprint.
*Sprint Demo: A meeting that team share what they've shipped in that sprint.
+
*'''''Sprint Demo''''': A meeting that team share what they've shipped in that sprint.
*Daily Stand-up: Also named stand-up is a definition for 15-minute mini-meeting for the software team to sync.
+
*'''''Daily Stand up''''': Also named stand-up is a definition for 15-minute mini-meeting for the software team to sync.
*Retrospective: A revising of what did and didn't go well with actions to help make the next sprint better.<ref name="multiple">CLAIRE DRUMOND. Agile Project Management. [ONLINE] Available at: "https://www.atlassian.com/agile/project-management"</ref>.
+
*'''''Retrospective''''': A revising of what did and didn't go well with actions to help make the next sprint better.<ref name="multiple">CLAIRE DRUMOND. Agile Project Management. [ONLINE] Available at: "https://www.atlassian.com/agile/project-management"</ref>.
 
+
 
+
  
 
====Kanban====
 
====Kanban====
 
[[File:KANBAN.png|200px|thumb|Kanban System Available at  <ref>[''Lean Kanban Methodology to Application Support and Maintenance Posted by Vikash Karuna on September 13, 2015 '']  [ONLINE] Available at'':https://agilegnostic.wordpress.com/2015/09/13/lean-kanban-methodology-to-application-support-and-maintenance/'' </ref> ]]
 
[[File:KANBAN.png|200px|thumb|Kanban System Available at  <ref>[''Lean Kanban Methodology to Application Support and Maintenance Posted by Vikash Karuna on September 13, 2015 '']  [ONLINE] Available at'':https://agilegnostic.wordpress.com/2015/09/13/lean-kanban-methodology-to-application-support-and-maintenance/'' </ref> ]]
Kanban is a framework for agile project management that adjust the work to the team's capacity. It's concentrate on everything carry out as soon as possible, providing teams the ability to respond to change even faster than scrum.
+
'''''Kanban''''' is a '''''framework''''' for agile project management that adjust the work to the team's capacity. It's concentrate on everything carry out as soon as possible, providing teams the ability to respond to change even faster than scrum.
 
+
The '''''Kanban framework''''' includes the following four components:
The Kanban framework includes the following four components:
+
*'''''List of work''''': List of work, or stories, are defined as issues or tasks that need to get done.
*List of work (or stories): List of work, or stories, are defined as issues or tasks that need to get done.
+
*'''''Columns or lanes''''': Used on a Kanban board to specify tasks from different workstreams, users, projects, etc.
*Columns or lanes: Used on a Kanban board to specify tasks from different work streams, users, projects, etc.
+
*'''''Work in Progress Limits''''': This is a rule to confine the amount of work to be done according to the team's capacity.  
*Work in Progress Limits (WIP): This is a rule to confine the amount of work to be done according to the team's capacity.  
+
*'''''Continuous Releases''''': The team works on the number of stories within the WIP limit and can release at any time.<ref name="multiple"/>
*Continuous Releases: The team works on the number of stories within the WIP limit and can release at any time.<ref name="multiple"/>
+
  
  
Line 137: Line 116:
 
====DSDM ====
 
====DSDM ====
 
[[File:DSDM1.png|200px|thumb|DSDM Framework Available at  <ref>[''Project Management Models Made Easy BY SUNITHA ANUPKUMAR '']  [ONLINE] Available at'':https://www.24point0.com/using-editable-ppt-products/project-management-models-powerpoint/'' </ref> ]]
 
[[File:DSDM1.png|200px|thumb|DSDM Framework Available at  <ref>[''Project Management Models Made Easy BY SUNITHA ANUPKUMAR '']  [ONLINE] Available at'':https://www.24point0.com/using-editable-ppt-products/project-management-models-powerpoint/'' </ref> ]]
DSDM stands for Dynamic Systems Development Method, and it’s an Agile method.  
+
'''''DSDM''''' stands for '''''Dynamic Systems Development Method''''', and it’s an Agile method.  
The DSDM Consortium published the first version of DSDM in 1994; around the same time as XP and Scrum.
+
DSDM has been designed to be compatible with generic project management methods, especially PRINCE2®. That makes DSDM different from lightweight frameworks like Scrum.  The DSDM Agile Project is a Framework that covers a large area of activities across the entire project lifecycle and contain strong foundations and governance, which separated from some other Agile methods. The DSDM Agile Project Framework is an iterative and incremental approach that accept principles of Agile development, including continuous user/customer involvement.<ref>Wikipedia. Dynamic systems development method. [ONLINE] Available at: "https://en.wikipedia.org/wiki/Dynamic_systems_development_method#References"</ref>.
+
 
+
 
+
 
+
  
 +
'''''The DSDM Consortium''''' published the first version of '''''DSDM''''' in 1994; around the same time as XP and Scrum.
 +
'''''DSDM''''' has been designed to be compatible with generic project management methods, especially PRINCE2®. That makes '''''DSDM''''' different from lightweight frameworks like Scrum. '''''DSDM''''' is an agile method that encompass all the activities being done during the project life cycle. It is based on repetitive approach that principles of agile development make the important part of it. It include the everyday users and customer involvement.<ref>Wikipedia. Dynamic systems development method. [ONLINE] Available at: "https://en.wikipedia.org/wiki/Dynamic_systems_development_method#References"</ref>.
  
 
====XP====
 
====XP====
 
[[File:XP1.png|200px|thumb|Extreme Programming (XP) at a Glance] Available at  <ref>[''Extreme Programming (XP) at a Glance (Visual) BY JD Meier,June 6, 2014 '']  [ONLINE] Available at''https://blogs.msdn.microsoft.com/jmeier/2014/06/06/extreme-programming-xp-at-a-glance-visual/'' </ref> ]]
 
[[File:XP1.png|200px|thumb|Extreme Programming (XP) at a Glance] Available at  <ref>[''Extreme Programming (XP) at a Glance (Visual) BY JD Meier,June 6, 2014 '']  [ONLINE] Available at''https://blogs.msdn.microsoft.com/jmeier/2014/06/06/extreme-programming-xp-at-a-glance-visual/'' </ref> ]]
XP is initial for Extreme Programming which is an agile software development method and its main goal is to produce higher quality software, and superior quality of life for the development team. XP is the most particular of the agile frameworks regarding sutible engineering practices for software development.<ref>Agile Alliance. Extreme Programming. [ONLINE] Available at: "https://www.agilealliance.org/glossary/xp/#q=~(filters~(postType~(~'post~'aa_book~'aa_event_session~'aa_experience_report~'aa_glossary~'aa_research_paper~'aa_video)~tags~(~'xp))~searchTerm~'~sort~false~sortDirection~'asc~page~1)"</ref>.  As Extreme Programming concentrate on customer satisfaction its mention as a successful method. Instead of delivering everything you could possibly want on some date far in the future this process delivers the software you need as you need it.
+
'''''XP''''' is initial for '''''Extreme Programming''''' which is an '''''agile software development method''''' and its main goal is to produce higher quality software, and superior quality of life for the development team. '''''XP''''' is the most particular of the agile frameworks regarding suitable engineering practices for software development. As '''''Extreme Programming''''' concentrate on customer satisfaction its mention as a successful method.<ref>Don Wells. All Rights reserved.  
Teamwork is one of the most emphasizing part of Extreme Programming. Managers, customers, and developers are all equal components in a cooperative team. Extreme Programming implements a simple, yet effective environment enabling teams to become highly productive. The team self-organizes around the problem to solve it as efficiently as possible.<ref>Don Wells. All Rights reserved.  
+
 
Last modified October 8, 2013. Extreme Programming:
 
Last modified October 8, 2013. Extreme Programming:
 
A gentle introduction. [ONLINE] Available at: "http://www.extremeprogramming.org/"</ref>.
 
A gentle introduction. [ONLINE] Available at: "http://www.extremeprogramming.org/"</ref>.
  
 
==Limitation==
 
==Limitation==
As we have learned about Agile project management in this article, it has strong advantages but it’s important to know the limitations and risks it brings:
+
As we have learned about '''''Agile project management''''' in this article, it has strong advantages but it’s important to know the limitations and risks it brings:
Lacking of enough documentation for the system cause that Agile methodologies consider as a not suitable system for maintenance    and its one of the first limitation known for Agile methodology. In the other hand documentation is not the fact of matter for programmer and developer when they use Agile Methodology because the main goal for them is to write software. Every system needs users for being alive and like some other system Agile Methodology is heavily depend on the user involvement and this could mention as another limitation for system. And this is Krysta clear that collaboration and connection between users can provide the success of system. There is also another limitation for Agile Methodology, which is concentrate work quality on the skills and behaviors of the developers. Generally designing of modules and submodules are constructed by single developer because they concentrate on building system that solve a particular problem not the general one. Basically, for the small group between 3 and 9 members Agile Methodology can be the best choice but unfortunately it not works well for teams with large number of members. <ref>Buric, Alden. The Agile Methodologies [ONLINE] Available at: "https://www.umsl.edu/~sauterv/analysis/Fall2013Papers/Buric/limitations-of-agile-methodologies-1.html"</ref>.  
+
Lacking of enough documentation for the system cause that Agile approaches consider as a not suitable system for maintenance    and its one of the '''''limitations''''' known for this approaches. In the other hand documentation is not the fact of matter for programmer and developer when they use Agile approaches, because the main goal for them is to write software. Every system needs users for being alive and like some other system, Agile approaches is heavily depending on the user involvement and this could mention as another '''''limitation''''' for system. And this is Krysta clear that collaboration and connection between users can provide the success of system. Basically, for the small group between 3 and 9 members Agile approaches can be the best choice but unfortunately it does not work well for teams with large number of members.<ref>Buric, Alden. The Agile Methodologies [ONLINE] Available at: "https://www.umsl.edu/~sauterv/analysis/Fall2013Papers/Buric/limitations-of-agile-methodologies-1.html"</ref>.
 
+
  
 
==Annotated bibliography==
 
==Annotated bibliography==
#Emerson Taymor. Agile Handbook. [ONLINE] Available at: "http://agilehandbook.com/agile-handbook.pdf: This handbook is a quick-starter and an overview of the framework for Agile Project.
+
#'''''Emerson Taymor. Agile Handbook.''''' [ONLINE] Available at: "http://agilehandbook.com/agile-handbook.pdf: This handbook is a quick-starter and an overview of the framework for Agile Project.
#Mark C. Layton and Steven J Ostermiller, "Agile Project Management For Dummies®, 2nd Edition", 2017 : This book beside an introduction to agile practices and methodologies help you also discover the steps to execute agile techniques on a project. The materials in this book, give you the tools and information you need to be successful with agile processes in the project management.
+
#'''''Mark C. Layton and Steven J Ostermiller, "Agile Project Management For Dummies®, 2nd Edition", 2017 ''''': This book beside an introduction to agile practices and methodologies help you also discover the steps to execute agile techniques on a project. The materials in this book, give you the tools and information you need to be successful with agile processes in the project management.
#Project Management Institute,"A Guide to Project Management Body of Knowledge", (5th Edition),2013 : This book is a set of standard  and guidelines for project management which can be used in different methodologies and tools (e.g., agile, waterfall, PRINCE2) to implement the project management framework.
+
#'''''Project Management Institute,"A Guide to Project Management Body of Knowledge", (5th Edition),2013''''' : This book is a set of standard  and guidelines for project management which can be used in different methodologies and tools (e.g., agile, waterfall, PRINCE2) to implement the project management framework.
 
+
 
+
 
+
 
+
 
+
 
+
  
 
==References==
 
==References==
 
<references/>
 
<references/>

Latest revision as of 16:17, 16 November 2018

Developed by Hoda Vazirinasab


Contents

[edit] Abstract

” Agility means the ability to balance between flexibility and stability. The 21st Century's market and business environment is more turbulent, unstable and full of tension than any other time and in view of investors unpredictable and dangerous. In this new century, the emergence and development of technological ideas and designs in the form of commercial products will not give you enough time to manage affairs and projects in a traditional way and you need to be more agile, in order to ensure the growth, development, continuation and survival of your business in competition with leading companies in various industries. Along with the evolution of various branches of industry and technology, project management as one of the most common ways of delivering products and doing services has undergone dramatic changes. Increasing pressures and stress caused, the speed of production of other companies, development and transfer of information, as well as increasing participation of customers and their more emphasis on various aspects of project outputs, have led project managers and custodians to seek more agile and aggressive approaches to project management. So that, in addition to obtaining customer’s satisfaction and other project stakeholders, they can make proper decisions and take actions as soon as possible . These developments have been so wide spread and universal in the last two decades that agile management has completely replaced traditional and waterfall approaches in managing many projects in industries and especially in Hi-Tech industries.[1]

[edit] Big idea

I want to start my discussion with an example to make it much clear.:

Let’s say, you are working in a company and you have your own piece of software for your business as usual and you are earning money using it. There is a business section in your company as sales, marketing and IT department that adds new feature to the existing software and maybe creates new pieces of software or maintaining and something like that. One day, one of the staff from the business section comes to you and says that they need something new. They want to start a new project to create for example a mobile application to increase sales in a way. First you do not know exactly what they want and how you would proceed with it. What would you do? The commonest way for the technical and management staff is to start a conversation with the business people, to ask them questions about what they have in mind, the needs and something like that. We keep doing that until we have a complete understanding of their expectations and when we are sure that we know their expectations, then we consider a product that can meet those expectations. Now we have the product and we create a plan that can help us create that product. Then we start the project and throughout the project, our goal is to follow the plan. Because that is probably, the best way we can realize that product. You usually have some deviations that it is completely normal and is ok. you have to have a monitoring and controlling system to understand the deviations and remove them and get back on track. After a while you get to the end and create a product as it was planned and designed upfront. You will show it to the business people. in certain cases, in some projects, when you do that, you realize the expectations for something else that you could not understand the expectations before.

It does not happen in every project. When you want to construct a building or when you want to build a bridge, you can understand the expectation from the beginning and then plan everything and create the product and everyone will be happy. But in some projects, such as IT development, it does not usually happen. Cases are different. As it is very common, how can we prevent it from happening? how can we solve this problem?. At the beginning of the project, you don’t know enough about the expectations of the customer. But instead of trying to make it precise in the beginning, you just go on with the project. In a short period of time you think about different ways of approaching the project and you pick one that seems to be the best, the one that you believe will bring those closest to the expectations as you know them. So, you run the project for a couple of weeks, create a small piece of product and show it to the customer. The fact is that you realize that maybe the only thing that is in common between technical people and business people is the product and that is the only way you can really understand each other. In this approach you will have multiple products during the project. So,you spend a few weeks and you create a very small piece of product. you show what you have worked on to the customer or the business side and receive their feedback. Using that feedback and new understanding you have from the way the business works within a small piece of product ,you have better understanding of the expectations. So you can take the next step, using the new understanding you will think about different alternatives, pick one that seems to be the best , create the second version of the product, show it to the customer again, receive more feedback and you go on like this,until you realize all the expectations. this approach is called adaptive,because you go on and let the environment help you adapt yourself and find your way through the project. So one common problem is that people think in adaptive approaches you just go on with the project and you don’t care about planning or designing or anything else. no, that is not the case. There is a special approach that helps you use the environment to find your way. So, this approach is what we call agile.

Agile project management, was first discussed in depth in the 1970s by software developers, is a style of project management that focuses on early delivery of business value, continuous improvement of the project’s product and processes, scope flexibility, team input, and delivering well tested products that reflect customer needs. Although agile approaches have roots in software development, you can use them for other types of products. In February 2001, a group of 17 software and project experts got together to discuss about their experiences, ideas and to suggest ways to improve the world of software development. This group created the Agile Manifesto which is an expression of core development values and 12 Principles behind it which help support the values in the Agile Manifesto and support agile project teams in implementing agile techniques and staying on track. According to these12 principles, agile methods focus on customer satisfaction, quality in every product, teamwork and project management[1]

In a comparison, we can see the differences between Agile Project Management and Historical Project Management :

  1. In agile project management we need to create a product backlog in terms of priority and importance, quickly update the product backlog as requirements and priorities change, whereas in Historical Project Management we must create a complete list of project requirement document at the beginning of the project and all changes must be controlled.
  2. In agile project management the development team convene quickly, at the start of each day, for no longer than 15 minutes, to coordinate and synchronize that day’s work and any obstacles, whereas in Historical Project Management weekly status meetings, conduct with all project stakeholders and developers. After each meeting, they send out detailed meeting notes and status reports.
  3. In Historical Project Management, at the beginning of the project a detailed project schedule with all tasks should be created and the project manager tries to keep the project tasks on schedule and updates the schedule on a regular basis, whereas in agile project management, specific tasks identify for the active sprint.
  4. In agile project management, the development team should be supported by helping it remove impediments. In this way, development teams define their own tasks, whereas in Historical Project Management, tasks should be assigned to the development team.
  5. In order to produce products, we have to go through a long way. In this path there is some factors lead us to produce great products. Making Changes is one of the most important and valuable factors to achieve these great products. End-users can be provided by project teams and the market is able to supply relevant, useful products that people need. In agile project management, changes are adopted systematically. The flexibility of Agile system is very helpful and can increase project ability because changes in an agile project make it predictable and manageable. By contrast, Unfortunately, in Historical Project Management methods change the way they manage procedures and budget structures that can’t improve new product requirements. Therefore, sometimes we can see negative affects appear, for instance historical project teams see that they are following a plan automatically and blindly. it makes them lose opportunities to produce more valuable products.[1]

[edit] Application

Decision making in Agile approaches, are based on an empirical control method and the real observation during the project. This method can affect project to improve and upgrade projects. In this method, project manager, by using frequent and inspection of the project to date, can make immediate adjustments, if necessary. In Agile projects, whole project should be divided in smaller segment called iterations to accommodate frequent inspection and immediate adjustments. This approach, involves the same type of work as in a traditional waterfall project : creating requirements and designs, improving the product, documenting it and if necessary, integrating the product with other products. After that, testing the product, solving any problems, and deploying it for use. But in Agile approach project manager need to break these steps for all product features in the project into iterations, also called sprints, instead of completing these at once, as in a waterfall project. Since the creators of the Agile Manifesto worked in the IT industry, they originally focused on software development. However, extension of agile project management techniques has gone beyond software development and even outside computer related products. Today, agile approaches are used by project management to create products in a variety of industries, including manufacturing, biotech, engineering, marketing, aerospace, nonprofit work, and even building construction. If you want early empirical feedback on the product or service you’re providing, agile methods can help you.[1]

[edit] Agile Planning

The Roadmap To Value is a great approach to look at the planning tasks in Agile Projects, which occurs at a number of points.

Stages of agile planning and execution with the Roadmap to Value.. Adapted from [2]


-In stage 1, as we can see in the figure, the product vision which is the end goal and destination for your project, need to be identified by the product owner. The product vision can help you to indicate how your company or organization’s strategy will be supported with the product. The product vision needs to be revisited at least once a year.

-In stage 2, the product road map which is the holistic view of product requirements need to be created by the product owner. The product vision is created by showing the product features during the project. This stage should be revised the at least biannually by the product owner.

-In stage 3, the release plan which identifies a timetable for the release of specific product functionality to the customer, need to be created by the product owner. There are many releases with the highest-priority features in an agile project and at least quarterly, a release plan should be created at the beginning of each release.

-In stage 4, the sprint planning which is establishment of specific iteration goals and tasks in the sprint, need to be created by the product owner and the development team, at the start of each sprint.

-In stage 5, the scrum meetings are hold every day during each sprint by the development team. This is establishment and coordination priorities for the day and discussion about what you completed the day before, what you will work on today, and any barriers you meet in your planning, therefore you can solve these barriers immediately.

-In stage 6, the sprint review need to be done by product owner and development team at the end of each sprint to demonstrate the working functionality to the product stakeholders.

-In stage 7, the sprint retrospective need to be held by the scrum team at the end of each sprint. In this stage, the scrum team discusses about their processes and environment during the sprint . It can help them to improve their process for the next sprint.

The Roadmap To Value can be repeated in each stage which contains planning activities.[1][3].

[edit] Control schedule in agile approach

In agile approach, control schedule tries:

  • To compare the total amount of work delivered with the amount of the work completed in the given time to assess the present status of the project schedule of the work completed.
  • To improve the process by reviewing what has been learned
  • To prioritize the rest of the work plan again
  • To assess the velocity of producing a product in given time
  • To assess how well the project schedule has changed and to control the actual changed as they occur[4]


[edit] Common agile techniques

Common agile techniques used:

[edit] SCRUM

The Agile Scrum Framework at a glance] Available at [5] ,

This model known for agile project management that uses fixed-length repetition of work, which is named sprints. The four ceremonies of scrum that bring structure to each sprint are :

  • Sprint Planning: It is a planning meeting that specify for a team what to do in the coming sprint.
  • Sprint Demo: A meeting that team share what they've shipped in that sprint.
  • Daily Stand up: Also named stand-up is a definition for 15-minute mini-meeting for the software team to sync.
  • Retrospective: A revising of what did and didn't go well with actions to help make the next sprint better.[6].

[edit] Kanban

Kanban System Available at [7]

Kanban is a framework for agile project management that adjust the work to the team's capacity. It's concentrate on everything carry out as soon as possible, providing teams the ability to respond to change even faster than scrum. The Kanban framework includes the following four components:

  • List of work: List of work, or stories, are defined as issues or tasks that need to get done.
  • Columns or lanes: Used on a Kanban board to specify tasks from different workstreams, users, projects, etc.
  • Work in Progress Limits: This is a rule to confine the amount of work to be done according to the team's capacity.
  • Continuous Releases: The team works on the number of stories within the WIP limit and can release at any time.[6]


[edit] DSDM

DSDM Framework Available at [8]

DSDM stands for Dynamic Systems Development Method, and it’s an Agile method.

The DSDM Consortium published the first version of DSDM in 1994; around the same time as XP and Scrum. DSDM has been designed to be compatible with generic project management methods, especially PRINCE2®. That makes DSDM different from lightweight frameworks like Scrum. DSDM is an agile method that encompass all the activities being done during the project life cycle. It is based on repetitive approach that principles of agile development make the important part of it. It include the everyday users and customer involvement.[9].

[edit] XP

Extreme Programming (XP) at a Glance] Available at [10]

XP is initial for Extreme Programming which is an agile software development method and its main goal is to produce higher quality software, and superior quality of life for the development team. XP is the most particular of the agile frameworks regarding suitable engineering practices for software development. As Extreme Programming concentrate on customer satisfaction its mention as a successful method.[11].

[edit] Limitation

As we have learned about Agile project management in this article, it has strong advantages but it’s important to know the limitations and risks it brings: Lacking of enough documentation for the system cause that Agile approaches consider as a not suitable system for maintenance and its one of the limitations known for this approaches. In the other hand documentation is not the fact of matter for programmer and developer when they use Agile approaches, because the main goal for them is to write software. Every system needs users for being alive and like some other system, Agile approaches is heavily depending on the user involvement and this could mention as another limitation for system. And this is Krysta clear that collaboration and connection between users can provide the success of system. Basically, for the small group between 3 and 9 members Agile approaches can be the best choice but unfortunately it does not work well for teams with large number of members.[12].

[edit] Annotated bibliography

  1. Emerson Taymor. Agile Handbook. [ONLINE] Available at: "http://agilehandbook.com/agile-handbook.pdf: This handbook is a quick-starter and an overview of the framework for Agile Project.
  2. Mark C. Layton and Steven J Ostermiller, "Agile Project Management For Dummies®, 2nd Edition", 2017 : This book beside an introduction to agile practices and methodologies help you also discover the steps to execute agile techniques on a project. The materials in this book, give you the tools and information you need to be successful with agile processes in the project management.
  3. Project Management Institute,"A Guide to Project Management Body of Knowledge", (5th Edition),2013 : This book is a set of standard and guidelines for project management which can be used in different methodologies and tools (e.g., agile, waterfall, PRINCE2) to implement the project management framework.

[edit] References

  1. 1.0 1.1 1.2 1.3 1.4 Mark C. Layton and Steven J Ostermiller | 2017 | "Agile Project Management For Dummies®, 2nd Edition"
  2. Mark C. Layton and Steven J Ostermiller | 2017 | "Agile Project Management For Dummies®, 2nd Edition" page 118
  3. Emerson Taymor. Agile Handbook. [ONLINE] Available at: "http://agilehandbook.com/agile-handbook.pdf"
  4. Project Management Institute | 2013 | "A Guide to Project Management Body of Knowledge" | (5th Edition)
  5. [AGILE SCRUM FOR WEB DEVELOPMENT ] [ONLINE] Available athttps://www.neonrain.com/agile-scrum-web-development/ This picture is under the following creative commons license: https://creativecommons.org/licenses/by-nd/3.0/nz/
  6. 6.0 6.1 CLAIRE DRUMOND. Agile Project Management. [ONLINE] Available at: "https://www.atlassian.com/agile/project-management"
  7. [Lean Kanban Methodology to Application Support and Maintenance Posted by Vikash Karuna on September 13, 2015 ] [ONLINE] Available at:https://agilegnostic.wordpress.com/2015/09/13/lean-kanban-methodology-to-application-support-and-maintenance/
  8. [Project Management Models Made Easy BY SUNITHA ANUPKUMAR ] [ONLINE] Available at:https://www.24point0.com/using-editable-ppt-products/project-management-models-powerpoint/
  9. Wikipedia. Dynamic systems development method. [ONLINE] Available at: "https://en.wikipedia.org/wiki/Dynamic_systems_development_method#References"
  10. [Extreme Programming (XP) at a Glance (Visual) BY JD Meier,June 6, 2014 ] [ONLINE] Available athttps://blogs.msdn.microsoft.com/jmeier/2014/06/06/extreme-programming-xp-at-a-glance-visual/
  11. Don Wells. All Rights reserved. Last modified October 8, 2013. Extreme Programming: A gentle introduction. [ONLINE] Available at: "http://www.extremeprogramming.org/"
  12. Buric, Alden. The Agile Methodologies [ONLINE] Available at: "https://www.umsl.edu/~sauterv/analysis/Fall2013Papers/Buric/limitations-of-agile-methodologies-1.html"
Personal tools
Namespaces

Variants
Actions
Navigation
Toolbox