Issues with Enterprise Adoption of Agile Technology

8/6/2019 Issues with Enterprise Adoption of Agile Technology

1/53

Issues with EnterpriseAdoption

Presentation 10

Aniket Mahanti

Managing Iterative Projects


2/53

2

Overview

Benefits of agile methods

Technology adoption cycle

Challenges in adopting agile methods

Introducing agile methods Agile adoption strategies

Agile adoption case study

Limitations of agile methods

Measuring success

Agile in large organizations

Conclusions


3/53

Benefits of AgileAdoption


4/53

4

Why use Agile methods?

Improved ROI

Early detection and cancellation of failing

projects Higher software quality

Improved control of a project

Reduced dependence on individuals andincreased flexibility


5/53

Technology AdoptionLife Cycle

Agile methods

The Chasm

Fuzzy Logic Adoption


6/53

6

Technology Adoption Life Cycle

T.A.L.C. originally developed at Iowa State

College (1957)

Track purchase of hybrid corn seeds byfarmers

Everett Rogers broadened the use of this

model in Diffusions of Innovation (1962)

Continuous process model


7/53

7

Rogers T.A.L.C.


8/53

8

Geoffrey Moores T.A.L.C. (1991)

High tech markets evolve thru a series ofphases

Each phase requires business strategy tochange because adjacent strategiesundermine each others strategies

When applied to high tech world, Product life

cycle is discontinuous (Cr

ossing theC

hasm) Cracks in the bell curve: Between any two

groups there is a gap


9/53

9

The Chasm

Venturesome

Confident Deliberate Skeptical Tradition-bound


10/53

10

Fuzzy Logic Adoption

FL developed in the 70s at UC Berkley

Coupling FL and expert system technologies

allowed better modeling imprecise reasoningprocesses of skilled human experts

FL adoption faced resistance in N. America

because of its fuzzy name

Japan very quickly adopted FL and by mid

90s almost all major appliances used the

technology


11/53

Challenges in AdoptingAgile methods


12/53

12

Challenges in Agile adoption

Serial thinkers

Closed mindedness

Office politics

Black and white mindedness

Fear of change


13/53

13

Challenges in Agile adoption (2)

Specialized skills

Out of date skills

Documentation-heavy mindset

Do it all at once attitude


14/53

14

Serial Thinkers

Many IT professionals think in a serial

manner

They want to identify and analyzerequirements before tackling design, and

design most of the system before coding

Need to give time, training, and mentoring to

these people

Be vigilant


15/53

15

Closed Mindedness

Many professionals have not invested time

understanding new methodologies

Assume that agile is code-and-fixin disguise Some people who can not be taught new

ideas should be asked to look for new

avenues

Actively educate

Challenge any misinformation being spread


16/53

16

Office Politics

Some people will prevent agility to save their

power base

Smart politicians will support the agilecrossover, but will wait for it to fail

Become politically adept


17/53

17

Black and White Mindset

Many people believe that issues need to be

eitherblackorwhite

Need to understand that there is greyand aspectrum ofcolors also

Inflexible people make agile adoption difficult

Most organizations need to adopt a range of

methods, some agile and some traditional.


18/53

18

Fear of Change

Adoption of agile methods likely requires

significant changes in the way the

organization works Fear of inability to learn new agile skills

Fear of not being able to fit into the new

environment

People who fear change will actively protest

and undermine adoption efforts


19/53

19

Specialized Skills

Many IT professionals have become

specialists with a very narrow skill set

because of serial development They have problems working with people

outside their specialties

Generalizingspecialists can work with a

wider range of artifacts

Expansion of current skill set necessary


20/53

20

Out of Date Skills

People not having strong object-oriented

programming background unprepared for

agile approaches Organizations have cut training and

education budgets

Faced with steep learning curve

Sufficient training and time should be

provided to improve skill set


21/53

21

Documentation-heavy Mindset

Wrong notion of developing comprehensiverequirement documents and detailed designmodels as an effective way to produce

software Take the agile approach to documentation

People need to be retrained to work with less

documents Some people could be reassigned to other

efforts to keep team agile


22/53

22

Do It All at Once Attitude

Serious mistake to adopt all agile principles inone go

Adopt agile techniques one at a time

Evolve the work environment over several

years to make the transition smoother


23/53

Introducing AgileMethods


24/53

24

How to Introduce Agile

Processes?

Obtain management buy-in

Education and support

Integrate to external processes Start pilot projects

Report and adapt

Sustain agility


25/53

25

Obtain Management Buy-in

Management needs to understand the

benefits that agile approaches can bring

Upper management involvement single mostimportant factor in introducing agile methods

Direct move to agile could be difficult

Using agile as a recovery mechanism for

failing projects could be more fruitful


26/53

26

Education and Support

Developers and management need to

understand values, practices, and principles

of the new methodology

Misconceptions should be eliminated

Responsibility associated with empowered

teams should be taught gradually

Support and time for transition should be

provided


27/53

27

Integrate to External Processes

Integrate agile practices into existing non-

agile processes

Draw information from the literature Create plans or status reports in traditional

format to obtain approval

Be ready to create additional lower value

deliverables

Important for facilitating agile introduction


28/53

28

Start Pilot Projects

Start a project that will deliver high business

value

Project should have respected and articulatebusiness sponsors

Helps maintain the momentum to switch to an

agile approach

Pilot => Pathfinder => Production


29/53

29

Report and Adapt

Publicize the success of the pilot projects

Raise awareness and listen to comments

Use the experiences of the empoweredteams to plan future agile projects

Ask the team involved in the pilot projects to

become mentors in subsequent projects


30/53

30

Sustain Agility

Provide constant encouragement and

stimulation so that teams do not go back to

the old approach

Promote discussion thru special interest

groups, practice groups, etc.

Management should take up a stewarding

role


31/53

Agile AdoptionStrategies

Agile Adoption Case Study


32/53

32

Agile Adoption Strategies

Wholesale

Adopting a set of practices en-masse

Need to experience the synergy of practices andthe danger of omitting supporting practices

Incremental

Adopting only specific practices

Need to temper disruptive change


33/53

33

Case Study: Control Systems

Manufacturer

Project intended to update their agingsoftware for the control of maintenance

systems in nuclear power facilities Limited agile adoption effort; small subset of

developers assigned to the agile team

Team chose to forego initial training and did

not utilize a common working area Several team members were shared with

other, non-agile projects


34/53

34

C.S.M.Wholesale Adoption

Upon beginning the 2-week iteration, team

immediately realized the need for basic

environmental support

Team frequently paused to conduct

impromptu training sessions for new

practices

First iteration delivered almost no businessvalue


35/53

35

C.S.M.Wholesale Adoption (2)

Team thought that initial experiences were

isolated to the first couple of iterations

They also though that they would quicklyramp up their velocity as the initial adoption

overhead is put behind

They understood their learning curve was

larger than anticipated, but maintained hopethat majority of learning was behind them


36/53

36

C.S.M.Wholesale Adoption (3)

After 10 weeks, recognizing the difficulties of

the team the technical manager intervened

Review showed less than20% of theprojected business value was achieved

Manager asked the team to revert back to

their previous development process

Decision was not well accepted


37/53

37

C.S.M.Retrospective

Severely underestimated the affect of

concurrent preparation and learning activities

on the ability to deliver business value

Development velocity set too large

Iteration zero for preparation and learning

Overhead of learning activities and

complexities of actual development

overwhelmed the developers


38/53

Limitations of AgileMethods


39/53

39

Limitations of Agile Processes

Limited support for distributed developmentenvironments

Limited support for building reusable artifacts

Limited support for development involvinglarge teams

Limited support for developing safety-critical

software Limited support for developing large, complex

software


40/53

40

Distributed Development

Environments

Distributed development environments not

able to accommodate face-to-face

communication advocated by agile methods

Hurdles in terms of team communication,

development culture, and customer

participation

Difficult for mainstream offshore vendors toadopt agile methods


41/53

41

Development with Large Teams

Large number of communication lines could

reduce effectiveness of review meetings and

face to face communications

Traditional software engineering practices

that emphasize documentation, change

control and architecture-centric development

more applicable Degree of agility may be less


42/53

Measuring Adoption andSuccess


43/53

43

Measuring Adoption and Success

Productivity: size/effort Size should reflect the amount of functionality

provided to the customer

Effort should measure the amount of work fordeveloping the new functionality

Cost reduction

Time-to-market compression

Quality improvement

Compare hard data to benchmarks


44/53

44

Measuring Adoption and Success (2)


45/53

Agile Methods in LargeOrganizations

Challenges

Prospects


46/53

46

Agile in Large Organizations

Systematic study as 15 pilot XP projects

Projects often depend on their environment;

work is distributed across several teams Introducing XP without extensive tailoring is

infeasible

Challenges lie in resolving incompatibilities

between the agile project and the

environment


47/53

47

Project Environment


48/53

48

Lessons Learnt

Large organizations often follow defined

software processes which can result in

double work when projects apply new

practices

Having mature processes already in place

ensures that efforts to become agile do not

turn a mature organization into a chaotic one


49/53

49

Agile in Large Organizations:

Prospects

Nothing prevents large organizations fromtrying XP on a small scale

Agile methods as another tool in software

process improvement toolbox

XP could be used to develop large, complex,safety-critical systems with long lifecycles

XP works best for small, independent,collocated projects; agile methods willinfluence other processes


50/53

50

Success Factors of Change

Eight determinants of organizational change (Conner, 1992)

Active sponsorship

of CIO

Death leap

stance Implementation

practices,

monitoring project

metrics, change

dynamics

Right people, good

team, accountable,

clear goals

Middle/upper

management, non-

management

opinion leaders

Existing HR practices, work

design, organizational

structure, policiesTraining, multi-way

communication, new roles

Change is amarathon, not a

sprint.


51/53

Conclusions


52/53

52

Conclusions

Agile yet to cross the chasm!

Most studies conducted for adopting agile

methods did not follow a scientific process Qwest experience is a positive indication

Hybrid (in-house evolutionary) approaches

best suited for use in large organizations

Refrain from wholesale adoption


53/53

53

Sources and References1. Cisco Systems, The Five Phases of SuccessfulService Development, 2000

2. Dan Turk et al., Limitations of Agile Software Processes, In Proc. of XP02 Conf.,

pg 43-46, 20023. Donald Reifer, HowGood Are Agile Methods?, IEEE Software, Vol. 19, No. 4, 20024. Gerold Keefer, Extreme ProgrammingConsidered HarmfulforReliable Software

Development, AVOCA GmbH, 2002

5. Jim Highsmith, Objections to Agile Development, Agile Project Management WhitePaper, Cutter Consortium, 2004

6. John Vecchio, The Tech Adoption Life Cycle, Fools Den, 2000

7. Mary Poppendieck, Crossing the Chasm: Moving XP into the Mainstream, 2004

8. Michael Spayd, Evolving Agile in the Enterprise: Implementing XP on a Grand Scale,In Proc. of ADC03 Conf., pg 60-70, 2003

9. Mikael Lindvall et al.,Agile Software Development in Large Organizations,IEEE Computer, Vol. 37, No. 12, 2004

10. Mike Cohn et al., Introducing an Agile Process to an Organization, IEEE Computer,Vol. 36, No. 6, 2003

11. Mike Griffiths, Crossing the Agile Chasm: DSDM as an Enterprise Friendly Wrapper forAgile Development, White Paper, Quadrus Development, 2003

12. Paul Hodgetts, Refactoring the Development Process: Experiences with the IncrementalAdoption of Agile Practices, In Proc. of ADC04 Conf., pg 106-113, 2004

13. Scott Ambler, Remaining Agile, AmbySoft, 2005

14. Stephanie Moore et al., Offshore Outsourcing and Agile Development, ForresterResearch Report, 2004

15. Steve Hayes, Why use Agile Methods?, ZDNet Australia, 2003

16. Tuomo Kahkonen,Agile Methods forLarge Organizations- BuildingCommunities ofPractice, In Proc. of ADC04 Conf., pg 2-10, 2004

Issues with Enterprise Adoption of Agile Technology

Documents

Transcript of Issues with Enterprise Adoption of Agile Technology