The Challenges of Aligning Agile Methods with the Outer World for Successful Development Projects

Transcription

1 SEPG NA, May 2014 The Challenges of Aligning Agile Methods with the Outer World for Successful Development Projects Winfried Russwurm, Siemens AG

2 The World of the Agile Scrum Teams.helps to systematically organize technical work for practitioners in Scrum teams, so they can do work in a more focused way.delivers features in predictable intervals for early verification.helps the customer to receive working software in predictable intervals.uses sprint cycles and metrics to rapidly and easily visualize work progress.represents an inner world embedded in a larger environment, e.g. a project Page 2

3 The Project World.employs and interfaces with one or more agile teams.needs to achieve repeatable project success by applying proven practices.performs many additional tasks, needs to manage the project as a whole.interacts with many stakeholders.works according to a process.the project works within a company Sprint 1 Sprint 2 Sprint n Page 3

4 The World of the Company.needs to manage many projects in a consistent way.needs to be profitable and successful.has created processes for sustainable working.is subject to various boundary conditions.is long term oriented Project 1 Project 2 Project n Page 4

5 Challenges Occurring: The Accumulation of Technical Debt Technical debt is work to be done before a particular project can be considered complete. If debt is not repaid, it will keep on accumulating interest, making it hard to implement features later on. Can be seen as invisible results of past decisions that negatively affect future. Examples and symptoms for accumulation of technical debt in agile approaches: Cutting of non-productive tasks: neglected refactoring, insufficient documentation, poor architecture, banning of QA, CM, testing, risk management. As long as features are delivered, this remains invisible. Picking easy-to-do features for early sprints and leaving difficult ones for the last sprints. Features important for the project are eventually dropped, since there are usually surprises with more difficult features. Dropped features are more likely in case of already accumulated technical debt (see above). Dropped features also remain invisible until the end of the project. Page 5

6 What are the Issues Resulting from the Accumulation of Technical Debt? Issues and debts are piling up and remain invisible to project and company, no early insight and control Some agile goals might have been achieved, but project and company goals are missed Project schedule blown at the end of project, delay and additional costs, missed time-to-market Products with long life-cycle can not be maintained or need to be re-engineered or even reverse engineered Customer receives update after update Satisfied customer short-term, annoyed customer mid-term Debt has to be repaid eventually, significant loss of money and reputation Causes rework, delay, cost even after several years What are the reasons and causes for the accumulation of technical debt? Page 6

7 Causes for Cutting Non-Productive Tasks Non-productive tasks may be imposed by the outer world. The goals of the outer world are not understood, communicated or accepted. Non-productive tasks (e.g. refactoring, architecture, QA, CM, peer reviews, risk management etc.) are not visibly contributing to working software (i.e. the feature-itis is raging). Non-productive tasks are deemed to be waste and are therefore banned by agile teams (violates agile principles). Done criteria are neglected, e.g. reviews not performed (violates agile principles). 70% work load (including white noise ) for maximum flow is not accepted by executives. 100% load is mandated. Velocity can not be maintained. Resources split between several projects, or too much white noise. The adherence to agile practices is fading (e.g. no velocity, no burndown, no inner discipline ). Page 7

8 Causes for Picking Easy-to-do-Features First Poor requirements management inside and/or outside agile teams Features / requirements / backlogs are not prioritized or ranked Non-functional requirements are missing (e.g. ilities) or deemed to not contribute to working software Product Owner/Manager not available Uncertainties in the project not addressed early ( decide later ) Total achievable effort from all sprints not aligned with effort needed for the total work to be implemented (needed for project success) Neglecting Scrum principles (e.g. sustainable pace), the inner discipline is missing Poor project management (no outer discipline ) Already accumulated technical debt Page 8

9 Another Cause: The Goals Diverge Agile goals: flexibility, direct customer contact, working software, rapid feature delivery Short term goals (sprint, product backlog) Success means to deliver working software Strong focus on creating value in terms of features Project goals: budget, schedule, quality, use proven practices on an overall level, repeatability Mid-term goals (market window, maintenance) Success means to conduct the project within time, quality and budget Adds activities often perceived as overhead (e.g. plans, QA, documentation) Company goals: business success, profitability, long-term perspectives Long-term goals (repeat customers, costs, avoid late surprises) Success means profit, survival, jobs, growth Adds activities often perceived as waste (e.g. contracts, archiving, reporting) So you ve got Technical Debt now what? (Ward Cunningham) Page 9

10 Lessons learned : Deep integration (I) Agile methods, development processes and process models for all worlds need to be deeply integrated. Clearly communicate the goals on agile, project and company level for a better mutual understanding. Mature processes are an excellent means to facilitate between the inner world and the outer world. Make benefits of activities visible, if deemed to be waste (e.g. our products are to be maintained for 30 years, we need thorough CM and documentation ). Agile requires inner discipline, the project requires outer discipline. Both understandings of discipline are aligned. Agile methods are embedded in a process world. The use of agile methods does not redundantize PM, REQM, QA etc. Adhere to agile methods (e.g. sustainable pace, done criteria, refactoring, velocity, throughput) Page 10

11 Deep Integration of Models, Methods and Process Process Models (e.g. CMMI-DEV, ISO15504) Deep Integation Organizational Process and Project Process Deep Integation Methods and Tools to be aligned with the Process (e.g. SCRUM, Kanban, automation, metrics) Deep Integation Work Results Page 11

12 Lessons learned : Deep integration (II) Deep integration of product lifecycle management (usually outside of development scope) Extensive automation helps to reduce word load Targeted measurements (e.g. from agile, open issues, risk management) Resolve contradictory slogans from various agile/lean principles, e.g. Decide as late as possible,vs. Address uncertainty early. Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live (Rick Osborne) And we can think of many corrollaries, such as Not paying down or restructuring technical debt is not an option (Todd W Fritsche) Page 12

13 Integration Example from Siemens AG From Siemens CT DC EU, Austria Page 13

14 Thank you for your attention! Dr. Winfried Russwurm Phone: Siemens AG, CT RTC SYE Otto-Hahn-Ring 6 D Munich, Germany Page 14