® IBM Software Group © 2007 IBM Corporation Scaling Agile Software Development for the Real World...

®

IBM Software Group

© 2007 IBM Corporation

Scaling Agile Software Development for the Real World

Scott W. AmblerPractice Leader Agile Development

IBM Software Group | Rational software

2

Scott Ambler - Background Practice Leader Agile Development

Senior Contributing Editor, DDJ

Fellow – International Association of Software Architects

www.ibm.com/rational/bios/ambler.html

www.ibm.com/developerworks/blogs/page/ambler


3

Agenda Warning!

Agile Software Development

Agile Adoption Rate

Scaling Agile

Successful Adoption


4

Warning! I’m spectacularly blunt at times

Many new ideas will be presented

Some may not fit well into your existing environment

Some will challenge your existing notions about software development

Some will confirm your unvoiced suspicions

Don’t make any “career-ending moves”

Be skeptical but open minded


5

Agenda Warning!

Agile Software Development What is Agile?

How Agile is Different

Agile Mythbusters

Agile Adoption Rate

Scaling Agile

Successful Adoption


6

What is Agile?

An iterative and incremental (evolutionary) approach performed in a highly collaborative and self-organizing manner with just the right amount of ceremony to frequently produce high quality software in a cost effective and timely manner which meets the changing needs of its stakeholders.

Core principles “Fits just right” process

Continuous testing and validation

Consistent team collaboration

Rapid response to change

Ongoing customer involvement

Frequent delivery of working software


7

How Agile is Different

Focus on collaboration: Less paperwork and more conversation

Stakeholders actively involved

Focus on quality We have a full regression test suite for our systems

We develop loosely-coupled, highly cohesive architectures

We refactor to keep them this way

Focus on working software: Greater feedback makes agile projects easier to manage

Less documentation is required

Less bureaucracy

Agilists are generalizing specialists: Less hand offs between people

Less people required

Specialists find it difficult at first to fit into the team

Agile is based on practice, not theory: This is a significant change from traditional

You need to see how agile works in practice to truly understand it


8

Addressing Misconceptions about Agile

1. Agile teams write documentation

2. Agile teams model

3. Agile requires greater discipline than traditional approaches

4. Agile teams do more planning than traditional teams, but it’s just in time (JIT)

5. Agile is more predictable than traditional

6. Agile scales very well

7. RUP can be as agile as you want to make it

8. Agile is not a fad, it is being adopted by the majority of organizations

9. Agile can do fixed price, but it’s still poor practice to do so


9

Agenda Warning!


Agile Adoption Rate Survey overview

Adoption rates

Success rates

Iteration lengths

Scaling Agile

Successful Adoption


10

Yes69%

No31%

Has Your Organization Adopted One or More Agile Techniques?

18% of respondents indicated they’re still in the pilot stage

15% of “No” respondents hope to do Agile this year

Source: Dr Dobb’s 2008 Agile Adoption Survey


11

Why Agile/Lean? It’s More Successful

Quality: 87% believe that delivering high quality is more important than delivering on time and on budget

Scope: 87% believe that meeting actual needs of stakeholders is more important than building the system to specification

Money: 80% believe that providing the best ROI is more important than delivering under budget

Staff: 76% believe that having a healthy workplace is more important than delivering on time and on budget

Schedule: 62% believe that delivering when the system is ready to be shipped is more important than delivering on schedule Source: Dr Dobb’s 2007 Project

Success Survey


12

Why Agile? Because it Works!


13

60

72

83

78

0 20 40 60 80 100

All

Co-Located

Near Located

Far Located

Agile Projects Success Rates (%)(214 co-located projects, 210 near located, 129 far located)



14

0 20 40 60 80 100 120 140 160

1 to 5

6 to 10

11 to 20

21 to 50

51-100

101 to 200

200+

Attempt Success

Largest Team Size Attempted vs. Successful



15

Agenda Warning!


Agile Adoption Rate

Scaling Agile Challenges with Agile in the Mainstream

Agility is Relative

AMDD Practices

Agile Testing

RUP Agile

Agile Data Practices

Successful Adoption


16

Challenges with Agile in the Mainstream

Agile Development

Co-located

Geographical distribution

Global

Application complexitySimple, single platform

Complex, multi-platform

Team size

Under 10developers

100’s ofdevelopers

Work groups

In-house Third party

Governance

Informal Formal

Entrenched process, people, and policy

Minimal Significant

Enterprise discipline

Projectfocus

Enterprisefocus

Compliance/regulations

Low risk Critical,Audited


17

Agility is Relative – It Depends on Project Dynamics

Technical and Regulatory Drivers

ComplianceGovernance

Application complexity

Organizational DriversTeam Size

Geographical DistributionOrganization Distribution

Entrenched process, people, policy

Small team New projects Simple application Co-located Minimal need for documentation

Maturing projects Multi-platform Growing in complexity Remote or offshore work Greater need for

coordination and handoffs

Mature or existing projects Large teams Complex, multi-platform

applications Distributed teams Need for scalability, reproducibility,

and traceability


18

Agile Modeling Best Practiceswww.agilemodeling.com/essays/bestPractices.htm


19

Comprehensive Agile Testing

Source: January 2007 Dr. Dobb’s Magazine

(www.ddj.com/dept/debug/196603549)

TDD is a form of confirmatory testing

TDD is a great start, but it’s not the full testing picture

Effective agile teams push their working builds to an independent test team on a regular basis for investigative testing

Change stories must be prioritized and put back on the team’s work stack

Defects == Requirements


20

Agile Database Practices

Database Refactoring www.agiledata.org/essays/databaseRefactoring.html

Database Regression Testing www.agiledata.org/essays/databaseTesting.html

Continuous Database Integration www.martinfowler.com/articles/evodb.html


21

Scale Agile via Rational Unified Process (RUP)

Organizations have instantiated RUP to be very agile

Scaling strengths: Risk-driven milestones

Explicit “go/no-go” decision points

Stakeholder concurrence gained during Inception

Architecture proven via working software during Elaboration

Managed deployment during Transition


22

Agenda

Warning!


Agile Adoption Rate

Scaling Agile

Successful Adoption Measured Capability Improvement Framework (MCIF)

Critical IBM Agile Resources


23

Example: Financial Service Company

Satisfy compliance mandate

Enable flexible/global resourcing

Improve oversight

Improve consistency/predictability

Increase innovation

Improve productivity

Reduce time-to-market

Operational Objectives

Recent SOX audit failure

Inconsistencies with integrated financial reporting

Functionality of customer web falling behind competition

Create financial products more quickly

Customer Business Challenges

Measured capability improvement frameworkMap business value to software delivery practices

Outside scope

Target: Phase 1

Already implemented

Software Delivery Best Practices

Shared vision

Use-case driven development

Whole team

Continuous integration

Iterative development

SOA modeling

…Structured testing

Test management

Functional testing

Security testing

Architecture modeling

SOA governance

Asset-based development

Test-driven development

2-level project planning

Risk-value lifecycle

Asset governance

Enterprise SOAAdopt Practice

80.46E

100.39D

61.618C

41.414B

72.322A

Innovation(Cust. Sat. )

Quality (Defect

Density)

Time to Market (M)Project

Business Metrics Ongoing Adoption Assessment


24

Critical IBM Agile Resources

www.ibm.com/rational/agile/

www.ibm.com/developerworks/

www.ibm.com/developerworks/blogs/page/ambler


25

© Copyright IBM Corporation 2007. 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, the on-demand business logo, Rational, the Rational 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.


26

IBM Rational Method Composer including RUP A configurable process platform to capture processes and

best practices

Adapt the process unique project needs

Templates provide process guidance to get teams up and running quickly

IBM developerWorks A thriving community of 5.7 million practitioners

One of the industry’s predominant sources for learning and best practices

Expert services so you don’t have to go it alone IBM Software Services, Rational

Rational experts in Agile Development and RUP

IBM Accelerated Solutions Delivery Practice, Global Business Services Focused on Agile discipline since 1998 Agile consulting, assessments, project delivery and transformational implementations

IBM Best Practices to Enable Agile SuccessProven. Practical. Flexible guidance.


27

Organization

Roles &Responsibilities

Processes

Measures

Policies &Standards

Mission & Principles

Lean Development Governancewww.ibm.com/developerworks/

Pragmatic Governance Body

Staged Program Delivery

Business-Driven Project Pipeline

Scenario-Driven Development

Simple And Relevant Metrics

Continuous Project Monitoring

Iterative Development

Adapt The Process

Risk-Based Milestones

Continuous Improvement

Embedded Compliance

Align HR Policies With IT Values

Align Stakeholder Policies With IT Values

Promote Self-Organizing Teams

Align Team Structure With Architecture

Integrated Lifecycle Environment

Valued Corporate Assets

Flexible Architectures


28

Mainstream Agile Practices

Regular Deployment of Working Software

Non-Solo Development Refactoring Continuous Integration Configuration Management Test Driven Development

(TDD) Agile Testing Agile Documentation


29

Survey Results Agile Adoption Survey

February 2008

Message sent out to DDJ mailing list

642 respondents:

54.8% were developers, 29.4% were in management

41.6% had 10-20 years IT experience, 37.2% had 20+ years

37.7% worked in orgs of 1000+ people

71% worked in North America, 17% in Europe, 4.5% in Asia

Data, summary, and slides downloadable from www.ambysoft.com/surveys/

Project Success Survey August 2007

Email to DDJ mailing list

586 respondents

54% were developers/modelers, 30% were in management

73% had 10+ years in IT

13% worked in orgs of 1000+ IT people

84% worked in commercial firms

69% North American, 18% European


30

Service Offering: Health Assessment for Software Delivery

Identify drivers for delivery improvements

Current state: Showcase practice adoption level for target projects

Future state: An initial roadmap outlining how you can evolve your delivery approach to address your key business drivers

List of inhibitors that may prevent successful adoption of target practices

Identifies potential metrics that help you track progress on the implementation of your roadmap


31

0 2 4 6 8 10

Reflections

Non Solo

Iterative

Scrum meeting

Automated Unit Tests

Use Cases

Vision

Evol. Architecture

Big Picture of Practice Adoption

Deep Dive on Practice

IBM Rational Self Check for Software Teams

Practice Comments Average Deviation

Use Cases Use Stories instead 7.8 0.50

Unit Test Not enough, not in build 6.8 1.89

Stakeholder Feedback Want more 8.5 0.58

Time-Boxed Iterations Not well specified 8.3 0.50

Daily Scrum Not Fridays 9.3 0.50

Test Early Not enough TDD 4.5 1.91

Reflections Need clear actions 8.8 0.50

Static Analysis Not automated yet. 3.3 0.96

The Assessment Tool

Experience Report


32

References and Recommended Reading www.agilealliance.com www.agilemodeling.com www.agiledata.org www.enterpriseunifiedprocess.com Ambler, S.W. (2002). Agile Modeling: Effective Practices for XP and the UP. New York:

John Wiley & Sons. Ambler, S.W. (2003). Agile Database Techniques. New York: John Wiley & Sons. Ambler, S.W. (2004). The Object Primer 3rd Edition: AMDD with UML 2. New York:

Cambridge University Press. Ambler, S.W. and Sadalage, P.J. (2006). Refactoring Databases: Evolutionary Database

Design. Reading, MA: Addison Wesley Longman, Inc. Larman, C. (2004). Agile and Iterative Development: A Manager’s Guide. Reading, MA:

Addison Wesley McGovern, J., Ambler, S.W., Stevens, M., Linn, J., Sharan, V., & Jo, E. (2003). The

Practical Guide to Enterprise Architecture. Prentice Hall PTR.

® IBM Software Group © 2007 IBM Corporation Scaling Agile Software Development for the Real World...

Documents

Transcript of ® IBM Software Group © 2007 IBM Corporation Scaling Agile Software Development for the Real World...