Copyright 2002, Freshwater Partners, all rights reserved. Lessons from the implementation practice of C-bridge Internet Solutions Making Agile Methods Work in a Commercial Consulting Environment

2/28/02 Copyright 2002, Freshwater Partners, all rights reserved. 2 About C-bridge Founded in 1996 Developer of custom e-business solutions – Internet, Intranet, Extranet, CRM, B2B2C2A, supply chain, content management, personalization, e-commerce, trade exchange – Over 150 systems delivered in 5 years – Teams ranged from consultants, customers Sample Customers – Aegon, Allmerica, Ameritrade, BellSouth, Caterpillar, Chevron, Economical Fosters, Insurance Group, JPMorganChase, Motorola, Phillips Petroleum, Seagate, Toyota, US West, US Navy, etc. Developed our method “RAPID Value” in 1997 and have refined it continuously since Created C-bridge Institute in 1999 to teach developed best practices to customers Grew to 900 employees and $84MM in 2000 Merged with eXcelon (ObjectDesign) in 2001 Discontinuing services practices to focus on XML and object database products

2/28/02 Copyright 2002, Freshwater Partners, all rights reserved. 3 About Freshwater Partners Assisting companies to drive business value with technology through education and consulting services – Assessments – Education – Coaching Our Process AssessingAligningEducatingCoachingMeasuring

2/28/02 Copyright 2002, Freshwater Partners, all rights reserved. 4 The Drivers for Agile Methods Speed to market – day delivery cycles A need to drive understanding of how new technology was to be leveraged

2/28/02 Copyright 2002, Freshwater Partners, all rights reserved. 5 Discover The Iterative Release Process Define 90 days (13 weeks) Design Develop Deploy 2 weeks 3 weeks 6 weeks 2 weeks Lines of readiness Weekly iteration Customers and team members need time to “learn” the requirements through interaction with each other. Define, design and deploy could be shortened in subsequent release cycles because system requirements were better understood and major design decisions had been made. Define and design also allows the team to innovate beyond current process assumptions.

2/28/02 Copyright 2002, Freshwater Partners, all rights reserved. 6 Primary Barrier to Development Speed Success Process Product Property Business Users IT Speed to market Value creation Customer retention Ease of use Lifestyle improvement Right features Development team quality of life Career progression Integrated business processes Initiative management Business goals/metrics Resource constraints Adaptability Involvement in System development Efficient user processes The system Fit with other user tools Requirements process Development process Quality process COTS integration Choice of architecture, platform and components Quality metrics Performance metrics Risk minimization Enterprise Integration Product line reuse System usage metrics System quality Stakeholders’ lack of shared perspective drives inefficient decision making. Stakeholders Operating Models

2/28/02 Copyright 2002, Freshwater Partners, all rights reserved. 7 Creating Stakeholder Understanding with Workshops Workshops provide a highly effective forum for stakeholders to discuss their issues in their own language. Creating understanding early in the lifecycle is the most important task of the development team. – Create jointly defined acceptance criteria Workshop content – User experience stories, processes, pain points, needs, wants – Group prototyping – Group development of workflows and use cases

2/28/02 Copyright 2002, Freshwater Partners, all rights reserved. 8 Project Preparation Another significant barrier to speed in development was lack of proper project definition. Solution: Discovery phase - A short phase before the project begins creating the right environment for the project – Business case – Clearly defined project goals and business objectives – Proper understanding of current IT infrastructure and plans – Organizational impact assessment – Ensure you have the right people for the team and time commitments exist – Project logistics – procurement, critical cycle constraints Without a basic understanding of these issues, the team can not create consensus on requirements.

2/28/02 Copyright 2002, Freshwater Partners, all rights reserved. 9 Documentation Deliverable-based process – Documentation reinforces process Documentation was kept as light as possible, but was still significant. Detailed system documentation was maintained in the source code. The goal of the printed system documentation was to make it possible to know where to look in the code if detailed designs were necessary. Documentation included – Project plan – Financial business case – Organizational impact assessment – Architecture assessment – System requirements – Use cases – System architecture and application performance requirements – Roles and interactions of primary business objects – Database design – Release plan – Testing plan – Acceptance criteria – System maintenance and support plan – System rollout plan

2/28/02 Copyright 2002, Freshwater Partners, all rights reserved. 10 Proof of Concept Prototype A working prototype that is built and tested during design to mitigate technical risk – Typical agile approach: Small builds to test new technical designs as needed throughout the release cycle. – Adapted approach: Brainstorm technical risks with the entire team Create a specification for a build that will test/mitigate the identified risks Build and test – Added benefit of testing the build process during design.

2/28/02 Copyright 2002, Freshwater Partners, all rights reserved. 11 Pair Programming and “Moving People Around” Did not seem to improve speed or quality on most C-bridge projects – Difficult to leverage programmers’ expertise in UI, middleware, database, network technologies. – When schedules were tight, the stronger developer tended to do most of the work Our solutions – Development sub-groups (UI, middleware, database) that owned code as a group. – Weekly code reviews of “suspect” code

2/28/02 Copyright 2002, Freshwater Partners, all rights reserved. 12 Development Environments Emphasis on maintaining a standard set of development environments. – Programmer, Integration, Build, Test, Production Developers integrated their code in the integration environment in serial fashion. Programmer implementation tasks were 1-3 days in length. Weekly builds had to run before anyone on the team could go home. Late in the process this moved to daily builds. QA tested all builds.

2/28/02 Copyright 2002, Freshwater Partners, all rights reserved. 13 User Stories Use cases were faster Stories were too imprecise to serve as coding specifications and created misunderstanding and rework. Use cases could be used as common working documents with business and IT personnel.

2/28/02 Copyright 2002, Freshwater Partners, all rights reserved. 14 Other Useful Practices Stand-up meetings – Often held at the beginning and end of every day – Emphasize identifying risks, not designing solutions. Optimize last – Optimization typically took place during the deploy phase User Acceptance Test – Acceptance test developed by the users, developed during define. – Focused users on how they were going to accept the system. – Gave development a target, captured by acceptance criteria. Use of an Application Framework and Experience Factory – Commonly useful code was maintained by a central group and used on many projects. Lessons from prior projects were distilled on a web site where they were easily accessed.

2/28/02 Copyright 2002, Freshwater Partners, all rights reserved. 15 Things That Are Simply Good Engineering Simple design Coding standards Unit tests / test harness – All developers were required to create unit tests, especially for business objects. Unit tests were aggregated and run daily by QA.

2/28/02 Copyright 2002, Freshwater Partners, all rights reserved. 16 Things We Did Not Try CRC Cards – UML diagrams worked very well for us and all of our engineers were already trained in their use.