Short summary of our lessons from Agile implementation in distributed environment

1. Experience from
Agile adoption
in distributed
environment
Software Development
2008
Jaroslav Procházka
Tieto / University of Ostrava

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
Jaroslav Procházka Tvorba softwaru 2008 2

3. 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
Jaroslav Procházka Tvorba softwaru 2008 3

4. Agile manifesto
Stressed communication
Continuous delivery
Simplicity
Change tolerance
Jaroslav Procházka Tvorba softwaru 2008 4

5. 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
Jaroslav Procházka Tvorba softwaru 2008 5

6. 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
Jaroslav Procházka Tvorba softwaru 2008 6

7. 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
Jaroslav Procházka Tvorba softwaru 2008 7

8. Jaroslav Procházka Tvorba softwaru 2008 8

9. 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
Jaroslav Procházka Tvorba softwaru 2008 9

10. 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, …
Jaroslav Procházka Tvorba softwaru 2008 10

11. But it is not Agile ….
Jaroslav Procházka Tvorba softwaru 2008 11

12. Experienced problems 2/4
2. Communication
– Assumptions behind decisions
– Ineffective communication
channels
(communication overhead)
– Just names somewhere
(lacking personal relationships)
Jaroslav Procházka Tvorba softwaru 2008 12

13. But Agile means …
Communication around the
architecture
Jaroslav Procházka Tvorba softwaru 2008 13

14. Experienced problems 3/4
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
Jaroslav Procházka Tvorba softwaru 2008 14

15. Experienced problems 4/4
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
Jaroslav Procházka Tvorba softwaru 2008 15

16. 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)
Jaroslav Procházka Tvorba softwaru 2008 16

17. OpenUP is a good start
• Minimal process
framework for software
development
• Contains Agile and
Lean practices
Jaroslav Procházka Tvorba softwaru 2008 17

18. 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
Jaroslav Procházka Tvorba softwaru 2008 18