Agile Software Development

IBM Software Group Agile Software Development Dr.-Ing. Thomas Stober Release Architect, WebSphere Portal IBM Deutschland Entwicklung GmbH 2007 IBM Corporation

Agenda Introduction WebSphere Portal About the team, the product.. and the traditional development approach Agile Software Development A variety of approaches Mix and Match Agile development for Portal Best practices 2

IBM Software Group Introduction 2007 IBM Corporation

About WebSphere Portal: The Team Global development 8 major locations Multiple delivery streams Major releases every 1 ½ years Express Fix packs Other product dependencies WebSphere Application Server WebSphere Process Server Quickr And many more Westford Raleigh Boeblingen Haifa Haifa India India Beijing Beijing Yamato Sidney Sidney 4

About Portal: Traditional Development Approach Management System Commitment, WHAT has to be developed IPD Integrated Product Development DCP Decision Check Points Concept Plan Availability Release Content Portal Development Process Description, HOW to develop Analysis Requirements Design and Development Line Items Design Documentation DCUT Design-Code-Unit- scenarios IUT Integrated Unit FVT Function Verification SVT System Verification Final regression testing GM Golden Master 5

About Portal: Traditional Development Approach Analysis The Perfect Plan Develop Coding complete Golden Master 6

The Perfect Plan Does NOT Exist! Human life is just an instance, its existence is subject to continuous change. Marc Aurel If anything can go wrong, it will. Murphy s Law 7

Waterfall Approach: Getting Tougher Towards the End Analysis Kosten/Umfang The Perfect Plan Zeit Qualität Develop Coding complete $ Fehlerkosten t Golden Master 8

When Everybody gets really nervous Develop Projected Defects Projected Valid Actual Defects Actual Valid Plan: Total Backlog complete Reality: we are not done 14000 Coding complete 12000 14000 12000 10000 8000 6000 4000 2000 10000 8000 6000 4000 2000 0 0 9 20051102 20051109 20051116 20051123 20051130 20051207 20051214 20051221 20051228 20060104 20060111 20060118 20060125 20060201 20060208 20060215 20060222 20060301 20060308 20060315 20060322 20060329 20060405 20060412 20060419 20060426 20060503 20060510 20060517 20060524 20060531 Total & Valid Defects GM

The Vasa Project, 1628 http://www.vasamuseet.se 10

Planning is good but has its limits Accept uncertainty There is no perfect plan Customer does not know or describe his requirements clearly enough Technical solution is not entirely understood Errors in design and implementation can invalidate plans Changes in team are possible at any time Change of customer requirements and your priorities are possible at any time Risk Management The most dangerous events are those which are not predictable Plan for Change! It ain't what you don't know that gets you into trouble. It's what you know for sure that just ain't so. Mark Twain 11

IBM Software Group Agile Software Development 2007 IBM Corporation

What is Agility? React to changing requirements and constraints Balance between Flexibility and Structure Within your organization During planning and execution When using processes and tools In your mentality 13

Agility: Keep the balance between predictable Structure and total Flexibility (I) Flexibility is good, but no for free! Airline Tickets are cheaper when you commit to your destination and travel dates early! Same is true for product features Provide best possible guidance and planning! Don t use Agility as an excuse for lack of planning and design Establish high-level goals and timelines Keep risks in mind and have mitigation plans ready Make sure that a plan has sufficient buffer to accommodate change 14

Agility: Keep the balance between predictable Structure and total Flexibility (II) Understand two fundamental cultural patterns according to Edward T. Hall, http://en.wikipedia.org/wiki/edward_t._hall Monochronism demands a planned, deliberate control over time. This is a task-oriented way of living. Individuals like to identify time periods when certain activities will be done. Their strengths may be utilized in developing schedules whose exactness and precision allows workers to function in a cooperative manner. It 's efficient for getting things done and it dominates most parts of the US and other industrialized countries. Polychronism is the perception of time as merely a context in which we live. Tasks are handled as they come. Such jobs require that the individuals constantly adjust to incoming new jobs and responsibilities. They enjoy change as part of their job (and) changing from one activity to another is the part of this pattern. This is a relationship-oriented way of living. It's efficient for building community, personal, and social relationships, and it dominates Asia, as well many rural areas. 15

IBM s definition of Agile Development Uses continuous stakeholder feedback to deliver high-quality and consumable code through use cases and a series of short, time-boxed iterations. Key Features: Stable code at the end of each iteration be able to ship every few weeks Meaningful stakeholder interaction get customer feedback outside-in-design. Avoid anything that does not add value (waste). Trust the team delegate responsibility establish teams responsible for end-to-end functionality (reduce hand-offs and task switching) 16

IBM Software Group Mix and Match: Agile Development for Portal 2007 IBM Corporation

Horizontal Teaming Theme & Component Matrix Themes Components Infrastr. CMAPI Security Owner Owner Owner Owner Owner Owner Organizational Focus component affinity. Goal/Delivery Focus major cross-cutting themes. Horizontal (= Tiger ) -Teams Owner Owner 18

INCEPTION --- STEP 1: Translating Customer Requirements into Vision/High Level Goals Vision Decision Customer I want a really cool user interface, which is state of the art Leadership Team Vision - Create a new User Interface - Support WAS 6.1 I want to leverage the most recent WAS as the common platform within my company Prioritization Strategy planning Release planning Budget allocation /staffing High level use cases Decision (staffing, rough timeframe and high-level goals) Deliver a release in 3Q07, and another in 1Q08 Invest 5 people to create a new User Interface Invest 4 people to support WAS 6.1 19

INCEPTION --- STEP 2: Translating Vision/High Level Goals into actual Requirements/Line Items Decision Content High-level goal Discussion Decision (staffing, rough timeframe and high-level goals) Deliver a release in 3Q07, and another in 1Q08 Invest 5 people to create a new User Interface Invest 4 people to support WAS 6.1 Leadership Team Invest 5 people to create a new UI Invest 4 people to support WAS 6.1 Leverage Ajax Tiger Team Leads Move from WMM to VMM Java 5.0 compliance Timeframe Discussion Teamcharter Requirements HCDD, plan Efforts Staffing Priorities Inception Teamcharter Requirements HCDD Plan Efforts Staffing Priorities Deliver a 6.0.2 release in 3Q07 and a 6.1 release in 1Q08 StabilizationPoints (Iteration Points Exits) GM Release 6.0.2 GM Release 6.1 Translating high-level goals into technical requirements and line items Content (requirements and plan outline) 20

INCEPTION --- STEP 3: Create an Iteration Plan Leadership Team Adjust Vision, Decision (staffing/timeframe/goals) when necessary Content (requirements and plan outline) Teamcharter Requirements HCDD Plan Efforts Staffing Priorities Teamcharter Requirements HCDD Plan Efforts Staffing Priorities LineScen. item Line item Line item Scen. Line Scen. item StabilizationPoints (Iteration Exits) Line item Scen. Line item Adjust priorities, requirements line items when necessary GM Release 6.0.2 Line itemline Scen. item Iteration Plan (Line Items for execution) GM Release 6.1 Line item Scen. Line item Work for a future release Tiger Team Content Plan Create a Plan... based on given timeframe... based on given goals... based on agreed teamcharter Iteration Plan - agile, adaptive - strategic cross-release thinking - includes Dev and work items Working - use case driven, - decentralized, - within given high level goals - in horizontal teams 21

ELABORATION, CONSTRUCTION --- STEP 1: Executing an Iteration Plan Iteration Plan (Line Items for execution) Teamcharter Requirements Line Items HCDD Plan Efforts Staffing Priorities Teamcharter Requirements Line Items HCDD Plan Efforts Staffing Priorities Tiger Team Leads Design Line item Scen. Line item Common CMVC Rel. 6.0.2 Design Line item Scen. Design Design Line item Scen. Line itemline Scen. item StabilizationPoints (Iteration Exits) Actual Code in CMVC streams Release Closure Release Management GM Release 6.0.2 Common CMVC Rel. 6.1 Design Line itemline Scen. item Tracking Status PCR Adjustment (when necessary) Release Closure Design Plan Code Monitoring GM Release 6.1 Line itemline item Scen. Work for a future release Future Release CMVC = Code repository 22

TRANSITION --- STEP 1: Release Closure Deliverables Release Quality Assessment Release Management Line item Line Scen. item Scen. Common CMVC Rel. 6.0.2 Tiger Teams Line item Iteration Exit Iteration Exit Scen. Line item Good Driver Line itemline item Scen. Deliverable Quality Assessment IUT Scen. Scen. Iteration Exit StabilizationPoints (Iteration Exits) GVT Iteration Exit Deliverable Quality Assessment IUT Good Driver Extended FVT Perf. ing Line itemline item TVT SVT Scen. Scen. Acceptance Final Regr Teams Line itemline item Work for a future release GM Release Scen. Scen. 23

Example: The Web 2.0 Tiger Team (I) Leadership Team Goals Business Scenarios Early Delivery as Portal V6.1 Beta Demo of Prototype on Greenhouse Demo at LotusSphere 09/2006 Mission defined Initial Team staffed GM Delivery as Portal V6.1 Beta 09/2007 Mission updated Plan aligned with Portal V6.1 Drag&Drop Themes & Skins Back Button 03/2007 Mission updated Plan aligned with Portal V6.0.2 REST Services Basic Client Side Theme Demo Portlets Semantic Tagging Client Side Programming Model AJAX Proxy, Access Control Property Broker Accessability and I18n 05/2008 (plan) Mission completed: GM Delivery with Portal V6.1 Business Portlets Project Mgnt Business Portlets Portlet Container Engine Web 2.0 Tiger Team Admin UI 24

IBM Software Group Summary and Best Practices 2007 IBM Corporation

Agile Development Outside In Design driven based on use cases Think horizontally across Organizations Sustainable Pace Continuous integration of code Stabilization points Prototyping and early customer feedback Learn as we go Allow teams to stay focused It s a lot about philosophy There is NO general rule Mix and Match is common Accept that Change is part of your plan Needs commitment by the entire organization 26

Critical for Success: Management Responsibility Initiate Tiger Teams early with staffing based on the budget decided Provide sufficient guidance to the teams: Provide a feature grid and a timeline grid Communicate a well defined overall Vision and high level Goals Communicate a rough timeline in which deliverables are expected Make clear and timely decisions Balance detailed goals versus flexibility Delegate responsibility to the teams Teams do detailed planning and prioritization of Line Items within the given High Level Goals they are the subject matter experts they have the authority to act within give guidance and goals Allow teams to focus on making progress be extremely cautious with re-planning and adjustment of goals ( next chart) 27

Critical for Success: Planning Responsibility Support Agility Do not overcommit a Tigerteam Only commit to really important must-have work items. Don t be too aggressive. Be realistic. Drive Content based on use cases and customer value Plan for test coverage and execution (automation!!) Anticipate changes throughout the project and be prepared to adapt to changes Stick to schedule/iteration length, but rather move content around ( time boxing ) Avoid excessive use of Agility Change is good! But it doesn t come for free Allow the team to stay focused Keep overall vision, high level goals and rough timeline as stable as possible Allow the team to execute Limit re-planning exercises, unless absolutely necessary Avoid team members being side-tracked Allow the team to gain a common team spirit Avoid changing team members too often 28

Critical for success: Collaboration Collaborate across component and location boundaries We = Tiger Team Avoid constantly changing team members Ensure a reasonable staffing Integrate test and development members Common goals Exchange of expertise More effective, quicker defect turnaround Integrate team members across locations and organizations We are a globalized company End-to-End thinking based on use cases Out of the box thinking Responsibility for customer value rather than component function Ensure component consistency and quality Associate a manager which supports the Tiger Team 29

IBM Software Group Your Questions, please... tstober@de.ibm.com 2007 IBM Corporation