Agile Approach @Synerzip

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

2. Discussion Topics • Agile 101 • Agile @Synerzip Confidential

3. 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

4. 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

5. Discussion Topics • Agile 101 • Agile @Synerzip Confidential

6. 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

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

8. 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

9. 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

10. 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

11. Build Server Structure Confidential

12. Recommended Dev Tools Confidential

13. Collaboration Tools Confidential

14. 3a. 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

15. Reqmt. and Dev. cycle - Typical • Client provides high-level requirements outline document, laying out the vision/roadmap (aka MRD) • 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. • b. Requirements’ details are clarified for each Iteration, through collaboration via Wiki etc. All requirements are put-up on Wiki/SharePoint, for all stakeholders to review • Once frozen, these requirements become “Product Backlog” - used to create Release and Iteration Plan with task list. • Issue Tracking System (Bugzilla) used to assign task to appropriate team members. • Test cases prepared against each requirement and attached to the Issue Tracking System. • Development team complete assigned tasks, reassign back to QA. • Steps 2-6 repeated for each iteration. Confidential

16. Reducing Uncertainty • The best way to deal with uncertainty is to iterate. • To reduce uncertainty about what the product should be, we work in short iterations and show/give working software to users every few weeks. • 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

17. 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

18. 3b. 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

19. Sample Product Backlog Confidential

20. Iteration Plan/Sprint Backlog Confidential

21. Iteration Project Plan - Example Confidential

22. Automated Build Script • Build script is to provide an automated way to generate system builds in a repeatable and consistent manner. • With Automated Build, you can automate the build, test and release processes and focus on more important issues. • Helps reducing the time and effort needed to create your application builds. • 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

23. 3c. 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

24. User stories on the wall Confidential

25. 3d. 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

26. 3e. 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

27. Release burn down bar chart Confidential

28. 3f. 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

29. 3g. 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

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

31. 3h. 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

32. 3i. 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

33. 4. Select Appropriate Discipline? Within the Agile approach, different projects have differing need for process discipline/ rigor. We need to select theappropriate level of discipline Confidential