experience from agile adoption in distributed environment

Experience from

Agile adoption

in distributed

environment

Software Development

2008

Jaroslav Procházka

Tieto / University of Ostrava

Jaroslav Procházka Tvorba softwaru 2008 2

Agenda

• Introduction, background

• Main problems in SWD

• Agile and small Czech businesses

• Agile and large global sourcing projects

• Common questions, pitfalls

• Experienced problems

• Conclusion


Background

• Support (in house apps, MSBS) – 3 years

• Java EE, ME developer and PM – 4 years

• ITIL consultant (mostly CZ, SK) – 2 years

• Agile and Lean coach and mentor (CZ/Europe) – more than 2 years

now


Agile manifesto

Stressed communication

Continuous delivery

Simplicity

Change tolerance


Main problems in SWD

• Never used features

• Not met agreed time & budget

• Quality issues

• Misunderstood requirements

• Bad estimates (for the whole project, for 2nd part of lifecycle: coding,

integration and testing), for maintenance issues.

• Overloaded people

• Unpredictable events

Source: Standish Chaos report


Agile and small

Czech businesses Easier to use agile techniques, often informally used:

• Smaller and co-located teams

• Team members believe the champion bringing Agile

(senior architect, PM, company’s visionary)

• Communication mostly not a problem

• Informal and valuable communication channels

(“hallway” communication)

• Smaller projects (3 to 9 people working on project)

• Teams having better contact with management

• Cross-functional teams


Agile and large global

sourcing projects

• Harder communication

(distribution, expensive channels, de-

personalized communication)

• Subjective requirements interpretation

(hard access to the customer)

• Micro-management

(onsite tendency to manage offsite

teams)

• Functional division of application

• Waterfalish thinking


Agile myths

• No documentation exists

• No analysis is done, only coding

• No architecture exists

• Only developers need to be agile

(not sales, managers, HR)

• Suitable only for green field development, small and co-located

teams


Experienced problems 1/4

1. Fundamental issue – mindset change and mentality

“Yes we do iterative (agile) development”

– 1st iteration Requirements gathering

– 2nd iteration Analysis

– 3rd iteration Design

– …

– Release 1x or 2x per year

– Analyst role creating Specification and throwing over the wall

to designers, …


But it is not Agile ….



2. Communication

– Assumptions behind decisions

– Ineffective communication

channels

(communication overhead)

– Just names somewhere

(lacking personal relationships)


But Agile means …

Communication around the

architecture



3. Commitment – support from management and sales people

(must understand “agile business model”)

– Fix price often mean fix all (scope, money, time)

hard to get benefits from Agile way of working

– team member’s commitment is built in

• XP: team member need to commit for values

• Scrum: team commits for sprint backlog



4. Tracking the progress and evaluation criteria – focus on plans and what is done from the plan

– focus on remaining work (e.g. Burn-down charts from Scrum)

Definition of done (DoD) Important and measurable milestones:

– 100% of unit tests passed

– 65% unit test coverage

– Max. 2 middle impact defects

– 0 high impact defect

– Regression tests coverage 70%

– All regression tests passed

– User has accepted demonstration


Where and how to start?

• Involve experienced mentor from the beginning

– To avoid reinventing the wheel

– To speed up the start

• Start with a small skilled team, known domain, technology

– Less risky pilot

• Do initial assessment with the mentor

– To fix the poorest part

– Repeat continuously to keep focus

• Avoid big bang adoption

– Implement techniques iteratively (same as software)

OpenUP is a good start • Minimal process

framework for software

development

• Contains Agile and

Lean practices



Conclusion

• To develop or maintain software following Agile approach is not easy:

– Mindset change is required

– Depends on people ;)

– Team commitment, involvement (team’s decisions) is the key

– Servant leader instead of manager

• Basic practices and techniques are described

• But skilled person to support implementation in the context of your organization is needed

experience from agile adoption in distributed environment

Technology

agile

mentor

management

fix

coding

project