View source for Agile project management

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

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==
''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 these'''''12 principles''''', agile methods focus on '''''customer satisfaction''''', '''''quality in every product''''', '''''teamwork''''' and '''''project management'''''.<ref name="APM" > Mark C. Layton and
Steven J Ostermiller | 2017 | "Agile Project Management For Dummies®, 2nd Edition"</ref>

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

	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.

==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.
Agile projects work in iterations (smaller segments of the whole project), to accommodate frequent inspection and immediate adaptation.
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.
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.<ref name="APM" > Mark C. Layton and
Steven J Ostermiller | 2017 | "Agile Project Management For Dummies®, 2nd Edition"</ref> 
===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.
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"/>]]


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

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

===Control schedule in agile approach===

In agile approach control schedule is concerned with:

*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.
*Conducting retrospective reviews (scheduled reviews to record lessons learned) for correcting processes and improving, if required,
*Re-prioritizing the remaining work plan (backlog),
*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),
*Determining that the project schedule has changed, and
*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:





====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> ,]]

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.<ref name="multiple">CLAIRE DRUMOND. Agile Project Management. [ONLINE] Available at: "https://www.atlassian.com/agile/project-management"</ref>.



====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> ]]
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 (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 work streams, users, projects, etc.
*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"/>



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





====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> ]]
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.
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:
A gentle introduction. [ONLINE] Available at: "http://www.extremeprogramming.org/"</ref>.

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


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







==References==
<references/>