Engine for Growth: Agile SaaS Case Studies

Engine for Growth: Agile SaaS Case Studies

Paul Petersen Director Ideas Ahead Pty Ltd

© 2014 Ideas Ahead Pty Ltd. All rights reserved. 2

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

SaaS Business Challenges


Business Disruption

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.


SaaS + Eco-System Explosion

Synchronise Data across your Business

Accounting System Add-On Market

Automate Tedious Tasks


10 Important Technology Trends in Business Application Architecture


SaaS Business ‘Engine’ Success

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


Agile or Responsive?

Customers, Partners, Owners, Managers, Team Leaders, Fellow Workers, etc

DON’T want you to be Agile!

They want you to be MORE RESPONSIVE!


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

D I S C L A I M E R


Agenda

Before Agile

Internal SDLC Weak Customer Engagement Long Release Cycles Manual Testing Poor or Patchy Quality

Today

Agile Development Clearer Business Value Shorter Release Cycles Automated Testing Improved Quality Outcome

TRANSFORM

http://www.google.com.au/url?sa=t&rct=j&q=&esrc=s&source=images&cd=&cad=rja&ved=0CAQQjRw&url=http://www.noupe.com/photography/40-beautiful-examples-of-waterfalls-photography.html&ei=x4USU477CYidkgXGrIDwBA&usg=AFQjCNENyS7zKthBmuOP8CYToDQ63q_sTw


Business Transformation

People, Culture New Agile Business Culture

Agile Mindset

Agile Manifesto Customer Engagement

IT Systems, Tools New Tools, Technology

Artefacts New Artefacts

Process Waterfall/Iterative

New Methods SCRUM/BDD/..

New Rituals / Flexible

Playing Poker Stand-ups/Retros

Prototype / MVP / Play Continuous Integration

Automated Test Tools

New Specs / Quotes Stories / Mockups/ More Presentations

Acceptance Criteria


Agile Software development manifesto

Individuals and Interactions

Processes and Tools OVER

OVER

Customer Collaboration Contract Negotiations

Responding to Change Following a Plan

Working Software Comprehensive Documentation

OVER

OVER

Source: www.agilemanifesto.org

http://www.agilemanifesto.org/


Agile Development – A new approach?

Agile Succeeds 3x More Often Than Waterfall!

Agile Development coined in the year 2001.

http://www.google.com.au/url?sa=i&rct=j&q=&esrc=s&source=images&cd=&cad=rja&docid=KK1-9IdeDCHcJM&tbnid=7jp8f5ng8br7HM:&ved=0CAUQjRw&url=http://www.onedesk.com/2013/01/waterfall-vs-agile/&ei=qaMSU-quKc3gkgWVlYGgDw&psig=AFQjCNGowZu3437OHFfuvfcc14eSVmqgOQ&ust=1393809274005810


Agile development approaches

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

http://www.google.com.au/url?sa=i&rct=j&q=&esrc=s&source=images&cd=&cad=rja&docid=KK1-9IdeDCHcJM&tbnid=7jp8f5ng8br7HM:&ved=0CAUQjRw&url=http://www.onedesk.com/2013/01/waterfall-vs-agile/&ei=qaMSU-quKc3gkgWVlYGgDw&psig=AFQjCNGowZu3437OHFfuvfcc14eSVmqgOQ&ust=1393809274005810


Aust. survey - favourite approach

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

Achievable Work Timebox

Faster ROI

Team owns Quality

Remove Waste, MVP

Engaged Customers


SCRUM methodology

24 Hr

2 – 4 Weeks

Daily Stand-up

Play Poker to determine Story Points

Sprint Planning Retro-

spective

Present Completed work

Tests are part of work

Epics, User Stories

User Stories

Estimates/Quote

BA/SME/ Prod Team

Estimates

Team

Customer Approves

Work Request

www.mountaingoatsoftware.com

Product/Support Backlog(s)

Sprint Backlog

Sprint (Working Days)

Deliverable Software

http://www.mountaingoatsoftware.com/


Before Agile – case 1

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 a Sprint (2-4 weeks)

• Story should be release-able

• Staff see outcomes quicker – much happier and Productive

Break requirements down into simple “user stories”

Easier to estimate smaller items

Lowers risk working on smaller items


Everyone likes a good story! Structure

As a… <role> in <BU>, I want... <goal/desire>, So that... <benefit/value>

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.

User Story Example


Before Agile – Case 2

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


Agile Analysis and Quoting


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!!!

Good User Stories


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

Lessons Learned #1 - 3


Before Agile

Team Structure(s)

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

Leader Dev

BA

QA Dev


Working Collaboratively as a Team vs. Individuals

Agile Businesses are team oriented:

Self Organising Focussed Share Risk / Reward Responsible for quality outcomes

Share knowledge / skills Become more creative / productive Self-improve


Agile Storyboard


Agile Management Tools - Pivotal Tracker, JIRA Agile, Rally, VersionOne, etc.


Measure Outcomes

0

10

20

30

40

50

60

70

80

90

100

Stor

y Po

ints

Sprints

Average Velocity Total Velocity (SP)


Before After 0

5

10

15

20

25

30

35

40

20.7 8.6

Quality Metric - Outcome Focus


How Agile Are You?

http://scrumbutt.me

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

Transitioning to Agile, Lessons Learned #4 - 5


Agile Testing Goals

New Standardised Approach Testers involved in Specification / Review

All Acceptance Test scenarios documented / re-usable

• Including Manual and Automated

Define the test scenarios in business friendly terms

• Develop simple data creation tools – Excel / API calls

Automate Testing Most Tests built will be Automate-able

• Reduces effort to Re-test after each change

‘Nightly’ Regression Testing / Results • Manage ever growing complexity of system

Cheap Industry tools to support above SpecFlow, TestDriven, Nunit, Jbehave/Junit,

OEUnit/Punit etc


Behaviour Driven Development (BDD)

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

BDD Collaboration

Hunting out value Building the

right software

Automated Acceptance Criteria

API & code design

Building the software right

Living Documentation


Specification by Example

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.


Speak Gherkin, Eat

Feature: Member B

Scenario: Member with Concessional Contributions And no TFN

Given a member in a superannuation fund

And the member has a blank Tax File Number

When the member makes a concessional contribution of 1000.00

Then the member's balance should equal 535.00

A single Acceptance Test

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

Test Result / Outcome expected

Test Action to be Performed

Test Data / Setup


SpecFlow/TestDriven.NET


Nunit – Execute Automated Tests


ABL Unit (11.4) - OpenEdge Unit/PUnit testing


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

Lessons Learned #6 - 9


Agile Business Lean Startup Intrepreneurs

Self-Renewing Business

Innovative Business

Ideas

Build

Product

Measure

Data

Learn

Build – Measure - Learn Feedback Loop, Eric Ries

Cycle Speed

Responsive Business


Introduce Lean/Innovation concepts Improved Customer Engagement &

Technology Adoption rate Lean Start-up / Ideas Culture Testable Hypotheses Minimum Viable Product (MVP)

Focus to Reduce Release Cycle Times further ie 4 weeks or less Decrease Manual Regression Testing before

release Increase total Automated Test Coverage

ie RISK

Explore OE11.4 ABL Unit Testing and Corticon Rules Engine Better Unit Testing and Automated Feature

Testing Model Compliance, Regulatory Rules Faster

Directions


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!

Summary

Q&A [email protected]

Thank you

mailto:[email protected]


Bonus Slides

Some Resources


What Is Agile development?

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.

http://en.wikipedia.org/wiki/Software_development_methodologies

http://en.wikipedia.org/wiki/Cross-functional_team

http://en.wikipedia.org/wiki/Cross-functional_team

http://en.wikipedia.org/wiki/Agile_Manifesto

http://en.wikipedia.org/wiki/Scrum_(development)

http://en.wikipedia.org/wiki/Kanban_(development)

http://en.wikipedia.org/wiki/Dynamic_systems_development_method


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

Agile Myths


Principles behind the Agile Manifesto

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

Visit the Resource Portal

Documents

Engine for Growth: Agile SaaS Case Studies