implementing an agile transformation using discipline ... ruc/implementin… · implementing an...

Implementing an Agile Transformation Using

Discipline Agile Delivery Michael J Lyons

World Wide Solution Deployment Architect, IBM Rational

[email protected]

2

Agenda

Why a transformation ? Why Agile / Lean ? Agile / DAD – What is it ? Agile Deployment Framework Agile Deployment Components

– Lifecycle / Process – People – Practices – Tools

Sample Agile Results General Transition Recommendations

2

2

3

Why a Transformation is Necessary? Involves widespread corporate change

– All aspects of IT

– The business must participate

– Human Resources

– CIO / CTO

Organizational Change principles must be implemented

Employee roles must be changed

Processes must be updated

Tools must be secured and people trained

Teams and team members can not learn Agile on their own, without a seasoned coach

Small isolated agile teams can be successful, but expanding to teams that must collaborate creates the need for an enterprise wide transformation

Have you adopted any agile techniques?

Source: State of the IT Union Survey, Dr. Dobb’s Journal, July 2009

Third-party research suggests even wider adoption

No 24% Yes

76%

Why Agile / Lean ? – they have gone mainstream

Results from Scott Ambler’s 2013 How Agile Are You?

Survey posted at www.ambysoft.com/surveys/

Recent survey on Agile adoption by Agile

criteria

4

http://www.ambysoft.com/surveys/

Why Agile / Lean ? they work

Dr. Dobb’s Journal 2008 Project Success Survey

0.8

0.8

2.7

0.4

0.8

0.2

1.8

2.3

4.0

3.0

5.6

5.0

4.4

3.9

6.0

4.9

Time

Money

Functionality

Quality

Agile

Iterative

Traditional

Ad-Hoc

Detailed results online at www.ambysoft.com/surveys/

0% 20% 40% 60% 80% 100%

Traditional

Ad-Hoc

Agile

Iterative

Successful Challenged Failed

Dr. Dobb’s Journal 2010

Project Success Survey

Bottom Line: Agile teams produce higher quality work, are quicker to deliver, are more likely to deliver the right functionality, and more likely to

provide greater ROI than traditional teams

5

Unified Process (UP)

6

Hybrid: DAD adopts best practices from several agile

methods

Extreme Programming (XP)

Scrum

DAD is a hybrid process framework. DAD adopted the best practices and philosophies from a number of methodologies

Harmony

Process Disciplined Agile

Delivery (DAD)

Lean

Agile

Modeling

Agile Deployment Framework: Overview

7

Pilot Project(s)

Define Working Model

Prepare for Pilot

Establish Core Team

Assess and

Decide

Execute Adoption Strategy

Milestone 0 Solution & Plan Approved

Milestone 1 Core Team Enabled

Milestone 2.n Incremental Working Model Defined

Milestone 3.n Ready for Pilot

Milestone 4.n Ready for Roll out

Milestone 5 Adoption Complete

Release 1

Release 2

Release 3

…

Agile Deployment Framework: Initialization

8

Pilot Project(s)

Define Working Model

Prepare for Pilot

Establish Core Team

Assess and

Decide








Release 1

Release 2

Release 3

…

A typical structure for a large-scale agile transition

Enterprise launch Early adopter phase

Setup

Setup overarching governance

Agree to KPIs and setup measurements

Identify target projects

Overarching strategy

Deploy environment and infrastructure for success

Agree and charter objectives

Initial training and change management

Training and onboarding materials

Mentors and champions

Center of Excellence

Process adaptation for project context

Oversight and steering

Methods and standards

Steering Benefit tracking Lessons learned

Mentor initial projects

Review and improve

Ev

alu

atio

n

1-2 months, depending on project context 1-3 months Determined by rollout plan

Scaling and change mgt

3 - 6 months per project

Create environment and infrastructure for success

Prepare mentors, Champions, and sponsors

9

10

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 production Defect trend

Continuous

Optimization

Process maturity level Adoption of agile practices

Productivity Function points per man year Sprint burndown chart

Release burndown chart

10

The Disciplined Agile Delivery life cycle – Customize?

11

12

Aligned new roles, artifacts, tasks

Roles – Product owner

– Scrum master

Artifacts – Product backlog

– Blockers list

– Sprint Goal

– Task Board

– Epics

– User stories

Tasks – Various

Screen shots from published versions of SCRUM EPF and OpenUP

13

Sample Artifacts Matrix

Role and Responsibilities – Coaches / Sponsors

Agile Coach:

– Provide advice to the team

– Provide opportunities for people to learn, even through mistakes

– Pair with the people they are coaching to provide detailed mentoring

– Help teams to solve problems

– Negotiate conflicts among team members

– Promote self-organization and self-discipline within the team

– Help the team to understand and meet their improvement goals

Agile Champions and Sponsors

– Support agile coaches

– Work closely with the business to help it understand and shift to agile development

– Work closely with IT senior managers to help them understand and adopt agile development

– Communicate to the organization the current status of the agile adoption, successes, and so on

– Help promote communication between agile coaches and teams

– Promote and defend the agile approach in their line of business

– Use collected results to show value

14

15

A practice is a documented approach to solving one or several commonly occurring problems. – Can be informally document through one white paper, or formally documented through a combination of training courses, tutorials,

process models, etc.

– One-stop-shop for relevant content, see Practice Components below

A practice can be adopted independently from other practices – Organizations can adopt one or a few practice at a time

– Avoid process war: practices can be shared across processes (e.g. OpenUp uses Scrum practices)

A practice has a positive impact on one or several business objectives – Time-to-Market, Improve Quality,

Increase Innovation, …

The adoption of a practice, and it’s

impact on business objectives, can

be effectively measured – A practice can be adopted incrementally

– Make it easy to learn about practices by making

practices stand out, do not hide them in context

of a process

Practice Components

Motivation – why do you need it

Process and methods

Tools for implementing the practice

Services aiding its implementation

Enablement – how is knowledge gained about the practice

Measurements of adoption level

What is a “Practice”?

16

IBM Rational Practices

Incrementally adopt

practices to

address key gaps

Foundation –Iterative Development –Two-Level Planning –Team Change Management –Shared Vision –Whole Team –User Story Development –Requirements Management

Later –Risk-Value Lifecycle –Test-driven development –Continuous Integration –Evolutionary Architecture –Concurrent Testing

Typical Deployment

17

Benefits of a practice-based approach

Benefits:

Offers a loosely coupled, modular way to adopt improved development techniques

Eases burden associated with large and complex processes

Independent practices can be learned separately, over time

Successful adoption can be measured as teams are ready

Result:

Easier, more effective deployment of customized and adaptable practices and processes.

Software that better meets business needs, delivered faster

Agile Deployment Framework: Mobilization

18

Pilot Project(s)

Define Workin

g Model

Prepare for Pilot

Establish Core Team

Assess and

Decide








Release 1

Release 2

Release 3

…

19

Scope - Identifying the right pilots

Characteristics considered:

– Project team / Project / Business engagement / User involvement

In order to learn as much as possible from the pilots...

– At least one pilot project should include some degree of dispersed team members

– At least one pilot project should include multiple teams

– At least one pilot project should involve co-operation with one or more internal and/or external vendors

– The pilots projects should cover different platforms (e.g. SQL server, Host/mainframe etc)

– The pilots should cover different kind of project types /tasks (e.g. new development, extension of existing systems, legislative, maintenance, error handling etc.)

– At a minimum 3 pilot projects should be planned

20

Decision Framework (detail)

21

Decision Framework (summary)

22

Major Activities for the pilots • Joint project planning

• “Adoption Through Execution”

•A small group of agile coaches will:

•Be trained and mentored on the practices to be deployed

•Determine the changes to the practices

•Document these modified practices

•Determine and document the tool usage model

•Determine initial metrics

•Projects will execute the new process and tools:

•Experienced coaches will mentor the team members and “grow” internal agile coaches

•Best practices will be harvested and the initial process updated

•Additional practices will be adopted by the teams

23

Project Specific Tools – RTC Agile Plan

24

Agenda




24

2

4

IBM Software Group improvement strategy Agile delivery has been informally adopted since the early 2000s,

likely earlier

The official adoption program started in 2006.

Adoption included these activities:

– Training and education at all levels in IBM Software Group (SWG), including

practitioners, middle management, and senior management

– Mentoring or coaching at all levels, particularly on project teams

– Alignment of tools with the agile process, include a significant adoption of tools

based on IBM Jazz™. Agile delivery adoption is a long-term, multiple-year

strategy, which is still underway

– Continuous process improvement

25

26

Improving productivity in IBM SWG through improved

agility

Y1 Y2 Y3 Y4 Y5

Headcount per Product Release 74 75

68

64

58 Revenue by Headcount

Lessons learned at IBM Train people on a just-in-time (JIT) basis:

– People lose 80-90% of newly gained knowledge within 4 weeks, if they don’t immediately apply that knowledge

Support team members: – Have a Center of Excellence (CoE)

– Have coaches or mentors

– Have champions or sponsors

– Have internal discussion forums

– Bring in outside speakers

– Support internal speakers

– Promote executive awareness of agile delivery, better yet, understanding

Support coaches and champions: – Offer coaching to people in both of these roles

– The CoE can often provide this required support

27

Lessons learned at IBM (continued) Be flexible:

– Individuals have different learning strategies

– Different teams are in different situations

– Aim for repeatable results, not repeatable processes

Have manageable growth: – Don’t increase the number of agile teams too fast; otherwise, teams cannot be

adequately supported

– Don’t increase the number of agile teams too slowly; otherwise people may experiment counterproductively on their own

– Treat agile adoption like an agile project

– Establish a release plan

– Schedule iterations after which you deliver something regularly

– Demonstrate your results, both successes and failures

– Reflect on what you’ve learned and steer the project accordingly

28

29

Metrics – Rational Development

Note: Goals are either internal IBM statistics or industry benchmarks.

Metric Goal Year 1 Measurement Year 3 Measurement

On Time Delivery 65% 47% 100%

Defect Backlog 3 Months 9+ Months 3.5 months

Enhancements Triaged 85% 3% 100%

Enhancements into Release 15% 1% 21%

Customer Sat Index 91% 88% 96%

Beta Defects Fixed Before GA 50% 3% 94%

Agile / Iterative Projects 25% 5% 78%

What results can you reasonably expect? Success criteria Year 1 Year 2 Year 3

Quality 3-5% fewer defects 3-5% fewer defects 3-5% fewer defects

Labor costs 2-3% improvement 4-5% improvement 4-5% improvement

Time to value 5% faster 10% faster 5% faster

Delivered functionality 5% improved

accuracy

5% improved

accuracy

5% improved accuracy

These figures pertain to a large-scale adoption across an IT department

The results are year-on-year

Agile delivery is not a cure-all

Beware anecdotal results from single-project teams. It’s easy to replace a troubled team with experts who show significant improvements

These numbers are conservative and based on experiences in developing IBM Rational software over the years. It is possible to do better

30

31

Agenda




31

3

1

General Transition Advice

Be prepared to confer with others to transfer your skills to them and to pick up new skills from them

Accept that “the rules” have changed and “you” must change too

Accept the idea that your traditional role might not exist anymore, although the team still completes activities that are associated with your traditional role

Be prepared to work in an evolutionary and collaborative manner

Be prepared to move away from a specialist role to become a generalizing specialist

Be prepared to deliver a potentially consumable solution every few weeks

32

Invest across the spectrum of improvements

Focusing on business outcomes offers the greatest return on investment

Source: IBM

Control

Efficiency

Business value

Individual Team Business Organization

Improve automation Improve processes

Improve collaboration

Increase flexibility and investment value

Implementation costs are per person per year

Cost to implement:

10%-35% Some culture change

Productivity:

25-100% Timeframe = Months

Cost to implement:

5%-10% Predictable

Productivity:

15-35% Timeframe = Weeks

Cost to implement:

25%-50% Much culture change

Productivity:

50-200+% Timeframe = Years

Cost to implement:

<5% Very predictable

Productivity:

5-25% Timeframe = Days

33

34

Planned Knowledge Transfer Activities

3 types of mentoring sessions

– Management workshops (2 hours)

– Project team workshops (2 hours)

– Role specific workshops (4 hours)

Train the trainer

– Trained local resources to deliver these mentoring sessions

Coach the coach

– Trained local resources enabled to do coaching in-house

Support framework

– Experienced agile coach allocated to each pilot for 1-2 days per week

– Support teams will be in place to provide advice, guidance and support for both method content and tools

Ensure general awareness and prepare for larger scale education through “roadshows”, articles, informal talks, etc.

Agile and the business – a different relationship

The business and IT processes must reflect one another:

– Plans must be high-level with the details coming just-in-time (JIT)

– Schedules and estimates must be given in ranges

– Traditional business approaches can eliminate most benefits of agile development

The new relationship with the business:

– Team members must be actively involved with development throughout the

lifecycle

– With greater visibility and control that teams have, teams also must become more

accountable

– Teams often don’t understand the implications of their requests; they must be

educated

35

Primary Challenge: Culture Change

Focus on delivering visible value to stakeholders regularly

– Specialists can struggle with delivering visible value at first

Focus on high-value activities

– Many traditional “best practices” are abandoned

Agile teams are self-organizing

– Many current managers struggle with self-organizing teams, and some people like

being directed

Disciplined agile teams are governed appropriately

– Your IT governance strategy will have to change

Disciplined agile teams are quality focused

– Quality is everyone’s job

36

Common Anti-patterns

Thinking you’re already agile

Focusing on a subset of the delivery process

Focusing on individual roles one at a time

Thinking that you’re in a special situation where agile practices can’t help

Danger!

37

38

Agile Transformation Best Practices

Adopt a “Stop-the-line” culture

– Eliminate technical debt

– Stop living with pain

Protect your teams

– Eliminate interruptions

– Be willing to say “No!”

– Foster a penalty-free environment

Provide support and encouragement

– Attend demos

– Encourage passion

– Promote self-directed teams

Advocate continuous improvement

– “If you’re not making mistakes, you’re not trying hard enough”

What is disciplined agile? Disciplined agile delivery is an evolutionary (iterative and

incremental) approach that regularly produces high-quality

consumable solutions in a cost-effective and timely manner

via a risk and value driven lifecycle.

It is performed in a highly collaborative, disciplined, and

self-organizing manner within an appropriate governance

framework, with active stakeholder participation to ensure

that the team understands and addresses the changing

needs of its stakeholders.

Disciplined agile delivery teams provide repeatable results

by adopting just the right amount of ceremony for the

situation which they face.

39

40

Critical Success Factors

Middle management championship is essential

– Winning over executives is easy

– Winning over practitioners is easy

– Winning over middle managers is HARD

- Architects, PMs, Test Managers and Development Managers

- These are the folks that must translate technical results into business results

Return on investment must be demonstrable in first deployments

• Incremental demonstration of value, early and often

• Disruption cost profile may dominate Value delivered profile

- You need to track and quantify both

Pilot significant change on business critical projects

• That is where the A-players are

• That is where organizational scrutiny/support is most intense

41

Summary




41

4

1

42

© 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

Partners

Demo Solution Center

Test

Requirements

DevOps

Modeling

Agile Planning

Integrations

JazzHub

Reporting

FocalPoint

implementing an agile transformation using discipline ... ruc/implementin… · implementing an...

Documents