www.synerzip.com

Agile Approach @SynerzipAgile/Iterative Development With Distributed Teams

WORKING DRAFT – September 2008

Confidential

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?

• 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

When done properly…

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 Lifecycle1. Engagement/Project kick-off2. Development Environment and Infrastructure set-up:

version control, issue tracking and build automation3. 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. Retrospectives4. 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

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

Version control, Issue tracking & build automation

Confidential

Typical Dev. InfrastructureCommon 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

Database Server Source ControlQA Sever

Offshore Team

Onsite Team

Client Network

Synerzip network

Firewall

Confidential

Build Server Structure

Confidential

Recommended Dev ToolsCategory Recommended Other Acceptable

ToolsNot Recommended

Version Control Subversion CVS/VSS/Microsoft Team System

More than one version control.

Issue Tracking Bugzilla Mercury Quality Center, Assembla, SalesForce.com, jira, SharePoint

Excel , MS Word

Project Plan Excel MS Project, Base camp, Assembla

Automated Build CruiseControl ANT, NANT

Confidential

Collaboration Tools

Category Recommended Other Acceptable Tools

Not Recommended

Voice Conference Conference Bridge Skype

Video Conference Polycom PVX Skype

Desktop Sharing LiveMeeting Webex, Goto Meeting, Remote Desktop

IM Skype/Yahoo MSN messenger

Document Collaboration

Wiki Base camp, Assembla, Sharepoint

Email

Confidential

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

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.

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

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.

Steps 2-6 repeated for each iteration.

2a. PRD/Product Backlog/4. Issue Tracking

6. Development Team

Customer

Subtitle

6/19/2008

2b.Wiki

Stakeholders

1. MRD / Requirements Outline

5. Test Cases

3. Release Plan/Iteration Plan

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

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

Sample Product Backlog

Confidential

Iteration Plan/Sprint Backlog

Confidential

Iteration Project Plan - ExampleHigh Level Iteration Plan For Development Phase of PRM Enhancement Work

IterationNumber of Weeks Start Date End Date User Story (Requirements)

Deliverables for the Iteration

1 3 11-Feb-08 29-Feb-08

Bulk Charge-out, Bulk Charge-in

Bulk charge-out, charge-inPass-along

2 2 3-Mar-08 14-Mar-08

Bulk Mark Destroyed, Bulk Move

Pass-along, Bulk Mark Destroyed

Create/Modify Barcode Printing Rule

Pass-along

3 2 17-Mar-08 28-Mar-08

Bug Fixes, changes for Bulk charge-out, charge-in, Mark Destroyed, Pass-along

Create/Modify Barcode Printing Rule, Bulk Move

Bulk Move

Create/Modify Barcode Printing Rule

4 2 31-Mar-08 11-Apr-08

Bar Code Printing PoC

Delete Barcode Printing Rule

Delete Barcode Printing Rule

Reconciliation

5 2 14-Apr-08 25-Apr-08

Bug Fixes, changes for Create/Modify/Delete Barcode Printing Rule

Reconciliation, Bar Code Printing

Bar Code Printing

Reconciliation

6 2 28-Apr-08 9-May-08

Bug Fixes, Minor changes for Reconciliation, Bar Code Printing

 

System Testing

 System Architecture Document

7 1 12-May-08 16-May-08 Final System Testing, Documentation System Architecture Document

Confidential

Automated Build Script1. 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

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

User stories on the wall

Confidential

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

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

Release burn down bar chart

Sto

ry P

oint

s

Iterations

ITR 1

ITR 2 ITR

3 ITR4

ITR 5

Confidential

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

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

Production Release Process

Get latest versionCheck out related files

Code changeLocal testing

DEVELOPER PC SourceControl Server

Team testing (optional)

BuildServer

Sand box

Check in source code

Get latest versionCreate new build

New build installed on QA server

QA Server

Pass QA? Roll back changesNo

New release installed on staging server

Get latest versionCreate new build (new release)

StagingServer

Deploy to production server

Source code zip file created and stored in the SourceContrrol

Yes

DEVE

LOPM

ENT

QAST

AGIN

G

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

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

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

4. Select Appropriate Discipline?

Unacceptable

Light Medium Heavy Overkill

Requirements/Planning (3a, 3b, 3c)

No formal requirements doc/Emails

Excel or Word Document

Wiki/SharePoint/SRS/Iteration Plan/Whiteboard

Wiki/SharePoint/SRS/Iteration Plan/Whyiteboard/Client Signoff

All steps of typical Waterfall model

Development /Coding Practices/Change Control (3e, 3f)

No Process Development Guidelines/Peer code reviews/CR

Development Guidelines/Peer code reviews/Senior Architect 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 (3d) No QA Process

QA Process/ 1QA - 4 Dev

QA Process /1.5 QA – 4 Dev

QA Process /2 QA – 4 Dev QA Process /3QA – 4 Dev

Build and Release (3g, 3h)

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

Documentation

No formal Documentation/Emails

PRD/System Architecture

PRD/System Architecture/Test Plan/Test cases/Wiki/SharePoint

PRD/System Architecture/Design Documents/Test Plan/Test cases/Release Plan

All Documents of Typical Waterfall Model

Within the Agile approach, different projects have differing need for process discipline/ rigor. We need to select the appropriate level of discipline