Usin

g U

ML,

Pat

tern

s, an

d Ja

va

Obj

ect-O

rien

ted

Softw

are

Engi

neer

ing 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

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 •  usability tests should be conducted with the end users.

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   High communication cost.

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 Process allows feedback of information to change process itself

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

Adaptiert von http://codebetter.com/blogs/darrell.norton/articles/50339.aspx

ScrumMaster

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 addressed in current iteration

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?

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.

Quelle: http://www.scrumforteamsystem.com/ProcessGuidance/Images/product_burndown.html

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.

•  Agile project management focuses on •  Empirical process control model •  Changing requirements are the norm •  Controlling conflicting interests and needs •  Very simple process with clearly defined rules •  Self-organizing teams, where each team member

carries a lot of responsibility •  No extensive documentation

•  Possibility for “undisciplined hacking”.