Agile project management in IT development projects with a focus on team performance

Table of Contents

List of Graphics

List of abbreviations

Management Summary

1 Introduction
1.1 Motivation
1.2 Overview
1.3 Intention

2 Agile project management
2.1 Basic concepts
2.2 History
2.3 Principles behind agile methods

3 Scrum: An agile development process
3.1 Overview
3.2 Roles
3.2.1 Product Owner
3.2.2 Team
3.2.3 Scrum Master
3.2.4 Project manager in SCRUM
3.3 Ceremonies and Artifacts
3.4 Examples

4 Perspective: Potential of SCRUM

5 Bibliography

List of Graphics

Figure 3-1: SCRUM overview

Figure 3-2: SCRUM elements

Figure 3-3: Team process

Figure 3-4: Project manager in SCRUM

Figure 3-5: Ceremonies and artifacts in SCRUM

Figure 3-6: Task note

Figure 3-7: Sprint Backlog

Figure 4-1: Fulfillment of project goals

List of abbreviations

illustration not visible in this excerpt

Management Summary

Traditional, inflexible management is inefficient in product development projects: Project members feel uncomfortable and the result does not meet customer's expectation. Therefore project management needs a kind of reorientation. The key success factors are the performance of the project team and the understanding of the customers' needs. Therefore the main goal of today's project management is to create the right environment for the project.

Agile project management promises to be a solution: It supports team performance and demands short project cycles. Short iteration and continuous feedback of the customers helps to stay on the right way and to adjust requirements if possible.

A popular example of agile project management is SCRUM. This study paper gives an overview about SCRUM itself. It presents roles, ceremonies and artifacts. It shows that SCRUM centers the team and the whole process is build around the team. The rules of SCRUM are simple and can easily be adapted. The focus of this paper is the roles of the process and how SCRUM supports team performance.

1 Introduction

1.1 Motivation

The results of current IT development projects are deflating: According to the Chaos Report¹ 18% of these projects end without any result; 53% exceed time and/or budget. In order to enhance these figures, people try to implement "better" project management in IT projects and to standardize projects with process model frameworks like the German "V-Modell XT" or IBM's RUP. People try to enhance the development process like any others business process: getting the knowledge from the people in the process! In many cases developers in such projects are discouraged because of the huge amount of formalism generated by the process model.

Why development projects - especially in the IT - are different? These projects are driven by innovation and creativity. The requirements are not clear at the beginning and it is nearly impossible to cover every detail in a functional specification. The team members in these projects are in general well educated and motivated.

How can we control this creative chaos? The goal is to give the project a frame: To help the team members in their daily work, to track progress and to generate value for the customer. At the same time we have to foster the creativity and individuality of every team member.

The goal in today's IT development projects management is to coach the team to generate value for your customer. To satisfy all stakeholders we need a continuous dialog between the customer and the project team.

SCRUM is an agile management framework for IT development projects. It defines a bunch of rules to structure the development process without generating too much formalism.

1.2 Overview

This paper gives a brief overview about SCRUM itself. First of all it defines the idea behind agile project management. The next part presents the rules and project cycles in SCRUM. It focuses especially the different roles in a SCRUM project; artifacts and ceremonies are just shortly described.

The last chapter gives you an idea of using SCRUM in real projects.

1.3 Intention

The intention of this paper is to give a brief overview about agile process frameworks using the example of SCRUM. It also describes the importance of team performance for the success of development projects.

2 Agile project management 2.1 Basic concepts

In order to discuss about agile project management we need to define some basic concepts of modern IT development and project management. These definitions based on (Rupp 2007):

Incremental development

The development of the whole system is split in parts. These parts are based on each other. The opposite is the complete development of the system at one point in time (for example through the integration of all modules at one go).

Iterative development

In iterative development steps are repeated in predefined intervals. For example requirements engineering is part of every project cycle. Experiences of one iteration can be analyzed and foster the next iteration. Iterative und incremental development is often combined. Both strategies help us to reduce complexity, minimize risks early and generate faster feedback.

Agile respectively adaptive development

Agile respectively adaptive development means to continuous match your action to the current environment. On the one hand this relates to the handling of risks and chances, on the other hand it applies to the handling of changing requirements. New requirements are not held back, but they influence the current plan.

Light- und heavyweight process models

Lightweight process models reduce the effort for formalism in project management. They define less rules and concentrate on the software development itself. Heavyweight process models define a huge amount of roles and artifacts. The effort for documentation is higher in heavyweight process models.

2.2 History

According to (Wikipedia 2008) agile software development first encountered in the early 1990s as a counterpart to heavyweight process models. The idea was to be more flexible than former process models like the waterfall model of development. The idea of agile software development gained popularity with the publication of Kent Beck's first book about Extreme Programming (short XP). XP introduces some very radical techniques for software development like pair programming or test driven development. It mainly describes techniques for software development; so it does not cover project management too much. Later popular process management frameworks like the Rational Unified Process adapted the ideas of agility. These management frameworks also cover aspects of the project management. The fundamental ideas are written down in the agile manifesto (see 2.3)

The term SCRUM was mentioned at the first time in a paper about new product development processes in 1986 (Takeuchi und Nonaka 1986). The authors compared this new approach, in which the project phases strongly overlap and the whole process is performed by one cross-functional team, to rugby, where the whole team "tries to go to the distance as a unit, passing the ball back and forth". The case studies come from the automotive, photo machine, computer and printer industries (cf. (ScrumAlliance 2008)).

Ken Schwaber formalized the process and published the first paper on SCRUM at OOPSLA in 1995. Since then Ken Schwaber collaborated the following years with other professionals (Jett Sutherland, Mike Beedle; et al.) and published various books about agile project management with SCRUM.

At the same time SCRUM was enhanced by the SCRUM community and adapted by many companies inside and outside the IT branch (i.e. SAP or Allianz, cf. below). In this way SCRUM has become one of the leading agile development methodologies (cf. (Aiello 2008)).

2.3 Principles behind agile methods

In 2001 some popular sponsors of agile project management und software development summarized their ideas in a central document, the agile manifesto (cf. (Beck, et al. 2001):

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

The four basic ideas are written bold. They express the core intention behind agility. Agility is not just a bunch of new methodologies, but a different way of thinking. Therefore it is not possible to simply use agile techniques in a project; rather the project members have to life this philosophy.

SCRUM realizes these ideas with a few simple rules and a few project roles. The main focus in all agile process models lies on communication and collaboration. The main goal is to create an optimal environment for the project (team). Tom DeMarco and Timothy Lister reduced this issue to a simple sentence: "The major problems of our work are not so much technological as sociological in nature" (DeMarco und Lister, Peopleware 1999).

The next chapter describes how SCRUM can help us to master this challenge.

3 Scrum: An agile development process

The description of SCRUM mainly based on (Pichler 2008) and the website of the Scrum Alliance (ScrumAlliance 2008), a nonprofit organization committed to deliver articles, resources, courses and events that will help Scrum users be successful. Today Ken Schwaber is the president of this organization.

3.1 Overview

SCRUM just defines a few simple rules. Figure 3-1 shows an overview about the basic elements: The Product Backlog is the base and lists all requirements and work packages. The project is structured in short cycles with a length of 2-4 weeks called Sprints. At the beginning of every sprint the team defines in an initial meeting, the Sprint Planning, the workload for the current Sprint and transfer it to the Sprint Backlog. So the Sprint Backlog holds a prioritized list of customer requirements for the current iteration. The progress is tracked in the Burndown Chart. The team meets every day in the Daily Scrum and defines the agenda for the day. At the end of each sprint, a potentially shippable product is delivered.

illustration not visible in this excerpt

Figure 3-1: SCRUM overview

[...]

¹ Standish Group, „Chaos Report," (2004).