Agile Software Development in the Large

Transcription

1 Agile Software Development in the Large Jutta Eckstein 1 Large Large in... Scope Time People Money Risks We concentrate on Large Teams Large is relative 1, 2, 10, 100, 2000 People 2

2 Principles behind Agile Manifesto Early and continuous delivery of valuable software Welcome changing requirements Deliver working software frequently Business people and developers work together Trust motivated individuals Face-to-face conversation Working software is the primary measure of progress Promote sustainable development Technical excellence and good design Simplicity is essential Self-organizing teams Team reflection and adjustment Source: 3 Deliver Working Software Frequently Balance risk reduction with feature accomplishment Two-week iterations have been proven Same heartbeat for all teams Time-boxed development: Knowledge about velocity Improvement of overall project plan 4

3 Delivery of Valuable Software Focus on completing valuable features Accomplishment means integration, test and documentation Definition of Done has to be agreed by all teams Structure teams along features For ensuring the business value and the customer s advantage Feature teams comprehend all necessary roles and all required know-how 5 Customer Involvement Defined single customer is rare, more typical is: Large invisible customer base Community of customers Therefore: Customer surrogate Product Owner(s) Team of product owners Lead product owner steers team Mid-iteration pre-planning for coordinating the business goal 6

4 Agility means Welcoming Change Success is only defined by the customer Change in features and in priorities Clear sign that customer gets better understanding Don t forget to obtain feedback from your end users Most often this can be addressed with iterations But: A change means: Time delay Elimination of another feature 7 Promote Sustainable Development For realistic planning determine each teams velocity Note: velocities are not comparable Ideally: each feature team provides its own estimates Synchronize baseline at times Reviews and code inspection External Internal Review team Continuously: pair programming 8

5 Trust Motivated Individuals Trust always goes ahead: By giving trust you re gaining trust Tom DeMarco Trust is based on: Communication Transparency Honesty Trust regards all: Developers Customers Managers 9 Face-to-Face Conversation Face-to-face communication is always preferred Daily Synchronization is a must to have a common understanding to deal with roles and issues to get feedback Think about: Daily Scrum of Scrums People exchange Communication facilitator 10

6 Simplicity is Essential Conceptual Integrity Simplicity comes from conceptual integrity (Parnas) System architect is premise for conceptual integrity Chief architect pulls the strings Communicates the vision Key ideas Technical responsibility assignments Technical decisions Servant with courage and experience 11 Continuous Attention to Technical Excellence enabled by Technical Service Team A good architecture evolves Tests ensure existing functionality Refactoring happens continuously Education in refactoring and writing tests is required Sometimes a dedicated refactoring team is the only solution Feature teams provide a product owner Formulates and prioritizes the requirements Steers the iterations of the technical service team Architecture is a service 12

7 Working Software requires Integration Changes will be integrated as often as possible Makes progress visible and measurable Conflicts are easier to solve Often two-stage integration Continuous feature team integration Cross team integration e.g. by nightly builds Integration needs support Plan at least 10% of development effort 13 Regular Team Reflection and Adjustment Staged retrospective Individual feature team retrospective Project-wide retrospective Changing representatives General advice Reflect on results of past retrospective Define actions for top 3 14

8 Self-Organizing Teams People and teams differ Each team defines its own process Retrospectives help to shape the process By ensuring the overall agility of the project Servants for large teams provide different views Process: Coach / Scrum Master Business: Product Owner Organizational: Project Manager Technical: Architect Each servant is most likely supported by a team 15 Lessons Learned Agile Manifesto provides guideline for scaling Feature teams and product owner(s) ensure business value Risk reduction by short feedback cycles Technical teams as service providers ensure conceptual integrity It is not the strongest of the species that survive, nor the most intelligent, but the ones most responsive to change. [Charles Darwin, The Origin of Species, 1859] 16

9 Many Thanks! Contact information: Jutta Eckstein Illustrations by: 17