Your SlideShare is downloading. ×
0
Lean Principles for Agile Teams
Lean Principles for Agile Teams
Lean Principles for Agile Teams
Lean Principles for Agile Teams
Lean Principles for Agile Teams
Lean Principles for Agile Teams
Lean Principles for Agile Teams
Lean Principles for Agile Teams
Lean Principles for Agile Teams
Lean Principles for Agile Teams
Lean Principles for Agile Teams
Lean Principles for Agile Teams
Lean Principles for Agile Teams
Lean Principles for Agile Teams
Lean Principles for Agile Teams
Lean Principles for Agile Teams
Lean Principles for Agile Teams
Lean Principles for Agile Teams
Lean Principles for Agile Teams
Lean Principles for Agile Teams
Lean Principles for Agile Teams
Lean Principles for Agile Teams
Lean Principles for Agile Teams
Lean Principles for Agile Teams
Lean Principles for Agile Teams
Lean Principles for Agile Teams
Lean Principles for Agile Teams
Lean Principles for Agile Teams
Lean Principles for Agile Teams
Lean Principles for Agile Teams
Lean Principles for Agile Teams
Lean Principles for Agile Teams
Lean Principles for Agile Teams
Lean Principles for Agile Teams
Lean Principles for Agile Teams
Lean Principles for Agile Teams
Lean Principles for Agile Teams
Lean Principles for Agile Teams
Lean Principles for Agile Teams
Lean Principles for Agile Teams
Lean Principles for Agile Teams
Lean Principles for Agile Teams
Lean Principles for Agile Teams
Lean Principles for Agile Teams
Lean Principles for Agile Teams
Lean Principles for Agile Teams
Lean Principles for Agile Teams
Lean Principles for Agile Teams
Lean Principles for Agile Teams
Lean Principles for Agile Teams
Lean Principles for Agile Teams
Lean Principles for Agile Teams
Lean Principles for Agile Teams
Lean Principles for Agile Teams
Lean Principles for Agile Teams
Lean Principles for Agile Teams
Lean Principles for Agile Teams
Lean Principles for Agile Teams
Lean Principles for Agile Teams
Lean Principles for Agile Teams
Lean Principles for Agile Teams
Lean Principles for Agile Teams
Lean Principles for Agile Teams
Lean Principles for Agile Teams
Lean Principles for Agile Teams
Lean Principles for Agile Teams
Lean Principles for Agile Teams
Lean Principles for Agile Teams
Lean Principles for Agile Teams
Lean Principles for Agile Teams
Lean Principles for Agile Teams
Lean Principles for Agile Teams
Lean Principles for Agile Teams
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Lean Principles for Agile Teams

551

Published on

This is a session on Lean Principles for Agile Teams presented at ERUC in October 2013. This is the deck used with the LEGO building block exercise PDF.

This is a session on Lean Principles for Agile Teams presented at ERUC in October 2013. This is the deck used with the LEGO building block exercise PDF.

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
551
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
38
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • “All the organizations we studied that are managed according to the Toyota Production System share an overarching belief that people are the most significant corporate asset and that investments in their knowledge and skills are necessary to build competitiveness. That’s why at these organizations all managers are expected to be able to do the jobs of everyone they supervise and also to teach their workers how to solve problems according to the scientific method.” – HBR, Decoding the DNA of the Toyota Production System“Base your management decisions on a long-term philosophy, even at the expense of short-term financial goals.”Add value to the organization by developing your people and partnersGrow leaders who thoroughly understand the work, live the philosophy, and teach it to others.Develop exceptional people and teams who follow your company's philosophy.Respect your extended network of partners and suppliers by challenging them and helping them improve.
  • http://www.istockphoto.com/stock-photo-15742269-blackboard-series.php?st=ee96d91
  • The technique was originally developed by Sakichi Toyoda and was used within the Toyota Motor Corporation during the evolution of its manufacturing methodologies. TaiichiOhno, described the 5 Whys method as "the basis of Toyota's scientific approach . . . by repeating why five times, the nature of the problem as well as its solution becomes clear.”
  • checking your email while performing another creative task decreases your IQ in the moment 10 points. That is the equivalent of not sleeping for 36 hours - more than twice the impact of smoking marijuana."
  • An engineer picks up a new piece of work - perhaps a defect or a new feature The engineer changes code and creates and executes unit tests (ideally using Test Driven Development) until satisfied that the code seems to work. Better than compiling and testing on the engineer's personal, they could request a 'private build' on an independent machine to ensure they are not relying on any quirks of their own machine. This private build would perhaps run additional automated unit tests for the components being modified. Once the coder is satisfied that the code is unlikely to break any other code, the coder is ready to commit/check-in/deliver their unit-tested code to the source code repository. Engineers also keep test cases, test case data and documentation in the source code repository. The engineer typically checks-in multiple times per day. A continuous integration server automatically initiates an 'integration build' when it detects the check-in. The integration build extracts latest shared source code, compiles and packages the software on an independent machine, runs static code analysis, checks coding standards are being followed, runs automated tests against the software, perhaps deploys the code to live servers, publishes the results (success or failure) and notifies the team. The integration runs without any human intervention whatsoever and must be as fast as possible since the coder is waiting for completion to know whether either they need to fix the broken build (a top priority) or they can move on to their next task/defect. For larger pieces of software, it may not be possible to include a full set of tests in the integration build and have it complete in a reasonable amount of time. Release builds can be scheduled (perhaps every night) or run on-demand to run a more complete set of test suites on a clone of the production environment. When engineers receive notification that builds have completed without any failures, and the engineers know all automated and manual testing is complete for what was included in the build, they can confidently move on to the next task or defect.
  • The phrase technical debt was first introduced by Ward Cunningham in 1992 as a metaphor identifying the affects on a software organization when it chooses a quick and dirty approach that's expedient in the short term but that increases complexity and is more costly in the long term.
  • http://www.istockphoto.com/stock-photo-15742269-blackboard-series.php?st=ee96d91
  • This slide outlines our best practices for adopting DevOps or improvements to existing DevOps capabilities. The steps are covered in a workshop services offering that where we provide a facilitated discussion to complete each of these steps. The workshop that supports these steps can be delivered over a single day to define initiatives/strategy or over 2-3 days to develop an executable roadmap for implementing a single initiative.Step 1 is to understand the scope and business goals for the DevOps improvement initiative or strategy. And to define how best to measures its success.Step 2 is to assess your team on their current practice based maturity.Step 3 is to define the required maturity improvements and architecture needed to achieve the business goals. Step 4 is to develop a strategy or roadmap to implement the initiative(s).
  • This slide shows how you would depict the current maturity level for a client. Blue represents a client that performs all of the activities adequately for that level/path. Yellow represents clients who perform a subset of the activities for that level/path adequately or perform the activities but not at an adequate level. In this slide, note the level/path marked with yellow have bolded type in one of the activities. These are the only activates they perform adequately. Also, this slide represents what a group of cross industry, enterprise clients indicated are their general maturity levels.
  • Transcript

    • 1. Lean Principles for Agile Workshop Elizabeth Woodward, Lean and Agile Strategist Fariz Saracevic, Agile Evangelist
    • 2. Agenda  Introduction: Status quo is not an option (5 min)  A brief history of lean and agile (5 min)  Lean principles – – – – – Mura with Flow Exercise (60 min) Break (10 min) Muda with Value Stream Mapping Exercise (60 min) Muri (10 min) Kaizen (10 min)  An approach to self-optimizing team of teams (5 min)  Summary (5 min) 2
    • 3. Status quo is not an option INTRODUCTION 3
    • 4. New Technologies Change What We Develop and How We Develop Cloud Big Data Requires Continuous Learning and Improvement, Lean and Agile Methods Mobile Social Internet of Things 4
    • 5. Many firms are underprepared for these rapid changes in technology, affecting their ability to be competitive Technology Trends Most Impacting Competitiveness Organizations Underprepared for Technology Trends Mobile device proliferation Collaboration across the ecosystem Explosion of unstructured data Cloud platforms and solutions Intelligent–connected systems Note: Survey respondents were allowed up to three selections The Challenge: Innovation, quality, speed in rapidly changing conditions Source: “The Software Edge: How effective software development and delivery drives competitive advantage,” IBM Institute of Business Value, March 2013 5
    • 6. Highlights of a few key activities over the past decades BRIEF HISTORY OF LEAN AND AGILE 6
    • 7. Brief History of Lean and Agile HBR New New Product Development Game Plan / Measur e DevOps Monitor / Optimize Continuous Innovation, Feedback and Improvements Release / Deploy 7 Develop / Test
    • 8. Importance of principles and values The Toyota story has been intensively researched and painstakingly documented, yet what really happens inside the company remains a mystery. Here’s new insight into the unspoken rules that give Toyota its competitive edge. – HBR, Decoding the DNA of the Toyota Production System 8
    • 9. Agile and lean transformations are culture changes “Culture reflects the realities of people working together every day… values, practices, and traditions that define …a set of who we are as a group.” --Frances Hesselbeim Work by Uwe Kils) http://www.ecoscope.com/iceberg/ 9
    • 10. Relationship between Agile and Lean Agile Lean Design build delivery focus Process improvement focus Objective To achieve faster and better software development and delivery To improve processes by focusing on customer value and systematically identifying and removing waste Principles Early and continuous delivery of working software Eliminate Waste Welcome frequent and late changes in requirement Build Quality In Strong collaboration between business and development team Defer Commitment Face-to-face conversation Sustainable development Simplicity - the art of maximizing the amount of work not done Deliver Fast Focus on Learning Respect People Optimize the Whole Agile and Lean are fully aligned and compatible methodologies with the common goal of increasing customer value and output quality while delivering results faster. 10 10
    • 11. Toyota Production System’s Three Types of waste MURA Elimination of Uneveness 11 MUDA Elimination of Waste MURI Avoidance of the Unreasonable 11
    • 12. Improve flow through the system ELIMINATING MURA (UNEVENESS) 斑 12
    • 13. JIT Pull vs. Push Push Anticipate usage Large batches High inventory Pull Focus on actual consumption Small batches Reduced inventory Demand Authorizes work Empty unit or kanban authorizes work Raw Material Input Finished 13
    • 14. Reducing cycle time by reducing batch sizes  Two ways to reduce cycle time: • Reduce work arriving • Create steady pace of service Cycle Time as a Function of Utilization and Batch Size*  45  Cycle Time (hours) 40 Large Batches 35    Agile planning—finer grained stories nearer in event horizon Splitting stories into tasks for sprint planning Recommendations for small tasks Small batch size reduces cycle time Large batch sizes increase variability High utilization increases variability Medium Batches 30 Small Batches 25 20 15 10 5 0 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% Utilization Figure source : Implementing Lean Software Development 14
    • 15. WIP Constraints and Kanban ―information radiator‖ Not started Development Testing G I F Acceptance C Done A B E J H Exit Criteria Exit Criteria Exit Criteria Exit Criteria Exit Criteria How can this flow be improved? 15
    • 16. Value of cross-functional teams  Toyota Production System: – One operator works across multiple machines – Reduces handoffs – NOTE: One person may walk their piece through multiple processes (not quite the same as a cross-functional team) Agile cross-functional team: All skills required to complete the work. 16
    • 17. Exercise: Improving flow Experiments to demonstrate elimination of Mura. 45 min 17
    • 18. 5 Whys  Used to explore the cause and effect relationships underlying a particular problem  Taiichi Ohno: ―…the basis of Toyota's scientific approach . . . by repeating why five times, the nature of the problem as well as its solution becomes clear." Why Why Why Why Why 18
    • 19. Ruthless elimination of 7 wastes in manufacturing ELIMINATING MUDA (WASTE) 無駄 19
    • 20. WASTES 20 7 無駄 1. 2. 3. 4. 5. 6. 7. Transportation Inventory Motion Waiting Overproduction Over-processing Defects 20
    • 21. What is waste?  A process adds value if it results in something customer will pay for.  Waste is when more resources are consumed than are necessary to produce what the customer wants. Price = Cost + Profit Profit = Price - Cost 無駄 21
    • 22. 1 Transportation Moving products creates risk of damage, lost, and delay with no added value for which customer is willing to pay. In Software = Movement between systems Movement between team members and handoffs 無駄 22
    • 23. Provide teams with the tools they need. Open and integrated. ―Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.‖ – Agile Manifesto Team Members Continuous Delivery Bridge Mainframe and Mobile Skills Open Lifecycle and Service Management Integration Platform Link Systems of Record to Systems of Engagement 23
    • 24. Recommendation of face to face communication ―The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.‖ – Principles of the Agile Manifesto Strive for the Richest Communication Channel Possible 24
    • 25. Transportation waste includes damage to and loss of information Edward T. Hall (1959), a renowned social anthropologist, argued that in a normal conversation: ―More than 65 percent of social meaning occurs through the nonverbal channel.‖ Nonverbal Communication 25
    • 26. Use effective methods for distance communication and collaboration to reduce waste 1 •Conference phones and headsets 2 •Screen sharing 3 •Instant messenger 4 •Video conferencing 5 •Agile Project Management (Electronic Task board) 6 •Lifecycle Management 26
    • 27. 2 Inventory Inventory is raw materials, work-in-progress (WIP), or finished goods—capital outlay that has not produced income. In Software = Delivering partially-completed capability Never-ending backlog 無駄 27
    • 28. Delivering potentially shippable product every iteration  No partially-completed work accepted Sprint Goal Product Backlog  Software delivered meet acceptance criteria  Software delivered meets the definition of done 24 hrs Daily Scrum Meeting 2-4 weeks Potentially Shippable Product Increment Sprint Backlog Sprint Planning Sprint Review 28
    • 29. Features meet the ―definition of done‖              All Acceptance Criteria of the User Story are met Code meets general Coding Standard Refactoring Design Review Functional Tests pass Unit Tests cover >70% code Code Review Functional Tests Written and passed Functional tests added to regression suite User acceptance tests pass Performance tests pass Integration tests pass … 29
    • 30. Prevent wasted backlog maintenance efforts  Will the team get to last item in this lifetime?  Effort to maintain extra backlog  Effort to create the extra backlog 30
    • 31. 3 Motion refers to the damage that the production process inflicts on the entity that creates the product (equipment or workers). In Software = Task switching Death march Throwing software ―over the wall‖ 無駄 31
    • 32. Cost of multi-tasking  One project at a time  Eliminate unimportant work Sprint Goal Product Backlog 24 hrs Daily Scrum Meeting 2-4 weeks Even brief mental blocks created by shifting Potentially Shippable Product Increment Sprint Backlog 40 % between tasks can cost as much as of someone's productive time. – David Meyer, University of Massachusettes Sprint Planning Sprint Review Sprint Reflection 32
    • 33. Preventing a Death March “Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. “*  Use Sprint burndown to track progress  Collaborate with stakeholders to make adjustments as needed  Reduce amount of work taken into the Sprint to ―get to done‖ *agilemanifesto.org 33
    • 34. ―Whole Team‖ to reduce waste related to motion  The Whole Team practice recommends having a team that includes people with all skills and functions needed for creating the product: – Developers – Testers – Designers – Technical writers – Customers – IT Operations… 34
    • 35. 4 Waiting Products that are not in transport or being processed, they are waiting. In Software = Delays in delivery working software to customers Bureaucracy—Decisions, approvals Elimination of blockers (inefficient tools, input, reviews) Waiting for feedback 無駄 35
    • 36. Daily planning addresses blockers and inefficiencies Sprint Goal Product Backlog 24 hrs Daily Scrum Meeting 2-4 weeks Potentially Shippable Product Increment Sprint Backlog Sprint Planning Sprint Review Sprint Reflection 36
    • 37. Team identifies issues during Daily Standups (Daily Scrums) 1. What did I do yesterday that helped the Development Team meet the Sprint Goal? 2. What will I do today to help the Development Team meet the Sprint Goal? 3. Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal? 37
    • 38. Continuous feedback “Business people and developers must work together daily throughout the project.” – Agile Manifesto Sprint Goal Product Backlog 24 hrs Daily Scrum Meeting 2-4 weeks  Reviews of working software provide additional feedback and adaptation Potentially Shippable Product Increment Sprint Backlog Sprint Planning Sprint Review Sprint Reflection 38
    • 39. 5 Overproduction More product is produced than needed at that time. Produced by large batches. Leads to excess inventory. In Software = Producing unnecessary features Backlog refinement based on horizon 無駄 39
    • 40. Producing Unnecessary Features Often or Always Used: 20% Features and Functions Used in a Typical System Rarely or Never Used: 64% Standish Group Study Reported at XP2002 by Jim Johnson, Chairman 40
    • 41. Agile work is done in ―small bites‖ from an ordered backlog Sprint Goal Product Backlog  ―Simplicity--the art of maximizing the amount of work not done--is essential.‖ –Agile Manifesto 24 hrs Daily Scrum Meeting 2-4 weeks Potentially Shippable Product Increment Sprint Backlog Sprint Planning Sprint Review 41
    • 42. Agility and Simplicity ―Every line of code costs money to write and more money to support. It is better for the developers to be surfing than writing code that won't be needed. If they write code that ultimately is not used, I will be paying for that code for the life of the system, which is typically longer than my professional life. If they went surfing, they would have fun, and I would have a less expensive system and fewer headaches to maintain.‖ -- Jeff Sutherland, CTO PatientKeeper Test Driven Development (TDD): Programming practice in which all production code is written in response to a failing test.‖ List Requirements Write One Test Run Test to Make Sure It Fails Refactor to eliminate code smells (e.g., duplicated code) Add or modify just enough code to make new test pass and all previous tests pass Test + Design 42
    • 43. 6 Over-processing More work is done than is required by the customer (e.g. more precise, higher quality). In Software = ―Gold plating‖ Unnecessary testing Excessive audits and validation 無駄 43
    • 44. User Stories Agile Practice Reducing unused software through acceptance criteria  The product owner’s conditions of satisfaction: – Testable so that you have an easy, binary way of knowing whether a story is finished – Done or not done; no ―partially finished‖ or ―done except‖ Card As a network administrator, I want to be able to apply policies to groups of network devices that require similar management so that I can reduce administrative efforts. 44 Conversation Confirmation •Able to group resources by location •Able to group resources by vendor •Able to group resources by services offered •Able to apply a policy to a group of resources 44
    • 45. Combinatorial Test Design (CTD)  For a customer in the Insurance Industry – The client had 15,000 tests, manually reduced to 6000 based on risk estimates – IBM modeled the claims adjudication process using CTD – – IBM identified 41 test cases to perform system test with better coverage  For a customer in the Telecommunication Industry – IBM reverse-engineered the model present in 117 hand-written test cases – Concluded that these tests could be replaced by 12 test cases  IBM internal – System recovery – – – – – – The test team suggested ~50 tests After holes were found and a model was created, there were ~7,800 tests CTD suggested only 17 Out of the 17 tests, 14 revealed unknown defects A total of 20 new defects identified No more outages for over two years 45
    • 46. Excessive audits and validation  Most enterprises embracing agile eventually adapt their business gating processes  Business validation processes often acquire excessive requirements over time 46
    • 47. Reducing excess processing—IP example Can the IP Law office work through non-disclosure agreements quickly enough? Can the IP Law office execute the patenting process quickly enough? 47
    • 48. 7 Defects Poor quality increases costs which should not be passed on to the consumer and are taken as a loss. In Software Cost of defects increases over time Technical debt carries additional cost Missing requirements Integration and migration failures 無駄 48
    • 49. Waterfall cost of defects found over time 49
    • 50. Earlier defect detection with agile leads to less waste Analysis Analysis Design Code Test Analysis Design Analysis Analysis Design Design Code Code Code Test Analysis Code Test Analysis Design Design Test Design Test Analysis Design Code Code Test Code Test Test 50
    • 51. Agile practice of continuous integration helps to find issues earlier. 51
    • 52. Agile teams addressing technical debt (Example) Agile team dedicated to new capability Agile team dedicated to technical debt 80%* *Percentages vary based on circumstances 20%* 52
    • 53. 5 3 Example: Technical Debt Measures used at IBM Metric Goal 2006 Measurement 2010 Measurement Maintenance / Innovation 50/50 42% / 58% 31% / 69% Time to Market (Major) 12 Months 18 + Months 12.5 Months Customer Calls -5% YoY ~ 135,000 ~100,000 (-19% since 2009) Customer Defect Arrivals -5% YoY ~ 6,900 ~2200 On Time Delivery 65% 47% 92% Defect Backlog 3 Months 9+ Months 3 months Enhancements Triaged 85% 3% 100% Enhancements into Release 15% 1% 21% Customer Sat Index 88% 83% 88% Beta Defects Fixed Before GA 50% 3% 94% ~ $10,000,000 ~ $6,400,000 Technical Debt Note: Goals are either internal IBM statistics or industry benchmarks. 53
    • 54. Value Stream Mapping Method for IDENTIFYING WASTE 54
    • 55. Value Stream Maps – Where did we waste the time? Cycle Time – Average end-to-end process time • From problem detection • To problem solution Begins and ends with the customer* Software Development Cycle Time – The speed at which a customer need is reliably and repeatedly translated into deployed software. Cycle Time Customer Request Customer Satisfied 55
    • 56. Enterprise agility requires coordination, communication and collaboration across the enterprise. SSE (hardware/software) has been pushing those boundaries. IT Example: Retail customer is targeting 24 hours from accepting new product to making web updates and adapting supply chain to fulfill request Supply Chain Enterprise SSE: Aerospace contractor is including manufacturers from supply chain early in requirements and design efforts Note: SSE is addressing complex lean and agile challenges that will eventually overlap with IT. Organization Portfolio Program Lean concept of optimization of the whole – ―whole‖ continues to expand. Team + Stakeholder Collab Product and Embedded Coverage Common IT Coverage IBM’s Intent 56
    • 57. devOps in SaaS – Common Definition 1. Agile 2. Agile -> Continuous Delivery GA ready functionality Whole Team Users Auto-mation GA ready functionality Demos, feedback Whole Team GA Auto-mation Continuous Integration Development Demos, feedback GA Continuous Integration Development Operations 3. Agile -> Continuous Delivery GA ready functionality Whole Team Auto-mation Demos, feedback Operations Continuous Deployment GA Continuous Integration Dev/Ops Collaboration 57
    • 58. Spread of Agility across roles 1. Development team 2. Operations 3. Customers/users 4. Product management 5. Marketing 6. Sales 7. Education/Enablement 8. Services 9. Intellectual property 10.Software supply chain 11.Product supply chain Supply Chain Enterprise Organization Portfolio Program Optimization of the whole with expanding view of ―whole‖ Team + Stakeholder Collab Increasing communication and collaboration 58
    • 59. Value Stream Map - Goals Goals of Value Stream Mapping Be able to answer these questions – How quickly can you bring value to your stakeholders? – Where does the time go? – What is the cost of batching your deliveries? – What is the fastest you could deliver / respond? – Did you really respond to your customer? 59
    • 60. Example Waterfall Value Stream Customer tells of Feature Need  Customer Gets Benefit Requirement Identified 1 hour Reqt Reviewed Reqts DB 1 week 1 month 1 hour 18 Month cycle 9 months Review & Decision. “In Plan?” Candidate List 1 day 3 months 1 hour 0 Just for this feature 1 week DCR Selection? 2 months 9 months DCUT 1 month 7 months Testing FV SVT IVT 2 months 1 day Mfg Test Prep Docs 1 week 1 day Install Upgrade 60 1 year Migrate Applications Avg Customer Request to Ship Dev Time = 3 Months Dev Waiting Time = 24 Months Total Dev Time = 27 Months Total Dev Efficiency = 13% In Production Avg Customer Request to Benefit Dev/Cust Working Time = 15 Months Waiting Time = 24 Months Total Customer Time = 39 Months Overall Customer Efficiency = 38% 60
    • 61. Value Stream Example Requirements Develop Test 23 - 33% Efficiency 123 hours Value Require -ments 1 hour 1 hour 1 week Develop Test Develop Test Requirements value waste Requirements Approval Test Requirements Marketing requests New Feature Develop Develop Test 2 weeks working together 1 day 500-660 Hours Total Cycle Time 1 week QA Deploy How much is Value? 2-3 months to merge 1 hour ½ week IBM Internal Use Only : With Thanks to Mary and Tom Poppendieck 61
    • 62. Exercise: Value Stream Maps Select a Process / Problem that is Relevant to you – Decide when the clock starts (e.g.. customer has a need) and when it stops (need is filled). Create a Value Stream Map – List / diagram the key steps to delivering customer value ( value add and waiting ) – List the average time of each step ( value add and waiting ) – If any step repeats, use the average number of repetitions Calculate Process Cycle Efficiency* – Add up time of each step plus time between steps = Total Cycle Time – Add up Value Added Time in each step Value Added Time – Process Efficiency = Total Cycle Time * George & Wilson, Conquering Complexity in Your Business 62
    • 63. Avoidance of the unreasonable MURI 63
    • 64. Applying lean Muri principles to agile development  Muri is avoided through: – Standardized work, standardized conditions of output – Work Flow, or logical directions to be taken – Repeatable Process Steps and Machine Processes  Agile examples: – Agile frameworks – Test automation – Procedures for continuous integration – Recommended practices – Varies according to what works for the individual team – Definition of done 64
    • 65. Continuous Improvement KAIZEN 65
    • 66. Relentless improvement, Learn through experiments Sprint Goal Kaizen: 1. Set goals and provide any necessary background. 2. Review the current state and develop a plan for improvements. 3. Implement improvements. 4. Review and fix what doesn’t work. 5. Report results and determine any follow-up items. Standardized work is the basis for Kaizen Product Backlog 24 hrs Daily Scrum Meeting 2-4 weeks Potentially Shippable Product Increment Sprint Backlog Sprint Planning Sprint Review Reflection 66
    • 67. Continuously improving through shared learning while extending boundaries AN APPROACH TO SELF-OPTIMIZING TEAM OF TEAMS 67
    • 68. IBM DevOps Reference Architecture for Agile Transformation Agile Agile Transformation Quality Improvement Continuous Delivery Initiative Market Experimentation Plan / Measure Develop / Test Release / Deploy Portfolio Management Code Deployment Mobile Transformation Monitor / Optimize Monitoring SW-Defined Environments Legacy Systems Level of importance: Critical Important Requirements Test Provisioning Customer Feedback Nice to Have Optional Collaboration Change & Configuration Management Dashboard / Analytics Jazz, OSLC and Open Standards Platform Discussion 68
    • 69. Where do you start: DevOps Adoption Roadmap Assess desired outcome and supporting practices to drive strategy and roll-out Step 4 Step 3 Step 2 Step 1 Determine What am I trying to achieve? Where am I currently? Where are my bottlenecks and priorities? How should I plan my practice improvement? Activities •Think through business-level drivers for improvement •Align vision and pains to common business drivers across silos •Look across silos, not just within the team, for improvements •What do you measure and currently achieve •What don’t you measure, but should to improve •What practices are well scaled vs. incubating •Refine objectives to particular practice areas •Business-level drivers expose practice gaps across silos •Focusing outside of the bottleneck limits overall improvement •It’s not just about tools, its about People, Practices, Technology, and information Objective Business Goal Determination Current Practice Assessment Objective & Prioritized Capabilities • Identify improvements to skills, processes, and tools to achieve desired outcome • Roadmap activity to define actionable plan • Target improvements which get the best bang for the buck Roadmap Discussion 69
    • 70. Development / Test Define release with business objectives Measure to customer value Improve continuously with development intelligence Test Continuously Manage environments through automation Provide self-service build, provision and deploy Automate problem isolation and issue resolution Optimize to customer KPIs continuously Reliable Plan and source strategically Dashboard portfolio measures Manage data and virtualize services for test Deliver and integrate continuously Standardize and automate crossenterprise Automate patterns-based provision and deploy Optimize applications Use enterprise issue resolution procedures Link objectives to releases Centralize Requirements Management Measure to project metrics Link lifecycle information Deliver and build with test Centralize and automate test management Plan departmental releases and automate status Automated deployment with standard topologies Monitor using business and end user context Document objectives locally Manage department resources Manage Lifecycle artifacts Schedule SCM integrations and automated builds Test following construction Plan and manage releases Standardize deployments Monitor resources consistently Collaborate Dev/Ops informally Practiced Scaled Plan / Measure Repeatable Practice based maturity model: Industry Average Release / Deploy Fully Achieved Monitor / Optimize Centralize event notification and incident resolution Partially Achieved 70
    • 71. Summary  Lean principles are embodied by many agile practices  Lean and agile are complementary  IBM DevOps provides paths for continuous improvement Examples  Agile methods help address the 7 wastes of Muda  Agile frameworks and practices can help improve flow  Agile frameworks and practices support standardization  IBM DevOps is an approach to Kaizen—continuous learning and improvement  Success relies on embracing people and management first 71
    • 72. Acknowledgments  Many people have provided insight that is captured in this presentation. We wish to acknowledge: – Millard Ellingsworth and Maria Ericsson for providing feedback on the content for this workshop – Paul Bahrs and Albert Ho for sharing their insight on the DevOps Maturity Model and Assessment – Thanks to Tom and Mary Poppendieck for the time they spent educating IBM teams during the early stages of IBM’s agile transformation. 72
    • 73. References  The Agile Manifesto. n.d. http://agilemanifesto.org/.  Ambler, Scott, and Mark Lines. Disciplined Agile Delivery. Boston: IBM Press, 2012.  Poppendieck, Mary, and Tom Poppendieck. Leading Lean Software Development: Results Are Not the Point. Boston: Pearson Education, Inc., 2010.  —. Lean Software Development: An Agile Toolkit. Upper Saddle River: AddisonWesley, 2003. 73

    ×