Agile In A Box V0 2
- 1. “ Agile In a Box” An overview of the Rhythm Agile Software Development Ecosystem (ASDE) and Agile Execution Framework (AEF) Version 1.2
- 2. Agenda Goals Context Rhythm Overview Questions/comments/open discussion
- 3. Goals Overview of an Agile Software Development Ecosystem (ASDE) and an Agile Execution Framework (AEF) being used successfully in a wide variety of industries, technologies and organizations How/why it can be highly effective in your organization
- 4. Context Software Methodologies: State of affairs The Agile movement, and its Manifesto Improving upon what’s out there
- 5. Today’s software methodologies Obviously, we should be aware and concerned about these statistics; they are a reflection of our industry. Are you seeing this as well in your shop? Standish (2001) The average project exceeds its schedule by 100% Johnson (2002) 64% of the features included in products are rarely or never used Lederer and Prasad (1992) 2/3 of projects significantly overrun their cost estimates The Conference Board Survey (2001) Executives at over 117 companies attempting implementations resulted in a 40% project failure rate. The Robbins-Gioia Survey (2001) 51% viewed their ERP implementation as unsuccessful The Chaos Report (1995) 31% of projects will be cancelled before they ever get completed. 52% of projects will cost over 189% of their original estimates.
- 6. Common Issues / Challenges Waterfall? There’s got to be a better way… Major causes of project failures highlighted the following: 57% -Bad communications between relevant parties 39% -Lack of planning of scheduling resources and activities 35% -Lack of quality control 34% -Milestones not being met 29% -Inadequate co-ordination of resources 26% -Costs getting out of hand 20% -Mismanagement of progress 17% -Overall poor management 11% -Insufficient measurable outputs
- 7. Common Issues / Challenges Business people and the SDLC team working together Plan what you can; adjust early and often Test Driven Design and Development Focus on delivering pieces that are complete; deliver something that works All inclusive plan that focuses on features, stories, use cases, not activities Deliver and demonstrate early and often; track costs sooner Move away from status based, go towards delivery based PMO, change management the SDLC team provides the estimates, not management Deliver working software early and often Agile! Major causes of project failures highlighted the following: 57% -Bad communications between relevant parties 39% -Lack of planning of scheduling resources and activities 35% -Lack of quality control 34% -Milestones not being met 29% -Inadequate co-ordination of resources 26% -Costs getting out of hand 20% -Mismanagement of progress 17% -Overall poor management 11% -Insufficient measurable outputs
- 8. Enter: Agile Manifesto (http://agilemanifesto.org)
- 9. What Is Agile? First, define ‘Ecosystem’ in this context The people, processes and environments working together to produce an end result Software Development Ecosystems (methodologies) that provide: Reduced risk through small, fast, development cycles Emphasis on real-time, face-to-face communication Communication - all team members and the customer work together to ensure success Focus on working software, not task completion status, as the primary measure of progress Ability to respond to change instead of following a plan
- 10. Agile vs. Traditional Development Adaptive methods focus on quickly adapting to change Predictive methods focus on detailed future planning Adaptive Predictive
- 11. Agile Software Development Ecosystems (ASDE) Rational Unified Process (RUP) Extreme Programming (XP) SCRUM Dynamic Systems Development Method (DSDM) Crystal Methods Feature Driven Development (FDD) Lean Development Adaptive Software Development (ASD) Rhythm (ASDE/AEF) More…
- 12. Who is using what? Heavy methodologies RUP (51%), SEI CMM (27%), ISO 9000 (26%) Agile 54% in-house methodology 38% XP, 23% FDD, etc.. Source http://www.cutter.com/freestuff/epmu0119.html
- 13. Room for improvement Hardly mentioned (weak link): Iteration Transition SDLC iterations and their respective transitions! Also, not mentioned: Stacked Iterations Iteratively stacked domain definition, development and testing! Hyper-Agility with a high Agility Rating
- 14. Staged versus Stacked Iterations Staged Stacked X X X X X X X X X Highly Tuned Software Factory Test Domain Area 4 Write Test Specs against Domain Area 5 Test Domain Area 3 Write Test Specs against Domain Area 4 Test Domain Area 2 Write Test Specs against Domain Area 3 Test Domain Area 1 Write Test Specs against Domain Area 2 Write test specs against Domain Area 1 Develop Domain Area 4 Req/Anal/DesignDomain Area 5 Develop Domain Area 2 Req/Anal/DesignDomain Area 3 Develop Domain Area 3 Req/Anal/DesignDomain Area 4 Develop Domain Area 5 Develop Domain Area 1 Preparation Req/Anal/DesignDomain Area 6 Req/Anal/DesignDomain Area 2 Req/Anal/DesignDomain Area 1 Test Domain Area 2 Write Test Specs against Domain Area 3 … wait… … wait… Test Domain Area 1 Write Test Specs against Domain Area 2 Write test specs against Domain Area 1 Develop Domain Area 2 … wait… … wait… … wait… … wait… Req/Anal/DesignDomain Area 2 … wait… Develop Domain Area 1 Preparation … wait… … wait… Req/Anal/DesignDomain Area 1 Iteration 1 Iteration 2 Iteration 1 Iteration 2 Iteration 3 Iteration 4 Iteration 5 Iteration 6
- 15. Even more room for improvement Over 10 years of Agile application experience Current suite of ASDE’s don’t get you to “ground-zero” How do I do this on a daily basis? Give me some guidance… 2002 Creoss introduced the concept of an Agile Execution Framework (AEF) Bringing the necessary foundation to your ASDE to make it work! Rhythm is one AEF; hope for many more to come in the future ASDE ASDE with AEF
- 16. Status Quo “ We do a horrible job going from one iteration to the next; we feed on percentage complete!” “ Our artifacts(specs) are close to being worthless; they are big, heavy, out of date and often times more wrong than right.” “ Our project plans are big, heavy and just about worthless (change all the time) that typically do not include defects, change requests and the underlying tasks that are the important details showing dependencies, etc. “ “ Our methodology team gets in our way, is completely worthless, try to help, but end up getting in our way, can we send them elsewhere?” “ Once we get towards the end of the project, we don’t seem to have a good pattern for managing our backlog of defects and such.” “ Our software deliveries are atrocious, most of our deliveries fail on deployment, our unit tests hardly work or cannot be re-run once they’ve been run.” “ Our ‘review’ meetings such as design review meetings are horrible experiences that are a bear to get through.” “ Our team has no rhythm, we restart, pause, delay all the time; we can’t get into a consistent groove with the organization participating.”
- 17. Putting together some ingredients… “… we are status-based, instead of delivery based!” Iteration Transition Meeting (ITM) “ ..worthless artifacts” Iteration Artifacts “… worthless project plans “ Software Iteration Plan (SIP) “… methodology team gets in our way” Iteration Advocate “… lack of pattern for managing our backlog of defects ….” Issue Review Meeting (IRM) “… software deliveries are atrocious” Software Push “… worthless review meetings.” Iteration Artifact Review Meeting (iARM) “… no rhythm” Heartbeat/Stacked Iterations
- 18. “Agile in a Box” Combining an Agile Software Development Ecosystem (ASDE) and an Agile Execution Framework (AEF) Rhythm ASDE/AEF
- 19. Rhythm ASDE The ‘macro’ dimension Phase 1: Definition 2 sweeps :: 2 scopes :: 2 Go/No-Go decision points Phase 2: Iteration (Rhythm AEF) Architecturally focused :: iterative accuracy :: incremental delivery :: Multiple sweeps :: multiple migrations :: feedback :: performance/tune Phase 3: Production Final deliveries :: tune again :: harden :: sunset legacy(if appropriate)
- 20. Rhythm ASDE (Myers flavor) Enhancement Requests New Feature Requests Defects PDS SRS SIP Roadmap Phase 1: Definition Client Facing Group QA/Test PPB PM Factory Definition Team
- 21. Rhythm ASDE (Myers flavor) Agile Software Factory Enhancement Requests New Feature Requests Defects Iteration 5 Iteration 6 Iteration 7 Iteration 8 Iteration 9 Iteration 9 Iteration 10 Iteration 11 PDS SRS SIP … .. Roadmap Phase 2: Iteration Phase 1: Definition Client Facing Group QA/Test Iteration 1 Iteration 2 Iteration 3 Iteration 4 iDS iCode iTS iSRS iDS iCode iTS iSRS iDS iCode iTS iSRS PPB Factory Team PM Factory Definition Team
- 22. Rhythm ASDE (Myers flavor) Agile Software Factory Enhancement Requests New Feature Requests Defects Phase 1: Definition Phase 3: Production Iteration 5 Iteration 6 Iteration 7 Iteration 8 Release Opportunity Iteration 9 Iteration 9 Iteration 10 Iteration 11 Release Opportunity Release Opportunity PDS SRS SIP … .. … .. Phase 2: Iteration Roadmap Client Facing Group QA/Test Iteration 1 Iteration 2 Iteration 3 Iteration 4 iDS iCode iTS iSRS iDS iCode iTS iSRS iDS iCode iTS iSRS Factory Definition Team PPB Factory Team PM
- 23. Rhythm ASDE (Myers flavor) Project Planning Board (Mondays 1pm) Phase 1: Definition Phase 3: Production Phase 2: Iteration iARM (Wednesdays, 9-11) SIP Review (Wednesdays, 3-4pm) iTM (Thursdays, 10-11am) IRM (Frequency dependent upon org) Factory Definition Team PPB CFG Factory Iteration Team PMO PPB/CFG (both optional but requested) PPB/CFG
- 24. Rhythm AEF (Phase 2: Iteration) Principles Primary Ancillary Your ASDE, PLUS: Buyer/Seller marketplace for artifact promotion Iteration Transition Meeting (ITM) Code, and specs are cycled together Iteration Artifacts Functionality, defects, change requests and tasks all in one place. Software Iteration Plan (SIP) Buzzing bee; Risk mitigator; Process-mentor in disguise! Iteration Advocate (IA) Transitioning from iterations to pre-production taskings Issue Review Meeting (IRM) Regression tested functionality for delivery Software Push Informal transfer of artifacts. A review of the next iterations domain developers are to build Iteration Artifact Review Meeting (IARM) Establish, support the rhythm of the efforts related to the project Heartbeat/Stacked Iterations At the conclusion of each iteration, challenge the team to migrate the application, one or two environments upstream Upstream Migration At end of each Hearbeat, measure planned versus actual Measure Velocity Pick a location; come only if you have something to say/contribute Daily 15 minute meetings Set this up once, it acts like a virtual developer whos job is to build applications Continuous Integration Engine (CIE) Performance test your implementation at 40 and 60 percent point. Performance test at the 40% and 60% completion The conveyor belt into production Unified Build Infrastructure (UBI) Use the ITM’s as your software factory; gate small and frequent releases Release Management and PMO Transfer debugging time into your regression testing engine Test Driven Design and Development (TDDD)
- 25. The Flywheel Flywheels store energy very efficiently (high turn-around efficiency) and have the potential for very high specific power compared with batteries. Flywheels have very high output potential and relatively long life . Flywheels are relatively unaffected by ambient temperature extremes . Warning, there are safety concerns associated with flywheels due to their high speed rotor and the possibility of it breaking loose and releasing all of it's energy in an uncontrolled manner. Physics Stored energy = sum of kinetic energy of individual mass elements that comprise the flywheel Kinetic Energy = 1/2*I*w 2 , where I = moment of inertia (ability of an object to resist changes in its rotational velocity ) w = rotational velocity (rpm) I = k*M*R 2 (M=mass; R=radius); k = inertial constant (depends on shape)
- 26. A word about compliance/Certification Sarbanes Oxley Compliance Rhythm attempts to yield results such as Reduce the time required, number of steps, number of people, number of errors to engineer software A huge part of Rhythm’s primary principles is a high focus on automation Software Migration Request (SMR) System Risk mitigation is also a huge aspect of Rhythm Early feedback; architecturally-driven, iterative, incremental are all aspects that are tantamount to repeatability of delivery Six-Sigma Rhythm has been adopted into Six-Sigma projects/initiatives A major marketing firm in KS, adoption of Rhythm closed 3 green belt and 2 black belt projects due to its maturity. Rhythm Compliance Two audits Part of our 1-4-3- 2 -1 Service Offering
- 27. Rhythm and the flywheel (HERE) … store energy…efficiently…high output potential and relatively long life…unaffected by ambient temperature extremes… concerns … possibility of it breaking loose Medium sized CLEC (Telco) New to Rhythm (started May 2006); 5 iterations; 1 production iteration; 3 application teams using Major Healthcare Firm (example of a very small project) 22 continuous iterations, 20-plus individuals, 1 release team 3 major releases Major Telecommunications Firm (example of a very large project) 169 continuous iterations, 400-plus individuals 3 parallel release teams, each consisting of 20-50 individuals each 3 releases Lots more… Not shown, before/after information Pretty staggering; the results
- 28. More examples: Rhythm in practice Major CLEC, CO Rhythm ASDE/Rhythm AEF; 2 projects, 1 in production, 1 underway Major Financial Institution, IL RUP ASDE/Rhythm AEF; 3 projects, all in production Large Telecommunications firm, CO FDD ASDE/Rhythm AEF 2 projects, 1 in production, 1 underway Campus ASP Provider, UT (DSDM) Incorporated all Rhythm techniques into their customized ASDE Major Bank, UT (Crystal) 2 projects adopted Rhythm, completed on-time, under-budget, 1 in production today, 1 already re-implemented County Government, CO (XP) 5 projects adopted Rhythm, 3 completed on-time an under budget, still in production