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. . 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.
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. . 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.
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 
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.
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. 
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. 
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.
|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. 
- 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.
- 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.
- Scrum Overview: Agile Software Development. Retrieved October 02, 2017, from https://www.mountaingoatsoftware.com/agile/scrum/resources/overview
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.
- ↑ 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
- ↑ Ulrich, K. T., & Eppinger, S. D. (2016). Product design and development. New York, NY: McGraw-Hill Education
- ↑ 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.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
- ↑ 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
- ↑ 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