to be, or not to be, agile - architecting be or not to be agile.… · knowledge and experience is...

Peter EelesIBM

To Be, or Not To Be,

Agile

The premiere software and product delivery event.June 6–10 Orlando, Florida

[email protected]

The Development Organization’s View

The Customer’s View

Agenda

� Introduction

� Selecting a project lifecycle

� Selecting practices

� Selecting measures (and automation)

� Summary

Credentials

� Based on IBM Rational’s clients

�Large and small organizations

�A variety of business and technical domains

� Based on IBM

�We use agile ourselves!

� Based on my own experiences� Based on my own experiences

�Including the following case study …

Case Study

� A large Scandinavian bank

� 2000+ developers

� 6 business units

� Development teams are often geographically distributed

Business Objectives

Name Description Goals

Time to

market

Projects deliver faster than

today

�Complete small projects within 7 months (average

time to market is currently 14 months)

�Deliver a first increment (demo) on projects within 8

weeks from project initiation followed by subsequent

increments (demos) at regular intervals of 2-4 weeks

Cost

efficiency

Projects deliver with lower

overall cost than today

�Increase the efficiency baseline (function points per

FTE) by 10%

“Agile Adoption Programme” initiated

efficiency overall cost than today FTE) by 10%

Quality Systems exhibit the agreed

level of quality

�Decrease the error baseline by 10%

Continuous

optimisation

The development

organisation is a learning

organisation using common

processes that are

continuously updated

�Knowledge and experience is used to improve

processes

�Processes are performed in a mature and

professional way (i.e. consistently) in order to harvest

the benefits of this

Key Decisions

� Project Lifecycle

�When should we use agile?

� Practices

�What agile practices should we adopt?

� Measurement / Automation

�What should we measure?�What should we measure?

�How should we measure?

It’s not just about methods and tools

Methods

Tools(for automating aspects of

the method)

Content Deals With

Process + method content

Practices, standards, guidelines

Tool selection

Tool configuration and integrations

Roles & responsibilities

Work products

Governance policies

Tool fitness-for-purpose

Tool integrations

Licensing

Enablement(in methods and tools)

Training curriculum

Training courses

Mentoring materials

Training and mentoring

Element

Functionality ( E.g. change m

gt, requirements m

gt, testing)

Qualities (E.g. usability, scalability, reliability, cost)

Constraints (E.g. geographic distribution, migration)

See http://www.ibm.com/developerworks/rational/library/edge/08/apr08/eeles/index.html

(in methods and tools)Mentoring materials

Infrastructure(for methods, tools and

enablement)

Infrastructure specification Distribution of organization

Solution packaging

Installation and configuration

Adoption(of the environment)

Adoption approach (e.g. plan)

Install, configure, train, mentor

Migration (including org. change)

Results

Governance (e.g. measurement)

Organization(to use and support methods, tools,

enablement, infrastructure)

Organization specification Skills

Centers of excellence

Functionality ( E.g. change m

gt, requirements m

gt, testing)

Qualities (E.g. usability, scalability, reliability, cost)

Constraints (E.g. geographic distribution, migration)

Streams

Methods

Tools(for automating aspects of

the method)

Enablement

Methods

Strategy

Enablement(in methods and tools)

Infrastructure(for methods, tools and

enablement)

Adoption(of the environment)

Organization(to use and support methods, tools,

enablement, infrastructure)

Tools

Organization Implementation

(OI)

Incremental adoption

� “Deliver in waves, produce in streams”

�Organize as a sequence of waves of change

Wave 0

Strategy

Wave 1

Strategy

Wave 2

Strategy

Methods

Tools

OI

Pilots

Methods

Tools

OI

Pilots

Methods

Tools

OI

Pilots

Organise to succeed

Sponsor

Reference

Steering

Committee

Project Design Reference

Group*

Strategy Tools OI Pilots

Project

Management

* “Network of agile practitioners”

Methods

Design

Authority

Agenda

� Introduction




� Summary

Typical Project Lifecycles

http://leadinganswers.typepad.com/leading_answers/files/agile_suitability_filters.pdf

To be, or not to be, Agile

� Management Influences

� Stakeholder Influences

� Project Team Influences

� Technology Influences

� Solution Influences

Management Influences

� Business Flexibility

�Management are willing to accept that business parameters, such as cost,

schedule and intermediate milestones, are flexible

� Empowered Teams

�Management is willing to allow the team (including the product owner) to make

key project decisions

Stakeholder Influences

� Acceptance of Agile

�Stakeholders understand and accept agile practices and the consequences of following these

� Number of Stakeholders

�The number and diversity of stakeholder relationships to be managed is limited

� Stakeholder Responsiveness

�The business representative, end users and testers are committed to spending a good deal of time working with the team in an iterative fashionspending a good deal of time working with the team in an iterative fashion

Project Team Influences

� Team skills

�Individuals on the team are team players, good communicators and are familiar with agile practices

� Embracing Change

�Team members expect and embrace frequent changes and iterative refinement of the solution

� Colocated Teams

�The project team will be colocated

� Team Stability

�Individuals will be assigned to the team for the duration of the project

� Team Roles

�Team members are able (and willing) to take on multiple roles during the project and to take on new roles if/when needed

� Agile Disciplines

�Team members have proven ability in performing disciplines that are critical for agile development with short iterations (design, testing and configuration management)

Technology Influences

� Development Environment

�The development environment (method, tools, training) will

support an agile way of working (such as automated regression

test, continuous integration and real-time dashboards) and is

sufficiently mature

� Execution Environment

�The execution environment can support regular releases

Solution Influences

� Requirements Churn

�There is a strong likelihood that there will be significant changes to requirements (and the solution) during the project

� Solution Complexity

�The required solution is relatively-complex (e.g. requires the use of unfamiliar technologies) and/or there are many different solution options

� Time-to-market

�The deadline (time) is the most important factor for the solution while the scope of the solution is flexiblescope of the solution is flexible

� Dependencies

�There are no (or only a few) dependencies on internal or external suppliers

� Release Frequency

�The solution can be subdivided in viable and meaningful business releases that can be delivered within 3-4 months

� Demonstrability

�The solution can be easily demonstrated on an incremental basis (through a user interface, for example)

Decision Framework (detail)

Decision Framework (summary)

Agenda

� Introduction




� Summary

IBM Practice Library

Start here!

A version of these practices is available in OpenUP

Case Study – Practices by Priority� Foundation

� Iterative Development

� Two-Level Planning

� Team Change Management

� Shared Vision

� Continuous Integration

�Whole Team

� High

� Medium

� Evolutionary Architecture

� Concurrent Testing

� Low

� Business Process Sketching

� Evolutionary Design

� Ultra Low

Process authoring and Tailoring� High

� Risk-Value Lifecycle

� Test-driven development

� Use case-driven development

� Process authoring and Tailoring

� Requirements Management

� Formal Change Management

� Component Based Software Architecture

� Design Driven Implementation

� Test Management

� Independent Testing

� Application Vulnerability Assessment

� Performance Testing

What’s in a Practice?

� Key concepts

� Work products

� Tasks

� Guidance

� Measurements

� Tool mentors

Roles, work products, tasks

� Roles

�Product owner

�Scrum master

� Work Products

�Product backlog

�Blockers list Screen shots from published versions of �Blockers list

�Sprint Goal

�Task Board

�Epics

�User stories

� Tasks

�Various

Screen shots from published versions of

SCRUM EPF and OpenUP

Agenda

� Introduction




� Summary

Measures help answer key questions

Agile-Related

Measures

IT-Related

Measures

Business-Related

Measures

Projects deliver

faster than today

Appropriate level of

management and

analysis activities

Agile role

adoption

Projects deliver with

lower overall cost

than today

Efficient change

request process

Agile practice

adoption

Are we meeting

business

objectives?

Are we seeing the

benefit where we

expected?

Are we agile?

Systems created or

updated in the

projects have the

agreed quality

The development

organisation is a

learning

organisation

Employee

satisfaction

Agile work product

adoption

Agile task

adoption

Agile process

adoption

Efficient

requirements

definition and

signoff

Fewer breakages

when solution

elements are

integrated

Less “solution

hardening” needed

Selecting Measures (Metrics)

� Simple criteria

�Who cares?

�Will it add value?

�Will collection be

intrusive?

Case Study – Initial Metrics

Business-related Agile-related

Cycle time

reduction

�Time spent from project initiation

to delivery of first increment

�Time spent from project initiation

to project closure

�Sprint velocity

�Blocking work items

Quality �Defects (severity 1 and 2) in �Defect trendQuality �Defects (severity 1 and 2) in

production per 100 FPs

�Defect trend

Continuous

optimisation

�Process maturity level �Adoption of agile practices

Productivity �Function points per man year �Sprint burndown chart

�Release burndown chart

Category: Cycle time reductionMetric: Sprint velocity

Objectives Sprint velocity is used to measure the performance (and therefore capability) of

the team. The velocity is useful in identifying the trend of how much work a team

can complete in a sprint.

Baseline Metric The number of points is plotted on the Y-axis and sprints on the X-axis. In initial

sprints, the team velocity is typically low but subsequently increases and

stabilises as the project proceeds. If the velocity rises or falls dramatically then it

needs the immediate attention.

Unit Velocity can be measured in term of points, days, hours, or any other unit the

team is using for estimation.

Responsibility Project Manager.Responsibility Project Manager.

When to Measure During project execution.

Manual/Automated Automated in Rational Team Concert.

Data Repository Available in Rational Team Concert.

Project Calculation Velocity, calculated as the number of units of work the team has completed in a

given sprint. Units can be points, days, hours or any other unit your team is using

for estimation.

Example See over for chart.

Target A trend of a steady or increasing number of work items being addressed over

time.

Sprint Velocity Example

Taken from RTC 2.0 project at jazz.net on 3rd December 2009

Category: QualityMetric: Defect trend

Objectives The defect trend is used to ensure that arrival and closure rates have some

correlation (i.e. that your arrivals don’t consistently outpace your closure,

resulting in a high defect backlog), to determine the remaining defect backlog, to

project the future defect arrival/close rate up to (and after) customer ship.

Baseline Metric Slope of a trend chart showing total cumulative defects (total found – total

closed) over time. Ideally, the slope should be flat or decreasing.

Unit Chart slope.

Responsibility Project Manager.

When to Measure During project execution.When to Measure During project execution.


Data Repository Available in Rational Team Concert and Rational Quality Manager.

Project Calculation �Number of defects found for each unit of time (usually a week, but could be day

or month, depending on sprint length).

�Number of defects closed for each unit of time.

�Total cumulative defects (total found - total closed).


Target A trend of a steady or decreasing number of defects over time.

Defect Trend Example


Category: ProductivityMetric: Sprint burndown chart

Objectives A sprint burndown chart allows the progress of the sprint to be measured.

Baseline Metric Slope of the chart. The number of remaining units (such as work items or hours)

is shown on the Y-axis, together with the number of planned units, and time is

shown on the X-axis. Ideally, the trend of remaining units should go down as

time progresses.

Unit Chart slope.

Responsibility Project Manager

When to Measure During project execution.When to Measure During project execution.


Data Repository Available in Rational Team Concert.

Project Calculation �Number of planned units during time I for the sprint.

�Number of actioned units during time I for the sprint.


Target A trend of a decreasing number of remaining units over time.

Sprint Burndown Example


Category: Continuous optimisationMetric: Adoption of agile practices

Objectives To measure the adoption of agile within a project that has selected the agile

lifecycle.

Baseline Metric Score provided by the Team Pulse survey.

Unit Ranking (from 0 to 5, where 5 represents full adoption).

Responsibility Project Manager

When to Measure During project execution.

Manual/Automated Manual.

Data Repository Central repository.

Project Calculation Derived from the Team Pulse survey which assesses the adoption of several

agile practices.

Example �The 6 team members completed the Team Pulse survey which gave an average

score over 3.0 for 4 practices, and below 3.0 for one of the practices.

�See over for example.

Target An average score > 3.0 in the Team Pulse survey.

Agile Adoption Example (detail)

Agile Adoption Example (summary)

Case Study – Automation

Automated Manual

Cycle time

reduction

�Time spent from project initiation to

delivery of first increment

�Time spent from project initiation to project

closure

�Sprint velocity

�Blocking work items

Quality �Defects (severity 1 and 2) in production per

100 FPs (FP count is manual)100 FPs (FP count is manual)

�Defect trend

Continuous

optimisation

�Process maturity level

�Adoption of agile practices

Productivity �Function points per man year (FP count is

manual)

�Sprint burndown chart

�Release burndown chart

Agenda

� Introduction




� Summary

Potential Relevance to You

� The general approach is broadly applicable

�Comprehensive consideration of a development environment

�Incremental adoption

�Risk-driven

�Managed as a project

� Tangible (reusable) assets� Tangible (reusable) assets

�Project lifecycle decision framework

�Practice definitions

�Metrics

�Tool configurations and integrations

�Enablement materials

Measured Capability Improvement Framework

Assess

Align proposed solution with business goals

and priorities

•Executive Business Value Workshop

(2-4 hours)

•Quick Diagnostics (1-2 days)

•Health Assessment (1-2 weeks)

Steer

Monitor projects, identify gaps, decide on corrective actions

and measure business value

•Self-Check

•Rational Insight

Act

Rapidly drive change and embed knowledge of

solution

•Rapid Deployment Packages

•Software Delivery Platform

Summary

� Agile is one of several possible lifecycles

� A successful transition to agile …

�Draws upon a small number of key principles

�Is risk-driven

�Is people-focused

�Is measured�Is measured

4

7

Daily iPod Touch giveaway

� Complete your session surveys online each day

at a conference kiosk or on your Innovate 2010 Portal!

� Each day that you complete all of that day’s session surveys, your name will be entered to win the daily IPOD touch!

SPONSORED BY

� On Wednesday be sure to complete your full conference evaluation

to receive your free conference t-shirt!

4

8

© Copyright IBM Corporation 2010. All rights reserved. The information contained in these materials is provided for informational purposes only, and is provided AS IS without warranty of any kind, express or implied. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, these materials. Nothing contained in these materials is intended to, nor shall have the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software. References in these materials to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. Product release dates and/or capabilities referenced in these materials may change at any time at IBM’s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any way. IBM, the IBM logo, Rational, the Rational logo, Telelogic, the Telelogic logo, and other IBM products and services are trademarks of the International Business Machines Corporation, in the United States, other countries or both. Other company, product, or service names may be trademarks or service marks of others.

www.ibm/software/rational

to be, or not to be, agile - architecting be or not to be agile.… · knowledge and experience is...

Documents