Succeed with Agile at Scale

Transcription

1 IBM Software Group Succeed with Agile at Scale Alfred Tse/Osmond Ng Rational Software Technical Professionals Growth Markets Asia Pacific June 25, IBM Corporation

2 Agenda Agile Software Development Addressing Scaling Risks Rational Team Concert (RTC) 2

3 Has Your Organization Adopted One or More Agile Techniques? No 31% Yes 69% 61.4% of developers thought they were doing Agile 78.2% of IT management thought they were doing Agile 18.3% of respondents indicated they re still in the pilot stage 15% of No respondents hope to do Agile this year Source: Dr Dobb s 2008 Agile Adoption Survey 3

4 Why Agile/Iterative? It s More Successful Functionality: 83% believe that meeting actual needs of stakeholders is more important than building the system to specification Quality: 82% believe that delivering high quality is more important than delivering on time and on budget Money: 70% believe that providing the best ROI is more important than delivering under budget Schedule: 58% believe that delivering when the system is ready to be shipped is more important than delivering on schedule Source: Dr Dobb s 2008 Project Success Survey 4

5 Why Agile? Because it Works! 5

6 IBM Agile IBM Software Group Rational software Use continuous stakeholder feedback to deliver high quality consumable code through use cases and a series of short, stable, time-boxed iterations. Agile Manifesto Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan Key concept: Agile development necessitates greater discipline than traditional methods. Quality and Consumability must be real, not platitudes. 6

7 Agile Scrum SE IBM Software Group Rational software Product Owner Or Product Owner Or Product OwnerSE SE Scrum Master Scrum Master / SE Scrum Master Team Team Team Sprint Sprint Sprint Backlog Backlog Backlog Feature Feature Feature Feature Feature Feature Feature Feature Feature Main role Think! On Scrum projects, an SE may perform as a Scrum Master or Product Owner or SE. On Medium or Higher Complexity Projects, SE can be engaged as a Product Owner, and works closely with the Scrum Master. SE obeys all the Scrum rules defined for Scrum and Sprint meetings. SE plays a role of a Pig rather than Chicken 7

8 Agile - Iterations IBM Software Group Rational software Time boxed 2 weeks 30 days, pre-determined Test - Automated continual Daily build all code works Documentation - Only enough to write code Change is OK embrace it People matter trust the team Iterations must add value and lead to convergence Irreversible decisions - save till the last minute Live show - at the end of the iteration user feedback Developers work in pairs Developers knowledgeable about the business Iterate till the desired capability is reached Each spiral is a time boxed iteration Time Review this side for content relative to module Generic Sample Iteration Plan Start each day with a meeting (a scrum) of the team or in a bigger project, the leaders (architects, PMs, managers, engineers), to identify and resolve open issues for the next day. Try to make decisions quickly and avoid long debates. Decide and move on. Remember that you will modify this process as you proceed. Here is an example four-week cycle, but this should be adapted to suit the working practices and needs of your team: Three days sizing and deciding which use cases will go into this next iteration Two days with developers, designers and architects completing the design for this iteration. Do not be afraid to re-factor. Two weeks implementing and unit testing the use cases. Remember that early defect prevention and removal will save you hours of work later in the cycle. The authors recommend a combination of: Pair programming (immediate defect prevention and removal) Inspections (even daily seems to work well, especially when review tools are available) Unit testing Disciplined check-in (e.g. open source contributors and committers) One week completing formal functional verification (including GVT), system test and stabilization of the new capabilities. Test often and Test early. (Note that some teams have overlapped the test cycle with some/all of the next Iteration - this may be appropriate for complex testing but not for the functional testing and stabilization which needs to be completed within the iteration.) One hour demonstrating the functionality created to your key stakeholders, and where possible, real customers. Schedule the meeting in advance to provide a concrete deadline. One hour reflecting on the process changes you will implement to make the next iteration even more effective. 8

9 The Agile Process Continuum Organizational Drivers Team Size Geographical Distribution Organization Distribution Entrenched process, people, policy Rational Unified Process Eclipse Way XP, Scrum, OpenUP, DSDM Technical and Regulatory Drivers Compliance Governance Application complexity 9

10 Agile Practice Coverage Impediments Burndown Sprint Review Meeting Daily Stand-up Scrum Refactoring Test First Sprints Iterations Acceptance Test Continuous Integration Retrospectives Product Backlog Pair programming Stories XP Onsite Customer Unit Test Task level commit Smoke Test Agile SCM Patterns* Private workspace Task Branch Integration Build Private Versioning Code line Policy Private System Build 10

11 Agenda Agile Software Development Addressing Scaling Risks Rational Team Concert (RTC) 11

12 Challenges with Agile in the Mainstream Compliance requirement Enterprise discipline Low risk Critical, Audited Project focus Enterprise focus Geographical distribution Co-located Global Agile Development Entrenched process, people, and policy Minimal Significant Application complexity Simple, single platform Complex, multi-platform Organization distribution (outsourcing, partnerships) In-house Third party Under 10 developers Team size 100 s of developers Degree of Governance Informal Formal 12

13 Largest Team Size Attempted vs. Successful to to to 20 6 to 10 1 to Attempt Success Source: Dr Dobb s 2008 Agile Adoption Survey 13

14 Agile Projects Success Rates (%) (214 co-located projects, 210 near located, 129 far located) All Co-Located Near Located Far Located Source: Dr Dobb s 2008 Agile Adoption Survey 14

15 Agility is Relative It Depends on Project Dynamics Organizational Drivers Team Size Geographical Distribution Organization Distribution Entrenched process, people, policy Maturing projects Multi-platform Growing in complexity Remote or offshore work Greater need for coordination and handoffs Mature or existing projects 50+ developers Complex, multi-platform applications Distributed teams Need for scalability, reproducibility, and traceability Agility at Scale Dealing with Complexity Small team New projects Simple application Co-located Minimal need for documentation Technical and Regulatory Drivers Compliance Governance Application complexity 15

16 Agenda Agile Software Development Addressing Scaling Risks Rational Team Concert (RTC) 16

17 Key areas of Scale to consider Iteration models Deferred commitment Sample iteration flow Lean software Test driven development 17

18 Risk: You ll Build the Wrong Thing Solution: Agile Requirements Management Requirements are prioritized by stakeholders Requirements are estimated by the development team Requirements will evolve throughout the project Stakeholders see working software each iteration Stakeholders can change the level of funding as appropriate Stakeholders determine when enough is enough 18

19 Risk: You ll Build the Wrong Thing the Wrong Way Solution: Evolutionary Architecture, Evolutionary Design 19

20 Risk: Low Quality Solution: Test Driven Development (TDD) and Independent Testing Effective agile teams push their working builds to an independent test team on a regular basis for investigative testing Change stories must be prioritized and put back on the team s work stack Defects == Requirements Scales TDD: TDD is a form of confirmatory testing. TDD is a great start, but it s not the full testing picture Critical strategy for addressing non-functional requirements 20

21 Risk: Non-Functional Requirements and Constraints Solution: Shared Vision (Requirements Envisioning) and Independent Testing 21

22 Risk: You ll Build the Wrong Thing the Wrong Way Solution: Adopt a Risk-Driven Lifecycle Stakeholder concurrence gained during Inception Architecture proven via working software during Elaboration 22

23 Risk: Overly Focused on Construction Solution: Look at Full SDLC 23

24 Risk: Competing Stakeholder Concerns Solution: Agile Business Analysis On-site customer is nice, so put them to work Stakeholders can be active participants in modeling Product owner is really a communication conduit between the team and stakeholders Must have agile business analysis skills PO gets the team access to the relevant stakeholders just in time Negotiate, negotiate, negotiate 24

25 Risk: Lack of Management Oversight Solution: Scale Agile via RUP Organizations have instantiated RUP to be very agile Scaling strengths: Risk-driven milestones Explicit go/no-go decision points Stakeholder concurrence gained during Inception Architecture proven via working software during Elaboration Managed deployment during Transition 25

26 Risk: Difficulty Transitioning Staff As always, people issues are the difficult ones Recognize that: You ve done similar paradigm shifts before: Structured to object technology Centralized to client/server Client/server to services-based You have significant cultural issues to overcome All positions, including management, potentially needs to move to agile Not everyone needs to be agile, but most will become so The Obvious Strategies: Hire experienced people Mentoring Training and education 26

27 Agenda Agile Software Development Addressing Scaling Risks Rational Team Concert (RTC) 27

28 Rational Team Concert support for Agile Teams Eclipse/RAD (Rational Application Developer) supports agile practices for a team member Refactoring Unit testing, test coverage Team Concert provides agility for a team Teams Process templates Agile process specific work item types Iteration planning Continuous integration Agile SCM practices Visibility/transparency 28

29 Process Templates Different agile templates available: Agile Scrum OpenUP Eclipse Way Agile process specific work item types Process can be tweaked at any time 29

30 Transparency/Visibility Knowing what is going on without having to ask Transparency in process team structure team roles team rules Transparency in development automatic linking build results/reports Dashboards/Reports for an individual for a team For a project 30

31 Team Dashboard 31

32 Team Awareness Events My events Team events Team central Team visibility/awareness User presence 32

33 Iteration Planning applied for Scrum 33

34 Continuous Integration Build results integrated into eclipse Build awareness Linkage between Work item fixed in build Build corresponding to a Build and release change-sets in build Personal builds 34

35 Build and Test Health 35

36 Agile SCM Best Practices* Jazz SCM supports agile best practices Refactoring tracking enables aggressive/agile refactoring Private versions Easy collaboration on change sets Attach to work item Delivery rules Suspending changes And more * Software Configuration Management, Patterns: Effective Teamwork, Practical Integration By Steve Berczuk with Brad Appleton Published by Addison-Wesley 36

37 Scaling-up: Teams of Teams Team Team stream Sharing change sets Continuous build Team events Teams of Teams Integration/stabilization streams Sharing baselines Integration builds A contributor can be a member of more than one team 37

38 Developing Jazz/Team Concert with Team Concert 38

39 the Jazz community 39

40 Critical IBM Agile Resources

41 Copyright IBM Corporation All rights reserved. The information contained in these materials is provided for informational purposes only, and is provided AS IS without warranty of any kind, express or implied. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, these materials. Nothing contained in these materials is intended to, nor shall have the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software. References in these materials to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. Product release dates and/or capabilities referenced in these materials may change at any time at IBM s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any way. IBM, the IBM logo, the on-demand business logo, Rational, the Rational logo, and other IBM products and services are trademarks of the International Business Machines Corporation, in the United States, other countries or both. Other company, product, or service names may be trademarks or service marks of others. 41