Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Agile hangover

1,686 views

Published on

This project started life with a waterfall process. The teams were divided by components with dedicated teams for business analysts and testing.

When we joined, the project had a number of issues including: Stagnate Skill set, Low Moral, Lots of Technical Debt, Unreliable and Costly Automated Tests, Unstable System, Unreliable Release Process and ineffective Off-shore teams.

We led a programme that focused on steadily improving the system as well as the team. We also brought the offshore teams closer to the point where they were considered an equal to the central on shore teams. For details please view the slides.

Published in: Technology
  • Be the first to comment

Agile hangover

  1. 1. Curing the Agile Hangover with Software Craftsmanship
  2. 2. Requirements Dev Test Release
  3. 3. Project Managers / Analysts ‘L’ Q.
  4. 4. Component Teams Dev Team 1 Dev Team 2 Component 1 Component 2 Component 3
  5. 5. And then
  6. 6. Scrum Master Developers . —V‘. ‘i‘'; r;I; rii 1. Component 3 Component 2 Component 1 1 ] ‘l‘§t= ,IIIi l : ,1-.2-. . _# :7 T4}
  7. 7. when the excitement settled
  8. 8. Mountain of Technical Debt Stagnant Skillset Lack of technical expertise Low Moral and Motivation Requirements not well understood Unreliable Release Process Long running builds The Hango er lnefficient Developl Debug/ Deploy cycles Unstable system Late discovery of bugs Unreliable and costly tests
  9. 9. The Hangover + Off—shore Ha ngoverz
  10. 10. So where did we go from there?
  11. 11. Bad Quality Software The Hangover Isolated Us and Them Developers Attitudes
  12. 12. Continuous integration to a different level - Early integration of code - Automated branches builds Comprehensive static analysis Emphasis on TDD (all levels) - Automated tests at the right levels Emphasis on Design (expressing the business) Tools and paradigms to suite the problem Healthy intolerance of bad code
  13. 13. Well Crafted Isolated Us and Them Developers Attitudes
  14. 14. - Investment in improvements - Percentage of our time in improvements and refactorings - Evolved to developers making the call of what needs to be improved and when - Design committee introduced. - Stop and fix attitude. No broken windows. - Code continuously deployed to production long before live dates - Frequent releases
  15. 15. Well Crafted Steadily Add Software Value Isolated Us and Them Developers Attitudes
  16. 16. Social coding - Pair-programming - Github - Feature branches - Pull request based commit model - Code reviewed by members of other teams No positions or hierarchies within the teams No special teams - Onshore / offshore equality Hiring and recruitment is a team activity. No managers involved. - Passion is a key criteria - Foundations of software development is more important than technology specific knowledge Individual efforts are valued and recognised by everyone - No egos Active participation in external communities Mentoring and education Culture of learning
  17. 17. Well Crafted Steadily Add Software Value Community of Us and Them Professionals Atfitudes
  18. 18. Team structure — BAs are part of the team (at least one per team) — At least one tester per team - BAs often pair with developers - Tests written in plain language (BDD / SBE) often by BAs Developers understand that writing code is just one of their responsibilities — Holistic approach to software development Customer representatives sitting next to the teams Fully automated and efficient build, release and deployment procedures - DevOps Close collaboration between developers and production services
  19. 19. Well Crafted Software Steadily Add Value " - “Hr 4- lu_Hl_'1'ra, || -‘ I ir'= .IF-‘rf: :“”r: Ii'i. -{flipI Community of Professionals Productive Partnership
  20. 20. - Transition from Green to Brown field - Challenge: Keep it healthy for as long as we can - Not to be scared of large refactorings and re-design - TDD on its own is not enough. A few re-design cycles are also needed. - Projects change directions / spinoffs - Open/ Closed principle - Fundamentally change the design without impacting existing functionality - Keep frameworks and infrastructure outside the boundaries of your domain
  21. 21. The Specifics
  22. 22. Low Moral and Motivation Career paths for every Role Empowered Professionals Lack of technical expertise
  23. 23. Long running builds d. Late Unreliable and Movery costly tests of bugs Component Unit "Integration System
  24. 24. Unit ‘(Component "Integration System
  25. 25. Mountain lnefficient Develop/ Debug/ T ": f_ I Deplov cvcles Boy Scout Rule egegfa Continuous. lmprr rverwer‘l Emphasis on Quality Embrace Collaborative Legacy Development U nstable system 25
  26. 26. Requirements Dev / T est Late discovery of bugs Release Unreliable Release Process Unstable system
  27. 27. Dev Prod Zero Downtime Integration Deployment -i7ll‘l7”. 'li‘l'». .lV Mr. I I: -li‘*-. ':2i*‘ Continuous Process Automation Deployment
  28. 28. Low Moral Stagnant I d Skillset Coachingand 3_" _ l/ lentoring M°t"’3t'°" Internal / External High Communities lfljCCUOfl of Passion Investment in People Selective Hiring Process Vendor Relationship 23
  29. 29. ii Continuous Integration I I I Pair 1 - Programing ‘ (__ A I Automated Testing Continuous ‘ ' ‘ Im rovement ' Ag}; D ‘ I ‘_; ¢_. i . H, ’ . I f Specification IF By Example . . Testing at the l] ‘- ‘ y __ right level . I
  30. 30. f ' 3} Automated P i Release and I UB5 mdc I . Deployment ‘ improvements ‘I ‘K . , I . . _, . s Continuous Disaster I Recovery l Practice ' Centre of Excellence Distributed If Local ' _ Communities ! S°: :‘: ;SC°n; °| “ of Practice .0“ “ Coding it _ J5 1 ii‘ I Simple Applications I : ié
  31. 31. Sandro Mancuso sandro@codurance. com @sandromancuso Thanks Mashooq Badar mash @codu rance. com @mashooq 51

×