Software Engineering Process Economy & Quality

(1)

Lund University / Faculty of Engineering/ Department of Computer Science / Software Engineering Research Group

Project delivery: Progress report

The SPA

reports you

RECEIVED

Your actions

on received

feedback

Excel format

preferred

Lecture 4:

Agile PM – Paper 3, Ch 4.10-11, 4.13-15 [Hughes]

Monitor & Control - Ch 9 except 9.6 & 9.9, 12.4 [Hughes]

Software Engineering Process

– Economy & Quality

ETSF 01

http://cs.lth.se/etsf01

AGILE PROJECT MANAGEMENT

Ch 4.10-11, 4.13-15 [Hughes],

P4 (not DSDM parts):

Coram, Bohner,

“The Impact of Agile Methods on Software Project Management”,

Proc of 12

th

_{Int. Conf. and Workshops on the Engineering of}

Computer-Based Systems, 2005.

Agile…

• One name for many different methods

• Each implementation is unique

Today’s lecture: Scrum, XP and Kanban

Principle-Driven Approach

based on

Agile Manifesto

More valuable

• Individuals & interactions

• Working software

• Customer collaboration

• Responding to change

Valuable

• Processes

and tools

• Comprehensive documentation

• Contract negotiation

• Following a

plan

Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward

Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron

Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber,

Jeff Sutherland, Dave Thomas, The Agile Manifesto,

http://agilemanifesto.org/,

2001

Agile focuses on…

• Maximizing ROI - delivering business value

• Quickly delivering working code

• Expecting and managing changes

target

scope

lead time

cost /

effort

changes

(2)

Agile SPM

• Gradual detailing

• Work order

• Priority

• Just-in-time

• Self-governing teams

Level of detail at dev start

Traditional

project

Agile

project

ReqtsDesignImpl Testing

Reqts

Design

Impl

Testing

ReqtsDesignImpl Testing

• Same activities different sizing and sequence

• Agile principles and management are different

Traditional Development

Agile Development

+ a preparatory phase:

High-level reqts +

design!

Scrum Development

PRE-GAME

POST-GAME

Time boxing

• time-box fixed deadline by which something has

to be delivered

• typically two to six week iterations

• Develop the most prioritized stories first

Continuous Feedback & Transparency

Business, Management and Development roles

involved in

• Sprint planning meeting

• Daily stand-up meetings

• End-of-sprint demo

• Sprint retrospective meeting

Kanban:

No iterations, team pull

http://www.crisp.se/gratis-material-och-guider/kanban

• Max velocity – WIP (work in process) / state

(3)

Kanban boards

• Simplest version: columns for to-do, in progress, done

• Common: Backlog, Ready, Coding, Testing, Approval,

Done columns

• Used to

– visualize workflow

– limit work-in-progress

– pull work from column to column

– monitor, adapt, improve

XP Development

Customer approval

& release

Stories

Priorities

(strict)

Effort estimates

Analysis Design

_planning

Test

Testing

Pair programming, TDD

Continuous

review

Code base

Continuous

integration

Auto test

Feedback

Kent Beck, eXtreme Programming eXplained, Addison Wesley, 2000

Backlog

Agile (XP) Phases

Exploration

Planning:

Release +

per iteration

Development

(iterations)

Production-izing

Death

Maintenance

Kent Beck, eXtreme Programming eXplained, Ch 21, Addison Wesley, 2000

• HL reqts

• Business

prio

• Prototypng

• Effort

estimates

• Prio

backlog

• Estimate

• Capacity

Release

Maintce

Rel

Final

Rel

A

D

T P

T

Pair programming

TCs

Exploration

• Define high-level requirements

• Prioritize from business perspective

• Explore / prototype

Planning

• Prioritize user stories

• Backlog (scrum)

• Story cards, story board

• Re-estimate, for each sprint

• Select set of stories for iteration according to

capacity

Development in Scrum vs XP

Iterations aka sprints

Scrum

30 days prescribed, varies in reality

XP

1-4 weeks

Work in prio order

Scrum

team chooses stories in sprint planning

XP

team chooses stories strictly according to agreed prio

(set by product owner)

Managing change: Constant re-prio of backlog

Scrum

no changes in scope during sprint

(4)

Activity Planning

• Product Owner/Customer defines & prioritises User

stories

• Backlog or Story card management

• Dependencies are built into the prioritised

list, i.e. not explicitly marked

Backlogs

Story cards

Effort Estimate

• Early estimates during exploration phase

• User stories estimated as part of iteration/sprint planning

• Time (man / person hours / days)

or relative estimates (story points, bananas, gummy

bears)

• Planning game (XP) or Planning poker (Scrum)

Resource Allocation

• Capacity driven

– Project level: In exploration phase

– Iteration level: In iteration planning

• Within iteration: team pull, i.e. self-allocation

Risk Management

• Built into the process, e.g. stand-up meetings:

Hindrances?

• Transparency, openess with information

• Iteration demos with customer / product owner

Traditional risk management techniques can be

used, even if not prescribed

Monitor

• Progress monitored by asking ”How much work

remains?”

• Frequent status checks -> Burn-down charts

… & Control

• Management does not control in agile, rather facilitate

• Team is responsible for managing itself– Team pull!

→ Team responsible for its own work practice / process

… within the ”rules”

• Regular feedback loops: pair programming, daily stand-up

• Sprint retrospectives

(5)

Strengths of Incremental Delivery

[Hughes 4.10]

• quickly delivers working increments

• user gets some benefits earlier

• reduces ‘gold-plating’ – focus on ROI

• avoids unnecessary overhead, e.g. keeping docs updated

• experienced engineers can be more productive

• shorten comm paths with customer & within

cross-functional teams

• feedback from early stages used in developing latter

stages

Weaknesses of Incr Delivery

[Hughes 4.10]

• weak long-term and overall perspective

• loss of economy of scale

• refactoring causes software breakages

• weak / missing documentation – esp for large scale

– Dependent on personal knowl: negative for new

members, transitioning to other team, audits, user doc

– Decision rationale, reqst-tc tracing may be lost

• Generalists have weaker specialist competence, e.g.

reqts, testing, architecture

• Less structure/guidance for weaker engineers

Monitor &

Control

(Ch 9 except 9.6 & 9.9,

12.4)

• Plan ≠ Reality / ’facit’!

• Aim is to reach

• Scope: good product

• Budget: cost

• Timeliness: market

window, commitments etc

►Monitor & Control

Schedule vs Reality

Roadworks!

Accident!

Monitoring

• Objective: to check if project is on track relative plan

• Different kinds of data (measurements!)

– Data from reports

– Subjective data on completion rate

– Data comparing actual cost and planned cost

– Data comparing actual value and planned value

Monitor via Reporting

Project Sponsor / Director Steering Committee Project manager PM for subproject Legacy Team Media Team Storage Team Leader for Media Player Team member: MM Dev Team member UX Design Team member Tester Team leader for FS ext Team member FileS Dev Team member Tester

Customer

(6)

Different Types of Reporting

Formal – Informal, Oral – Written, Regular - Ad Hoc

Formal

Informal

Regular

Oral

Re-occurring progress

meetings, eg stand-ups

Around coffee machine

Written

Job sheets, progress

reports

Emails to known

collegues

Ad Hoc

Oral

Review meetings

Ad hoc meetings

Written

Issues reports, change

requests

Emails for issues

investigation

Project vs Line Organisation

Manager

Analysis

Coding

Testing

…

PM

Feature

A

Feature

B

System

Test

…

Functional (usually Line)

Task (usually Project)

Quantitive cost & remaining effort,

but thin on qualitative info, e.g.

issues, actual state of progress.

Collecting progress details

Need to collect data about:

• Achievements

• Costs

Exercise on partial completion

Developer has produced 250 lines of Java code for a task

estimated at total 500 loc.

Questions

1.Reasonable to assume task 50% complete?

2.Why / Why Not?

3.How can PM deal with this?

Cost vs Time

Actual relative planned cost

≠ actual relative planned time

• Project can be behind time but under budget

Example: Delayed due to not deploying committed staff

• Project can be on time but over budget

Example: additional resources have been added to cope with work load

→Need to monitor both achievements and costs

Collecting progress details

Need to collect data about:

• Achievements

• Costs

Exercise on partial completion

Developer has produced 250 lines of Java code for a task

estimated at total 500 loc.

Questions

1.Reasonable to assume task 50% complete?

2.Why / Why Not?

3.How can PM deal with this?

Possible answers

1. Not necessarily

2. Possible issues

• Incorrect estimate

• Non-typical or uneven progress so far

• Test & debugging not started yet

3. More (qualitative) knowledge of progress

(7)

Gantt charts

Slip charts

Burn-Down Charts (Scrum)

Fever Chart (Critical Chain)

Prioritized monitoring

[Hughes 9.7]

Monitoring and reporting has a $-tag!

Focus on monitoring based on risk

• Critical path activities: if delayed later dependent

activities are delayed

• Activities with less than a specified float

• High risk activities: E.g. top 5-10 risks

• Activities using critical resources

+ activities with external dependencies

+ resource allocations

Assessing progress

Checkpoints – predetermined times when

progress is checked (plan + process)

– Event driven: check takes place when

a particular event has been achieved

– Time driven: date of the check is

pre-determined

Frequency and level of reporting

• Corresponding to organizational level

• Higher risk → more frequent

assessment

(8)

Control or Getting back on track

[Hughes 9.8]

+ Understand the issues! E.g. missing information, weak

tools, non-functioning team etc etc etc

• Try to shorten critical path by adding resources

– Overtime

– Re-allocate existing staff to more critical activities

– Get more staff

• Reconsider activity dependencies

– Over-lap activities to avoid waiting for completion of another

– Split activities to remove dep. to activities / critical resources

Control by Modifying the Target

• Re-negotiate the commitment: time (deadline), cost or scope

– Reduce scope &/ quality

– Increase cost or deliver later. Consider incremental delivery!

For changes that affect business case (scope-cost-time) involve

• All affected stakeholders

• Inform and gain approval from steering committee and project sponsor

• Ensure affected parties are informed

Summary

Two main PM tasks

• PLAN

• GUIDE, i.e. monitor & control a project

to meet agreed goals and targets

Monitor and control

• Monitor through analysing, compiling incoming reports

• Take corrective and adjustive action when needed

• Manage change in a structured way

• Coordinate roles and people (project meetings etc)

exercises:

9.1 and 9.2

Software Engineering Process Economy & Quality

Project delivery: Progress report

The SPA

reports you

RECEIVED

Your actions

on received

feedback

Excel format

preferred

Lecture 4:

Agile PM – Paper 3, Ch 4.10-11, 4.13-15 [Hughes]

Monitor & Control - Ch 9 except 9.6 & 9.9, 12.4 [Hughes]

[email protected]

Software Engineering Process

– Economy & Quality

ETSF 01

http://cs.lth.se/etsf01

AGILE PROJECT MANAGEMENT

Ch 4.10-11, 4.13-15 [Hughes],

P4 (not DSDM parts):

Coram, Bohner,

“The Impact of Agile Methods on Software Project Management”,

Proc of 12

th

Int. Conf. and Workshops on the Engineering of

Computer-Based Systems, 2005.

[email protected]

Agile…

• One name for many different methods

• Each implementation is unique

Today’s lecture: Scrum, XP and Kanban

Principle-Driven Approach

based on

Agile Manifesto

More valuable

• Individuals & interactions

• Working software

• Customer collaboration

• Responding to change

Valuable

• Processes

and tools

• Comprehensive documentation

• Contract negotiation

• Following a

plan

Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward

Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron

Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber,

Jeff Sutherland, Dave Thomas, The Agile Manifesto,

http://agilemanifesto.org/,

2001

Agile focuses on…

• Maximizing ROI - delivering business value

• Quickly delivering working code

• Expecting and managing changes

target

scope

lead time

cost /

effort

changes

Agile SPM

•

Gradual detailing

•

Work order

•

Priority

•

Just-in-time

•

Self-governing teams

Level of detail at dev start

Traditional

project

Agile

project

ReqtsDesignImpl Testing

_{Int. Conf. and Workshops on the Engineering of}

_planning