Your SlideShare is downloading. ×
  • Like
Experience from Agile adoption in distributed environment
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.


Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Experience from Agile adoption in distributed environment


Short summary of our lessons from Agile implementation in distributed environment

Short summary of our lessons from Agile implementation in distributed environment

Published in Technology , Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads


Total Views
On SlideShare
From Embeds
Number of Embeds



Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

    No notes for slide


  • 1. Experience from Agile adoption in distributed environmentSoftware 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• ConclusionJaroslav 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 nowJaroslav Procházka Tvorba softwaru 2008 3
  • 4. Agile manifesto Stressed communication Continuous delivery Simplicity Change toleranceJaroslav 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 reportJaroslav Procházka Tvorba softwaru 2008 5
  • 6. Agile and small Czech businessesEasier 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 teamsJaroslav 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 thinkingJaroslav 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 teamsJaroslav Procházka Tvorba softwaru 2008 9
  • 10. Experienced problems 1/41. 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/42. 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 architectureJaroslav Procházka Tvorba softwaru 2008 13
  • 14. Experienced problems 3/43. 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 backlogJaroslav Procházka Tvorba softwaru 2008 14
  • 15. Experienced problems 4/44. 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 demonstrationJaroslav 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 neededJaroslav Procházka Tvorba softwaru 2008 18