Agile Inspired Risk Mitigation Techniques for Software Development Projects

Agile Inspired

Risk Mitigation Techniques

for

Software Development Projects

Michael Bica, Sogard Inc. Presented at GTISLIG, Toronto

Roadmap

I. Risks

 _Heuristics

 Risks & Estimation

II. Project Management vs. SDLC

III. Agile Methodologies

 _Manifesto  Principles

 Brief Descriptions of Some Agile Methodologies IV. Risks vs. Agile Techniques

V. Risks vs. Organization Types

A Few Questions

 Who is involved in software development projects?  Familiarity with agile methodologies?

 Is there a prescribed methodology in your organization?

 _Waterfall

 _{Rational Unified Process (RUP)}  _Agile

What Is a Risk?

Merriam-Webster

Risk

= Possibility of Loss or Injury

This evening

Risk

= Any factor, situation or event that may

Success vs. Failure

Success = project is on time, on budget and delivers all

the required functionality

Failure = project is late, over budget, not meeting

Chaos Report

 Source - Standish Group

 _{Issued in 1995}

 Interviewed 365 senior managers

 Covered approximately 8500 projects

 Project outcome (resolution) types

 _{Project Succeeded – completed on time, on budget, with}

all features as initially specified (16.2%)

 Project Was Challenged – completed and operational,

but over budget, over time estimate or did not meet initial scope (52.7%)

Chaos Report - Overruns

Cost & Time Overruns

Cost Schedule Overrun Amount [%] N o P ro je ct s [% ]

Chaos Report - Success Factors

 User Involvement

 Executive Management Support  Clear Statement of Requirements  _{Proper Planning}

 Realistic Expectations

 Smaller Project Milestones  _{Competent Staff}

 Ownership

 _{Clear Vision and Objectives}  Hard-working, focused staff

Chaos Report - Challenging Factors

 Lack of User Input

 Incomplete Requirements & Specifications  Changing Requirements & Specifications  _{Lack of Executive Support}

 Technology Incompetence  Lack of Resources

 _{Unrealistic Expectations}  Unclear Objectives

 _{Unrealistic Time Frames}  New Technologies

Chaos Report - Cancellation Factors

 Incomplete Requirements & Specifications  Lack of User Involvement

 Lack of Resources

 _{Unrealistic Expectations}  Lack of Executive Support

 Changing Requirements & Specifications  _{Lack of Planning}

 Didn't Need It Any Longer  _{Lack of IT Management}  Technology Illiteracy

Waltzing with Bears

 Tom De Marco, Timothy Lister – Waltzing with Bears –

Managing Risks on Software Projects

 Core software development risks

 _{Schedule flaw}

 _{Requirements inflation}  _{Specification breakdown}  Team Turnover

Estimation Process

 Estimation Types

 _{Bottom up}  Top down

 Bottom Up

 Done by the team

 _{Depends on team self knowledge and maturity}  _{Hard to challenge}

 Top down

 Historical - works for similar projects

Parametric Estimation

 Algorithm based, proprietary or public  One of the best known public tools

COCOMO

 Estimates the effort, cost, schedule

and team needed to build a given software project

 Model first published by Barry Bohem in Software

Engineering Economics, Prentice-Hall (1981) for waterfall approach

 The current model COCOMOII available since 2000

COCOMO II Inputs and Outputs

 Inputs

 _{SLOC – single lines of code}

 Function Points – quantifying the information processing

functionality associated with major external data input, output, internal file types, and external interfaces

 Outputs

 _Effort

 Schedule  Cost

Scaling Factors

 Estimation algorithm uses scaling factors_{scaling factors} to include

effect of risks on project outcome

 _{Precedentness – Has the team done it before}

(technology, business domain)?

 _{Requirements Flexibility – Can development team}

influence requirements?

 _{Architecture Risk Resolution – Has the architecture}

addressed all the required quality attributes (response time, capacity, availability, security) ?

 _{Team Cohesion – Has the team worked together before?}  _{Project Management Maturity}

Scaling Factors

 Scaling factors can be assigned 6 values:

 VLO, LO  N

 H, VH, XVH

 The selection of scale drivers is based on the rationale

that they are a significant source of exponential variationexponential variation

on a project’s effort or productivity.

 Each scaling factor affects the project outcome

independent of the others

Scaling Factors Influence on Effort

VLO LO NOM HI VHI XHI

0 10 20 30 40 50 60 70 80 90 100 110 120

Scaling Factors Influence on Effort Variance (%)

Precedentness Dev. Flexibility Architecture Team Coehision Process Maturity

Cumulative Effect of Scaling Factors

VLO LO NOM HI VHI XHI

0 20 40 60 80 100 120 140 160 180 200

Best vs. Worst Case Scenario (%)

Effort Time

Additional Factors

 Contributing factors to a project’s schedule and effort  Project outcome is affected by

 Product attributes  Platform attributes  Personnel attributes  _{Project attributes}

Project Management vs. Engineering Process

 Project Management is a generic discipline, applicable to

any engineering domain

 Different engineering processes can be managed with a

common Project Management Framework (PMF)

 Engineering domains require different activities

 For example, any software development project includes

some form of: a) Requirements Gathering, b) Design, c) Coding d) Testing and e) Deploying in production

 _{For software development, the engineering process has}

Many SDLCs

 _{Waterfall and Rational Unified Process (RUP) are two}

of the best known SDLCs

 Newer SDLCs have been bundled under the “Agile”

umbrella, e.g.:

 SCRUM

 Extreme Programming (XP)  _{Feature Driven Development}  _{Lean Development}

 All methodologies employ same activity types

Waterfall

 Assumes:

 Linear development phases

 Predictable development activities  Immutable requirements

 _{Perfectionism}

 These assumptions are too strong, because:

 Requirements change

 Technologies change, most activities are new  Teams change

Requirements

Gathering Analysis & Design Coding Testing Release

Rational Unified Process

 RUP is a process framework, focused on software

development

 Provides a generic, flexible, iterative life cycle –

described by the RUP Chart: 4 phased and 9 disciplines

 Provides guidance in terms of

 _{Roles described in terms of competencies, responsibilities}  _{Activities to be performed during each phase}

 _{Tools to be employed}

 _{Artifacts to be produced}

Rational Unified Process

 RUP phases & their goals

 _{Inception – determine project scope, business case}

 Elaboration – refine requirements, establish architecture,

mitigate most technical risks

 Construction – build the system up to deployment point

in limited environment (“beta testing”)

 Transition – finish product and deploy in production

Rational Unified Process

 RUP disciplines & phases where most effort spent

 _{Business Modeling - Inception}  Requirements - Elaboration

 Analysis & Design – Elaboration, Construction  Implementation - Construction

 Test - Construction

 _{Deployment – Construction, Transition}

 _{Configuration & Change Management - All}  _{Project Management - All}

 Environment - All

Iterative Development & Incremental Releases

 Iterations end with potentially releasable code  Iterations are demonstrated to the client

 Iterations are feature driven

 _{May have parallel activity streams}

 Requirements  Development  Testing – UAT  Defect fixes

Iteration Example

Detail Requirements

(N+1) User Acceptance Testing _{( N-1)}

Design ( N)

Code ( N)

Integrate (N)

Test (N)

Agile Manifesto

“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

 _{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.”

Principles of the Agile Manifesto

 Our highest priority is to satisfy the customer through

early and continuous delivery of valuable software.

 Welcome changing requirements, even late in

development. Agile processes harness change for the customer's competitive advantage.

 Deliver working software frequently, from a couple of

weeks to a couple of months, with a preference to the shorter time scale.

 _{Business people and developers must work together}

daily throughout the project.

 Build projects around motivated individuals.

Principles of the Agile Manifesto

 Give them the environment and support they need, and

trust them to get the job done.

 The most efficient and effective method of conveying

information to and within a development team is face-to-face conversation.

 Working software is the primary measure of progress.  _{Agile processes promote sustainable development. The}

sponsors, developers, and users should be able to maintain a constant pace indefinitely.

 Continuous attention to technical excellence and good

design enhances agility.

Principles of the Agile Manifesto

 Simplicity--the art of maximizing the amount of work

not done--is essential.

 The best architectures, requirements, and designs emerge

from self-organizing teams.

 At regular intervals, the team reflects on how to become

more effective, then tunes and adjusts its behavior accordingly.

Pre Manifesto Agile Methodologies

 SCRUM – Ken Schwaber

 Extreme Programming – Kent Beck

 Feature Driven Development - Jeff De Luca  _{Crystal Clear - Alistair Cockburn}

 Adaptive Software Development – Jim Highsmith  DSDM – DSDM Consortium

SCRUM

 Scrum Master – manages the team, interacts with

project sponsor

 _{Product Backlog}

 _{An evolving, prioritized queue of product features}  _{Owned by Product Owner}

 Contains the requirements for the system or product being

developed by the project

 _{Sprint – a 30 day development iteration, includes all}

software development activities, results in executable code, potentially releaseble, which is demonstrated to the client

SCRUM

 Sprint Goal - functionality from the Product Backlog

that the team commits to implement during the Sprint

 _{Sprint Backlog - what work will have to be performed}

in order to reach the sprint goal (team determined)

 Daily Scrum – 15 min. standing meeting with team

members, covering “What I've done yesterday”, “What I'm doing today”, and “What is holding me back”

 Notes:

 _{Features assigned to the current Sprint are immutable}  _{Progress is measured through “Effort Remaining”}

XP (Extreme Programming)

 Fine scale feedback

 _{Pair Programming}  Planning Game  Test First  Whole team  Continuous process  _{Continuous Integration}  Design Improvement  Small Releases  Shared understanding  _{Coding Standards}  Collective Code Ownership  Simple Design  Programmer welfare  _{Sustainable Pace}

Feature Driven Development

 Iterative and incremental  Activities:

 Develop overall model  Assemble feature list  Plan by feature

 _{Design by feature}  _{Build by feature}

 Best Practices:

 _{Domain Object Model}  Develop by Feature  Individual code ownership  Feature teams  _Inspections  _{Regular Builds}  _{Visibility of progress}

Lean Development

 Eliminate Waste – extra features, requirements churn,

crossing organizational boundaries

 Focus on Learning

 _{Build Quality In – test driven development}

 Defer Commitment – take irreversible decisions at the

latest responsible moment

 _{Deliver Fast}

 Respect People

Agile Common Denominators

 Activities

 _{Test driven development}  Light on documentation

 Scheduling

 Iterative development

 Time bound  Feature driven

 Full development cycle  Incremental releases  Requirements  _{No gold plating}  Flexibility  Early feed-back  Defer implementation  Team  _{Small teams}  Co-location

 Daily status reports  Communication

Fuzzy Issues in the Agile Domain

 Estimation – hard to do with “just-in-time” requirements  Architecture

 Poor system architecture is a risk factor

 Feature Driven Development, SCRUM friendly

 XP requires YANGTNI (you are not going to need it)

 _Scalability

 Small teams are a core factor in agility  Proposed team size is ~ 10 developers  For larger teams scalability not known

 _{Compressed schedules - requiring extensive parallel work}

Requirements

 Risks:

 _{Incomplete requirements}

 Uncontrolled requirement changes  Scope creep

 Techniques:

 _{Flexibility in change control (e.g. Backlog)}

 _{Defer implementation - iterative development}  Obtain early feed-back from users

Architecture

 _{Short, time bound iterations}  _{Continuos refactoring}

Team

 Risks:

 _{Team has not worked together before}  Lack of cohesion

 Lack of technical skill  High turnover

 Techniques:

 _{Small team}

 Co-located team

 Daily status reports  Whole team design

 Pair programming, code reviews  _{Sustainable pace}

Communications

 Risks:

 _{Poor communication between client and team}  Poor communication inside team

 Techniques:

 Include client representatives and users on the team  _{Daily status updates}

 _{Co-located team members}

Schedule

 Risk:

 _{Underestimation}

 Techniques:

 High level estimates

 Only next iteration is precisely estimated - “Rolling wave

SD as Core Business

 Software assets are core products of the organization  Typical examples: Microsoft, Corel

 Marketing group drives the product definition – they are

the clients of software development teams

 SD teams are fairly stable, well tuned together  Technologies are well understood

 _{Development is focused on adding new features to the}

product

SD for Business Support

 Software is developed to support core business processes  Typical examples: banking, insurance

 Business departments are clients of SD teams

 _{Development is focused to meet business needs for}

increased agility, better operational support, regulatory

 Two types of projects:

 _{Maintenance – fairly stable teams, well understood}

technologies, lower risk

 New technologies – most of the times the organization

does not have very senior people available, architecture not proven, higher risk

SD as Consulting

 Consulting companies are brought in to deliver turn key

projects when the client does not have the resources or the technological savvy to do it internally

 _{Most projects involve new technologies}

 Teams are assembled from pools of resources

 Most of the time teams are low cohesion and high

technical capabilities

 Client constrains may force projects into sub-optimal

technical decisions

Project Manager Context

 PM works within organization's constrains

 _Process

 Resources  Location

 Tools, infrastructure, architecture

 Can influence requirements

 Can influence or control project schedule

 Can influence or control the team composition  _{Controls project execution}

Requirements

 Flexibility

 _{Assume requirements are negotiable}

 Offer same business functionality for less  Cost is a strong argument

 Bundle requirements in features

 _{Easier to deliver releases earlier in project life-cycle}

 Obtain early feed-back from users on requirements

 Screen mock-ups

Iterative Development

 Feature driven

 Time bound – duration of 2-6 weeks

 Complete – team delivers fully tested deployable code  _Advantages:

 User-feedback on the actual product is elicited sooner,

thus minimizing the possibility of requirement changes later in the life cycle of the project

 Team performance issues are identified early in the

Incremental Releases

 Improves the project ROI by providing business value at

an earlier stage (Minimum Marketable Features)

 Example:

1 Release 2 Releases 4 Releases

Cost $1,000,000.00

Duration 12 months

Benefits 600K savings/year

Incremental no yes yes

ROI

1 year -$1,000,000.00 -$700,000.00 -$550,000.00

2 year -$400,000.00 -$100,000.00 $50,000.00

Test-Driven Development

 Develop test cases before actual code is written  Mandate all development team to employ test

frameworks, such as JUnit for Java (long term benefit – helps with regression testing as well)

Team

 Bring senior people on the team

 Build team with people you have previously worked

with

 _{Co-locate development team}

 Hijack a conference room for the duration of the project  Great sponsorship support (they want the room back)  Very short communication paths

 Very efficient for team building

Further Reading

 Boehm, Barry; R. Turner - Balancing Agility and

Discipline: A Guide for the Perplexed, 2004; Boston, MA; Addison-Wesley, 2004, ISBN 0-321-18612-5

References

[1] Boehm, Barry; R. Turner - Balancing Agility and Discipline: A Guide for the Perplexed, 2004; Boston, MA; Addison-Wesley, 2004, ISBN 0-321-18612-5

[2] Boehm, Barry- Software Cost Estimation with COCOMO II, Prentice Hall 2000, ISBN 0-13-026692-2 [3] DeMarco, Tom; Lister, Timothy – Waltzing with Bears – Managing Risk on Software Projects; Dorset

House Publishing 2003, ISBN 0-932633-60-9

[4] Gramus, David; Herron, David – Function Point Analysis: Measurement Practices for Successful Software Projects; Addison-Wesley 2000; ISBN 0201699449

[5] Highsmith, J.A. - Adaptive Software Development: A Collaborative Approach to Managing Complex Systems, 2000, New York: Dorset House, ISBN 0-932633-40-4

[6] Highsmith, J.A. - Agile Project Management: Creating Innovative Products, Addison-Wesley, 2004, ISBN 0-321-21977-5

[7] Beck, K. - Extreme Programming Explained: Embrace Change, Addison-Wesley, 1999, ISBN 0-321-27865-8

[8] Schwaber, Ken – Agile Project Management with Scrum, Microsoft Press, 2003, ISBN 0-7356-1993-x [9] Schwaber, Ken; Beedle, Mike – Agile Software Development with Scrum, Prentice Hall, 2002, ISBN 0

Scale Driver Descriptions

Weighted average of "Yes" answers to CMM Maturity Questionnaire

PROJECT MATURITY seamless interactions highly cooperative largely cooperative basically cooperative interactions some difficult interactions very difficult interactions TEAM COEHISION full (100%) mostly (90%) generally (75%) often (60%) some (40%) little (20%) ARCHITECTURE RISK RESOLUTION general goals some conformity general conformity some relaxation occasional relaxation rigorous REQUIREMENTS FLEXIBILITY thoroughly familiar largely familiar generally familiar somewhat unprecedented largely unprecedented thoroughly unprecedented PRECEDENTNESS Extra High Very High High Nominal Low Very Low Scale Factor

Product Attributes

 Constraints and requirements placed upon the project to

be developed

 Required software reliability (RELY)  Database size (DATA)

 Documentation match to life-cycle needs (DOCU)  _{Product complexity (CPLX)}

Platform Attributes

 Limitations placed upon development effort by the

hardware and operating system being used to run the project

 _{Execution time constraint (TIME)}  _{Main storage constraint (STOR)}  _{Platform volatility (PVOL)}

Personnel Attributes

 Personnel attributes refer to the level of skills that are

possessed by the personnel.

 The skills in question are general professional ability,

programming ability, experience with the development environment and familiarity with the project’s domain.

 Analyst capabilities (ACAP)

 _{Applications experience (APEX)}  _{Programmer capabilities (PCAP)}  _{Platform experience (PLEX)}

 _{Programming language experience (LTEX)}  Personnel Continuity (PCON)

Project Attributes

 Project attributes refer to the constraints and conditions

under which project development takes place.

 Use of software tools (TOOL)  Multi-site Development (SITE)

What Are Function Points?

 Function Points measure a software project by

quantifying the information processing functionality

associated with major external data input, output, or file types.

 Five user function types need to be taken into account

 External Inputs (EI)  _{External Outputs (EO)}  _{External Queries (EQ)}

 _{Internal Logical Files (ILF)}  _{External Interface Files (EIF)}

Function Point Descriptions

Function Point Type Description

External Inputs

External Outputs External Queries

Internal Logical Files

Each unique user data or user control input type that (i) enters the exter-nal boundary of the software system being measured and (ii) adds or changes data in a logical internal file.

Each unique user data or control output type that leaves the external boundary of the software system being measured.

Each unique input-output combination, where an input causes and gen-erates an immediate output.

Each logical group of user data or control information in the software system. Include each logical file (e.g., each logical group of data) that is generated, used, or maintained by the software system.

External Interface Files

Files passed or shared between software systems should be counted as external interface file types within each system.

Counting Function Points

Function Points Complexity

 There are three levels of

complexity both for

screens (EI, EO and EQ, respectively) as well as data storage (ILF) and external interfaces (EIF)

Complexity of Data Elements

No of Data Elements 1-4 5-15 >15 <2 L L M 2 L M H >2 M H H No of File Types (Domain Types) Complexity of ILF No of Data Elements 1-19 20-50 >50 1 L L M 2-5 L M H >5 M H H No of Element Types (DB Tables)

Counting Precision (Granularity)

 Factors to be considered:

 _Cost

 Accuracy

 Counting types:

 Detailed: +-10% precision, not cost effective

 _{Average: +- 15% precision, somewhat cost effective}  _{High Level: +- 20% precision, very cost effective}