Agile Development

Case Study and Workshop

BackgroundCraig ParsonsRevolution IT, MelbourneDev projects - 9 yearsAgile dev projects - 3 yearsQA and Release Manager, Rightmove.co.uk

Agile since 2005Lots of concurrent projectsAdopting Agile changed everything!Cohesive and productive teams

This Session….What is Agile?Becoming Agile

Dealing with changeTeam structureStreaming iteration output – uninterrupted dev and test cycles

Making it workProcedures and policiesQuality checkpointsCommunication and collaboration Managing releases

Lessons learned and observations

What is Agile?agile Adjective1. quick in movement; nimble 2. mentally quick or acute [Latin agilis]

Iterative developmentAnalysis -> design -> code -> test -> release small components (stories)Relies heavily on collaboration and effective communicationCross functional teamsA team is not doing agile, they are agile.

Manifesto for Agile Software Development

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

http://agilemanifesto.org/

The Agile WorldPlanning

Requirements and storiesEstimatingTest casesTechnical design

Meetings and communicatingIteration kickoffStand-upsWalkthroughsShowcasesBuild meetingsPre-release meetingsRetrospectives

Managing iterationsPre-test entry criteriaPre-release exit criteriaContinuous integration / build systemsDealing with issues/bug fixes

Cross Functional TeamsBefore Agile

QA / Release

Java

Oracle

BA / PM

SYS

Cross Functional TeamsAgile Team Structure

QA / Release

Agile 2

TL BA

J

DB D

JQA

Agile 1 Agile 2

Agile 4Support

SYS

Becoming AgileStrange at firstBenefits for test quickly evidentTransparency took getting used toNot instantly popularReorganise teams to become Agile

Much easier to allocate resourcesResponsibilities clearFormalise Agile teamQA remain objective, whilst contributing to Agile teams

Working Guidelines for AgileStoriesEstimatingWalkthroughsQuality checkpointsIteration kickoffDaily stand-upsShowcasesRetrospectives

Story GuidelinesShould be clear and specific Enough basis to develop without questionsEnough basis to write detailed testsPoint of reference when there are disagreementsIf there is ambiguity, ask the BA to update the story!Everything that happens within a project should be in a storyExample summaries:

As a public user I’d like to have my saved search results emailed to meAs an admin user I’d like to manage customer contact details.Migrate data to new USER table on QA

Example StoryID: RM_209Summary: As a user I want to register a new login

Requirements:Registration screen must comply with page template (refer story RM_205)Username must be no less than seven charactersUsername should be unique so that no two registered users have the same usernameUsername must have alpha numeric charactersPassword must be more than six charactersWhen user enters password text it should appear marked as ‘*’ sMeaningful confirmation message must return once registration is successfulPasswords must be hashed in the databaseUser info must be written to new table RMUSER with columns USERID, UNAME, PWORD (refer DB update RM_227)

Story Lifecycle (1)1. Analysis 2. Write story 3. Story review4. Dev and Test estimates5. Compile iteration based on estimates6. Iteration kickoff meeting 7. Iteration Dev phase

1. (Dev) Develop story /unit tests/code review 2. (QA) Write test cases

Story Lifecycle (2)8. Dev walkthrough story with QA and BA

• (BA) Review work for story relevance• (Dev) Review test cases• (QA) Ensure unit tests/code reviews are done

9. Iteration QA phase (test -> fix -> test ….)10. Showcase / signoff11. Release story (iteration)12. Retrospective

Stand ups monitor progress throughout!

Story Lifecycle

Analysis

Write

Review

Estimate

Allocate

Iteration KO

Develop

Prep Tests

Walkthrough QA

Showcase

Release

Retrospective

EstimatingEstimates occur before a story is allocated to an iterationEstimates should be measured in story points

Most effort = 5 pointsLeast effort = 0.5 points

Iterations have max capacity (e.g. 30 points)Present range of stories to align effort and capacityMake estimates fun

5 pts = 0.5 points =

Dev and test estimate separately A dev (small library change) may be a tester’s (requiring lots of regression)

Estimate board – exampleIteration 8 estimates

Story Dev Test

RM_234 Update all pages with new logo and disclaimer .05

RM_246 As a user I want to be able to register a new login 2

RM_289 Re-factor batch libraries 4 4

RM_267 Compose and distribute useability test invitations 0

RM_765 Add opt in / opt out config in Site Admin 2

RM_256 Migrate logins to new RMUSER table on QA

Total points 27.5 13.5 14

WalkthroughsDev, QA and BA presentDev walks through changes in dev environmentHandover point from dev to testGives BA chance to review work for adherence to storyDev and BA review test casesQA reviews entry criteria

Code reviews (did it pass, any issues?)Unit tests

Entry CriteriaHelps keep the train movingDeveloper cannot pass the story to QA until:

Unit tests have been written/updated to accommodate change and passed (Cruise)Peer code review has passedCVS / Subversion logs for changed added to story

Ensures quality of work before test/release effortEncourages developer collaborationTraceabilityReduce riskUnit tests always up to date

Exit CriteriaAssessed by the entire team before releaseBA, QA/Release, Dev, SYSStory should not be released with iteration until:

Walkthrough done and stakeholders signed offTesting completed (verification, regression, performance)Outstanding defects reviewedOutstanding entry criteria satisfiedRisk analysis OK

Iteration KickoffBriefOccurs after previous retrospectiveOverhang from last iteration?Run through all stories allocated to the iteration Review estimatesMake sure everyone is readyRisks“Go team!”

Daily Stand UpsEvery morning (without fail!)Run by project team leaderNo longer than 15 minutesAll project team must discuss:

What I did yesterdayWhat I’m doing todayAny issues:

Test environmentSystem issuesRelease to environmentsDependenciesEntry criteria not satisfied

Stand-ups - considerationsNo excuses for suffering in silence Everyone should leave clear on what they should be doing and what everyone else is doing!Learned to:

Manage dominatorsEncourage quieter team mates

ShowcaseOccurs prior to release and after QA completeShowcase new and changed stories for iterationAll dev/test/business stakeholders presentPlatform for official release signoff Transparency of workStakeholders feel involvedWhat it took to get to this pointMarks team achievement!

RetrospectivesLead by team leader or BAOccur after iteration is released / completed!All stakeholders should be presentMinutes recorded on whiteboard

Discuss:What was released?What didn’t make it?Outstanding defectsWhat went well? (around the room)What didn’t go well? (around the room)

How will we prevent these points in the future?Agree a way forward – everyone!!

Distribute minutes, and refer back to them!

Agile Iteration and Release ManagementRelease cyclesCommunication!Release meetingsRelease tagsCruise Control + SeleniumRoles and responsibilities

Release Management - AgileRelease to Production every two weeksFour week iterations (2 dev + 2 QA)QA team responsible for testing and managing releasesRelease management rosterTesters are gatekeepers throughout processWork with tags, so dev can commit during regressionIntegrated release system – Cruise Control + SeleniumEnvironments

Dev (to create)Test (to verify)QA/Pre-Prod (for regression, performance, session replication, fail over, etc) Prod (the real world)

Iteration Release Cycle (1)1. Story allocated to iteration and release number in

JIRA.2. Build manager exports list of changes for build and

books build meeting• All developers, QA and system architects present• Build manager runs through list to ensure change

passed in Cruise and QA have started testing• Discuss high risk changes in detail• Rollback procedure

3. BM pushes Cruise build to test environment at request • Sending notification each time

Iteration Release Cycle (2)4. At end of verification phase, BM creates tags

and deploys to QA env...5. Regression test phase6. Pre-release meeting7. Review exit criteria for release8. Compose release notes to distribute

company wide• All repositories to be released• CVS tags• Database changes

Iteration / Release CyclePhase 1 Phase 2

Weds Thurs - Tues Weds Thurs - Fri Mon Tues

Prod Release

Stand-up Stand-up Stand-up Stand-up Stand-up Stand-up

Send releasenotes

Deploy to test Performancetests

Merge tags Verificationtests

VerificationTests

Regressiontests

RegressionTests

QA signoff

Deploy trunk to test env.

Fix defects Dev nextiteration

Dev nextiteration

Dev nextiteration

Dev nextiteration

Retrospectives Dev nextiteration

Build meeting Showcase Prepare release notes

Iteration kickoff Create tags Story reviews Pre releasemeeting

Walkthroughs Deploy to QAenv.

Agile Team Developers Testers Build Manager Systems

Communicating BuildsRelease Manager responsible for communicating build informationVital for project team to know when changes have been deployed (to any environment)Any delays could delay project!Any build related questions, ask the build managerEmail group, Release setup for build communication. (incl. QA, Dev, BA’s, SYS, anyone else who wants to know)Notification sent to Release for every deployment to test and QA environments

Build Emails - SampleTo: Release GroupSubject: New build released to QA

Good morning,

A new build has successfully been deployed to <environment>The updated modules are:

publicsite/trunkbatch/trunkadmin/trunk

They include all changes passed through Cruise as at <time>

Regards,Your friendly build manager

Build Email - SampleTo: Release GroupSubject: Deployment issues

Good morning,We are currently experiencing issues with our deployment system and cannot release any builds until they have been resolved.

Resolving this is our highest priority.I apologise for the delay, and will keep you informed.

Regards,Your friendly build manager.

Build Preview MeetingOccurs mid iterationJust before release Tag is created Ensure everything is ready for the buildHelps gather information about release itemsIdentify risks introduced by new code (what does this impact?) Provides visibility to the buildPlatform to discuss/enforce entry criteriaOpportunity for Systems team to assess risk – especially DB changes

Pre-Release MeetingOfficial handover from QA to SYSPlatform to discuss release with all stakeholders.QA / Release Manager runs through Release NotesHighlight issues found during testingIdentify risks associated with releaseAgree a release plan

DB changes firstOrder of modulesUpdates to cron jobs

Config ManagementBefore Agile – we had commit freeze during testingNeeded to keep the train movingLots of CVS project modulesLots of testing and developing at the same timeDevelopers should be able to commit at any time regardless of cycleNo measure of quality before QA startsSolution

Create live tags during regression phase for releaseImplement and maintain Selenium tests for all modules to run at build time

Releasing Tags

Trunk

Tag/snapshot

Iteration 1Dev/Verify

Iteration 1Fix/Regression

Iteration 2Dev

Release

Merge

Tag

Builds – Cruise Control

CVS

Module1

Module2

Module3

Module4

Cruise Control

Selenium Tests

Selenium Tests

Selenium Tests

Selenium Tests

Alert!Build Failed!

M1Build_145

Commit new

change

M2Build_097M3Build_225M4Build_002

Deploying Cruise builds

M1Build_145 Deploy

Test

Pre-Production

Production

Integrating ChangesChange is not ready to test until it is part of Cruise build

Compiled, integrated and Selenium passed

Developer’s responsibility to monitor their change building after committing in CVS

Immediate action required if build failsModule is locked out until last commit passes Cruise

When it can go wrong….Cut cornersIneffective communicationSticking to process when it doesn’t workNot learning from retrosPreparing for meetingsDo things without telling anyone

Dev changesSystem changesData refresh…

Observations - AgileResponding to change doesn’t create hassleLittle to no rework after releaseMuch better relationship between IT and businessMore team bonding within ITCross functional teams promoted multi-discipline learning – and appreciation!Better working relationshipsFaster throughput of workIssues resolved promptly!Consider dependencies!!

ReviewAgile overviewAgile team structuresStory guidelinesStory lifecycleDev and Test estimatesWalkthroughs / quality checksStand-upsShowcasesRetrospectivesManaging iterationsConfig management and build systemsRelease management and communication