Agile Project Management with SCRUM

Revision as of 15:52, 14 February 2018

First agile project management (APM) methodologies were created and implemented in the early 1990s, especially for IT projects, mainly cause of the fast-changing project environment. In the manifesto of agile software development, the following key values for APM are defined: " Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan"^[1].

The overall goal is to reduce complexity in the development of projects, to support a quick implementation in an inexpensive and high-quality way according the customer needs. Furthermore, a key characteristic of APM is the high level of responsiveness to changes as well as continuous Stakeholder involvements over the whole project duration ^[2]. The SCRUM agile project management approach is the dominant methodology used in the practical context and was introduced by Nonaka and Takeuchi in their "new product development Game" ^[3]. It is designed to guide team in the iterative and incremental delivery of a product. In the following article the overall SCRUM process is described with its roles, meetings and rules. In addition, a comparison between the traditional "old-school" project management approach and APM Scrum is executed and the benefits as well as limitations of the SCRUM methodology are discovered and critically analyzed.

Big Idea

SCRUM Process

The Scrum process consists out of four artefacts: product backlog, spring backlog, different sprints and the final product.

The process begins with the product planning meeting, where the product backlog, which include all functionalities and requirements for the product or system as well as the different tasks which have to be executed in order to get the final product, is defined. As the Scrum approach is an agile project management methodology the product backlog is dynamic and never completed and therefore just a rough estimation, which always could be changed during the whole project. Moreover, the Product Backlog prioritizes the different requirements according to their value creation ^[2]. In general, the product backlog could be compared with a traditional specification sheet ^[4]. The whole project is divided in different cycles, so-called sprints, where the actual work is done ^[5]. Within the sprint planning meeting the sprint backlog is defined ^[6]. Therefore, as many of the tasks of the before defined Product backlog are transferred to the sprint backlog as the team believe it can turn in to potentially product functionalities at the end of the sprint. The target of each sprint is to create a new product functionality, which can be introduced to the customer and brings the desired benefit. Therefore, the customer is always up-to-date within the whole scrum process and provides continuous feedback which is considered and implemented in the sprints ^[2]. Normally one task within the sprint backlog does not take longer than 4 to 16 hours. In case a task last longer, it is not well defined. Furthermore, it is important that the sprint backlog is updated on a regular basis. In fact, it might be that the team add or remove assigned tasks from the sprint backlog in order to avoid redundancies. At the end of each sprint a sprint review meeting with the customer and all project stakeholders takes place to discuss the achieved functionality and receive valuable feedback. The sprint process is a repetitive process and last as long until all functionalities and task of the product backlog are implemented and then lead to the final product ^[5].

Figure 1 below gives an overview of the complete Scrum Process with its different meetings and artefacts.

SCRUM Roles

Within APM using Scrum there are three defined roles: the process owner, Scrum Master as well as the Scrum Team.

Ken Schwaber defines the product owner role in his book Agile Project Management with Scrum as following: "The Product Owner is the one and only person responsible for managing the Product Backlog and ensuring the value of the work the team performs. This person maintains the Product Backlog and ensures that it is visible to everyone" ^[5]. The product owner has the overall responsibility of the whole project including preparing and defining the product backlog, involving customers and users, initiating product launch, attending scrum meetings ^[6]. In general, the product owner acts as an extension of the customer and represents the customer needs and is usually a person from product management or marketing department but also could be the user of the product itself or a key stakeholder of the project.

The Scrum Master has to ensure that the team is working efficiently and eliminate problems and obstacles in order to create an optimal working environment for the team. Therefore, the Scrum Master's key function and main responsibility is the coordination of meetings and processes for the whole project. In fact, the role is in charge of how has to be done and using Scrum in the right way ^[7] . Moreover, it is not advisable that one person is scrum master and product owner the same time ^[6].

The Scrum team is a cross-functional and self-organizing team and consists usually out of five to ten persons 
^[4]
. It is accountable for the implementation of the requirements in terms of product functionalities which have been defined by the product owner in the product backlog. In fact, the team perform the actual value creation process and develop the product within the different project sprints ^[6].

SCRUM Meetings

During the whole Scrum process usually four different kind of meetings take place: Product planning meeting, sprint planning meeting before each sprint, Daily Scrum and the review and retrospective meeting after each sprint.

During the product planning meeting the vision including product features and requirements are defined as well as prioritized according their importance towards customer. All requirements, features and functionalities are included in the product backlog, which is formulated within this meeting. The sprint planning meeting defines sprint backlog and takes place before each new sprint for preparation purposes. The sprint backlog has to be updated on a regular basis as there might occur changes during the sprint phase. In order to define the sprint backlog, the product backlog is reviewed, the sprint goal defined and a commitment of the team to the defined sprint takes place ^[8]. Normally, the product owner and Scrum Master and the team participate the sprint planning meeting. Furthermore, it is important the product owner has prepared the product Backlog prior to this meeting. For the daily Scrum meeting the whole Scrum team meets every day for approximately 15 minutes (fixed time). Within the meeting every team member has to answer the following three questions to share information and inform the team on the current status - What I am going to do today? - What did I do yesterday? - Are there any obstacles or problems to clarify?

If possible, the product owner should attend the meeting to understand the progress being made and answer questions to prevent problems and obstacles and clarify them accordingly ^[6]. Within the review and retrospective meeting, a prototype or demo with the developed features during the last sprint is presented to all members of the SCRUM team as well as customer if available. Its purpose is to discuss and review the finished sprint and clarify what of the sprint backlog was achieved accordingly and what is maybe missing ^[8].

Application

The Scrum practice is preferably applicable in very complex projects that require a close synchronization of various activities as well as if different teams working together to produce a product in a short time frame. In fact, the Scrum practices can be easily adapted to manage even the most complex projects within a rapidly changing environment, where requirements and functionalities are not clearly defined in advance ^[2]. By applying Scrum, the upcoming confusion within complex projects are reduced by implementing the time-box principle just, what means to allocate a fixed time period to each sprint, to ensure that the team has the goal always in their mind. Furthermore, it is important to teach the team the scrum theory and practices with its advantages and benefits that the team gets an adequate knowledge and is fully convinced to use the Scrum method for their project ^[5].

Comparison between 'old-school' and agile scrum project management

There are several key differences between the traditional 'old-school' project management approach and the modern APM using SCRUM. The main differences are stated in table 1 below.

First of all, within the traditional project management several different roles are involved in the process of bringing a product to life. In fact, the responsibility is split among different persons which reduces the flexibility of a great amount. In contrast, the APM Scrum methodology identifies one person which is the product owner and there in charge of the whole project which leads to an easier implementation of changes. In addition, within old-school project management the product manager is not directly a part of the rest of the project development team and act more in an isolated and detached manner. On the other hand, within the APM Scrum method the product owner works directly together with the Scrum master and is part of the Scrum team. Besides, the product or project in traditional project management is pre-defined permanently in a very early stage and there is no room for changes during the upcoming development process. On the contrary, APM with Scrum is an agile and dynamic process where changes based on customer feedback can be easily implemented during all project stages. Furthermore, the customer feedback in the traditional project management approach is received and taken in consideration after the product is developed and already launched. In fact, the customer feedback is not taken in account at all. However, within APM Scrum methodology the project team receives customer feedback after each sprint, and therefore in an early stage and on a continuous basis ^[6].

Benefits

The APM using Scrum approach enables companies to manage complex projects, program and portfolios, where the scope, requirements and product specifications might change during the development process. The famous economy magazine Forbes states in their article the benefits of using agile software development nine main benefits of using the APM approach for managing projects:

1. Faster feedback cycle: due to the breakdown to sprints approach there is a fast feedback cycle of the customer as a review meeting after each sprint is taking place. This leads to an improvement of the overall team performance and makes the work more comfortable.

2. React to changes instantly: during a project especially in software development is permanently facing changes. The APM Scrum methodology helps to adapt this change rapidly and let them not disrupt the overall project

3. Recognize problems in an early stage: through to the daily scrum meetings, problems and obstacles are recognized in an early stage and could be clarified directly.

4. Flexible Prioritization: The APM Scrum method is very flexible in prioritizing features desired by the customer.

5. High customer satisfaction: Due the close interaction with the customer at least at the end of the sprint the product is directly matching the customer needs.

6. Perceive benefits of work sooner: After each sprint a new feature of functionality is developed, and you see directly a result and the benefit.

7. Easy commitment and accountability measurement: due the intermediate seal in sprints the level of commitment and accountability is easily measurable.

8. Detailed project plans: learning is part of the APM Scrum method especially within the sprint review meeting. Therefore, an iterative process management could be implemented easily which eliminates waste of time and therefore increases efficiency and effectiveness.

9. Responsibility is split among the team: APM Scrum gives the team purpose and split ownerships and goals among the whole team ^[9] .

In addition, due to the continuous meetings, especially, the daily scrum, information on status and progress of projects are better accessible for all team members. Therefore, disagreements, obstacles and problems within the team are directly brought to the surface which leads as a consequence to a better team climate and working environment. In general, using the APM scrum approach leads to higher productivity and lower costs as well an improved employee engagement and job satisfaction ^[7].

Limitations

First of all, the APM Scrum methodology presuppose a high degree of dedication and engagement of the project team as all project members and stakeholders have to put in an extraordinary effort throughout the whole development process. Depending on the type of project the team members record a huge amount of overtime. In fact, the success of a project working with APM Scrum is highly dependent on the cohesiveness of the team and their commitment to the Scrum practice. Another limitation is the huge coordination effort which is required for growing teams. In general, within APM Scrum small teams are preferred to keep it dynamic and agile. Similar to the problems with growing teams, APM Scrum is difficult to apply for larger projects for example in the aerospace industry ^[5]. Furthermore, estimations in terms of time and costs of the projects difficult due to dynamic approach and changes on a continuous basis. Moreover, the success of APM using Scrum highly depends on the structure of the organization who uses it. For organizations with a more traditional structure with strong hierarchies, the APM Scrum idea of self-organizing team is difficult or rather not applicable. In addition, as the with APM Scrum the development process of the product is very dynamic, it might be that the customer or other project management stakeholders will keep demanding for new functionalities and it is therefore difficult to provide detailed cost estimations as well as find an end of the project. Lastly, If the market conditions and project characteristics are anchored and predictable it is not necessary to use the APM Scrum approach as there is no necessity for an agile approach.

Annotated bibliography

References

1. ↑ Manifesto for Agile Software Development, Agilemanifesto.org , (Accessed on 6th of February),
2. ↑ ^{2.0 2.1 2.2 2.3} Project Management Institute, A Guide to Project Management Body of Knowledge, (Project Management Institute, 2013),
3. ↑ Takuchi, H. & Nonaka I., The new product development game, (Harvard Business Review, 1986),
4. ↑ ^{4.0 4.1} Sobiech, F., Abbildung von Synergiepotenzialen zwischen IT-Anforderungen in Scrum, (Springer Fachmedien Wiesbaden GmbH, 2016),
5. ↑ ^{5.0 5.1 5.2 5.3 5.4} Schwaber, K., Agile Project Management with SCRUM, (Microsoft Press, 2004),
6. ↑ ^{6.0 6.1 6.2 6.3 6.4 6.5} Pichler, R., Agile Project Management with SCRUM: Creating Products that Customers Love', (Addison-Wesley, 2010)
7. ↑ ^{7.0 7.1} Cohn, M., Succeeding with agile - Software development using Scrum, (Addison-Wesley, 2010),
8. ↑ ^{8.0 8.1} Sliger, M., Agile project management with Scrum, (Paper presented at PMI Global Congress 2011 - North America, Dallas, Project Management Institute, 2011),
9. ↑ Forbes Magazine., https://www.forbes.com/sites/forbestechcouncil/2016/05/09/the-benefits-of-using-agile-software-development/2/#32ded1d664c6, (Accesses on 12th of February 2018),