Moldova ICT Summit 2011 - Pentalog's presentation in Project Management section.

1,286 views

Published on

Agile in practice : Fixed price projects and distributed teams.

Published in: Education, Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,286
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Moldova ICT Summit 2011 - Pentalog's presentation in Project Management section.

  1. 1. AGILE IN PRACTICE: FIXED-PRICE PROJECTS AND DISTRIBUTED TEAMS p e n t a l o g . c o m
  2. 2. SUMMARY <ul><li>Pentalog High Tech
  3. 3. Time and Material Contract versus Fixed Price Contract
  4. 4. 3 dimensions of a project: </li><ul><li>Distributed teams
  5. 5. Fixed Price contract
  6. 6. Agile methodology – Scrum </li></ul><li>Project Infrastructure – Continuous Integration Concept
  7. 7. Cases study: Altadis and Atlas projects
  8. 8. Gained experience/ difficulties
  9. 9. Success factors </li></ul>
  10. 10. PENTALOG HIGH TECH IS THE LEADER OF THE FRENCH OFFSHORE INDUSTRY 20ME
  11. 11. PENTALOG BUSINESS LINES SPECIFIC DEVELOPPEMENT AND THIRD-PARTY MAINTENANCE <ul><li>Development of specific applications
  12. 12. Developing portals, on demand SaaS applications
  13. 13. Software testing
  14. 14. Third-party application maintenance, Third-party software validation </li></ul>CONSULTING, BI, IMPLEMENTATION OF SOFTWARE PACKAGES,TRAINING <ul><li>Consulting, audits, studies and project management assistance
  15. 15. Business intelligence, datawarehouse design, data mining
  16. 16. Integration of ERP or CRM-type software packages
  17. 17. Training </li></ul>FACILITIES MANAGEMENT, HOSTING, SUPERVISION <ul><li>Facilities management and infrastructure supervision
  18. 18. Website and application hosting </li></ul>
  19. 19. <ul><li>TRADITIONALLY, AN IT SERVICES COMPANY OFFERS </li><ul><li>Time and material contract: delegation of resources to a client
  20. 20. Fixed-price contract: taking over the development of a functional scope </li></ul><li>FIXED-PRICE PROJECT: THIS IS WHERE THE ACTION IS! </li><ul><li>The Client would like to keep the
  21. 21. deadline/scope/budget commitments
  22. 22. Client - demand for provider flexibility
  23. 23. Provider - resistance to commitments </li></ul></ul>EVERYTHING LIES ON THE SHARING OF RISKS
  24. 24. DISTRIBUTED TEAM ADVANTAGES <ul><li>Possibility of reduction of project budget
  25. 25. Operative creation and extension of the team
  26. 26. Simplification of finding the required resources
  27. 27. Cultural exchange
  28. 28. Responsibility distribution between PM&TL </li></ul>DIFFICULTIES <ul><li>Time shift
  29. 29. Cultural differences
  30. 30. Not enough face to face communication
  31. 31. Complexity in common infrastructure creation and maintenance
  32. 32. Additional costs on business trips
  33. 33. Respect of the established common rules (coding, architecture, commits etc.)
  34. 34. Difficulty to assure full availability for communication </li></ul>
  35. 35. FIXED PRICE TEAM ADVANTAGES <ul><li>Fixed budget
  36. 36. Fixed deadline
  37. 37. Fixed scope
  38. 38. Full visibility on project specifications
  39. 39. Externalization of risks </li></ul>DIFFICULTIES <ul><li>Difficulties on estimations
  40. 40. Tunnel Effect
  41. 41. Late feedback
  42. 42. No flexibility from provider
  43. 43. Specification avalanche at the beginning
  44. 44. Specifications out of date during the project </li></ul>
  45. 45. SCRUM ADVANTAGES <ul><li>Flexibility
  46. 46. Reduced time to market
  47. 47. Transparency
  48. 48. Early Client/end user feedback
  49. 49. Client implication in taking decisions
  50. 50. Continuous amelioration of the processes and technical aspect </li></ul>DIFFICULTIES <ul><li>Overall project budget control on Client side
  51. 51. Evolving scope, budget, deadline
  52. 52. Complexity of modules/tasks prioritization on Client side
  53. 53. Necessity in assurance of the constant team motivation </li></ul>
  54. 54. FIXES PRICE / DISTRIBUTED TEAM / SCRUM ADVANTAGES <ul><li>Fixed budget, deadline, scope per 3 Sprints
  55. 55. Visibility on project specifications per 3 Sprints
  56. 56. Partial externalization of risks
  57. 57. Possibility of reduction of project budget
  58. 58. Operativity of creation extended team
  59. 59. Simplification of finding required resources
  60. 60. Cultural exchange
  61. 61. Responsibility distribution between PM&TL
  62. 62. Flexibility
  63. 63. Reduced time to market
  64. 64. Early Client/end user feedback
  65. 65. Client implication in taking decisions
  66. 66. Continuous amelioration of the processes and technical aspect </li></ul>DIFFICULTIES <ul><li>Time shift
  67. 67. Cultural differences
  68. 68. Not enough face to face communication
  69. 69. Additional costs on business trips
  70. 70. Respect of the established common rules (coding, architecture, commits etc.)
  71. 71. Difficulty to assure full availability for communication
  72. 72. Overall project budget control on Client side
  73. 73. Complexity of modules/tasks prioritization on Client side
  74. 74. Overall project - evolving scope, budget, deadline
  75. 75. Necessity in assurance of the constant team motivation </li></ul>
  76. 76. TYPES OF FIXED-PRICE CONTRACTS
  77. 77. PROJECT INFRASTRUCTURE – C ONTINUOUS INTEGRATION CONCEPT <ul><li>Continuous Integration Concept: SVN, HUDSON +SONAR </li><ul><li>Builds at every commit on SVN
  78. 78. Automatic deployment twice per day or when required
  79. 79. Notifications at every build creation and deploy (build status, errors – where in code and which commit provoked it)
  80. 80. SONAR: coding conventions, code duplication, Unit Tests coverage, etc. </li></ul><li>Confluence: documents and requirements repository, charring ideas and best practices
  81. 81. Project Mailing List
  82. 82. Management and bug tracking tool: JIRA </li><ul><li>Stories, tasks
  83. 83. Bugs
  84. 84. Burn Down chart </li></ul></ul>
  85. 85. Project A V1 – PENTALOG AND CLIENT'S TEAMS
  86. 86. PROJECT A V2 – PENTALOG/CLIENT COMMON TEAMS
  87. 87. PROJECT B  ORGANISATION
  88. 88. RECONCILING AGILITY AND FIXED-PRICE PROJECTS <ul><li>There is no miracle recipe, there are just paths to explore: </li><ul><li>Team commitment: </li><ul><li>Developer's responsibility
  89. 89. Constant developers motivation within every sprint </li></ul><li>Sharing the estimation and risk: </li><ul><li>Transparency
  90. 90. Applying changes while respecting workloads </li></ul><li>Requirements prioritization
  91. 91. Commitment on short and consistent sprints
  92. 92. Highlighting the benefits for the client: </li><ul><li>Flexibility and acceptance for requirements changes
  93. 93. Early Testing = Less Validation </li></ul></ul><li>Scrum shouldn't necessarily be applied to the letter: </li><ul><li>The ScrumMaster must remain focused on the management of the development team
  94. 94. He shouldn't hesitate to assume the role of the “Product Owner” if decisions are not taken on time </li></ul></ul>
  95. 95. <ul><ul><li>High level specifications at the beginning and their refining during the Sprint implementation.
  96. 96. The request of detailed estimations based on the insufficiently detailed specifications
  97. 97. Client Daily availability and feedback with delay
  98. 98. Lack of direct communication with technical Client coordinator
  99. 99. As the project was agreed upon as Fixed-price during the Sprint development the Client is trying to add changes.
  100. 100. Prototype and development teams source code synchronization.
  101. 101. Creation and utilization of common functional components between teams.
  102. 102. Modules integration developed by different teams.
  103. 103. Code uniformity
  104. 104. Assuring the exact procedures/processes following by everyone involved </li></ul></ul>GAINED EXPERIENCE AND DIFFICULTIES
  105. 105. SUCCESS FACTORS <ul><li>Good communication
  106. 106. Often business trips to communicate Face To Face
  107. 107. Desktop Sharing/Pair programming
  108. 108. Common system for task tracking and progress monitoring
  109. 109. Involvement in the creation of the software architecture
  110. 110. Project infrastructure 24 by 24
  111. 111. Maximum availability of the Product Owner, Scrum Master and teams
  112. 112. Plan for stabilization Sprint and re-factoring tasks
  113. 113. Showing respect for commitments </li><ul><li>No meeting postponements
  114. 114. Demonstration of the quality of deliverables </li></ul></ul>
  115. 115. <ul><li>Establishing a relationship of trust </li><ul><li>Between teams
  116. 116. With the Client </li></ul><li>Ensuring a total transparency </li><ul><li>On the progress
  117. 117. On the estimation of efforts </li></ul><li>Development team </li><ul><li>Maintaining a sustained production rhythm without taking it too far
  118. 118. Plan a period of time between the Sprints
  119. 119. Preparing demonstrations
  120. 120. Estimating the tasks of the following Sprint
  121. 121. Not giving in to the temptation of overloading a Sprint </li><ul><li>Collegiality and honesty of estimations
  122. 122. Respecting the maximum capacity of a sprint </li></ul></ul></ul>SUCCESS FACTORS
  123. 123. THANK YOU! p e n t a l o g . c o m

×