Kimberly Davis CSM, CSPO, PMI-ACP, SA, SP, CAL1 Lead Agile Architect ASRC Federal Mission Solutions Moorestown, NJ

Size: px

Start display at page:

Download "Kimberly Davis CSM, CSPO, PMI-ACP, SA, SP, CAL1 Lead Agile Architect ASRC Federal Mission Solutions Moorestown, NJ"

Lorraine Osborne
5 years ago
Views:

1 Kimberly Davis CSM, CSPO, PMI-ACP, SA, SP, CAL1 Lead Agile Architect ASRC Federal Mission Solutions Moorestown, NJ

2 INTRODUCTION

3 Our Scaled Agile Transformation Scaling Agile across two enterprises Scaling Agile across 165 teams Approximately 2K in people Work is in the DoD 40+ years of Waterfall CMMI Level 5 Earned Value Management Ultimate customer is all over the place in the ocean, on a ship somewhere

4 Leave you with the some valuable lessons learned to prevent the question, So if you had to do it over again, how would you do it? Concepts in Being Agile v. Doing Agile at Scale An understanding this is going to be easy, but I am going to tell you, it will be worth it!

5 SOME BACKGROUND

6 A Tale of a Scaling Blunder We re going to do Agile it saves us money and gets capabilities delivered faster and higher quality Great! Let s come up with a 3-year plan, train everyone, hire some coaches, and kick off SAFe s release planning in about 6 months and be Agile!! Hoorah!! Good plan! Go off and find some people to execute this! Oh and we will need metrics to measure our progress. And since Agile will save us money, this won t really cost a thing!

7 One year later.

8 We re burning down features and increasing our velocity, but we re still not better, faster, cheaper what gives? Well, we ran a pilot with a few small teams so we could learn from their experience and scale it to the other 100 teams. Then we hired 20 coaches at $150/hour. When we scaled our pilot, we found that the approach didn t work for everyone, so we needed to reorganize and co-locate teams. Teams also increased velocity, because they started estimating higher! So, we ve spent $5M for a new set of metrics and a re-org? What did the coaches teach us? We also adopted the Agile toolset you used to get your metrics. Some of the teams are doing agile and practicing Agile ceremonies, but there is something missing.

9 Agile is a Mindset, not a Process

10 GETTING STARTED Get Organizational Alignment

11 Why do organizations adopt Agile? VersionOne s 11 th Annual State of Agile Report

12 Where We Got Started We were handed a 3 year transformation plan We were told we were using Scaled Agile Framework We were told how we should organize our teams We gave our teams 2 days of Agile training We were told how to do Agile No one understood what it meant to be Agile 12

15 To successfully create the significant breakthroughs in your development effectiveness that are possible with agile, it has to be aligned with why you want to do it in the first place and what you need to achieve from it. - authors of A Practical Approach to Large-Scale Agile Development

16 Getting Organizational Alignment Continuous Employee engagement Establish business objectives High level deliverables Evolving the business Be transparent with objectives

17 Clear Business Objectives Gives

18 Scaling Some Principles

19 Combine Trust & Continuous Learning

Show Results of Continuous Improvement Iteration Business Objectives Health Check Priority Theme Exit Criteria 1 Quality Standard Priority 1 Bug Closure <= 1 week Automated Test Pass 100% L2 Test

as standalone Run Subsystem C as standalone Feature Toggle can show A, B or C or a combination 3 Python Training Vendor Assessment and Selection completed Training Scheduled 4 User can call scripts

20 Show Results of Continuous Improvement Iteration Business Objectives Health Check Priority Theme Exit Criteria 1 Quality Standard Priority 1 Bug Closure <= 1 week Automated Test Pass 100% L2 Test Issues responce time <= 24hrs 2 Decouple Software for System X Dependencies reduced to 0% Test Cases reduced by 20% Automated Regression Tests Pass 100% Run Subsystem A as standalone Run Subsystem B as standalone Run Subsystem C as standalone Feature Toggle can show A, B or C or a combination 3 Python Training Vendor Assessment and Selection completed Training Scheduled 4 User can call scripts to create new environments for tests on a set of virtual machines Code is deployed to that environment; user is informed of status Database schema is updated with Evoltionary Database Design so schema changes will Build an Orchestrator not break the application; user is informed of status for automation Aomated Testing is kicked off; user is informed of status coordination Results are stored and user(s) are notified Done Not Done

21 Lessons Learned #1 Summary 1. Understand where you and where you want to be and be transparent with this information 2. Don t make decision on where to get started in a vacuum 3. Like planning in Agile, if you make a long, lengthy, detailed plan on your transformation, it will be obsolete shortly! 4. Build a culture for continuous improvement this will help get you to where you want to be 5. If you are transparent with your vision and incremental business objectives for getting you where you want to be and are showing qualitative progress, you will gain trust which is essential 21

22 ENTERPRISE COORDINATION Creating Meaningful Plans that Deliver Value

23 Where we got Started with Release Planning SAFe Release Planning pilot for one large program Scaled our Release Planning pilot to the rest of our Programs under one Common Source Library Our Customer still marched to a Build Plan so release planning cadence matched the Builds But. The customer directed more and more branches on the CSL Release cadence no longer matched the builds Release Planning pilot did not scale well Release Planning detail was too much which made the planning effort difficult to change Programs were still marching towards S-curves limiting WIP was scary for them Metrics built around what we planned at release planning created bad behavior Even though we did release planning and indicated what we couldn t do, we were still being asked to do more with no letting less important work slide

24 Plan Just Enough Software is unpredictable Until more information is known So plan what you know.

25 WIP Limits and Continuous Planning at Scale Work In Progress (WIP) limits at the highest level Driven by iterative business objectives Controls the amount of work in progress throughout the organization Continuous backlog grooming for business objectives Grooming and planning is continuous as work flows through the system Coordinate the cadences for planning, iterations, releases and so forth

26 Backlog Assess Plan To Do (3) In Progress (2) Done Executives Bus. Obj. Bus. Obj. Bus. Obj. Bus. Obj. Bus. Obj. Bus. Obj. Program Managers Feature Feature Feature Feature Feature Feature Team of Teams A Epic Epic Epic Team of Teams B Epic Epic Epic Team of Teams C Epic Epic Epic Team A1 US US US US Team A2 US US US US Team B1 US US US US Team B2 US US US US Team C1 US US US US Team C2 US US US US

28 What s The Balance?

29 Lessons Learned #2 Summary Good Planning practices are facilitated by: 1. Continuous planning/backlog grooming at the Executive Level 2. An acceptance of limiting Work in Progress 3. Just enough planning so change is easier to bare 4. Accepting the Iron Triangle Shift 29

30 INVEST IN YOUR FUTURE Maintain a Competitive Advantage

31 Our Initial Agile Investments Training Forming Teams Re-organizing Tools New Roles This led to the need for a consultant Because we were trying to do agile And were not focusing on being Agile Meanwhile, automation and our architecture were a second thought. 31

32 The Expense is not in Just Being Agile Business Objectives centered around code quality Decoupling Refactoring Sound and efficient architecture Feature Toggles Automation and Continuous Integration are essential for enabling Continuous Delivery 32

33 Push for Value Being Agile will enable you do identify what is not providing VALUE Legacy processes, procedures, meetings, and so forth that no longer provide value Don t just add Agile to what you re organization does Being Agile will enable you to identify how you can deliver more VALUE Continuous attention to your architecture Focus on finding bugs and resolving them faster 33

34 Lessons Learned #3 Summary 1. Use the Agile Empirical Process for identifying what you need to be investing in to Be Agile 2. You need to invest in laying the ground work for scaling 3. Identify anything the organization is doing that does not provide value 34

35 WRAP-UP

36 Agile is about continuous improvement, so by definition your transformation is like laundry it s never done.

37 DAD 1. What s your recipe? 2. How would you continue to perfect your recipe to keep your customers coming back for more?

38 Don t just take the leap Don t do Agile, be Agile - Scale the Principles Assuming doing Agile is going to make you better, faster and cheaper is a broad assumption Avoid telling teams how to adoption information overload The investment is not in Agile itself, its in evolving your organization Understand the organization and the value each part provides

Finally! A Model for Evaluating Agile Performance: The Agile Performance Holarchy. Darian Poinsetta Senior Executive Agile CxO

Finally! A Model for Evaluating Agile Performance: The Agile Performance Holarchy Darian Poinsetta Senior Executive Agile CxO Enter to Win a Prize! Have any questions? Feel free to talk to Darian at the