Agile Project Management with SCRUM

Latest revision as of 18:06, 16 November 2018

Developed by Lorenz Sieferle

First agile project management (APM) methodologies were created and implemented in the early 1990s, especially for IT projects, mainly because 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 to 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 teams in the iterative and incremental delivery of a product. In the following article the overall scrum process is described with its roles, meetings and application. 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.

[edit] Big Idea

[edit] SCRUM Process

The scrum process consists out of four artifacts: product backlog, sprint backlog, different sprints and the final product.

The process begins with the product planning meeting, where the product backlog, which includes 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 previous 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 one or multiple new product functionalities, which can be introduced to the customer and brings the desired benefit. In fact, the customer is always up-to-date within the whole scrum process and can provide continuous feedback which is considered and implemented immediately 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. It might happen 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 to receive valuable feedback. The sprint process is a repetitive mechanism which last until all functionalities and tasks of the product backlog are implemented, and subsequently leads to the final product ^[5].

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

Figure 1: Overview of scrum process. Adapted from ^[5]

[edit] SCRUM Roles

Within APM using scrum there are three defined roles: the process owner, the 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 for the whole project including preparing and defining the product backlog, involving customers and users, initiating product launch and 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 the product management or marketing department but could also 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. The role is in charge of ensuring that the team uses scrum the right way ^[7] . Moreover, it is not advisable that one person is the scrum master and product owner at the same time ^[6].

The scrum team is a cross-functional and self-organizing team and consists usually of five to ten members ^[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 executes the actual value creation process and develops the product within the different project sprints ^[6].

[edit] 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 to 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 takes place before each new sprint for preparation purposes and defines sprint backlog. 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 is taking place ^[8]. Normally, the product owner and scrum master and the team participate in the sprint planning meeting. Furthermore, it is important that 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 each team member has to answer the following three questions to share information and inform the team on the current status:

• What am I 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 to 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 customers, if available. Its purpose is to discuss and review the finished sprint and clarify which points of the sprint backlog were achieved and which not ^[8].

[edit] Application

[edit] General recommendations

The scrum practice is preferably applicable in very complex projects that require a close synchronization of various activities as well as when different teams are 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, which means to allocate a fixed time period to each sprint, to ensure that the team has the goal always in mind. Furthermore, it is important to teach the team about the scrum theory and practices with its advantages so that the team gets an adequate knowledge and is fully convinced to use the scrum method for their project ^[5].

[edit] Successful application example

Service1st is a software development organization, which generate a new release of its software at least once every year. The last two months before each release the software developers have to spend a huge amount of over hours on evenings and weekends to complete the release on time. This is not only bad for the employees themselves, but also for the customers because of implemented bugs within the software caused by the high pace and pressure. Currently, at the beginning of each release the program managers defines with the marketing team the required new functionalities based on customer needs and create detailed work plans for the implementation. Changes within the work plans are handled through a formal change control process which takes time. The work plans are executed with the waterfall method which means that the development employees are assigned tasks by role. In fact, there are different roles for analyzing, designing, coding, testing and documenting which are executed by different persons. The problem is that the developers do not work efficiently in a team and only focus on their own tasks which results in people having to wait for others to complete their assigned tasks first. This leads to everyone is feeling isolated from reality within the first three months and after that, they try to make up what they could not achieve before. To improve the situation, the team needs more specific guidance and clear instructions what to do. This can be achieved by applying the APM scrum approach. The sprint planning meeting achieves that the team focus on its efforts and divide the overall release in smaller workflow functionalities as well as prioritize them. The team gets excited as the have a short time frame with 30 day sprint and a limited amount of product functionalities to develop. In addition, the team is able to taste their own success within a short period of time and does not have to wait until the release is executed to feel their accomplishment. By focusing on the product functionality the team makes progress step by step to the final release. Moreover, it minimizes the bugs within the software release because each increment is tested after it is developed and during the sprint review meeting, it is reviewed and inspected accurately ^[5].

[edit] 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 e.g. product marketer, product manager as well as project manager. 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, the product owner, who is in charge of the whole project. This leads to an easier implementation of changes. In addition, within the old-school project management the product manager is not directly a part of the rest of the project development team but acts 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 the APM scrum methodology the project team receives customer feedback after each sprint, in an early stage and on a continuous basis ^[6].

[edit] 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 nine main advantages of using the APM with scrum approach for managing projects:

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

• React to changes instantly: Many projects especially in software development are permanently facing changes. The APM scrum methodology helps to adapt this changes rapidly and let them not disrupt the overall project.

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

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

• 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's needs.

• Perceive benefits of work sooner: After each sprint a new feature of functionality is developed, and a result and the benefit can be directly observed.

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

• Detailed project plans: Learning is part of the APM scrum method especially within the sprint review meeting. An iterative process management could be implemented easily which eliminates waste of time and therefore increases efficiency and effectiveness.

• Gives the team purpose: APM scrum gives the team purpose, split ownerships and common goals ^[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 consequently leads 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].

[edit] 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, small teams are preferred to stay 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, since the development process of the product with the APM scrum approach is very dynamic, it might happen 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 to 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.

[edit] Annotated bibliography

Schwaber, K., Agile project Management with SCRUM, Microsoft Press, 2004: The book nicely elaborates the overall Scrum process with its roles, flows and artifacts. In addition Schwaber states three different application examples from his own experience and gives recommendation for a successful application.

Pichler, R., Agile Product Management with Scrum: Creating Products that Customers Love (Addison-Wesley Signature Series. Upper Saddle River, NJ: Addison-Wesley, 2010: The book explains the whole agile project management using Scrum approach from the product vision to the release. Pichler sets his focus on product owner role and describes this role in greater detail including best practices examples.

Project Management Institute, A Guide to the project Management Body of Knowledge, fifth Edition, 2013: The book describes all relevant topics and aspects of project Management in a general point of view. In Chapter 2.4.2.4 Adaptive Live Cycles it briefly introduces agile project management, explains the overall process and the preferred application.

[edit] 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 5.5 5.6} Schwaber, K., Agile Project Management with SCRUM, (Microsoft Press, 2004),
6. ↑ ^{6.0 6.1 6.2 6.3 6.4 6.5 6.6} 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),