Engine for Growth: Agile Saas Case Studies

Engine for Growth: Agile SaaS Case Studies

Paul Petersen Director Ideas Ahead Pty Ltd

SaaS Business Challenges

Adapting to Rapidly Changing Market Demands . In the Collaborative Economy Increasing Speed of Delivery . With Time Compression Managing Growth - Economies of Scale . Utilisation of global “available” Idle Capacity Maintaining Reputation . With Social Education and Actionable Brands Innovating ahead of competitors . Global Mining of Cross-Domain Talent

Collaborative Economy • Causing disruption of assets, middlemen, trust, ownership • Driving innovation investment, partnerships, reinvention Idle Capacity • Untapped social, economic and environmental value of under-utilised or idle assets Time Compression + Micro Transactions • Ability to reduce time to process, transact or gain access, etc. • Small immediate payment/loans/credit, etc.

Synchronise Data across your Business

Automate Tedious Tasks

Accounting System Add-On Market

Adapting to Rapidly Changing Market Demands . Agile -> Lean Start-Up Approach

Increasing Speed of Delivery . Continuous Integration of new services / technology

Managing Growth - Economies of Scale . Automated 365 Monitoring of Variable Demands

Maintaining Reputation . Deliver Quality Outcomes and Measure Impact

Innovating ahead of competitors . In/Entrepreneurs -> Self-Renewing Organisation

Customers, Partners, Owners, Managers, Team Leaders, Fellow Workers, etc DON’T want you to be Agile!

They want you to be MORE RESPONSIVE!

D I S C L A I M E R

. This talk may include stories that maybe exaggerated to get points across and are aimed to make it more interesting, than when it really happened.

. People’s names have been removed to protect their egos.

. The events, facts and people reflect my glorified memories of what really happened and information contained herein is subject to change on the fly.

. Any silly questions may be answered with appropriately silly answers.

D I S C L A I M E R

Before Agile TRANSFORM Today

. Internal SDLC . Agile Development . Weak Customer Engagement . Clearer Business Value . Long Release Cycles . Shorter Release Cycles . Manual Testing . Automated Testing . Poor or Patchy Quality . Improved Quality Outcome

Agile Mindset New Agile Business People, Culture Culture Agile Manifesto Customer Engagement

New Rituals / Flexible Process New Methods

Waterfall/Iterative SCRUM/BDD/.. Playing Poker Stand-ups/Retros

Prototype / MVP / Play IT Systems, Tools New Tools, Technology Continuous Integration Automated Test Tools

New Specs / Quotes Stories / Artefacts New Artefacts Mockups/ More Presentations Acceptance Criteria

Individuals and Processes OVER Interactions and Tools

Comprehensive Working Software OVER Documentation

Contract Customer Collaboration OVER Negotiations

Responding to Change OVER Following a Plan

Source: www.agilemanifesto.org

Agile Development – A new approach?

Agile Succeeds 3x More Often Than Waterfall!

Agile Development coined in the year 2001.

Agile development approaches

Show of Hands - who uses . Traditional / Home Grown . Considering / Moving to Agile . Already Agile -> Whole Business

Aust. survey - favourite approach

Achievable Work Timebox

Team owns Quality

Faster ROI Remove Waste, MVP

Engaged Customers

Agile Australia 2014 – June Survey. Agile TODAY Vol. #8, August 2014.

SCRUM methodology

Work Request

Daily Tests are Stand-up part of work BA/SME/ User Stories Prod Team

Play Poker to Estimates/Q Estimates determine Story Points Present uote 24 Hr Team Completed work

Sprint Planning Retro- Epics, 2 – 4 spective Customer User Stories Approves Weeks

Product/Support Sprint Sprint Deliverable Backlog(s) Backlog (Working Days) Software www.mountaingoatsoftware.com

Requirement Specifications . Larger and complex documents . Assumed complete scope was known up front . Slow/tedious review cycles or NOT read . Downstream issues often uncovered

Estimates and Quotes . Estimates Team put under pressure . Estimates often inaccurate . Risk contingency viewed as overhead/waste . Resources allocated near 100% to work to full set of features

Working in Smaller Chunks

How do you eat an elephant?

• Story must be able to be completed within . Break requirements down into simple “user a Sprint (2-4 weeks) stories”

• Story should be release-able . Easier to estimate smaller items

• Staff see outcomes quicker – much happier . Lowers risk working on smaller items and Productive

Everyone likes a good story!

Structure As a… in , I want... , So that...

Example As an Accountant, I want the system to calculate gains and losses on collectables separately to investment assets, So that I don't have to manually maintain Capital Gains Tax records off system into EXCEL and then manually amend the End of Year tax return.

Requirement Specifications . Poor Requirements [Defined by Customer BA team] . Assumptions/Risks not challenged . Poor Quality outcomes (rework cutting into profit)

Estimates and Quotes . High level estimates for quotes . Testers not involved in estimates . Contingency added due to poor requirements . Clients often questioned ROI

What is Missing from this User Story?

As an Accountant, I want the system to calculate gains and losses on collectables separately to existing investment assets, So that I don't have to manually maintain Capital Gains Tax records off system into EXCEL and then manually amend the End of Year tax return.

Business Value: Automation will save each accountant, 30 mins for each client with collectible assets, per annum. Design Notes: The CGT calculations must be processed when .. The calculations must complete within 3 seconds. Acceptance Criteria / Examples!!!

Lessons Learned #1 - 3

1. User Stories are NOT the whole story . Empower ‘all’ staff to ask more ‘good’ clarifying questions . Reduce Risks / Assumptions with Examples . Determining the Real Business Value is an Art . Still capture UX design, mock screen changes etc

2. Requirements Specs  Epics /Themes . Sections /Topics  User Stories . Outcome Examples  Acceptance Tests . Business Processes  Help/Doco

3. Fixed Priced, 3rd Party Integration work . May force more detailed Specifications, agreed API etc. . Can still be written to be more Story like with Outcome focus

Before Agile

Team Structure(s) Leader BA Dev QA Dev

Product Owners / BAs / Developers available for Q&A . But focussed on new work not older work

Helpful and mostly friendly . Unless under pressure (usual)

Tension between Developers and Testers . Especially if issues found late

Agile Businesses are team oriented:

. Self Organising . Share knowledge / skills . Focussed . Become more creative / productive . Share Risk / Reward . Self-improve . Responsible for quality outcomes

Sprints 100

50 Average Velocity

Story Points Story 40 Total Velocity (SP)

0  Before After  20.7 8.6

How Agile Are You?

http://scrumbutt.me

4. Start the change process early – introduce some elements . Allocate BA/QAs to start defining the tests up front . Ask Daily status – Stand-up questions . Print out a summary, show the overall progress on a whiteboard with post-it notes or a project printout/posted

5. When playing poker (estimating) . Have examples of different sized completed stories with Notes . Easier to compare relative effort

Agile Testing Goals

New Standardised Approach Automate Testing . Testers involved in Specification / Review . Most Tests built will be Automate-able . All Acceptance Test scenarios documented / • Reduces effort to Re-test after each change re-usable . ‘Nightly’ Regression Testing / Results • Including Manual and Automated • Manage ever growing complexity of system . Define the test scenarios in business friendly terms Cheap Industry tools to support above • Develop simple data creation tools – Excel / API calls . SpecFlow, TestDriven, Nunit, Jbehave/Junit, OEUnit/Punit etc

What is BDD? Dan North Tweeted: BDD is about “Using examples at multiple levels to create a shared understanding and surface uncertainty to deliver software that matters.”

Building the Hunting out value right software Automated Acceptance Criteria

Collaboration BDD

API & code design Living Documentation

Building the software right

. Collect examples of ‘real’ expected responses from the system. . Each response is an acceptance criterion + unit of sign-off. . Helps define the scope. Without Acceptance Criteria there is no way to know the User Story is complete. . Examples added to source base – act as single source of truth that capture’s everyone’s understanding.

The Feature describes a capability of the product. Best described as the User Story Title.

Feature: Member B A single Acceptance Test

Scenario: Member with Concessional Contributions And no TFN Test Data / Setup Given a member in a superannuation fund And the member has a blank Tax File Number Test Action to be Performed

When the member makes a concessional contribution of 1000.00

Then the member's balance should equal 535.00

Test Result / Outcome expected

Lessons Learned #6 - 9

6. Teams changes at end of each sprint (skillset mismatch) . Let them self organise – better buy in

7. Existing bugs found during testing . 2hr rule

8. Automated Testing Coverage – . Build Library of re-usable components . Work on tackling ROI areas to Minimising Release/System Testing

9. Inconsistency across teams when Integration testing . Architecture / standards still needs to be owned and maintained

Ideas

Learn Build

Cycle Speed Data Product

Responsiv Measure e Business Build – Measure - Learn Innovative Feedback Loop, Eric Ries Business

Self-Renewing Business

Focus to Reduce Release Cycle Times Introduce Lean/Innovation concepts further ie 4 weeks or less . Improved Customer Engagement & . Decrease Manual Regression Testing before Technology Adoption rate release . Lean Start-up / Ideas Culture . Increase total Automated Test Coverage . Testable Hypotheses ie RISK . Minimum Viable Product (MVP)

Explore OE11.4 ABL Unit Testing and Corticon Rules Engine . Better Unit Testing and Automated Feature Testing . Model Compliance, Regulatory Rules Faster

. Agile / Lean Development works

. Challenge your business mindset to become more Responsive!

. Prepare for cultural change but use retrospectives for continuous improvement

. Focus on Quality Outcomes and Measurement via Feedback loop

. Cheap tools are available for Automated Testing – use them!

Q&A

[email protected]

Bonus Slides

Some Resources

Agile software development is: 1. a group of software development methods where requirements and solutions evolve through collaboration of self-organizing, cross-functional teams usingadaptive planning, evolutionary development, early delivery, continuous improvement and encourages rapid and flexible response to change.

2. It is a conceptual framework that uses iterative development focusing on frequently delivering small increments of working software.

3. Coined in the year 2001 when the Agile Manifesto was formulated.

4. There are many variations of agile processes: Scrum, Kanban, Dynamic systems development method (DSDM)

5. It is lighter and more people-centric than traditional approaches.

Myth 1 Agile is a Methodology not a Mindset Myth 2 Agile Methods Do Not Require Doco Myth 3 Labelling It ‘ Agile’ makes it Agile Myth 4 Agile Projects Are Not Planned Myth 5 Agile is a ‘Silver Bullet’ Solution

1. Customer Satisfaction comes first 2. Welcome changing requirements 3. Deliver working software frequently 4. Collaborate with all stakeholders 5. Individual Motivation 6. Face to Face Conversation 7. Working software as measure of progress 8. Sustainable pace of development 9. Technical excellence & good design 10. Simplicity 11. Self-organizing teams 12. Adaptation through Retrospectives

. Get session details & presentation downloads . Complete a survey . Access the latest Progress product literature www.progress.com/exchange2014