Agile Project Management

(1)

e Engineering Agile Project

Management

(2)

Outline

•  A mountaineering example

•  Project context

•  Goals, client types

•  Environment, methods, tools, methodology

•  Different types of planning

•  Processes in software development

•  Defined process control model

•  Empirical process control model

•  Scrum

(3)

Key Decisions in an Expedition

•  A leader must answer several key

questions to create a successful expedition

•  What mountain should be climbed?

•  What types of tools should be used?

•  Who should be member of the team?

•  Does the expedition need a leader?

•  Different answers to these questions lead to different styles:

Fixed-rope

Siege style Free Solo Alpine style

(4)

Key Decisions in a Software Project

•  Project goals

•  Schedule

•  Cost

•  Project organization

•  Software life cycle model

•  Tools

•  Methods

•  Team members and organization

Influenced by Methodology

(5)

Methodology

•  Software engineering methodology (See Software Engineering I)

•  Collection of methods and tools for developing and

managing a software system to achieve a specific goal while change occurs

in a given project environment

•  Defined by the client and current state of the

development organization. Constrains the project manager (Example: Hierarchical or project-based organization)

A methodology specifies for a specific project environment 1) when methods or tools should be used and when not

2) what to do when unexpected events occur.

(6)

Project Environment

•  Participants’ expertise

•  Beginner, expert, slow learner, fast learner

•  Type of Client

•  Domain knowledge, decision power

•  End user access

•  No end user available, end user participates in requirements elicitation, end user participates in usability tests

•  Technological climate (“technology enablers”)

•  Geographical distribution

•  Project duration

•  Rate of change

(7)

Client Type

No Client Proxy Client

Low

Pseudo Client Local King Client

High

Low High

Domain Knowledge

Decision Power

(8)

End User Access

•  Clients and end users usually do not have the same interests

•  Clients are interested in

•  an early delivery date

•  as much functionality as possible

•  low cost

•  End users are interested in

•  a familiar user interface

•  an easy to learn user interface

•  a system that supports their specific task well

•  If the project success depends on the usability of the product, then

•  end users should be included in the project

(9)

Project Environment

•  Participants’ expertise

•  Beginner, expert, slow learner, fast learner

•  Type of Client

•  Domain knowledge, decision power

•  End user access

•  No end user available, end user participates in requirements elicitation, end user participates in usability tests

•  Technological climate (“technology enablers”)

•  Geographical distribution

•  Project duration

•  Rate of change

(10)

Technological climate

•  Depending on the requirements expressed by the client, a project may be constrained in the technological components it has to use.

Examples:

•  A project needs to improve a legacy system

•  It deals with well-known and mature technology but the technology might be out of date

•  A project develops a first-of-a-kind prototype

•  based on a new technology enabler

•  Examples: RFID, GPS

•  Usually has to deal with preliminary versions of components and immature technology

•  GPS in a mobile phone

(11)

Geographical Distribution

•  “Single room” projects: Participants in a single room

•  Reasons for distributed projects:

•  Organization may have resulted from the merger

•  Organization is a consortium, located in different geographical locations

•  Part of the organization must be collocated with client

•  Geographical distribution has advantages and disadvantages:

  Promise of low cost labor

  Increases the availability of skill

  May take advantage of different time zones

  Slows down communication and decision making

  Lowers awareness among teams

  Leads to loss of information between sites

(12)

Methodology Issues

•  Methodologies provide general principles and strategies for selecting methods and tools in a given project environment

•  Key questions for which methodologies provide guidance:

•  How much involvement of the customer?

•  How much planning?

•  How much reuse?

•  How much modeling before coding?

•  How much process?

•  How much control and monitoring?

(13)

How much Planning does a Project Manager need?

•  Two styles of navigation [Gladwin 1964]

•  European navigation:

•  Current Location and Desired Location

•  Planned Route

•  Route Deviation and Route Correction

•  “Polynesian navigation”

(14)

“European Navigation” (Plan-based)

Event: Course deviation.

Auckland

(Desired Location)

Lima

(Current Location) Planned Route

Actual Route

Action: Course correction

(15)

Pros and Cons of Plan-based Thinking

•  Plus

•  Very useful to kick off a software project

•  Useful also if the outcome is predictable or if no major change occurs

•  Con:

•  Of limited value to control the project when

•  the outcome is unpredictable

•  when unexpected events occur that change the project environment, tools or methods

•  Examples of unexpected events:

•  Appearance of new technology unknown at project start

•  A visionary scenario turns out to be unimplementable

•  Company is merged with another one during the project.

(16)

Polynesian Navigation (Situation-based)

Event: “Birds seen”

Lima

(Current location)

“We need a new place for living.

Let’s go to Auckland”

Tahiti

(Empty island, great place for Living)

Action: “Follow the birds”

(17)

Situated action

•  Context-dependent action [Suchman 1990 xxx]

•  Selection of action depends on the type of event, the situation and the skill of the developer

•  European Navigation is context independent

•  Event: “Course deviation in the morning”

•  Action: “Course correction towards planned route”

•  Event: “Course deviation in the evening”

•  Action: “Course correction towards planned route”

•  Polynesian Navigation is context dependent

•  Event: “Birds seen”, Context: Morning

•  Action: “Sail opposite to the direction of the birds

•  Event: “Birds seen”, Context: Evening

•  Action: “Sail in the direction of the birds”.

(18)

Pros and Cons of Situation-based Planning

•  Pro:

•  Very useful when the outcome is unpredictable

•  Small effort during the planning phase

•  Fast reaction to changes in the requirements

•  Risks are minimized by short iterations

•  Con:

•  Real-time communication (preferable face-to-face) produces very little written documentation

•  Key project knowledge is only in the heads of a few people

(19)

Methodology Issues

•  Methodologies provide guidance, general

principles and strategies for selecting methods and tools in a given project environment.

•  Key questions for which methodologies provide guidance:

•  How much involvement of the customer

 How much planning?

•  How much reuse?

 How much modeling?

•  How much process?

•  How much control and monitoring?

(20)

Problems with linear Models

Requirements

Process

System

Allocation

Process

Concept

Exploration

Process

Design

Process

Implementation

Process

Installation

Process

Operation &

Support Process

Verification

& Validation

Process

Each edge describes 2 types of dependencies - Temporal dependency:

„must be finished before“

- Logical dependency:

„The API depends on the subsystem decomposition“

(21)

The Waterfall Model is a Dinosaur Waterfall Modell

Requirements

Process

System

Allocation

Process

Concept

Exploration

Process

Design

Process

Implementation

Process

Installation

Process

Operation &

Support Process

Verification

& Validation

Process

Each edge describes 2 types of dependencies

•  Temporal dependency:

„must be finished before“

•  Logical dependency

„The API depends on the subsystem decomposition“

(22)

red yellow

green blue

red blue yellow

green

blue

(23)

red yellow

green blue

red blue yellow

green

blue

(24)

Controlling Software Development

How do we control software development? Two opinions:

•  Through organizational maturity (Watts Humphrey)

•  Defined process, Capability Maturity Model (CMM)

•  Through agility (Ken Schwaber)

•  Large parts of software development is empirical in nature;

they cannot be modeled with a defined process

•  There is a difference between defined and empirical process

•  Result: Two models

•  Defined process control model

•  Empirical process control model.

(25)

Example of a Defined Process Control Model: CMM

•  A software development process is mature

•  if the development activities are well defined and

•  if management has some control over the quality, budget and schedule of the project

•  Process maturity is described with

•  a set of maturity levels and

•  the associated measurements (metrics) to manage the process

•  Assumption:

•  With increasing maturity the risk of project failure decreases

•  CMM: Capability Maturity Model (Software

Engineering Institute, SEI, Watts Humphrey 1985)

(26)

CMM levels

•  Process maturity is described with a set of maturity levels and associated metrics to manage the process

•  Idea: With increasing maturity the risk of failure decreases.

1. Initial Level

also called ad hoc or chaotic

2. Repeatable Level

Process depends on individuals ("champions")

3. Defined Level

Process is institutionalized (sanctioned by management)

4. Managed Level

Activities are measured and provide feedback for resource allocation (process itself does not change)

5. Optimizing Level

(27)

Key Process Areas

•  To achieve a specific level of maturity, the organization must demonstrate that it

addresses the key process areas for that level:

•  There are no key process areas for Level 1

•  KPA Level 2: Basic software project

management practice (e.g SPMP 1058)

•  KPA Level 3: Infrastructure for single software life cycle model

•  KPA Level 4: Quantitative understanding of process and deliverables

•  KPA Level 5: Keep track of technology and

process changes.

(28)

Pros and Cons of Process Maturity

•  Benefits:

•  Increased control of projects

•  Predictability of project cost and schedule

•  Objective evaluations of changes in techniques, tools and methodologies

•  Predictability of the effect of a change on project cost or schedule

•  Problems:

•  Need to watch a lot (“Big brother“, „big sister“)

•  Overhead to capture, store and analyse the required information.

(29)

Example of a Empirical Process Control Model: Scrum

•  Original definition (from Rugby): A Scrum is a way to restart the game after an interruption,

•  The forwards of each side come together in a tight formation and struggle to gain possession of the ball when it is tossed in among them

•  Definition used in agile Project Management:

Scrum is a technique

•  To manage and control software and product

development with rapidly changing requirements

•  Based on improved communication and maximizing cooperation.

(30)

Why Scrum ?

Traditional methods

are like relay races Agile methods are

like rugby

(31)

Practicing a Scrum Real Scrums

(32)

Testudo:

Battle Formation used by the Romans

(33)

Scrum as Methodology

•  Involvement of the customer

•  Onsite customer

•  Planning

•  Checklists and incremental daily plans

•  Reuse

•  Checklists from previous projects

•  Modeling

•  Models may or may not be used

•  Process

•  Iterative, incremental process

•  Control and Monitoring

•  Daily meetings.

(34)

Overview of Scrum

Scrum  Master

Potentially shippable Product Increment

Daily Scrum meeting

(35)

Scrum is a special case of issue-based modeling

I1:Open

I2:Open I3:Open

SD.I1:Open

Imp.I1:Open

Sprint Backlog

Product Backlog

(36)

Components of Scrum

•  Scrum Roles

•  Scrum Master, Scrum Team, Product Owner

•  Scrum Activities

•  Sprint Planning Meeting

•  Kickoff Meeting

•  Sprint (~~ Iteration in a Unified Process)

•  Daily Scrum Meeting

•  Sprint Review Meeting

•  Scrum Artifacts

•  Product Backlog, Sprint Backlog

•  Burndown Charts

(37)

Managing a Software Project with Scrum

•  Two Lists

•  Project Backlog: Issues for the whole project

•  Sprint Backlog: Issues for one iteration(“sprint”)

•  Four Types of Meetings

•  Kickoff Meeting: At the beginning of a project

•  Sprint Planning Meeting: List of prioritized features

•  Daily Scrum: Informal status meeting, about 15 min

•  Sprint Review Meeting: Demonstration of features to management and customer

•  Two Activities to manage the Artifacts

•  Establish the Project Backlog: List of requirements from stakeholders (developers, manager and

customer)

•  Establish the Sprint Backlog: List of issues to be

(38)

Scrum Artifacts

•  Product Backlog

•  Sprint Backlog

•  Measuring project progress:

•  Burn down Charts

(39)

Product Backlog

•  Requirements for a system, expressed as a prioritized list of Backlog Items

•  Is managed and owned by a Product Owner

•  Spreadsheet (typically)

•  Usually created during the Project Kickoff Meeting

•  Can be changed and re-prioritized before each

Sprint.

(40)

Estimation of Product Backlog Items

•  Establishes team’s velocity (how much effort a Team can handle in one Sprint)

•  Units of complexity

•  Size-category: L, M, S (“T-Shirt size”)

•  Story points

•  Work days/work hours

•  Methods of estimation:

•  Expert Review

•  Creating a Work Breakdown Structure (WBS)

•  Planning Poker (next week)

(41)

Sprint Backlog

•  A subset of Product Backlog Items, which defines the work to be done in a Sprint

•  Is created ONLY by Team members

•  Each item has it’s own status

•  Should be updated every day.

(42)

Sprint Backlog

•  No more then 300 tasks in the list

•  If a task requires more than 16 hours, it should be broken down

•  Team can add or subtract items from the list

•  Product owner is not allowed to do it.

(43)

Measuring Progress In Scrum

•  The Scrum master is concerned about

•  Sprint progress: How is the team doing toward meeting their Sprint goal?

•  Release progress: Will the release be on time with the quality and functionality desired?

•  Product progress: Are we in time for delivering the product?

•  Visualisation of product development progress in a graphical curve

•  3 types of Visualisations

•  Sprint progress: Sprint burn down chart

•  Release progres: Release burn down chart

•  Product progress: Product burn down chart

(44)

Burn Down Charts

•  A burn down chart shows for the remaining estimated amount of work at a given point in time

•  The project end date can be determined by a trend-line through the curve

•  Deviations from the original project end date can thus be recognized and dealt with (improved risk

management).

 X-axis: Time (in days)

 Y-axis: Remaining effort (in hours)

(45)

Advantage of Burn Down Charts

•  Addresses the issue that many unexpected changes occur during project time

•  Minimal effort to create the curve and keep it up-to-date

•  Even less effort to look at it.

(46)

Sprint Burn Down Chart

•  Shows on a daily basis the remaining hours needed to finish the tasks in the sprint backlog

•  The remaining hours are based on estimates established during the spring planning meeting and revised during the daily scrum meeting

•  Ideally the curve should be monotonically decreasing and cross the x-axis at the end of the sprint

•  In reality, it is not at always decreasing

•  The curve slope can even go back up.

(47)

Release Burn Down Chart

•  Visualizes the progress towards a release

•  X-axis: Sprints

•  Y-axis: hours needed for the release

•  Answers the project management question:

•  Can the release take place at the planned milestone?

(48)

Product Burn Down Chart

•  The “big picture” view of project’s progress

•  Created at the end of a sprint in the sprint review meeting

•  Helps in the decision whether items should be removed from the product backlog to keep the original deadline.

Each column shows the estimates for the work needed

for the items in the product backlog, i.e., the speed

of the teams emptying the product backlog.

(49)

Additional Readings

•  Watts Humphrey

•  Managing the Software Process, Addison Wesley, 1989

•  A Discipline for Software Engineering, Addison Wesley, 1995

•  Introduction to the Personal Software Process, Addison Wesley, 1997

•  Introduction to the Team Software Process, Addison Wesley, 2000

•  Ken Schwaber and Mike Beedle

•  Agile Software Development with Scrum, Prentice Hall, 2002

•  Mike Cohen

•  Agile Estimation and Planning, Prentice Hall, 2005.

(50)

Summary

•  Traditional software project management focuses on the maturity of a development process

•  can be assessed using a process maturity model, such as the SEI’s CMMI.