Agile Approach Synerzip Agile Iterative Development With Distributed Teams

Agile Approach @Synerzip Agile/Iterative Development With Distributed Teams WORKING DRAFT – September 2008 www. synerzip. com

Discussion Topics • Agile 101 • Agile @Synerzip Confidential

What is Agile? • Agile development is the ability to develop software quickly, in the face of (rapidly) changing requirements • Agility is achieved by adhering to well understood practices, discipline, and feedback • Various flavors are practiced in the industry – SCRUM, Extreme Programming (XP), Adaptive Software Development, etc. • From Agile Manifesto of 2001: “Agile approach values… – – Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan …that is, while there is value in the items on the right, items on the left are valued more” But, Agile is not an excuse to do maverick development without due attention to requirements analyses, thoughtful design, robust development & testing Confidential

Why Adopt Agile Approach? When done properly… • It is just more suitable for fast moving companies – Builds software which is more likely to delight customers • Embraces “changing requirements” as a positive, • Allows more innovation - relieves the product managers of the fear of committing to an irreversible change – Builds better quality, robust code – Provides better visibility and delivery predictability to management • It lends itself well for working effectively with offshore/ distributed development teams – Quick release cycles (Sprint) and scrum make the efforts put in by the offshore team more visible leading to trust – Requires less onerous documentation around requirements, thereby main bottleneck in leveraging offshore is dramatically reduced Over 70% of large & small companies have plans to adopt one or more of the agile practices this year Confidential

Discussion Topics • Agile 101 • Agile @Synerzip Confidential

Agile Approach @Synerzip • Next few pages lay out the general approach of Agile development followed at Synerzip • This is a highly collaborative process, across distributed teams, including client and Synerzip professionals • This general approach is applicable to all software development & testing projects, e. g. – – New Product Development Ongoing Maint/Enhancement of Existing product Configuration/Integration of Enterprise Software Development of QA Automation Framework • The very nature of Agile process is that it is flexible and adaptable in different client/project situations • While process adaptability/flexibility is an asset, we still need follow a minimum level of software engineering discipline – “hygiene” as described in following pages. Confidential

Agile/Iterative Dev Lifecycle 1. 2. 3. Engagement/Project kick-off Development Environment and Infrastructure set-up: version control, issue tracking and build automation Repetitive steps in each development iteration a. Requirements Analysis b. Iteration Planning & Estimation c. Daily scrum, weekly report, monthly review d. Test automation and test driven development e. Change control and re-estimation f. Coding standards and code review g. Release process and document h. Review of Iteration Deliverables i. Retrospectives 4. Select “Appropriate” Discipline/Rigor for Development Confidential

1. Engagement Kick Off • What Works • Clear agreement on project objectives, scope, team and discipline. • Team roaster is on the wiki, team has gone through the customer’s web site and documents sent by the customer and is prepared to ask some pertinent questions. • Standard practices at Synerzip for setting up VPN, version control and database server are explained by going over a document. Clear idea of the days required to set up these things is given to the client team. • Clear agreement with client team on periodic interactions – daily calls, weekly reports, monthly reviews, etc. • Team shows the first deliverable in week 2 or 3 of the engagement. • What Doesn’t • • There is no identified owner/ champion who will make it work. No formal meeting or conference call happens to kick off the engagement. Contract is used to define roles and responsibilities. Teams don’t invest time on identifying and agreeing on tools of collaboration such as VPN, Bug tracking, version control etc. • Teams start work in isolation without demonstrating what they are working on and without seeking/ providing any feedback. Confidential

2. Development Infrastructure Version control, Issue tracking & build automation • What Works • Common version control for both on-site and off-shore teams • All tasks including features, changes and bugs are filed in the issue tracking system. • Separate out production build and development build by having tasks that are affected by developers’ work in the development build so that it runs faster than the production build. • What Doesn’t • Code drops are FTPed or Emailed back and forth. • Two or more repositories at off shore and on site location. • Developers check in code which is incomplete- which breaks the build. Confidential

Typical Dev. Infrastructure Common development code-base, development- and test environment Sending code, deploys, etc back and forth via email because some cannot ABC and others can only XYZ is a living nigtmare Confidential

Build Server Structure Confidential

Recommended Dev Tools Category Recommended Other Acceptable Tools Not Recommended Version Control Subversion CVS/VSS/Microsoft Team System More than one version control. Issue Tracking Bugzilla Mercury Quality Center, Excel , MS Word Assembla, Sales. Force. com, jira, Share. Point Project Plan Excel MS Project, Base camp, Assembla Cruise. Control ANT, NANT Automated Build Confidential

Collaboration Tools Category Recommended Other Acceptable Tools Voice Conference Bridge Skype Video Conference Polycom PVX Skype Desktop Sharing Live. Meeting Webex, Goto Meeting, Remote Desktop IM Skype/Yahoo MSN messenger Document Collaboration Wiki Base camp, Assembla, Sharepoint Confidential Not Recommended Email

3 a. Requirements Analysis • What Works • Well defined independent requirements for the remote team. • Well documented requirements in a spreadsheet or a word document, each requirement is numbered • Copious Q & A and interaction over the requirements. Questions can be tracked using a spreadsheet or Wiki • Stakeholders Actively Participate • Gradual reduction in means uncertainty with goal uncertainty. • What doesn’t • There is no clearly well carved of set of requirements for the remote team to work on • Treating requirements analysis as a one time exercise. • Why document the requirements when you know it is going to change anyway? • Assumption that the customer needs what he wants and wants what he says. • Requirements analysis in isolation. • Trying to define every requirement to the last detail up front. Confidential

Reqmt. and Dev. cycle - Typical 1. Client provides high-level requirements outline document, laying out the vision/roadmap (aka MRD) 2. a. On site Product Manager works with client team and prepares PRD/Product Backlog. This remains a live document. Each requirement tracked through a unique number. 3. b. Requirements’ details are clarified for each Iteration, through collaboration via Wiki etc. All requirements are put-up on Wiki/Share. Point, for all stakeholders to review 3. Once frozen, these requirements become “Product Backlog” - used to create Release and Iteration Plan with task list. 4. Issue Tracking System (Bugzilla) used to assign task to appropriate team members. 5. Test cases prepared against each requirement and attached to the Issue Tracking System. 6. Development team complete assigned tasks, reassign back to QA. 1. Steps 2 -6 repeated for each iteration. Confidential

Reducing Uncertainty 1. The best way to deal with uncertainty is to iterate. 2. To reduce uncertainty about what the product should be, we work in short iterations and show/give working software to users every few weeks. 3. Similarly uncertainty about how to develop the product is reduced by iterating. For example, missing tasks can be added to plans, inadequate designs can be corrected sooner rather than later. Confidential

Agile Documentation • Need far less documentation than you think • Intent of Agile Documents – – – Maximize stake-holders investment Are concise Fulfill a purpose Are sufficiently accurate, consistent and detailed Are sufficiently indexed • Typical Documents Needed– PRD, System Architecture, Project Plan, Product Backlog, Weekly Status Report, Test Cases, Test Plan. Confidential

3 b. Iteration Planning & Estimation • Product Backlog is prepared in which high level gross estimates are done against all the requirements and the requirements are arranged in their order of priority. • Requirements with higher risk are addressed first. • Iteration plan has detailed tasks listed with hours estimated against each task. • There has to be some flexibility in every estimate. At least one of the three - time, resource, scope - needs to be flexible. Confidential

Sample Product Backlog Confidential

Iteration Plan/Sprint Backlog Confidential

Iteration Project Plan - Example High Level Iteration Plan For Development Phase of PRM Enhancement Work Number of Weeks Iteration Start Date End Date User Story (Requirements) Deliverables for the Iteration Bulk Charge-out, Bulk Charge-in 1 3 11 -Feb-08 29 -Feb-08 Pass-along Bulk charge-out, charge-in Bulk Mark Destroyed, Bulk Move Create/Modify Barcode Printing Rule 2 2 3 -Mar-08 14 -Mar-08 Pass-along, Bulk Mark Destroyed Bug Fixes, changes for Bulk charge-out, charge-in, Mark Destroyed, Pass-along Bulk Move 3 2 17 -Mar-08 28 -Mar-08 Create/Modify Barcode Printing Rule, Bulk Move Bar Code Printing Po. C Delete Barcode Printing Rule 4 2 31 -Mar-08 11 -Apr-08 Reconciliation Delete Barcode Printing Rule Bug Fixes, changes for Create/Modify/Delete Barcode Printing Rule Bar Code Printing 5 2 14 -Apr-08 25 -Apr-08 Reconciliation, Bar Code Printing Bug Fixes, Minor changes for Reconciliation, Bar Code Printing System Testing 6 Confidential 7 2 1 28 -Apr-08 12 -May-08 9 -May-08 16 -May-08 System Architecture Document Final System Testing, Documentation System Architecture Document

Automated Build Script 1. Build script is to provide an automated way to generate system builds in a repeatable and consistent manner. 2. With Automated Build, you can automate the build, test and release processes and focus on more important issues. 3. Helps reducing the time and effort needed to create your application builds. 4. The build script will be part of Continuous Integration which gets triggered based on the rules e. g. developer checks-in a code file which triggers the build process. Confidential

3 c. Daily scrum, wkly report, mnthly review • What Works • All team members answer three standard questions in the scrum which is a 10 -25 minutes stand up meeting. • Scrum happens next to the wall on which stories are put up under each team member’s name. (See picture) • Weekly report indicates progress in terms on % completion on various tasks. • Monthly review has no major surprises as the client team has already gone through the salient issues. • What Doesn’t • Team members work in isolation and no one knows what the others are working on. • Members digress and start discussing issues and solutions in the scrum. • Weekly report gives no idea of progress by using open statements like “this week the team continued to work on UI layer” Confidential

User stories on the wall Confidential

3 d. Test automation + test driven development • What Works • Customer’s buy in is required so that team can spend the required hours on writing tests before rushing into write the code. • Team’s buy in is required because it takes more efforts to think through the unit tests before the code is ready. Developers find it easier to write the code than to write tests. • Tests should run every time you build. The build should fail even if one test fails. • Unit testing and coding happen in parallel as an intense pair programming exercise. • What Doesn’t • Unit tests are an after thought and only partially test the code. • Unit tests are written presuming certain data and environment and they start failing and stop being used once the data and the environment change. • Test driven development initiative starts with writing unit tests for legacy code. Confidential

3 e. Change control and re-estimation • What Works • New requirement or change is brought to the client’s notice right at the time when the requirement gets communicated. • Burn down chart shows old requirements and change requests separately. ( See release burn down bar chart) • Change requests are added to the further iterations. Re estimation is done at the end of each iteration. ( See cone of uncertainty) • What Doesn’t • Teams engage in an endless discussion whether a feature is new or part of the original requirements or a bug. • Changes are implicitly assumed to be included in the estimate and a separate estimation exercise is not carried out. • Test cases don’t reflect the changes. • Unit tests are not modified to test for the change. Confidential

Release burn down bar chart Confidential

3 f. Coding standards and code review • What Works • Coding standards are shared in a document form between the teams. • Naming conventions are documented. • Peer to peer review , self review and automated review are used in addition to a senior member’s formal review. • What Doesn’t • There is no explicit agreement on which coding standards are being followed. • All code is expected to be reviewed by the lead or the architect. Confidential

3 g. Release process and documentation • What Works • There is a release document covering salient features that have got added, bugs that are fixed and known open issues if any. • Release numbers indicate major, minor and build number explicitly. • Release version is tagged in version control. • Production Release Process • What Doesn’t • There is a no release process. Last known working version is released to production. • Release numbers don’t indicate whether it’s a major or a minor release. • Release endlessly waits for a 100% bug free version. Confidential

Production Release Process 1. Source Code is taken from Source Control and build on Build Server. 2. Successful build it is copied to QA Server. 3. If QA passes the test, the new release is installed on Staging Server. Confidential

3 h. Review of Iteration Deliverables • What Works • Client reviews Iteration Deliverables at the end of every iteration and provides feedback about the same. • What Doesn’t • Iteration Deliverables are not timely reviewed by the client. Confidential

3 i. Retrospectives • What Works • It’s used as a process to improve by accepting constructive criticism. • Teams willingly provide feedback in genuine interest of the project. • What Doesn’t • Not having retrospectives- teams repeat the same mistakes. • Retrospectives are used to do finger pointing. (Blame doesn’t fix bugs!) • Teams keep quiet – “why to bring up an unpleasant topic- especially if it concerns your customer”? Confidential

4. Select Appropriate Discipline? Within the Agile approach, different projects have differing need for process discipline/ rigor. We need to select the appropriate level of discipline Unacce ptable Light Medium Heavy Overkill Requirements /Planning (3 a, 3 b, 3 c) No formal requirements doc/Emails Excel or Word Document Wiki/Share. Point/SRS/I teration Plan/Whiteboard Wiki/Share. Point/SRS/Iteration Plan/Whyiteboard/Client Signoff All steps of typical Waterfall model Development /Coding Practices/Cha nge Control (3 e, 3 f) No Process Development Guidelines/Pe er code reviews/CR Development Guidelines/Peer code reviews/Senior Architect Reviews/Low Level Design review/ Client Signoff/CR Development Guidelines/Peer reviews/Team Lead review/ Senior Architect Reviews/LLD review/ Client Signoff/CR/Approvals QA (3 d) No QA Process/ 1 QA - 4 Dev QA Process /1. 5 QA – 4 Dev QA Process /2 QA – 4 Dev QA Process /3 QA – 4 Dev Build and Release (3 g, 3 h) No Process Manual Build and Release process Automated Build / Release Process/ Periodic Client Signoff Separate Build/Release Environment/ Automated Build and Release/ Client Signoff with each Iteration Separate Build/QA/Release Environment/ Automated Build and Release/ Client Signoff with each iteration Documentatio n No formal Documentati on/Emails PRD/System Architecture/Test Plan/Test cases/Wiki/Share. Point PRD/System Architecture/Design Documents/Test Plan/Test cases/Release Plan All Documents of Typical Waterfall Model Confidential