Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Agile DC 2018 Kanban Case Study for Energy Company

96 views

Published on

Is it possible to deliver software improvements faster and with better quality in a highly regulated environment? What if the organization only uses off-the-shelf commercial packages like SAP rather than custom software? Oh, and much of the team is still learning the ropes? And by the way, our business users are unavailable during monthly and quarterly close, and to top it all off whole divisions go off-line for weeks or months at a time during refinery “turnaround” events? How can we improve cycle times, if it sometimes takes us months just to figure out how to design a solution for a single request?
In this session, we will examine a case study at an energy company that needed to increase their speed of delivery and their level of quality, while at the same time controlling costs. They started to adopt Kanban a year ago, by visualizing their waterfall process on a board and holding a daily stand-up. However, cycle times were still unacceptably long, and the board did not change much day-by-day. Worse, the business was getting more impatient and the backlog of urgent requests was growing longer. The team was ready to take the next step and deepen their kanban implementation.
We will examine a number of improvements that were made and the impact of each one of them. Larger work items were broken down into user stories, enabling progress to be tracked at a more granular level and helping the team to break down difficult problems into smaller, bite-sized chunks. Defects were captured individually on the board so large items did not appear to “stall” for no reason. Time-boxed “Spikes” could be created to capture efforts required to identify alternatives and reduce risk in design or implementation. The kanban boards went through multiple iterations as we updated them to better reflect our new process.
Hand-in-hand with these improvements came training and practice. How do we create properly formed user stories? When is it appropriate to create a Spike? How can we make process policies explicit? Please see this case study about one Fortune 200 company’s journey towards a deeper and more complete implementation of Kanban. Perhaps the “alternative path to agility” is right for your organization?

Published in: Software
  • Be the first to comment

  • Be the first to like this

Agile DC 2018 Kanban Case Study for Energy Company

  1. 1. 1 Faster Better Cheaper in a highly regulated environment? Craeg Strong CTO, Ariel Partners October 15, 2018 Washington, DC © Copyright Ariel Partners 2018 *sales@arielpartners.com ((646) 467-7394
  2. 2. 2 Agenda Context A. Prior Work B. Selected Engagement Details 1. Agile Requirements Decomposition via User Stories 2. Applying the Kanban Method C. Observations and Discoveries 1. Ongoing Challenges 2. Lessons Learned and Takeaways
  3. 3. 3 Craeg Strong Software Development since 1988 Large Commercial & Government Projects Agile Coach / DevOps Engineer Kanban Trainer / SpecFlow Trainer Performance & Scalability Architect Certified Ethical Hacker New York & Washington DC Area CTO, Ariel Partners AKT, KMP, CSM, CSP, CSPO, ITILv3, PMI-ACP, PMP, LeSS, SAFe www.arielpartners.com cstrong@arielpartners.com @ckstrong1
  4. 4. 4 Energy Company
  5. 5. 5 Unique Challenges for Energy Sector Highly Constrained COTS Product Few Developers With Deep Domain and Product Knowledge Lengthy Analysis Required Customers Often Unavailable Highly Distributed Organization
  6. 6. A. PRIOR KANBAN IMPLEMENTATION
  7. 7. 7 Initial Kanban Implementation 1. Established LeanKit to track the work 2. Process captured as-is, no changes 3. No changes to existing responsibilities or titles Consultant helped IT teams implement Kanban in early 2017 Before Kanban SharePoint Functional Requirements Document System Design Document Detailed Design Document User & Admin Guides Analyze Design Build Test Deploy With Kanban A) No Changes To Documentation B) Requirements Captured on Cards C) Kanban board lanes reflect process steps Minimum Marketable Feature
  8. 8. 8 Minimum Marketable Features Minimum As small as possible. If an MMF can be subdivided into multiple MMFs, it should be– even if those MMFs are to be delivered together. Marketable Something that could be potentially deployed on its own (used in production, with live data) Feature Something that is perceived, of itself, as value by the user. Minimum Marketable Features. The smallest set of functionality that must be realized in order for the customer to perceive value. A “MMF” is characterized by the three attributes: minimum, marketable, and feature.
  9. 9. 9 Initial LeanKit Implementation HypercareBacklog Deploy System / User Test Build / Unit Test Func Design Reqs Analysis Approval
  10. 10. 10 Development Process Back Office Demand Middle Office Front Office Governance Committee Analysis Committed& SequencedQueue Uncommitted Arrivals Backlog Analysts Developers Testers Hypercare Average 120+ Days (!!!) Approval Gate IT Need to Do Better Analysts Play Both Roles Other
  11. 11. 11 Kanban Foundational Principles 1. Start with What you do Now 2. Agree to Pursue Incremental, Evolutionary Change 3. (Initially) Respect the Current Process, Roles, Responsibilities & Titles Hmmm, we got stuck on this one
  12. 12. B. INCREMENTAL IMPROVEMENTS
  13. 13. B1. REQUIREMENTS DECOMPOSITION
  14. 14. 14 As Is versus To Be As Is Delivered MMF Lengthy Delays Lack of Visible Progress Kanban Board not adding value Difficult to Estimate Difficult to Subdivide Identified Minimum Marketable Feature User Story User Story SpikeSpike  Regular Visible Progress  Kanban Board tells a story  Small, estimable chunks  Independently valuable stories  Can assign work to multiple teams To Be Delivered MMF User Story Idea or Request Identified Minimum Marketable Feature
  15. 15. 15 Decomposing MMF into User Stories… MMF User Story Relationship Parent Child Effort 2 weeks to 4 months of development 2 days to 2 weeks Analysis Requirements Document As a/I want/So that Possibly a UX mockup Testing Test Plan (up to dozens of tests) 2-12 Acceptance Criteria Value to Business Immediately recognized as independently valuable Has value to the business, but the value may be best realized when combined with other user stories split out from the MMF
  16. 16. 16 …and Spikes User Story Spike Goal Realize business value Reduce risk by answering a question or gathering information Effort 2 days to 2 weeks 2 days to 2 weeks Completion Acceptance Criteria fulfilled Hypothesis is proven true or false Next Steps Testing, Documentation, Deployment Discarded or recycled
  17. 17. 17 Properly Formed User Stories Splitting User Stories 1. Performance (ways to add caching or improved performance) 2. Simple to complex 3. Interface variations: excel, grid, graphical, mobile, 4. Variations in data: geographic region, or by refinery, or by customer 5. Operations: splitting out CRUD 6. Business rule variations 7. Workflow steps: this then that 8. Breakout a spike INVEST 1. Independent 2. Negotiable 3. Valuable 4. Estimable 5. Small 6. Testable User Story Components 1. “As a…” Identify the Stakeholder. More than one? Split! 2. “I want…” Identity the function the way the stakeholder would 3. “So that…” Identify the business value. What is the Stakeholder’s goal? 4. Acceptance Criteria 1. Assumptions 2. Invariants 3. Pre- and Post-Conditions
  18. 18. 18 Example #1: EBITDA Story Compute Operating Income component of EBITDA by company Story Compute Income Tax component of EBITDA by company Story Compute Depreciation component of EBITDA by company Story Compute Interest component of EBITDA by company Story Compute Amortization component of EBITDA by company Story Compute EBITDA by company combining component calculations Story Control Access to EBITDA calculations by company Story Reconciliation report to compare EBITDA in AO report to BPC P&L statement Story Schedule report to enable reconciliation during close MMF Description EBITDA Calculations by Company – for Accounting and Reporting Team Earnings before interest taxes depreciation and amortization
  19. 19. 19 Example #2: Trader Checkout Process Story Basic read-only details view for trader for formula tablet Similar to existing report, but omits trades already approved or rejected, activated or pending. Most trades have formula tablets Story Trader can approve or reject deal details Story Trader can only approve/reject their own trades Story Read-only form for middle office to review rejected details Story Force modified deals to be re-approved Story Update historical deal details so I don’t have to approve them Spike Determine how fixed price tablets will be displayed Small percentage of trades have fixed price tablets Story Support fixed price tablet support for TCM view MMF Description New Trader Checkout Process (TCM) For Audit To prevent booking errors, have traders explicitly approve or reject trades on a daily basis before they are activated
  20. 20. B2. APPLYING THE KANBAN METHOD* *STATIK: SYSTEMS THINKING APPROACH TO IMPLEMENTING KANBAN
  21. 21. 21 1. Leading Questions 2. Motivations for Change 3. Analyze Sources and Nature of Demand 4. Identify and Define Classes of Service 5. Analyze Delivery Capability 6. Model Delivery Workflow 7. Kanban System Design (Lane Policies, WIP Limits, Replenishment Cycles, etc.) Applying the Kanban Method
  22. 22. 22 Motivations For Change Internal Dissatisfaction Work beginning on MMF but card is stuck “waiting for approval” Significant time spent on documentation (Reqs doc, Func spec, Tech spec) Not much day-by-day movement on the board Large projects do not appear on the board No visibility Into Work Being done for MMF Difficult to tell what is blocked or high priority Coordination with Other Groups (e.g. Help Desk) not reflected on board How Can I tell what has moved since last week? External Dissatisfaction Too slow / Long lead time Unpredictable delivery Quality issues
  23. 23. 23 Updated LeanKit Board Design Backlog Approval Reqs Analysis Func Design Build / Unit Test System / User Test Deploy Hypercare Previous Flow Hypercare DefectsUser Stories & Spikes Backlog On Deck Reqs Analysis Design / Build System Test User Test Deploy Hypercare Specify Ready In Progress Func Test Identify In Progress Test Deploy Updated Flow
  24. 24. © Copyright Ariel Partners 2018 *sales@arielpartners.com ((646) 467-7394 24 Updated Board
  25. 25. 25 On Deck Lanes: Two MMFs Per Stakeholder Group All Five Stakeholder Groups Can Indicate their Top Two Priorities Top Two Can Change Anytime Prior To Commitment
  26. 26. 26 Parallel Parent[MMF] and Child[User Story] Work Child Stories Created When MMF Analysis Begins “Ready” User Stories Can Be Completed Anytime Additional User Stories Created As Needed During MMF Analysis & Design Spikes Created As Needed Finish-to-Finish Dependency (MMF to Child Story)
  27. 27. 27 Hypercare Defects Captured External Defects Appear Directly Under Their Parent MMF Separate Card Type (Hypercare vs Internal Defect) Makes Querying Easy
  28. 28. 28 Improving Functional / Technical Team Collaboration Functional Team Technical team Handoff From This… Time Level Of Effort MMF Reqs Analysis MMF Design & Build … To This! Functional Technical Level Of Effort Time Story Identification Story In Progress MMF Design MMF Reqs Analysis Explicit Entry/Exit Policies Explicit Entry/Exit Policies Explicit Entry/Exit Policies
  29. 29. C. ONGOING CHALLENGES & LESSONS LEARNED
  30. 30. 30 Lessons Learned for Highly Regulated / COTS / Energy Challenge Response 1. Spikes frequently needed to explore different designs 2. Estimation process helps team identify areas of significant uncertainty and risk (Extra-Large “T” Shirt) Older Development Platform, Largely Manual Processes Development takes longer; user stories must be split more fine-grained Highly Specialized Team Members Not Fungible Benefits from “swarming” and collaboration are limited, often leading to increased Work In Progress Stakeholders Unavailable for Extended Periods of Time Identify backup stakeholders & More Up-Front Estimation and Planning Required to avoid Blackout times Highly Complex Commercial Software Package
  31. 31. 31 Takeaways Kanban Well-Suited for “Highly Constrained” SW Development Low Barrier to Entry Transparency Promotes Trust Highlights Sources of Delay Conducive to Incremental Change Compatible with SDLC methods (Waterfall, Scrum, SAFe, etc.) Kanban Method and STATIK Simple and Powerful Techniques Helps Break down Barriers and Encourage Collaboration Limiting the amount of Work in Process reduces Overburdening Improvement Workshops can be repeated as needed
  32. 32. 32 Discussions, Q & A © Copyright Ariel Partners 2018 *sales@arielpartners.com ((646) 467-7394 Craeg Strong Savant Financial Technologies, Inc. d/b/a Ariel Partners Cell: (917) 992-0259 cstrong@arielpartners.com www.arielpartners.com @arielpartners Thank You!

×