Case Study: Waterfall to Agile

6 months in…

Tony Bruce, Richard Wadsworth, Andrew Jutton

Agenda

• What will Agile mean to you?• Case study : Set the scene• Past – Present – Future– Physical Environment– Requirements Gathering– Development– Testing– Deployment

• Summary

What will agile mean to you?

• You are no longer working on your own

• You will have a much deeper understanding of the application:– Requirements– Architecture– Data

• You will have an opportunity to contribute• You will have equal ownership

Set the scene

• WNW Consulting Ltd– Software Delivery consultants– Engaged to help improve the quality of and the

manner in which software is delivered

• Insurecom Ltd– Insurance software house

The Physical Environment

Requirements Gathering

• Past– Separate documents used for each discipline– BAs defining requirements/solutions in isolation– Developers acting as interpreters– Testers completely left out of the loop– Minimal Business interaction– Minimal End User engagement

Requirements Gathering

• Present– Product Owner in place– End User engagement– BA, Devs and Testers plan and review together• Acceptance criteria• Examples (Given, When, Then)

– BA owns the requirement and the story– The team is talking

Requirements Gathering

• Future– BAs work with internal and end customer– BA owns the requirement– Team owns the story– A single test plan document shared by all– Wider coverage (not just happy path)– Improving plan and review sessions

Development

• Past– BA wrote the Functional Spec– Architect wrote the Tech Spec (sometimes)– Dev implemented from Tech Spec

– Little knowledge sharing– Little feedback from the business and each other– Major development was outsourced

Development

• Present– Working code over specs and prototypes– Code drops : little and often– Automated Build Validation Test deployments– “DevBox” testing

Development

• Future– Define best practices• Clear architectural patterns• Consistency

– Work closer still with BA and Testers– Code Sharing

Testing

• Past– Manual test scripts• Written before testing started

– Manual testing• Mostly testing happy path

– UI testing

Testing

• Present– Testing integrated into the lifecycle– Test early, test often– Continuous feedback cycle– Automated test execution

Testing

• What worked– Moved from Windows to Web– UI Automation– Service API automation– BDD

• What didn’t work– Coded Automation

• Difficult to keep tests alive during rapid development• Time consuming

– BDD• As a team not enough investment upfront

– Code drop / Testing not in sync

Testing

• Building out the SDLC

Deployment

• Past– Manual– Error prone– Long lead time– Unpredictable– Required specialist knowledge

Deployment

• Present– Wix 3.5 and Component based msi– Fully scripted– Tokenised configuration– Manual smoke tests– Repeatable– Predictable– Fast• build out a new environment in 30 mins

Deployment

• Future– One click deployment– Automated suite of smoke tests– Any authorised user can deploy– Fully integrated into build process– Productised for reuse– Integrated into Service Delivery processes

Summary

• The whole team understands the application• Get people out of their comfort zones• Knowledge share• Everyone contributes to the project• Everyone owns the project

• Not limited to greenfield development

• You’re no longer working on you own• Halfway through the journey

Thank You