asq-sig-agile-for-legacy-20150623

1

Teaching An Old Dog New Tricks:

Agile For Legacy Systems

Craeg Strong CTO, Ariel Partners

June 23, 2015 Mclean, VA

© Copyright Ariel Partners 2015 *[email protected] ((646) 467-‐7394

2

Software Development since 1988

Large Commercial & Government Projects

Agile Coach / Kanban Trainer

Performance & Scalability Architect

Apache Ant Open-Source Contributor

New York & Washington DC Area

CTO, Ariel Partners CSM, CSP, CSD, CSPO, PSM, PMI-‐ACP, PMP, SAFe Agilist

www.arielpartners.com

[email protected] @ckstrong1

Craeg Strong


3

Agenda 1.  Up Front AsserOons 2.  Why Is Legacy Different? 3.  SituaOonal Assessment 4.  Whirlwind Tour

1.  FaciliOes 2.  Team 3.  Agile Methodology 4.  Technical Debt 5.  DocumentaOon 6.  “Sprint 0” 7.  Lifecycle Management Tool 8.  Roadmapping 9.  Automated Tests 10.  DevOps AutomaOon

5.  Summary


4

AsserOons 1 2 3


Big legacy projects represent a cons4tuency that has been largely le8 out of the conversa4on about Agile.

Agile methods can provide benefits for big legacy so8ware projects – even if they have been previously successful under waterfall.

Agile prac4ces may need to be customized and introduced in a different order in a legacy project.

5

q Mission-Critical q  Heavily Regulated

q Missing or Out of Date q  Significant Documentation Requirements

q Mostly Manual q  System Not Designed For Testability

q  Resistant to Change q  Battle Fatigue

q Optimized For Non-Collaboration q  Private Offices May Be Tied To Self-Worth

q  Heavyweight, Prescriptive q Manual-Intensive Reporting

q  Lengthy Approval Process q  Skeptical of Open Source

How Is Legacy Different?


System Criticality

Documentation

Testing

Staff

Facility

Governance

Procurement

6

SituaOon Assessment Mature So]ware

Significant Challenges

Assessment Ques4ons q What does our capital budget look

like? OpEx vs CapEx q  How long will the capability be

needed? q  How many of the original team are

available? q What is the state of the code base

relaOve to modern best pracOces? q Does the so]ware use a strategic

plaaorm? Is it sOll supported?

UNIX Healthcare.gov FBI Trilogy

Denver Airport Baggage Handling

System

“Criminal JusOce Project”

Conclusions ü  How much we will invest in

the exisOng code base ü  How we will allocate our

budget between maintenance and re-‐design

ü  How that allocaOon may shi] over the next 5 years


7 © Copyright Ariel Partners 2015 *[email protected] ((646) 467-‐7394

Criminal JusOce Project

8

Whirlwind Tour 1.  FaciliOes 2.  Team 3.  Agile Methodology 4.  Technical Debt 5.  DocumentaOon 6.  “Sprint 0” 7.  Lifecycle Management Tool 8.  Roadmapping 9.  Automated Tests 10. DevOps, CI/CD AutomaOon


9

Dream

1. FaciliOes


Reality

10

Summary: Structuring The Space


Remove Barriers to Collaboration q Co-Locate The Team q Cubicles à Open Spaces q Put Whiteboards Everywhere q Post-Its of all shapes and colors q Dual Hi-Res Monitors

11

2. Staffing The Team

q New Project q Lightweight Governance q Little Technical Debt

Traditional Scrum Team

Developers Testers Business Analyst

CM/Build Engineer

DBA

© Copyright Ariel Partners 2015 *[email protected] ((646) 467-‐7394 11

q Legacy Project q Heavyweight Governance q Significant Technical Debt

Specialists

DevOps Engineer

UX Designer

Technical Writer

Development

Developers Testers Business Analyst

CM/Build Engineer

DBA

Tool /Automation Specialist

Increasing Complexity

12

Team ComposiOon


Project Veterans (Mid/Senior) ü  Senior Developer ü  Domain Expert ü  Expert Manual Tester ü  Training Specialist

50%

30%

20%

New Staff ü  Junior ü  Midlevel

Specialists (Senior) ü  UX Designer ü  DevOps Engineer ü  Build AutomaOon Engineer ü  Tool Specialist ü  Technical Writer ü  UI Test AutomaOon Expert ü  BDD/TDD Developer

13

Summary: Structuring The Team


Mix of System Knowledge & New Automation Skills Needed q Up To 50% Experienced Staff Members q Most New Staff Should Bring Specific Automation Skills q Relatively Few Junior Developers q May Need Documentation Specialists q Expect Some Turnover, Especially Veterans

14

3. Methodology


0%

10%

20%

30%

40%

50%

60%

*According to VersionOne

15

Choosing A Methodology


Scrum Kanban Awareness & Precedent

Awareness, Acceptance, or OrganizaOonal Precedent

No Experience With Agile, or Previous NegaOve Experience

Nature of the Work Best for Development or “Disciplined O&M”

O&M or Development plus O&M

Stakeholder Availability

Time-‐Boxed IteraOons provide Convenient Planning Horizon for Stakeholders

Stakeholders cannot commit to fixed Ome-‐frames, or can engage more frequently

External Dependencies Effort fairly self-‐contained, Cross-‐FuncOonal team

Lots of dependencies on external teams

Openness to Change Need or Want Clean Break from past: RevoluOon

EvoluOonary approach is necessary

Team Preferences & Maturity

Ceremonies, Time-‐Box Desirable

Escape “Tyranny of the Time-‐Box,” Lengthy Planning MeeOngs

16

What If You Are Kind Of In The Middle?


Scrum Kanban Awareness & Precedent

Awareness, Acceptance, or OrganizaOonal Precedent

No Experience With Agile, or Previous NegaOve Experience

Nature of the Work Best for Development or “Disciplined O&M”

O&M or Development plus O&M

Stakeholder Availability

Time-‐Boxed IteraOons provide Convenient Planning Horizon for Stakeholders

Stakeholders cannot commit to fixed Ome-‐frames, or can engage more frequently

External Dependencies Effort fairly self-‐contained, Cross-‐FuncOonal team

Lots of dependencies on external teams

Openness to Change Need or Want Clean Break from past: RevoluOon

EvoluOonary approach is necessary

Team Preferences & Maturity

Ceremonies, Time-‐Box Desirable

Escape “Tyranny of the Time-‐Box,” Lengthy Planning MeeOngs

17

Consider Scrumban


Adopting Scrum

To facilitate adopOon of Scrum, starOng from wherever you are right now Demand Analysis, Workflow Analysis

Amplifying Scrum

Help idenOfy, implement, and measure improvements for an exisOng Scrum team WIP limits, Lead Time Metrics

Scaling Scrum

To facilitate inter-‐team planning and communicaOon Visualize and manage dependencies via Kanban boards, PorColio Kanban

Using the Kanban Method for…

18

How Does Kanban Improve Scrum?

Service Pack Month 2 Month 3 Month 4 Month 5 Month 6 Month 1

Sprint 1

Product Backlog

Sprint Backlog

Release Backlog

Sprint 2 Sprint 3

Sprint 4 Sprint 5

Sprint 6 Sprint

Backlog Sprint Backlog Sprint

Backlog Sprint Backlog Sprint

Backlog

Sprint Planning System Testing Government Acceptance Testing

Release Planning

Retrospective Change Control Board

18

Change Control Board MeeOng


19

Challenges We Encountered Using Scrum For Maintenance Project

Release Month 2 Month 1

Sprint 1

Product Backlog

Sprint Backlog

Release Backlog

Sprint 2

Sprint Backlog

Change Control Board MeeOng Influx of

Expedited Items

Expectation

q  Too Many Work Items q  Recurring Need For Estimates q  Constant Interruptions

Reality © Copyright Ariel Partners 2015 *[email protected] ((646) 467-‐7394

20

? (Dark Matter)

Why Were We Always So Busy?

Work Item Type Class Of Service Business User Story Standard

Infrastructure User Story Standard Tier III EscalaOon Expedited ProducOon Script Fixed Date Hot Fix Expedited Escaped Defect Expedited DocumentaOon Deliverable Fixed Date DocumentaOon Rework Expedited Technical Chore Intangible

Kanban gives us the analytical tools to understand these work items better and to see why they have been

disrupting the smooth delivery of value © Copyright Ariel Partners 2015 *[email protected] ((646) 467-‐7394

21

Summary: Choosing A Methodology


Pick Best-Fit For Situation q Learn Both Kanban and Scrum q Full-Time Coach q Up-Front Training “Agile Bootcamp” q Learning Kanban Makes You Better At Scrum

22

4. Technical Debt

90%

10%

Greenfield

60%

40%

Legacy

NegoOate A High Percentage of Bandwidth To Be Spent Paying Down Technical Debt


23

Focus On Test AutomaOon

Version Control

Automated Smoke &

Verification Tests

Compile Automated Unit Tests Packaging

Automated Security

Tests

Automated Performance

Tests

Static Analysis

Deployment

End Sprint

DEV

TEST

Begin Sprint

q  Ideally we have full automated test coverage

q  We can potenOally ship at the end of any sprint


24

But Set Aside Extra Time For Manual Testing

Dev Sprint

Dev Sprint

Tech Sprint

Dev Sprint

Tech Sprint

Release Sprint

PROS

•  Faster Technical Debt Reduction

•  Faster Progress Towards

Continuous Delivery •  Additional Testing •  Fewer Regressions

CONS

•  Reduced Business Value Delivery

•  Additional Complexity

•  Inconsistent Metrics


For our project, Technical Sprints were the “training wheels” we needed to maintain high quality in the absence of test automaOon. We have since discarded them.

25

Summary: Dealing With Technical Debt


Maintain High Levels Of Quality In Spite of Low Initial Automated Test Coverage q Achieve Agreement On Need For Infrastructure

Investment q Allocate Additional Time Required For Manual Testing q Balance Cost of Delay with Cost of Failure q Testing / Hardening Sprints May Require Whole-Team

Participation q Remove Barriers To Manual and Automated Testing

26

5. Documentation


Tradi4onal Governance Comprehensive documentaOon is a criOcal component of so]ware development

Agile Working so]ware over comprehensive documentaOon

27

Recognize That DocumentaOon Requirements May Be Bursty

Sprint TesOng

DocumentaOon Procurement Guidance

Release

Design & Technical DocumentaOon

Sprint Sprint Sprint Sprint Sprint

TesOng DocumentaOon

TesOng DocumentaOon

TesOng DocumentaOon

TesOng DocumentaOon



Training DocumentaOon












Interface DocumentaOon


28

Summary: Dealing with DocumentaOon Requirements


Maintain High Quality Documentation That Is Valuable q  Improve Documentation Capabilities q Plan and Measure the Work q Reduce Amount of Documentation Required q Reduce Effort Required to Produce Documentation

29

6. Sprint 0


1. People Staffing Reaches Critical Mass (~80%)

2. Hardware Every Team Member Has An Imaged PC

3. Software Source Code Manager Installed

4. Initial Product Backlog Small List of Business and Technical Items

5. Initial Kanban Board Simple Workflow, One Post-It Per Item

30

Summary: When To Start IteraOng?


Don’t Wait: Start Iterating As Soon As Possible q Automated Build May Take Extra Time To Setup… q Automated Testing May Not Be Possible At First… q Last Few Staffing Slots May Take Time To Fill… q …But You Will Learn Quickly

q Kanban Workflow Board Will Evolve Rapidly q Gather Baseline Metrics

31

7. Lifecycle Management Tool


Tes4ng Tool

Defect Tracking Tool

Requirements Tool

Traceability Cross-‐Reference

Agile Tool

q  One Tool Specialist q  Custom ReporOng Likely To Be

EssenOal

32

Use Manual Kanban Board


q  Workflow Evolves Quickly q  Excel Can Be Used For Metrics q  Immature Agile Tool May Be Burden

33

Summary: Tool Chain Support For Agile


Simplify Tool-Chain & Automate Prudently q Tool Consolidation May Be Beneficial q Automated Reports Preferable To Manual Reporting –

But Watch Cost versus Benefit q Always Start With Manual Kanban Boards q Capture Metrics In Excel To Start With

34

8. Roadmapping


Sprint Sprint Sprint Sprint Sprint Release N

Sprint

Installer Improvement

Automated Builds

Feature 1

Sprint

Upgrade .NET

Release N+1 Sprint

Feature 2

Upgrade DB Libraries

Upgrade GUI Libraries

Business Roadmap

Technical Roadmap

35

Technical Improvements Address Risks


Express Technical Items In Terms of The Business Risks They Mi4gate

Bad

InvesOgate ArOfactory

Binary Repository

Migrate To EnOty Framework

Rewrite Error Handling Component

Improve Config Mgmt: Eliminate Unused Third

Party Libraries

ReOre Obsolete & Unsupported

Database Libraries

Replace COM Components PrevenOng NaOve 64-‐Bit

OperaOon

Good

36

Demonstrate Progress On Technical Items Via Reports


Release 2015-‐01

37

Summary: Maintain Both Business and Technical Roadmaps


Roadmaps Can Help Communicate The Big Picture q May Help Replace Gantt Charts and Earned Value

Management q Avoid Overpromising q Start With Technical Spike To Determine Feasibility q Focus on Removing Technical Barriers First q Older Platforms & Libraries May Not Support Automation q Platform and Third Party Upgrades Require Significant

Testing

38

9. Automated Tests


q WriOng Automated Tests For Legacy ApplicaOons Not Designed For Testability Is Difficult

q We Are Asking Our Customer To Make A Large Investment In AutomaOon With Delayed Return On Investment

q We Need To Maximize Our Efforts

ü  Create Tests That Don’t Break When We Change The GUI ü  Get The Whole Team Involved ü  Focus On Business Scenarios, Not Source Code ü  Create Tests That Will Survive A Component Rewrite ü  Create Tests That Support Traceability To Requirements

If only we could..

39

BDD/ATDD To The Rescue


Given…

When…

Then…

Behavior Driven Development

Acceptance Test Driven Development

Gherkin

40

Feature File

BDD With SpecFlow 1. Write Feature

Step DefiniOons 2. Generate Template


Tester

Analyst

3. Fill In Code

Developer

41

The Agile RTM

q  All system functions expressed as user stories q  All user stories have acceptance criteria q  Each criterion translated to an automated test using structured

English (Gherkin) q  Customized report matches epics and user stories to automated

acceptance tests q  Test fails unless software is implemented correctly

Links to Theme Record in TFS

Links to Epic Record in TFS

Links to User Story in TFS

Links to Feature DocumentaOon

Generated via Pickles

© Copyright Ariel Partners 2015 *[email protected] ((646) 467-‐7394 41

42

Summary: Focus On High-‐Value Automated Tests


BDD/ATDD Tools Enable High-Value Tests q “Three Amigos” Work Together (Analyst, Tester, and

Developer) q Tests Map Directly To Acceptance Test Criteria q Code Tags Provide Traceability To Features or User

Stories q BDD/ATDD Tools Rapidly Maturing q More Robust, Lower Barrier To Entry Than GUI-Level

Test Tools

43

10. DevOps Automation


Monitor

Smoke Test

ConOnuous IntegraOon

Build Package

Source Control

Develop

Report

Configure

Build Scripts

Unit Test IntegraOon Test

Other Tests

Upload To Repo

Deploy

NoOfy

Collaborate

Dev ITE

Smoke

Tier III

ST 1

ST 2

How To Achieve Vision of Full Automation?

Track

44

Automate Each Piece of the Pipeline: One By One


Manual Ad-Hoc

Undocumented

Analyzed Documented

Baselined

Initial Automation: Stand-Alone

Script

Improved Automation:

Build Script adds Validation

Pre-Conditions Post-Conditions

Full “Lights Out” Automation: Reporting

Diagnostics

This Step is EssenOal

45

Summary: DevOps AutomaOon


Establishing Continuous Integration & Continuous Delivery (CI/CD) q DevOps Tools Maturing Rapidly q Support Varies Widely By Platform (Linux/Unix,

Windows, Mainframe) q Legacy Projects Typically Have Many Manual &

Undocumented Processes (Folklore) q Significant Analysis & Problem Solving Skills Required q Many High-Value Candidates For Automation Are Non-

Obvious q Avoid Paving the Cow Paths

46

Summary


q Legacy Projects Can Realize Benefits By Adopting Agile Practices

q Practices May Need To Be Modified q Consider Kanban or Scrumban q Staff Your Team Thoughtfully q Manage Stakeholder Expectations q Balance Cost of Delay with Cost of Failure q Adopt Systems Thinking Approach To Addressing

Technical Debt q Reduce Complexity q There Is No Silver Bullet

47

QuesOons?


We are available for consulOng or Agile coaching We love to compare notes and talk shop!

Ariel Partners (646) 467-‐7394 [email protected] www.arielpartners.com @arielpartners

Thank You!

asq-sig-agile-for-legacy-20150623

Documents

q battle fatigue q

q missioncritical q

q heavyweight

manual q system

regulated q missing

testability q resistant

collaboration qco

old dog new tricks