Alm Agile In Large Projects V2

1,485 views

Published on

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

No Downloads
Views
Total views
1,485
On SlideShare
0
From Embeds
0
Number of Embeds
9
Actions
Shares
0
Downloads
15
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • SR3:7 weeks, 27 developers = 945 developer daysDefects raised by UAT = 420 defects Provider Online:1152 developer daysDefect raised by UAT = 150 defects
  • Prioritise accuratelyTo realise value as soon as possiblePrioritise highest value items early onProduct Increments are all production-qualityProvide appropriate responses to problemsNo wasted effort on unnecessary areasDocumentation at the right level in the right placesTechnical solutions which are just good enoughFocus on key practicesQuality of the product deliverablesVisibility of the Product Backlog ItemInspect and adapt – with every SprintHave the right attitudeRealise that agile processes are people-drivenBuy-in leads to project successProject success promotes buy-in across the businessHave the right teamA Product Owner with clear vision and clear authorityFirst commitment is the projectCan answer questions quickly and definitelyBought-in to the SCRUM processA SCRUM Master who can drive the projectEnsuring the smooth working of the teamRunning workshops to drive out the Product BacklogCommunicating the processes and benefits to the wider business communityAn Architect who can drive the solutionMaking the right technology choicesMentoring team members in the development process and the solutionA committed development teamKeen to learn new technologies and approachesBought-in to the SCRUM processKnowledgeable testersWith product and domain knowledgeCommunicating effectively with the development team
  • Lack of commitmentFrom IT – looking for the benefits of agile without the cost of changeProviding resources with other project commitmentsFailing to remove impediments quickly and effectivelyFrom the business – paying lip-service to the change with an inappropriate Product OwnerDriving from the wrong directionThe agile transition is a change in the relationship between IT and the businessToo often it is IT-driven, decided in advance and then presented to the businessTo the business, it’s just another IT initiative Lack of understandingRigidly applying all aspects of a methodology, even when they prove to be detrimentalAdapting agile practices to suit existing processes, teams, documents and standardsPicking and choosing agile practices without experience of their benefits and costsIn SCRUM, the project team should be hosted in one location. Co-location is an option can but can severely limit velocityTest-Driven Development in XP is a complete change in the development processHaving unrealistic expectationsEstablished agile teams to do deliver higher quality systems in less timeTransitioning to agile is not an overnight processIn SCRUM, the first Sprint for a new, blended team should be expected to fail
  • Alm Agile In Large Projects V2

    1. 1. Making Agile Work For Large Projects<br />Mark Drysdale<br />
    2. 2. Agenda<br />Traditional Delivery<br />What is Agile<br />Scrum<br />Case Study – Company X<br />History<br />Pilot<br />Rollout<br />2<br />
    3. 3. The Risks of Software Development <br />Delivering too little, too late<br />Discovering functional needs late in the project<br />Building the right things wrong<br />Building more than you need<br />Adding complexity which leads to non-maintainability<br />Poor quality software<br />Software buggy<br />Software not maintainable<br />
    4. 4. Industry Statistics<br />
    5. 5. Agile is … the Methods<br />AGILE<br />Lean Thinking<br />Queuing Theory<br />Theory of Constraints<br />eXtreme Programming (1996)<br />Scrum (2001)<br />DSDM (1995)<br />Feature Driven Development (1997)<br />Crystal (mid 1990s)<br />Kanban (2008 ish)<br />AUP/OpenUP<br />Lean Software Development (2003)<br />
    6. 6. Contrasting Waterfall with Agile<br />Analysis<br />Design<br />Code<br />Test<br />Deploy<br />Waterfall<br />Time<br />Analysis<br />Analysis<br />Analysis<br />Analysis<br />Design<br />Analysis<br />Architecture<br />Releasable<br />Releasable<br />Releasable<br />Deploy<br />Design<br />Design<br />Design<br />Code<br />Code<br />Code<br />Code<br />Agile<br />Test<br />Test<br />Test<br />Test<br />
    7. 7. The Scrum Process<br />Daily Scrum<br />Meeting<br />24hours<br />Sprint review<br />Sprint<br />Backlog tasks<br />expanded<br />by team<br />Sprint Planning<br />Sprint<br />Backlog<br />Potentially Shippable<br />Product Increment<br />Product Backlog<br />Anyone can contribute items<br />Prioritized by Product Owner<br />
    8. 8. Company X<br />Company X spent £100 million on tech refresh and consolidation<br />80 legacy system consolidated to 1<br />All other major projects suspended for 4 years<br />Was it a Success?<br />It has enabled Company X to take the next step...<br />But...<br />2 years late<br />500+ defects in Live<br />Backlog of over 200 Change Requests<br />Business has had to accept over 150 manual work arounds<br />New CTO<br />Previously experience with Scrum at …<br />Dictated that 4 Project would be run as Scrum in first year<br />Commercial in Confidence<br />8<br />Why Change?<br />
    9. 9. Company X – Pilot<br />Commercial in Confidence<br />9<br />Ideal Agile Project Candidate Checklist<br />
    10. 10. Company X Pilot – Providers Online<br />First major web initiative<br />Java based CMS<br />Java Struts portlets<br />.Netwebservices<br />.Net backend<br />Oracle Database<br />12 Month projects<br />£2.2 million budget<br />Team of 22<br />Java and .Net teams had never worked together<br />Testers from 3 suppliers<br />Project in total had 6 different suppliers<br />Only 3 Company X permanent members<br />Disengaged Product Owner<br />Commercial in Confidence<br />10<br />What????<br />
    11. 11. Company X Pilot – Providers Online<br />Co-located everyone!<br />Moved out to another building<br />Created our own build servers<br />Own code branch<br />Implemented CI for Java<br />Manual daily builds for .Net<br />Created our own System Test Environments<br />2 Scrum teams<br />Cross functional<br />Scrum Master<br />3 Java<br />2 .Net<br />1 Html<br />1 Business Analyst<br />2 Manual testers<br />1 Automation Tester<br />Commercial in Confidence<br />11<br />First Steps<br />
    12. 12. Company X Pilot – Providers Online<br />Complete UAT 2 weeks early<br />Order of magnitude less defects discovered in UAT<br />Delivered on time and under budget<br />£1.9 million<br />Commercial in Confidence<br />12<br />What a Success!<br />
    13. 13. <ul><li>Resolves conflicts
    14. 14. Identifies cross-team dependencies
    15. 15. Escalate dependencies
    16. 16. Coordinate technical issues
    17. 17. Aids integration</li></ul>Business Focus<br />Project<br />Manager<br />Technical<br />Coordinator<br />Scrum of Scrums<br />Team Rep.<br />Team Rep.<br />Solution Focus<br />Team Rep.<br />Management Focus<br />Company X Rollout – Scaling Scrum<br />ScrumMaster<br />Product<br />Owner<br />ScrumMaster<br />Product<br />Owner<br />ScrumMaster<br />Product<br />Owner<br />Scrum<br />Team<br />Scrum<br />Team<br />Scrum<br />Team<br /><ul><li>Focus on business aspects
    18. 18. Resolves backlog dependencies and conflicts
    19. 19. Enables prioritisation across teams
    20. 20. Shields teams from conflicting change
    21. 21. Ensures single vision</li></ul>Product<br />Owner<br />Product<br />Owner<br />Product Owner Group<br />Product<br />Owner<br />Product<br />Owner<br />
    22. 22. Company X Rollout <br />Technical Enablers<br /><ul><li>Migrated from MKS to Microsoft TFS
    23. 23. Cut build time from hours to 10 min
    24. 24. Continuous Integration
    25. 25. 10-15 builds a day
    26. 26. TDD
    27. 27. MsTest
    28. 28. Rhino Mocks
    29. 29. Automation of Build
    30. 30. Nightly Builds and Deployments
    31. 31. Automation of Regression tests
    32. 32. QTP Pack takes 7 hours to run
    33. 33. Multiple servers</li></li></ul><li>Scaling Challenges<br />Moving from optimal single team poses challenges<br />Distributed/dispersed teams<br />face-2-face communication compromised<br />planning, retrospectives and other meetings difficult<br />timezone differences can introduce delays<br />Multiple teams<br />team structure: feature/component/hybrid?<br />communication and coordination between teams<br />potential for wasteful activity – hand-offs, delays etc.<br />dependencies across teams<br />are distributed by default, even if only within the same building<br />Sprint synchronisation<br />software/system integration across teams<br />usually requires extra coordination and planning activity and roles<br />
    34. 34. Distributed Scrum - How to ramping up<br />Cell based replication<br />
    35. 35. Distributed Scrum - How to ramping up<br />Distribute first team<br />
    36. 36. Distributed Scrum - How to ramping up<br />Distribute second team<br />
    37. 37. Distributed Scrum - How to ramping up<br />Seed third team from members of first teams<br />
    38. 38. Distributed Scrum - Enablers<br />Video conferencing<br />For daily stand ups<br />Planning <br />Retrospectives<br />Digital Scrum boards<br />Wiki and online velocity charts<br />Scrum teams in offices/grouped desks<br />Offshore/Onshore Exchange<br />Continually moving team members between locations<br />
    39. 39. How will you succeed?<br />Prioritise accurately<br />Provide appropriate responses to impediments<br />Focus on key practices<br />Have the right team<br /><ul><li>A SCRUM Master who can drive the project
    40. 40. A committed development team
    41. 41. Knowledgeable testers</li></ul>Have the right attitude<br />
    42. 42. Pitfalls – What will prevent success?<br />Lack of commitment<br />From IT – looking for the benefits of agile without the cost of change<br />From the business – paying lip-service to the change with an inappropriate Product Owner<br />Driving from the wrong direction<br />The agile transition is a change in the relationship between IT and the business<br />Lack of understanding<br />Rigidly applying all aspects of a methodology, even when they prove to be detrimental<br />Adapting agile practices to suit existing processes, teams, documents and standards<br />Having unrealistic expectations<br />Transitioning to agile is not an overnight process<br />In SCRUM, the first Sprint for a new, blended team should be expected to fail<br />

    ×