Agile Methodology

From apppm
(Difference between revisions)
Jump to: navigation, search
 
(18 intermediate revisions by 2 users not shown)
Line 1: Line 1:
[[Category:''Agile Methodology'']]
+
''Developed by Sophie Emilie Smietana''
  
Agile methodology in project management focuses on incremental and continuous improvements. Flexibility in scope, team dynamics and inputs, as well as, producing quality results is essential to agile. Agile methodology consists of a manifesto and as well as 12 principles. Agile methodology developed its popularity within the software development industry. Over the past 25 to 30 years agile methods helped the software and IT industry increase the productivity and success rate. Today, agile is spreading to other fields and industries.
 
The execution of agile in projects is done by diving projects into smaller parts, known as sprints. A sprint-period typically lasts from 1 to 4 weeks. During each sprint, daily scrum meetings are held.
 
  
== '''Introduction''' ==
+
 
 +
Increasing the success rate for projects has been a priority for as long as projects have been around. Concurrently with projects in a corporate setting became more structured, so did the search for better project management strategies and methods. Agile methodology originally developed its popularity within the software development industry. Over the past 25 to 30 years the method helped the software and IT industry increase their productivity and success rate. The rugby metaphors surrounding agile have their origin in the manufacturing industry. <ref name="tak">Takeuchi, I. N. (2016, June 08). The Big Idea: The Wise Leader. Retrieved October 01, 2017, from https://hbr.org/2011/05/the-big-idea-the-wise-leader </ref>.  Today, agile is no longer just for the software industry, it is now spreading rapidly to other fields and industries. Agile methodology can be seen as an umbrella term for several different frameworks, with all the sub-methods and frameworks adhering to the agile manifesto as well as the 12 principles.  Agile methodology in project management focuses on incremental and continuous improvements. Flexibility in scope, team dynamics and inputs, as well as, producing quality results are essential to the foundation of the method. This article will look at how agile methodology gained its popularity, how to apply it in practice with focus on scrum, and what to be aware of when utilizing this method.
 +
 
 +
== '''Big Idea''' ==
 +
Today, most projects are everchanging, thus flexibility in the development process is of still higher importance. Agile helps foster managing of projects, programs, and portfolios in a flexible and collaborative way. It permits fast changes and pivots if need be. One of the perhaps most used frameworks within agile is scrum. Scrum is a rigid way of organizing the management of project, programs, and portfolios, while still allowing for great flexibility in the development of new products and services. The usage of scrum naturally grew within the software development industry. Software development requires almost endless iterations, which is one of the reasons why agile is a perfect match. The diffusion of agile into other industries during the past 25 to 30 years is due to its success in the software industry and the lack of room for failed projects in other industries.  <ref name="design">Ulrich, K. T., & Eppinger, S. D. (2016). Product design and development. New York, NY: McGraw-Hill Education </ref>.
 +
Even though the overall principles of agile are firmly defined, the execution of applying the method within companies has many shapes. This is both a result of project managers adapting the method to fit their way of running project, but perhaps more often due to confusion as to what exactly agile covers. This is understandable as even the literature does not always agree. E.g. lean is mostly considered its own methodology, however, occasionally it is thought to be one of the frameworks under the umbrella term, agile. 
 
{{#ev:youtube|https://www.youtube.com/watch?v=Z9QbYZh1YXY|300|right| Mark Shead - What is Agile?|frame}}
 
{{#ev:youtube|https://www.youtube.com/watch?v=Z9QbYZh1YXY|300|right| Mark Shead - What is Agile?|frame}}
 +
But why is agile gaining popularity amongst project managers especially? Nine of the main reasons are highlighted below.
 +
*Faster feedback cycle
 +
*Constant change
 +
*Problems are identified early
 +
*Flexible prioritization
 +
*High potential for customer satisfaction
 +
*Benefits of your labor is recognized sooner
 +
*Free commitment and accountability measurement
 +
*No Need to Waste Time Creating and Adjusting Detailed Project Plans
 +
*It Gives Your Team Purpose  <ref name="benefits"> Editors, F. T. (2016, May 09). The Benefits Of Using Agile Software Development. Retrieved October 02, 2017, from https://www.forbes.com/sites/forbestechcouncil/2016/05/09/the-benefits-of-using-agile-software-development/3/#f42e1f29f836 </ref>
 +
When working on a project level you are more concerned with day-to-day changes than if you are working on managing entire portfolios, where focus often will be more on the long-term basis. You are in contact with your team on a daily basis as a project manager, and you fix potential problems sooner. This all ads to project managers being more prone to go agile compared to program or portfolio managers. 
  
== Why is the agile methodology important?==
+
== '''Application''' ==
 +
Although agile methodology is generally viewed as one methodology it consists of multiple practical approaches or sub-methods. Focus will be on the application of the framework called scrum, mainly in a project management setting. In practice, the execution of agile in projects is done by diving projects into smaller parts, known as sprints. A sprint-period typically lasts from 1 to 4 weeks. During each sprint, daily scrum meetings are held.
 +
In figure 1 an overview of the scrum can be seen. <ref name="scrum"> Cohn, M. (n.d.) Scrum Overview: Agile Software Development. Retrieved October 02, 2017, from https://www.mountaingoatsoftware.com/agile/scrum/resources/overview </ref>
  
Agile presents some new opportunities for managing projects, programs, and portfolios. Agile is great for situations where the complexity is big, uncertainties are many, and the project is likely to change during the execution of the work. However, using agile may not be suitable in all situations.
+
[[File:Scrum_overview.png|thumb|upright=3.0|Figure 1 – Scrum overview<ref name="scrum"/>]]
  
 +
=== '''Agile Vocabulary''' ===
 +
The agile methodology based its terminology on rugby expressions, using words such as scrum. It consists of several different terms and expression, however, some of the most common ones are mentioned and explained below. 
 +
 +
'''Product Owner'''
 +
The product owner is an extension of the customers. The product owner is responsible for the product backlog and have authority to change the product along the way. The product owner will typically be from the product management or marketing department, but can also be one of the key stakeholders or key users of the product.
 +
 +
'''Team or Scrum Team'''
 +
The team usually contain between five and nine team members. There can be hundreds of scrum teams and scrum projects within large corporations. However, it is also possible to have a scrum ‘team’ consisting of only one person. The scrum teams are the backbone of the development and execution of the project. The team can be diverse, coming from several different departments, or it can be a focused team, e.g. only software developers. The preferred combination will depend on the situation at hand. However, when utilizing scrum, the team members collectively agree on a set of tasks to be completed within the next sprint. This enforce the team feeling, due to reaching the tasks are a common goal.
 +
 +
'''Product Backlog'''
 +
The product backlog is an overview of all the tasks regarding the desired features or changes to the product that is left to be done. It is important that the backlog is up to date and prioritized at all times. The product backlog will be prioritized according to what the team, scrum master, and especially the product owner wants done first.
 +
 +
'''Sprint Backlog Meeting or Sprint Planning Meeting'''
 +
In order to plan the coming sprint a meeting is held at the beginning of each sprint. The product owner will present the items from the product backlog with the highest priority. The scrum team will then select the number of tasks they can realistically finish before the start of the next sprint. The next process is to move the items from the product backlog into a sprint backlog. 
 +
 +
'''Sprint Backlog '''
 +
The sprint backlog is similar to the product backlog. However, the sprint backlog is only concerned with what the team is supposed to work on during the current sprint. It is also more detailed than the backlog.
 +
 +
'''Scrum Master'''
 +
The scrum master is the voice of the team.  He is the protector of the team and his job is to keep the team as productive as possible by helping where needed and by removing obstacles standing in the way for the team’s productivity. The scrum master will also assist the team members in using the scrum process.
 +
 +
'''Sprints'''
 +
Sprints are typically 1 to 4 weeks periods. During the sprint, the team works on solving the problems in the sprint backlog.
 +
 +
'''Scrum'''
 +
Scrums are 24-hour periods. The team has daily scrum meetings where all team members answer the following three questions.
 +
* What did you accomplish since the last meeting?
 +
* What are you working on until next meeting?
 +
* What is getting in your way or keeping you from doing your job?
 +
The questions are meant to help steer and guide the team members in the right direction and keep the project on track.
 +
 +
'''Sprint Retrospective and Sprint Review Meeting'''
 +
After every sprint period, a sprint retrospective is conducted. This allows the team to determine what was done right and what should be changed for future sprints. It is a way of acknowledging the individuals and the team’s efforts in an informal way.  <ref name="scrum"> Cohn, M. (n.d.) Scrum Overview: Agile Software Development. Retrieved October 02, 2017, from https://www.mountaingoatsoftware.com/agile/scrum/resources/overview </ref>
 +
 +
 +
== '''Limitations – and the Right Conditions for Agile''' ==
 +
Agile presents some new opportunities for managing projects, programs, and portfolios. It is great for situations where the complexity is big, uncertainties are many, and the project is likely to change during the execution of the work. However, using agile may not be suitable in all situations. In table 1, favorable and unfavorable situations for different conditions can be seen.
 
{| class="wikitable"
 
{| class="wikitable"
|+ Table 1: The Right Conditions For Agile <ref name="IWBI Standard (2017).">IWBI Standard. (2017).The WELL Building Standard. Retrieved from https://standard.wellcertified.com/</ref>
+
|+ Table 1: The Right Conditions For Agile <ref name="embrace"> Takeuchi, D. K., Darrell K. Rigby Jeff Sutherland Hirotaka Takeuchi, Bradley Staats and David M. Upton, & Steven Spear H. Kent Bowen. (2017, March 21). Embracing Agile. Retrieved September 22, 2017, from https://hbr.org/2016/05/embracing-agile</ref>
 
!''Conditions''
 
!''Conditions''
!'’Favorable''
+
!''Favorable''
!’’Unfavorable’’
+
!''Unfavorable''
 
|-
 
|-
 
| Market Environment
 
| Market Environment
Line 44: Line 97:
 
|}   
 
|}   
  
 
+
As can be seen in table 1, agile shows its full potential when change is big. As a result, it is not a suitable method for maintenance, since emphasis is not on documentation. Furthermore, there is a great dependency on user involvement, the success of the project will therefore be reliant on the user’s communication skills and willingness to be involved in the development process. The number of members in one team is also a big limitation. The team should seldom be less than three and no more than nine to keep a dynamic and flexible team. <ref name="limit"> [3]Limitations of Agile Methodologies - The Agile Methodologies. (n.d.). Retrieved October 02, 2017, from https://www.umsl.edu/~sauterv/analysis/Fall2013Papers/Buric/limitations-of-agile-methodologies-1.html</ref>
== '''Big Idea''' ==
+
 
+
=== '''Agile Vocabulary''' ===
+
The agile methodology based its terminology on rugby expressions, using words such as scrum. Agile consists of many different terms, however, some of the most import ones are mentioned and explained below. 
+
 
+
==== '''Product Owner''' ====
+
The product owner is an extension of the customers. The product owner is responsible for the product backlog and have authority to change the product along the way.
+
 
+
==== '''Team''' ====
+
 
+
...
+
==== '''Product Backlog''' ====
+
The product backlog is an overview of all the tasks on the product that is left to be done. It is important that the backlog is up to date and prioritized at all times.  
+
 
+
==== '''Sprint Backlog Meeting''' ====
+
 
+
...
+
 
+
 
+
==== '''Sprint Backlog ''' ====
+
The sprint backlog is similar to the product backlog. However, the sprint backlog is only concerned with what the team is supposed to work on during the current sprint. It is also more detailed than the backlog.  
+
 
+
==== '''Scrum Master''' ====
+
The scrum master is the voice of the team
+
 
+
==== '''Sprints''' ====
+
Sprints are typically 1 to 4 weeks periods. During the sprint the team works on solving the problems in the sprint backlog.  
+
 
+
=== '''Scrum''' ===
+
Scrum are 24 hour periods. The team has daily scrum meetings where all team members answer the following three questions.  
+
 
+
* What...
+
* ....
+
* ...
+
 
+
=== '''Sprint Retrospective''' ===
+
After every sprint period a sprint retrospective is conducted. This allows the team to determine what was done right and what should be changed for future sprints.
+
 
+
== '''Application''' ==
+
 
+
== '''The Right Conditions for Agile''' ==
+
 
+
...
+
 
+
== '''Limitations''' ==
+
  
 
== '''Annotated Bibliography''' ==
 
== '''Annotated Bibliography''' ==
 
*Takeuchi, D. K., Darrell K. Rigby Jeff Sutherland Hirotaka Takeuchi, Bradley Staats and David M. Upton, & Steven Spear H. Kent Bowen. (2017, March 21). Embracing Agile. Retrieved September 22, 2017, from https://hbr.org/2016/05/embracing-agile
 
*Takeuchi, D. K., Darrell K. Rigby Jeff Sutherland Hirotaka Takeuchi, Bradley Staats and David M. Upton, & Steven Spear H. Kent Bowen. (2017, March 21). Embracing Agile. Retrieved September 22, 2017, from https://hbr.org/2016/05/embracing-agile
Provides an overview of the basics of what agile encompasses as well why agile should be utilized more in project management.  
+
Provides an overview of the basics of what agile encompasses as well why agile should be utilized more in project management. It has a focus on the types of environments which are favorable and unfavorable for using agile as the project management tool.
 
+
* Limitations of Agile Methodologies - The Agile Methodologies. (n.d.). Retrieved October 02, 2017, from https://www.umsl.edu/~sauterv/analysis/Fall2013Papers/Buric/limitations-of-agile-methodologies-1.html</ref>
 
+
This site provides a short but easy to understand overview of some of the limitations which agile methodologies undoubtedly have.  
== '''References''' ==
+
*Scrum Overview: Agile Software Development. Retrieved October 02, 2017, from https://www.mountaingoatsoftware.com/agile/scrum/resources/overview
<references/>
+
It focuses on both the historical aspect of agile’s development, as well as, on the framework scrum. It puts forward a collective description of the most common words associated with agile and scrum.  
 
+
 
+
 
+
== '''Annotated Bibliography''' ==
+
 
+
*Winch, G. M. (2010). Managing Construction Projects. Iowa: Blackwell Publishing Ltd.
+
 
+
Provides a focused perspective on the role of people involved in construction, especially on project management. One of its approaches is the quality of conformance to requirements, not only product related but also process related. To reach this conformance, quality management systems are used, thus Winch explains further and in detail the different systems that exist. It also provides some Case Studies where the theory is made clear by using real-life examples.  
+
 
+
*Arthur, B. (2017). The Difference between Quality Assurance and Quality Control. Retrieved from https://www.dialog.com.au/open-dialog/the-difference-between-quality-assurance-and-quality-control/
+
 
+
Describes the characteristics of Quality Assurance and Quality Control, and explains the connection and differences between both. They are considered to be strategies applied at different stages of the project, and Arthur describes this in a very clear way. It also discusses the benefits of applying these strategies at the right moment.
+
 
+
*LEED, U. G. (2017). Leadership in Energy and Environmental Design. Retrieved from http://leed.usgbc.org/leed.html
+
 
+
Shows a very detailed overview of the LEED Certification, including its meaning, the reasons to and benefits from choosing LEED, the people that should be involved in the project, categories, steps to follow and more. It serves as a good introduction to the certification and further information can be found in the different sections of type of certified buildings.
+
 
+
*IWBI. (2017). The WELL Certification Guidebook. New York
+
 
+
Guides the user through all the steps that are to be followed to get the WELL certification. It dives into the Project Team’s roles, the documentation requirements, performance verification and the final report. It allows the reader to have a clear picture of how to achieve the award and continue with the health engagement in the future.  
+
 
+
  
 
== '''References''' ==
 
== '''References''' ==
  
 
<references/>
 
<references/>
Among the systems of Quality Assurance to identify the procedures of quality management, the third-party ones have now been proven to be the best practice as they follow international standards such as ISO. These systems consist of independent parties that certify the quality of a building. Thus, many independent third parties such as LEED and WELL have emerged in the last 15 years. These certifications are based on [[Sustainability in Construction]] and aim to increase the number of sustainable buildings in the world.
 
 
LEED certification provides independent verification of a building or neighborhood’s green features, allowing for the design, construction, operation and maintenance of resource-efficient, high-performing, healthy, cost-effective buildings <ref name="LEED, 2017">LEED, U. G. (2017). Leadership in Energy and Environmental Design. Retrieved from http://leed.usgbc.org/leed.html</ref>.
 
 
On the other hand, WELL is a performance-based system for measuring, certifying, and monitoring features of the built environment that impact human health and wellbeing, through air, water, nourishment, light, fitness, comfort, and mind. <ref name="Knox, 2015">Knox, N. (2015). WELL Building Standard. U.S. Green Building Council. Retrieved from http://www.usgbc.org/articles/what-well</ref>.
 
 
[[File:Figure_1._Professional_System_Diagram.jpg|thumb|left|250px|Figure 1: Professional System Diagram <ref name="Winch, G. M. (2010)">Winch, G. M. (2010). Managing Construction Projects. Iowa: Blackwell Publishing Ltd.</ref>]]
 
 
 
 
 
 
 
{| class="wikitable"
 
|+ Table 1: WELL’s  Score Table <ref name="IWBI Standard (2017).">IWBI Standard. (2017).The WELL Building Standard. Retrieved from https://standard.wellcertified.com/</ref>
 
!''Concept''
 
!''Preconditions Applicable''
 
!''Preconditions Achieved''
 
!''Optimizations Achieved''
 
!''Optimizations Achieved''
 
!''Concept Scores''
 
|-
 
| Air
 
| 12
 
| 12
 
| 17
 
| 3
 
| 5
 
 
|-
 
| Water
 
| 5
 
| 5
 
| 3
 
| 0
 
| 5
 
 
|-
 
| Nourishment
 
| 8
 
| 8
 
| 7
 
| 6
 
| 9
 
 
|-
 
| Light
 
| 4
 
| 4
 
| 7
 
| 2
 
| 6
 
 
|-
 
| Fitness
 
| 2
 
| 2
 
| 6
 
| 3
 
| 7
 
 
|-
 
| Comfort
 
| 5
 
| 5
 
| 7
 
| 2
 
| 6
 
 
|-
 
| Mind
 
| 5
 
| 5
 
| 12
 
| 12
 
| 10
 
 
|-
 
| '''Total'''
 
| '''41'''
 
| '''41'''
 
| '''59'''
 
| '''29'''
 
| '''7'''
 
|}
 
 
 
  
Quality can be defined as “the degree to which a set of inherent characteristics fulfils requirements” <ref name="Winch, G. M. (2010)">Winch, G. M. (2010). Managing Construction Projects. Iowa: Blackwell Publishing Ltd.</ref>. One of the objectives of the Quality Management Systems is to make clear that non-conformance in a product is somebody’s fault. Thus, workers are encouraged, reward-based, to take responsibility when achieving high quality.
+
[[Category:Project Management]][[Category:Agile Project Management‏‎]]
There are four main basic approaches to make sure that high quality has been reached and these act as a complement rather than as an alternative:
+
* ''Inspection'': physical check.
+
* ''Quality Control (QC)'': management control techniques.
+
* ''Quality Assurance (QA)'': externally accredited procedures.
+
* ''Total Quality Management'': continuous process improvement.
+

Latest revision as of 14:58, 9 November 2018

Developed by Sophie Emilie Smietana


Increasing the success rate for projects has been a priority for as long as projects have been around. Concurrently with projects in a corporate setting became more structured, so did the search for better project management strategies and methods. Agile methodology originally developed its popularity within the software development industry. Over the past 25 to 30 years the method helped the software and IT industry increase their productivity and success rate. The rugby metaphors surrounding agile have their origin in the manufacturing industry. [1]. Today, agile is no longer just for the software industry, it is now spreading rapidly to other fields and industries. Agile methodology can be seen as an umbrella term for several different frameworks, with all the sub-methods and frameworks adhering to the agile manifesto as well as the 12 principles. Agile methodology in project management focuses on incremental and continuous improvements. Flexibility in scope, team dynamics and inputs, as well as, producing quality results are essential to the foundation of the method. This article will look at how agile methodology gained its popularity, how to apply it in practice with focus on scrum, and what to be aware of when utilizing this method.

Contents

[edit] Big Idea

Today, most projects are everchanging, thus flexibility in the development process is of still higher importance. Agile helps foster managing of projects, programs, and portfolios in a flexible and collaborative way. It permits fast changes and pivots if need be. One of the perhaps most used frameworks within agile is scrum. Scrum is a rigid way of organizing the management of project, programs, and portfolios, while still allowing for great flexibility in the development of new products and services. The usage of scrum naturally grew within the software development industry. Software development requires almost endless iterations, which is one of the reasons why agile is a perfect match. The diffusion of agile into other industries during the past 25 to 30 years is due to its success in the software industry and the lack of room for failed projects in other industries. [2]. Even though the overall principles of agile are firmly defined, the execution of applying the method within companies has many shapes. This is both a result of project managers adapting the method to fit their way of running project, but perhaps more often due to confusion as to what exactly agile covers. This is understandable as even the literature does not always agree. E.g. lean is mostly considered its own methodology, however, occasionally it is thought to be one of the frameworks under the umbrella term, agile.


Mark Shead - What is Agile?

But why is agile gaining popularity amongst project managers especially? Nine of the main reasons are highlighted below.

  • Faster feedback cycle
  • Constant change
  • Problems are identified early
  • Flexible prioritization
  • High potential for customer satisfaction
  • Benefits of your labor is recognized sooner
  • Free commitment and accountability measurement
  • No Need to Waste Time Creating and Adjusting Detailed Project Plans
  • It Gives Your Team Purpose [3]

When working on a project level you are more concerned with day-to-day changes than if you are working on managing entire portfolios, where focus often will be more on the long-term basis. You are in contact with your team on a daily basis as a project manager, and you fix potential problems sooner. This all ads to project managers being more prone to go agile compared to program or portfolio managers.

[edit] Application

Although agile methodology is generally viewed as one methodology it consists of multiple practical approaches or sub-methods. Focus will be on the application of the framework called scrum, mainly in a project management setting. In practice, the execution of agile in projects is done by diving projects into smaller parts, known as sprints. A sprint-period typically lasts from 1 to 4 weeks. During each sprint, daily scrum meetings are held. In figure 1 an overview of the scrum can be seen. [4]

Figure 1 – Scrum overview[4]

[edit] Agile Vocabulary

The agile methodology based its terminology on rugby expressions, using words such as scrum. It consists of several different terms and expression, however, some of the most common ones are mentioned and explained below.

Product Owner The product owner is an extension of the customers. The product owner is responsible for the product backlog and have authority to change the product along the way. The product owner will typically be from the product management or marketing department, but can also be one of the key stakeholders or key users of the product.

Team or Scrum Team The team usually contain between five and nine team members. There can be hundreds of scrum teams and scrum projects within large corporations. However, it is also possible to have a scrum ‘team’ consisting of only one person. The scrum teams are the backbone of the development and execution of the project. The team can be diverse, coming from several different departments, or it can be a focused team, e.g. only software developers. The preferred combination will depend on the situation at hand. However, when utilizing scrum, the team members collectively agree on a set of tasks to be completed within the next sprint. This enforce the team feeling, due to reaching the tasks are a common goal.

Product Backlog The product backlog is an overview of all the tasks regarding the desired features or changes to the product that is left to be done. It is important that the backlog is up to date and prioritized at all times. The product backlog will be prioritized according to what the team, scrum master, and especially the product owner wants done first.

Sprint Backlog Meeting or Sprint Planning Meeting In order to plan the coming sprint a meeting is held at the beginning of each sprint. The product owner will present the items from the product backlog with the highest priority. The scrum team will then select the number of tasks they can realistically finish before the start of the next sprint. The next process is to move the items from the product backlog into a sprint backlog.

Sprint Backlog The sprint backlog is similar to the product backlog. However, the sprint backlog is only concerned with what the team is supposed to work on during the current sprint. It is also more detailed than the backlog.

Scrum Master The scrum master is the voice of the team. He is the protector of the team and his job is to keep the team as productive as possible by helping where needed and by removing obstacles standing in the way for the team’s productivity. The scrum master will also assist the team members in using the scrum process.

Sprints Sprints are typically 1 to 4 weeks periods. During the sprint, the team works on solving the problems in the sprint backlog.

Scrum Scrums are 24-hour periods. The team has daily scrum meetings where all team members answer the following three questions.

  • What did you accomplish since the last meeting?
  • What are you working on until next meeting?
  • What is getting in your way or keeping you from doing your job?

The questions are meant to help steer and guide the team members in the right direction and keep the project on track.

Sprint Retrospective and Sprint Review Meeting After every sprint period, a sprint retrospective is conducted. This allows the team to determine what was done right and what should be changed for future sprints. It is a way of acknowledging the individuals and the team’s efforts in an informal way. [4]


[edit] Limitations – and the Right Conditions for Agile

Agile presents some new opportunities for managing projects, programs, and portfolios. It is great for situations where the complexity is big, uncertainties are many, and the project is likely to change during the execution of the work. However, using agile may not be suitable in all situations. In table 1, favorable and unfavorable situations for different conditions can be seen.

Table 1: The Right Conditions For Agile [5]
Conditions Favorable Unfavorable
Market Environment Customer preferences and solution options change frequently. Market conditions are stable and predictable.
Customer Involvement Close collaboration and rapid feedback are feasible. Customers know better what they want as the process progresses. Requirements are clear at the outset and will remain stable. Customers are unavailable for constant collaboration.
Innovation Type Problems are complex, solutions are unknown, and the scope isn’t clearly defined. Product specifications may change. Creative breakthroughs and time to market are important. Cross-functional collaboration is vital. Similar work has been done before, and innovators believe the solutions are clear. Detailed specifications and work plans can be forecast with confidence and should be adhered to. Problems can be solved sequentially in functional silos.
Modularity of Work Incremental developments have value, and customers can use them.

Work can be broken into parts and conducted in rapid, iterative cycles. Late changes are manageable.

Customers cannot start testing parts of the product until everything is complete. Late changes are expensive or impossible.


Impact of Interim Mistakes They provide valuable learning. They may be catastrophic.

As can be seen in table 1, agile shows its full potential when change is big. As a result, it is not a suitable method for maintenance, since emphasis is not on documentation. Furthermore, there is a great dependency on user involvement, the success of the project will therefore be reliant on the user’s communication skills and willingness to be involved in the development process. The number of members in one team is also a big limitation. The team should seldom be less than three and no more than nine to keep a dynamic and flexible team. [6]

[edit] Annotated Bibliography

  • Takeuchi, D. K., Darrell K. Rigby Jeff Sutherland Hirotaka Takeuchi, Bradley Staats and David M. Upton, & Steven Spear H. Kent Bowen. (2017, March 21). Embracing Agile. Retrieved September 22, 2017, from https://hbr.org/2016/05/embracing-agile

Provides an overview of the basics of what agile encompasses as well why agile should be utilized more in project management. It has a focus on the types of environments which are favorable and unfavorable for using agile as the project management tool.

This site provides a short but easy to understand overview of some of the limitations which agile methodologies undoubtedly have.

It focuses on both the historical aspect of agile’s development, as well as, on the framework scrum. It puts forward a collective description of the most common words associated with agile and scrum.

[edit] References

  1. Takeuchi, I. N. (2016, June 08). The Big Idea: The Wise Leader. Retrieved October 01, 2017, from https://hbr.org/2011/05/the-big-idea-the-wise-leader
  2. Ulrich, K. T., & Eppinger, S. D. (2016). Product design and development. New York, NY: McGraw-Hill Education
  3. Editors, F. T. (2016, May 09). The Benefits Of Using Agile Software Development. Retrieved October 02, 2017, from https://www.forbes.com/sites/forbestechcouncil/2016/05/09/the-benefits-of-using-agile-software-development/3/#f42e1f29f836
  4. 4.0 4.1 4.2 Cohn, M. (n.d.) Scrum Overview: Agile Software Development. Retrieved October 02, 2017, from https://www.mountaingoatsoftware.com/agile/scrum/resources/overview
  5. Takeuchi, D. K., Darrell K. Rigby Jeff Sutherland Hirotaka Takeuchi, Bradley Staats and David M. Upton, & Steven Spear H. Kent Bowen. (2017, March 21). Embracing Agile. Retrieved September 22, 2017, from https://hbr.org/2016/05/embracing-agile
  6. [3]Limitations of Agile Methodologies - The Agile Methodologies. (n.d.). Retrieved October 02, 2017, from https://www.umsl.edu/~sauterv/analysis/Fall2013Papers/Buric/limitations-of-agile-methodologies-1.html
Personal tools
Namespaces

Variants
Actions
Navigation
Toolbox