carey schwaber analyst forrester research

TeleconferenceWhat’s New In Application Development Processes And Methodologies?Carey Schwaber

Analyst

Forrester Research

September 14, 2006. Call in at 12:55 p.m. Eastern Time

2Entire contents © 2006 Forrester Research, Inc. All rights reserved.

Definitions

► Software development methodologies consist of documented practices for building software.

► “A methodology is a process with a price tag on it.”


Agenda

• Reasons to revisit your development methodology

• Accommodation of multiple methodologies

• Methodology segmentation

• The methodology market: open and commercial

• How to get started and where to get help


Agenda







There’s ample room for improvement

Agree Strongly agreeSomewhat agreeSomewhat disagreeStrongly disagree Disagree

“Please indicate how much you agree or disagree with these statements aboutapplication software you use that is custom-developed by your IT organization.”

Source: Forrester’s Business Technographics® March 2005 United States Technology User Benchmark Study

“New apps or changes toexisting apps are deliveredat expected quality levels”

2% 7% 20% 29% 35% 7%

Base: 418 technology influencers at US companies with more than 500 employees who personally used custom applications developed by their IT organizations

(percentages may not total 100 due to rounding)

“New apps or changes toexisting apps are deliveredin the time frame needed”

3% 9% 20% 31% 30% 7%

Base: 417 technology influencers at US companies with more than 500 employees who personally used custom applications developed by their IT organizations

(percentages may not total 100 due to rounding)


The “if onlys” of application development

• App dev organizations feel they could build better software for less money in less time “if only”:

» Requirements change could be stamped out.

» There were time to conduct enough testing.

» [Insert your favorite noble goal here.]

• What if these are impossibilities?


Traditional process improvement efforts can make matters worse

• Process improvement often involves taking The Book Of Process and adding additional levels of detail and new means of enforcement.

• This appeals to command-and-control instincts.

• And this gives management the impression of having addressed the problem.

• But it doesn’t necessarily result in better software.

• Formalizing an ill-conceived development process can make matters worse, not better.


Why adopt a new methodology?

• Shops adopt new methodologies to:

» Improve time-to-market/productivity.

» Reduce total cost of development efforts.

» Enhance quality of delivered software.

» Strengthen relationships with business partners and end-user satisfaction.

» Comply with internal and external rules and regulations.

• Determining which of these goals is most important to you will help guide your methodology selection process.


Agenda







326

111212

7

14

25

Not applicableDon’t knowYes, we have onestandard methodology

across the entirecompany.

We have a set ofstandard

methodologies;different development

organizations andprojects can usedifferent standard

methodologies withinthis set.

No, differentdevelopment

organizations usedifferent

methodologies.

Less than $1B $1B or more

“Is a standard methodology — or set of methodologies — used by all of the developmentorganizations in your company (e.g., each business unit’s IT department)?” (2004)

Most firms don’t use a single standard methodology

Base: 83 companies


Methodology frameworks versus methodologies

• The premise: No single methodology can address all of a large organization’s needs.

• The solution: Customize one or more methodologies to build out a portfolio of methodologies (a “methodology framework”).

• Methodologies in a methodology framework share a common core of activities, deliverables, and metrics for the sake of standardized interfaces with external groups and easier reporting.

Elements core to all methodologiesin the methodology framework

Elements that vary by methodology


Template for a methodology framework

Risk category WebLegacy

maintenancePackaged

appsSOA

1: Low, <10 people, low $ risk, collated teams, <100 person-days

2: Low/medium

3: Medium, >30 people, moderate $$ risk, geographical distribution, >50 person-days, subject to internal compliance requirements

4: Medium/high

5: High, >50 people, large $$ risk, significant geographical, organizational, and/or cultural distribution, >100 person days, subject to external compliance requirements

Common factors: Project management, change management, requirements management, issue tracking, testing, and quality assurance


Currently conducting primary research on process rationalization

• Process standardization initiatives span large and heterogeneous organizational units.

• Full process standardization is rarely a possibility — and even when it’s possible, it’s often not advisable.

• The challenge? Finding a way to accommodate multiple methods and enable experimentation with new methods — all without creating unnecessary cost and complexity.

• Currently researching best practices and next practices for process rationalization, Forrester’s term for a rightweight approach to process standardization.

• Contact Megan Daniels ([email protected], 617/613-6359) about participation.

• Targeting publication in November 2006


Agenda







Development process taxonomy

All developmentprocesses

Waterfall Iterative

Agile


Waterfall versus iterative

Opportunity forrequirements

change


change


change


change

Project A: Waterfall development process

Project B: Iterative development process

J F M A M J J A S O N D

J F M A M J J A S O N D

Requirements definition Formal approval process for requirements change

Release

Release 1Iteration 0

Release 2 Release 3 Release 5Release 4


Agile iterations are not mini-waterfalls

• Activities like design, development, and testing are nearly concurrent.

• “Just enough upfront design,” “real-time specification,” and “continuous testing.”


What makes a process Agile instead of just iterative?

• Agile processes are defined by the presence — not the absence — of certain development practices:

» Incremental iterations, with the team delivering working software every few weeks

» Specific engineering practices are necessary to maintain the stability of the code base throughout each iteration

» Self-managing teams work together to determine how they will deliver the functionality they have committed to for a particular iteration

» Ruthless focus on the elimination of waste comparable in both theory and in practice to lean manufacturing


CMMi is not a development methodology

SourceMethodology

SEICMMi

ISOISO 9001, ISO/IEC 15504

US DODDOD-STD-2167A

SECC/IEEESWEBOK

n/aSix Sigma

• Standards describe recommended methodology content or means of process improvement

• These standards can be adopted alongside virtually any development methodology

OCGITIL


“Which of the following development methodologies are currently in use by any development organizations in your company?” (2004)

32

27

27

17

16

3

14

6

4

Homegrown iterative or spiral

Homegrown waterfall

Rapid application development (RAD)

Rational unified process (RUP)

Agile methodology (e.g., XP, Scrum, DSDM,FDD, Crystal)

Method/1

Don't know

None

Other

(multiple responses accepted)Base: 83 companies

Homegrown processesprevail. Waterfall processes,though largely discredited,are still in common usage.


Agile processes slowly gain interest“How aware are you of Agile

processes?”“How interested are you in

adopting Agile processes?”

Base: 346 software and services decision-makersat North American and European enterprisesthat are aware of but not already using Agile

Base: 911 software and services decision-makersat North American and European enterprises

Source: Forrester’s Business Technographics® November 2005 North American And European Enterprise Software And Services Survey


Agenda







Overall methodology market landscape

• What’s available: » Methodology content

» Tools to author, customize, and distribute the content

• Key sources for both: » Vendors

» Nonprofit organizations

» Communities of interest

» Open source projects

» This equals another dimension for methodologies: open and closed.

» But in the past two years, the line between open and closed methodologies has blurred.


What’s an “open source development process”?

1. A freely available development process

2. A development process used by an open source project

42

17

17

8

6

Open source software development has had noimpact on our development organization

We have adopted some techniques used by opensource projects.

We have adopted some open source tools

We have changed our organization/roles inresponse to the examples of open source

Don't know

Base: 83 companies

“How has open source development impacted your internal application development efforts?” (2004)

While still nascent, theinfluence of open sourceprojects’ techniquesis growing across thedevelopment community.


Examples of freely available development processes

• MSF

• OpenUP

• eXtreme Programming

• Scrum

• Dynamic Systems Development Methodology


An example of a process used by an open source project: “The Eclipse Way”

• Eclipse development practices emphasize feedback and project rhythm.

» Continuous testing, continuous integration, consume your own output, community involvement, new and noteworthy, milestones first, retrospectives, early incremental planning, always have a client, component-centric, dynamic teams, built to last, API first

» “The Eclipse Way,” Erich Gamma and John Wiegand, EclipseCon 2006: http://eclipsecon.org/2005/presentations/econ2005-eclipse-way.pdf

» “Java in the Trenches,” Erich Gamma and John Wiegand, JavaOne 2006: http://java.sun.com/javaone/sf/sessions/general/day3.jsp

• Eclipse development practices are Agile development practices.

• Open source projects and Agile projects behave very similarly.

• Eclipse is just one example of a very large-scale implementation of these practices.

© 2004, Forrester Research, Inc. Reproduction Prohibited

Comparing Traditional, Agile, And Open Source Development

May 2004, Best Practices “Applying Open Source Processes In Corporate Development Organizations”


• IBM Rational Unified Process (RUP)» RUP and plug-ins provided by IBM and IBM partners*

» Eclipse Process Framework (EPF) and OpenUP

» Partners involved via EPF include CGEY, BearingPoint, Covansys, Number Six Software, Telelogic, and Xansa.

• Microsoft Solutions Framework (MSF)» MSF For CMMi Process Improvement

» MSF For Agile Software Development

» Partners like Conchango and Cognizant have provided plug-ins for Scrum and Feature-Driven Development, respectively.

RUP and MSF: a tale of two process frameworks

* Sample RUP plug-ins made available by IBM target SOA maintenance, COTS packagedelivery, systems engineering, and user experience. A full list of RUP plug-ins is available athttp://www-128.ibm.com/developerworks/rational/library/05/1206_ibmstaff/


IBM Rational Method Composer (RMC) and RUP

• Methodology framework that includes the process guidance of RUP and SUMMIT Ascendent

• Strengths:

» Strong tool support (RMC, an Eclipse-based tool) for authoring, configuring, viewing, and publishing processes

» Integrated with Rational Portfolio Manager; process guidance available from within other IBM Rational tools

» Breadth and depth of content

» Plug-in architecture and sheer number and diversity of plug-ins

• Weaknesses:

» No support for process implementation (e.g., workflow automation)

» Range of possible customization is daunting

• Best for:

» Definition of methodology frameworks for large enterprises

• Additional resources:

» www.ibm.com/software/awdtools/rup/


The Eclipse Process Framework (EPF)

• Founded by IBM Rational

• Still in “incubation” phase

• Elements include:

» Commercial, free, and custom process content

» Tooling

» Common metamodel (Unified Method Architecture)

» Built on Eclipse

• RMC and RUP will be based on EPF Composer and OpenUP:

» EPF Composer is a subset of the functionality in RMC; OpenUP/Basic is a version of RUP for small projects.

» Future releases of Rational Method Composer will be based on key milestones/releases of EPF Composer; future releases of RUP may include OpenUP content.


» eclipse.org/epf


Microsoft Solutions Framework (MSF)

• A methodology framework that includes Microsoft’s MSF for Agile Software Development and MSF For CMMi Process Improvement

• Strengths:

» Includes not just process guidance but also iteration structure, work item type definitions (data, workflow, and UI), queries, and starting list, permissions and policies, a project portal, and document templates for use within Visual Studio Team System.

» Process content available outside of this context as well.

• Weaknesses:

» Customization is currently accomplished by editing HTML, Word, and XML files.

» Less breadth and depth of process guidance than is found in RUP.

• Best use:

» Microsoft shops looking for basic guidance and workflows for lightweight iterative processes.


» microsoft.com/msf


Common question: Are RUP and MSF Agile?

• RUP and MSF are methodology frameworks, not methodologies.

• RUP and MSF can be used to define any methodology — waterfall, iterative, or Agile. For example:

» Companies often adopt RUP specifically because they want to accommodate waterfall and iterative development.

» Microsoft partners have created Agile flavors of MSF, but MSF Agile itself is not itself an Agile process.

• In practice both RUP and MSF are most often used to define iterative processes

• RUP and MSF are Agile in the sense that they are flexible, but they are not Agile in the sense of belonging to the family of Agile processes or fully embodying the principles of Agile development.


Agile processes (XP, Scrum, DSDM) overall

• Strengths:

» Close collaboration of business customers with development team

» Dramatic time-to-benefit, quality, business customer satisfaction, and employee morale improvements

» Myriad consultancies available to assist with implementation

» Large and vibrant community

» Large volumes of print and online literature

• Weaknesses:

» Requires significant organizational change management

» No single source of truth about what Agile is and is not

• Best for:

» Shops that need to improve the results of their development efforts in the face of competitive pressures, the threat of outsourcing, etc.

» Small, collocated project teams


eXtreme Programming and Scrum in particular

XP

• Strengths:

» Engineering practices (test-driven development, continuous integration)

» Keeps software quality high throughout each iteration

• Weaknesses:

» Lack of interfaces with other IT processes (e.g., QA, PPM)

» Not very strong on project management practices

• Best use:

» Small collocated teams facing time-to-market pressures and/or struggling with software quality

Scrum

• Strengths:

» Project management practices for incremental, iterative projects

» Ensures that the software that is ultimately delivered meets business needs

• Weaknesses:

» Narrow scope, with virtually no recommendations for engineering practices

• Best use:

» Small collocated teams struggling with time-to-market and/or business stakeholder satisfaction challenges

» Product companies


Dynamic Systems Development Method (DSDM)

• Framework for project delivery created in 1994 by the DSDM consortium.

• Strengths:

» A single coherent body of knowledge about how to manage development projects using Agile principles and methods.

» Backed by an established nonprofit organization that provides a manual, training courses, accreditation.

» Previously very affordable; now free for end user companies

• Weaknesses:

» Stronger on life-cycle management than on granular development practices

» Minimal market share, especially outside of North America

• Best use:

» Shops looking for a defined Agile process supported by an established organization.

» Enterprises that want the benefits of Agile development without the radicalism of some Agile processes.


What are IBM and Microsoft doing about Agile?

• OpenUP/Basic and MSF Agile are meant to be Agile processes.

• What distinguishes these process from Agile processes is that they are “tooled.”

• The challenge of adopting Agile is not tooling, but people.

• The danger of OpenUP and MSF Agile is that enterprises will think they can adopt Agile by implementing a tool.

• The result? Users will either:

» Think they’re doing Agile and be disappointed by the results.

» Figure out that Agile processes aren’t toolable and resort to other means of Agile adoption (literature, community, coaches, co-sourcers).


What it means

• Proper Agile processes are best for shops that need to dramatically improve their development efforts and can tolerate significant change.

• RUP and MSF are better for shops that are under less pressure to change their ways.

• Technology platform should influence companies choosing between these two dominant methodology frameworks.


Agenda







Two primary models for process consulting services

• Co-sourcing

» Consultant co-sources a project to pilot the new process

» Project members are then used to seed other projects

• Coaching and mentoring

» Ongoing or intermittent guidance from experienced experts

» With intermittent guidance, team learns to work through issues on its own

» With ongoing guidance, very small number of coaches

• Both models typically involve initial training

There are other models, but these are the most effective.


10

4

1

5

2

1

5

4

2

0

21

7

2

2

5

1

1

6

2

2

Systems integrators/consultants

Vendors of methodologies/process management tools

Tools vendors

Books

Internet sites

Conferences

User groups

None: We never go outside of our own organization for help withdevelopment processes

Don’t know

Other

Less than $1B $1B or more

SIs/consultants are the most popular choice for help with development processes

“Where does your company go for help with development processes?”

Base: 83 companies


Key consultancies

RUP• IBM

• NumberSix

• CGE&Y

• BearingPoint

• Covansys

• Sogeti

• Deloitte Consulting

Agile• ThoughtWorks

• Sapient

• Conchango

• ObjectMentor

• Net Objectives

• eXoftware

• ValTech

• Quadrus

• Xansa

• Digital Focus


Recommendations

• Determine degree of process rationalization required.

• Determine goals of process rationalization.

• Gauge the relative need for process definition and process automation.

• Evaluate methodologies on scope, breadth, and depth.

• Evangelize the new process(es).

• Train the development organization on a team-by-team basis.

• Take a “train the trainer” approach, and seed novice teams with experienced resources.


Carey Schwaber

+1 617/613-6260

[email protected]

www.forrester.com

Thank you

carey schwaber analyst forrester research

Documents