Successfully reported this slideshow.

Business Agility And Software Development Alan Chedalawada

1,400 views

Published on

Valetch Agile Edge event presentation October 1st 09 London

Published in: Technology, Business
  • Be the first to comment

Business Agility And Software Development Alan Chedalawada

  1. 1. Business Agility & Software<br />Lean-Thinking<br />Alan Chedalawada<br />
  2. 2. Alan Chedalawada<br />President<br />Senior Enterprise Consultant, Coach, Trainer, CSM Trainer<br />Lean, Scrum, Coaching, Business and Strategy Development <br />MS with honors from Columbia University’s Computer Technology and Application Masters program <br />Lean Systems & Software Consortium – President of Board of Directors<br />alan.chedalawada@netobjectives.com<br />
  3. 3. Agility<br />Its about Agility; you can be more agile or less agile in your efforts<br />An agile team is only as agile as the business & management is agile…<br />
  4. 4. What Is your Goal (for IT)?<br />Improve Software development & Deployment?<br />- OR -<br />Faster realization of Business value?<br />Software, by itself, is useless<br />_1s<br />
  5. 5. Conversation: Value<br />What is Value to the Customer?<br />What is Value to the Business?<br />How are these different?<br />How does this relate to priority?<br />Who defines / identifies value?<br />How is this assessed?<br />What are the primary drivers for the business?<br />
  6. 6. Focus on Speed<br />Quality, low cost, speed: all are essential<br />Starting with low cost:<br />Has limited value <br />Causes poor decisions<br />Starting with speed gives insights<br />Requires quality for sustainability – Go fast now & also in the future!<br />Speed and quality result in lower cost<br />
  7. 7. Speed of Business Value<br />Develop Faster<br />Deploy Faster<br />Use Faster!<br />
  8. 8. Trends for Business Value Realization<br />
  9. 9. Type 1 <br />release<br />release<br />release<br />Business value realized<br />Time<br />
  10. 10. Type 2 <br />release<br />release<br />release<br />Business value realized<br />Time<br />
  11. 11. Type 3 <br />release<br />release<br />release<br />Business value realized<br />Time<br />
  12. 12. Type 4 <br />release<br />release<br />release<br />Business value realized<br />Time<br />
  13. 13. Business Value Realization Trends<br />
  14. 14. Business Value – Financial Institution (example)<br />Grow / Retain Assets<br />Improve Operations<br />Reduce Cost<br />Compliance<br />Mitigate Risk<br />
  15. 15. Challenges with Software Development<br />
  16. 16. The Risks of Software Development<br />Building more than you need<br />Building lower priority items<br />Building the right thing wrong<br />Poor quality of software<br /><ul><li>Software is buggy
  17. 17. Software is not maintainable</li></ul>Architectural risks<br />Having the wrong resources<br />Discovering functional needs late in the project* but being unable to build them<br />* Could this be a good thing?<br />_1dd<br />
  18. 18. Waste: Building What You Do Not Need<br />Usage of Features and Functions in Typical System<br />Source: Standish Group<br />Study of 2000 projects at 1000 companies<br />_1<br />
  19. 19. Building What You Do Not Need<br />Top three reasons software projects fail<br />Lack of user (sponsor) involvement<br />No executive management support<br />Unclear, incomplete, & changing requirements<br />Typical project has 25% change in requirements<br />65% of features defined in early specs rarely or never used<br />Source: Standish Group<br />CHAOS Report 1994, 2004<br />
  20. 20. Which Is More Important?<br />Discovery of what’s valuable?<br />To the Customer & To the Business<br />Building (and achieving it)?<br />You can not build the right thing if you haven’t discovered it first!<br />Not everything is known or understood upfront by Business / Customer (from a systems view)<br />Business should be able to:<br />Specify what’s most important at any given point in time<br />Learn from what is already implemented <br />Learn from their changing environment<br />Update and reprioritize their requirements <br />
  21. 21. Change Tolerant Software<br />60-80% of all software is developed after first release to production.<br />Change-intolerant software becomes brittle and breaks easily after a short time.<br />A software development process that anticipates change will result in software that tolerates change.<br />Disciplined and frequent exploration of design spaces should be a normal part of the development process.<br />
  22. 22. Make – Value - Flow<br />Guidance: Value trumps Flow, Flow trumps eliminating waste<br />
  23. 23. Primary Focus<br />Faster Business value realization<br />Focus on cycle time, vs. throughput & resource optimization<br />Fewer things in work improves cycle time<br />Guidance: Value trumps Flow, Flow trumps eliminating waste<br />
  24. 24. The Lean Enterprise<br />Value<br />Flow<br />Lean<br />Enterprise<br />Make<br />Sustainably<br />
  25. 25. Enterprise Agility<br />Business Agility<br />Management Agility<br />Team Agility<br />Technical Agility<br />
  26. 26. Lean Agile Software Development<br />Consists of Guiding Principles<br />Core Practices for Iterative development<br />Process for incremental discovery, development and deployment of business value<br />Continual improvement of the ‘System’<br />Knowledge stewardship<br />
  27. 27. Lean-Agile Software Development Process<br />Lean Software Development enables the discovery, prioritization, and deployment of highest business value<br />Agile methods enable the incremental delivery of business value based on the team’s development capabilities<br />Business Discovery must move at the same pace as team’s capacity (velocity)<br />Lean<br />Agile<br />Support & <br />Feedback<br />Project<br />Approval<br />Project<br />Staffing<br />Project<br />Development<br />Project<br />Deployment<br />Visioning<br />Patterns / TDD<br />
  28. 28. Organizational Impacts<br />Business <br /><ul><li>Prioritize features by highest business value
  29. 29. ‘drive’ the development efforts to incrementally deliver
  30. 30. Value Stream Owner</li></ul>Development Organization<br /><ul><li>Focus on SPEED in delivering software functionality
  31. 31. Must include functionality, maintainability, and extensibility
  32. 32. Requires excellent engineering practices</li></ul>Management<br /><ul><li>What is the best way to achieve Fast, Flexible, Flow
  33. 33. Continuous Standards Improvement
  34. 34. Organizational guiding principles, Impediment removal</li></li></ul><li>Organizational “Boundaries”<br />
  35. 35. Iterative vs. Incremental<br />Incremental development<br />Smaller ‘chunks’ at a time (based on business value ROI)<br />Iterative development<br />Solution evolved based on inspection and refinement<br />Whole Teams – all skills needed for discovery, development, & validation of software solution<br />Focus on speed of delivery<br />All efforts are primarily on current increments<br />
  36. 36. Focus on Business Evolution vs. System Evolution<br />Example - whiteboard<br />
  37. 37. Why Agile?<br />Challenges / Questions<br />Does it work in the real world?<br />Would it work for my company?<br />What must we do?<br />How long until we see results?<br />
  38. 38. Challenges & New Approach<br />Current/Old Approach –Project based<br />Fixed Scope, Budget, Schedule<br />Define all requirements without priority<br />Scope evolves, but budget and schedule remain fixed <br />Big Bang Deployment<br />New Approach – Business Value based<br />Discover highest business value, allocate budget here<br />Prioritize based on Business Value, Sequence based on ROI<br />Re-prioritize based on updated discovery, budget follows<br />Team only builds & deploys priority increments <br />
  39. 39. Organizational Change<br />Change is situational; change only succeeds if people do things differently;<br />Transition is psychological - 3 phase process<br />Ending – letting go of the old ways and old identity<br />Neutral zone – when the old is gone, but the new isn’t operational<br />New beginning – when people develop the new identity, experience the new energy, and discover new sense of purpose that make the change begin to work<br />
  40. 40. Success Factors for Business Agility<br />Business Value driven<br />Scope of Portfolio<br />Continual Business Planning<br />Focus on Realizing Business Value!<br />
  41. 41. Critical Success Factors to Agile<br /><ul><li>Clear business vision, continuous planning and oversight
  42. 42. Dedicated and empowered business leader
  43. 43. Project scope can be partitioned into independent pieces that can be delivered separately</li></ul>Process<br />People<br /><ul><li>Continuous planning, discovery and development
  44. 44. Prioritization of technology spending to highest business value
  45. 45. Boundaries to empower teams
  46. 46. Resolution of impediments to speed and flow
  47. 47. The right business leads
  48. 48. Allocation of business SMEs to support projects
  49. 49. Skills excellence and optimized team performance</li></li></ul><li>End Session <br />
  50. 50. Business Driven Software Development<br />
  51. 51. Lean Thinking: Value<br />Value is what the customer wants<br />What they are willing to pay for (or endears you to them if you are not charging them)<br />What you are trying to produce<br />Information that is used to create value<br />Discovering What to Build<br />Discovering How to Build<br />In the context of the business<br />_1dd<br />
  52. 52. Lean Thinking: The Value Stream<br />The flow from beginning to end of creating the value<br />Often cuts across companies, virtually always cuts across organizations<br />It should look at the sequence of steps that transform the original idea into value in the customers’ hands<br />_1dd<br />
  53. 53. Business Driven Software Development<br />Business Driven Software Development is where the Business:<br />Owns Scope and Incremental Releases<br />Continually discovers and prioritizes increments by highest business value<br />Continually manages and validates what the development teams are producing<br />
  54. 54. Glossary<br />Minimum Marketable Feature – Increment of realizable business value; decomposed from projects, comprised of business capabilities.<br />Business Capability – business functionality ‘supporting’ the business and/or provides value to our customers<br />Business Feature – an increment of business value that is comprised of slices of business capabilities. <br />
  55. 55. Key Business Roles<br />
  56. 56. We Have Two Pipelines<br />Give Feedback<br />Selecting what to work on <br />Developing It<br />Fast – Flexible - Flow<br />_1s<br />
  57. 57. Business Driven Software Development<br />4 Stages (containers)<br />Business Portfolio<br />Business Product Portfolio (MMFs)<br />Release Product Backlog<br />Sprint Backlog(s)<br />
  58. 58. Business Portfolio – Container 1<br />
  59. 59. Business Value – Financial Institution (example)<br />Grow / Retain Assets<br />Improve Operations<br />Reduce Cost<br />Compliance<br />Mitigate Risk<br />
  60. 60. Minimum Marketable Features – Container 2<br />
  61. 61. Decompose MMFs into Business Features<br />
  62. 62. Release Product Backlog – Container 3<br />
  63. 63. Release View cont’d.<br />
  64. 64. Business Planning<br />Product Owner & Customer Team<br />Business Team<br />Business Sponsor / Manager<br />Why<br />What<br />How<br />
  65. 65. Example<br />Whiteboard <br />
  66. 66. Do You Need to Know the Cost in Order to Prioritize?<br />Business value should be identified without cost;<br />Whether it is prioritized (sequenced) will depend on cost; H-L estimates would be utilized to determine ROI<br />
  67. 67. What Is “The Product”?<br />The product is the long term value goal of the business<br />The releases are the interim rollouts of this value to the customers<br />Projects are the means of organizing the delivery of one or more releases<br />
  68. 68. Think Products, not Projects<br />Major Release<br />Maintenance<br />Completion<br />Dot upgrade<br />First Production Release <br />Beta Release<br />Alpha Release<br />Start of Project<br />Internal Release<br />Feasibility<br />Concept<br />Projects<br />Up-front funding<br />Scope fixed at onset<br />Success = cost/schedule/scope<br />Team disbands at completion<br />Documentation tossed over-the-wall to maintenance<br />Short Term Thinking<br />Products<br />Incremental funding<br />Scope expected to evolve<br />Success = profit/market share<br />Team stays with product<br />Team uses its own documentation<br />Lasting Value<br />
  69. 69. Product Development Staffing <br />Intact teams  invested in the product’s success<br /><ul><li>Long term domain learning
  70. 70. Long term software understanding
  71. 71. Team members learn to work well together</li></ul>Product Development Scheduling<br /><ul><li>Product Champion / Product Manager
  72. 72. Regular convergence points (gates)
  73. 73. Long term release schedule</li></li></ul><li>Think Products, Not Projects<br />Value-Based Decisions<br />All requirements are not created equal<br />Learning-Based Processes<br />Deploy early, deploy often<br />Long Term Thinking<br />Design for maintainability<br />Global Optimization<br />Software, all by itself, is useless<br />
  74. 74. Product View: All Types of Development<br />All work is prioritized and done by the same team(s)<br />New functionality<br />Enhancements<br />Maintenance<br />Defects<br />Change Management<br />
  75. 75. Project Priority Challenges<br />Project-Driven Approach<br />Can we do this?<br />
  76. 76. Project View: By Project Business Value<br />The project has been prioritized. Making good progress on completing features in release. <br />
  77. 77. Product Portfolio View: By Business Value<br />Same project, within program, sorted by business value<br />Q: Why is so much work being spent on lower priority features?<br />
  78. 78. Break<br />
  79. 79. Product Backlog Management<br />
  80. 80. We Have Two Pipelines<br />Give Feedback<br />Selecting what to work on <br />Developing It<br />Fast – Flexible - Flow<br />_1s<br />
  81. 81. Basic Agile Flow<br />*Sprint = Iteration<br />s<br />
  82. 82. Key Roles<br />
  83. 83. Responsibilities of a Product Owner<br />Determine what Stakeholders Want<br />Decide what They Actually Get<br />Drive the Team at a Sustainable Pace<br />Write Stories Representing This<br />Explain The Stories to the Team<br />Approve the Functional Tests<br />Validate That We Got What We Wanted<br />Release the Product<br />These responsibilities are often separated into different people<br />Business people, Customer SMEs,<br />Analysts and Testers<br />
  84. 84. Iterative vs. Incremental<br />Incremental development<br />Smaller ‘chunks’ at a time (based on business value ROI)<br />Iterative development<br />Solution evolved based on inspection and refinement<br />Whole Teams – all skills needed for discovery, development, & validation of software solution<br />Focus on speed of delivery<br />All efforts are primarily on current increments<br />
  85. 85. Focus on Business Evolution vs. System Evolution<br />Example - whiteboard<br />
  86. 86. Product Backlog<br />A constantly evolving, prioritized, collection of business and technical functionality that needs to be developed into a system (Use Cases, Stories, Tasks, Features…)<br /><ul><li>Really only four priorities: frontburner, backburner, fridge, and freezer</li></ul>Initial elements of Functional Requirements are Features<br />Features are fleshed out and decomposed into Stories/Tasks <br />Can use a WBS to organize and find other Stories (now or later)<br /><ul><li>Functional Architecture Stories are added (refactoring,…)
  87. 87. Team Stories are added (infrastructure, process,…)
  88. 88. Business Stories are added (documentation, training, …)</li></ul>Stories are Sized<br />Stories are chosen to expand based on business value<br /><ul><li>Business priority
  89. 89. Architectural interest
  90. 90. Technical Risk</li></ul>All Stories/Tasks are sized by those who do them…<br />
  91. 91. Considerations / Questions<br />New application vs. enhancement?<br />New technology? To our Company? To Team?<br />What skills do I need? And who… from external groups?<br />Identify ‘Tent Poles’?<br />External Vendor dependencies?<br />Special security risks?<br />Business team with understanding?<br />Budget gaps? Or constraints? Schedule?<br />SI initiatives?<br />
  92. 92. Technology Precision<br />
  93. 93. Transition to Product Backlog / Release Planning<br />
  94. 94. ATM Project<br />Team<br />Business<br />Product<br />Management<br />Sales Spt<br />Structure<br />Function<br />Team<br />Training<br />Marketing<br />Support<br />Domain<br />Model<br />Conversions<br />Dev/SCM/Test<br />Environments<br />User <br />Training<br />Rewrites<br />Dev<br />Process<br />User Docs<br />Refactorings<br />App<br />Framework<br />Business<br />Framework<br />…<br />Tools<br />Adapt<br />Processes<br />Maintenance<br />Docs<br />…<br />…<br />Work Breakdown Structure (WBS) <br />Login<br />Withdraw <br />Cash<br />Deposit<br />Check<br />Transfer<br />Funds<br />Refresh Cash<br />Drawer<br />…<br />
  95. 95. Sprint Backlog(s) – Container 4<br />
  96. 96. Teams Pull from Business Needs<br />Team<br />Business Owner & Tech owner<br />Business Owner<br />Why<br />What<br />How<br />Customer / User Feedback<br />
  97. 97. Things to Look For<br />Is ‘Done’ on stories achievable within a sprint?<br />How often does the team adjust estimates? (size)<br />How often does the Top-line change?<br />Are all risks visible?<br />Meeting the sprint commitments? Pace?<br />
  98. 98. Is it Complete?<br />All work is represented<br />All dependencies are noted<br />All risks uncovered – stories / tasks created to mitigate<br />All discovery managed – stories / tasks<br />How long (in sprints) does it take to complete your Product Backlog? Is it ever complete?<br />
  99. 99. Making It Visible<br />Risks<br />Issues<br />Uncertainties<br />Impediments <br />Dependencies<br />Should be known and shared between and among teams <br />Mitigate with Stories in the Backlog<br />
  100. 100. Burn-Up Chart to Show Progress<br />Same data as erstwhile Burn-Down chart<br />Clearer to see what happened<br />
  101. 101. Sprint 4: Feature Burn Up by Release<br />This graph shows<br /><ul><li>Num features actively in work
  102. 102. Swarming well on incremental delivery?</li></ul>Q: In Sprint 4, likely to succeed in release?<br /><ul><li>Why so many activities for future releases?</li></ul>% Complete<br />FEATURES<br />Business view: Feature completion<br />
  103. 103. Sprint 5: Refocused Based on Priorities<br />In Sprint 5, Product Owner refocuses team based on business value priorities<br /><ul><li>Increases likelihood of success in earlier releases
  104. 104. Less work on features for future releases </li></ul>highBusiness Priorityl low<br />% Complete<br />FEATURES<br />Business view: Feature completion by priorities<br />
  105. 105. Product Backlog Topline – Sprint 4<br />1465, May Elevation variance <br />1472<br />138 point short fall<br />1460, Security Depository variance<br />Nov. 2007 Planned<br />August 2007 committed<br />May 2007 complete<br />Dec’07<br />Feb’07<br />Sep’08<br />
  106. 106. Challenges when evolving to Enterprise Agility<br />Principles vs. Practices. Working on shifting perspectives.<br />Shifting from a project focus/internal view. Lack of clarity around what constitutes a product and slow movement towards this view.<br />Engaging business. Seen as IT “stuff” and sometimes viewed as something that is being forced on the business.<br />Support teams in a large enterprise. Many dependencies.<br />Preventing unhealthy rogue adoptions. It’s the shiny new object that everyone wants to play with.<br />
  107. 107. Challenges cont’d.<br />Incentives and compensation are not aligned with the change. The enterprise continues to recognize and reward behaviors that aren’t necessarily aligned with what we are trying to introduce. <br />Difficult to break the focus on resource utilization.<br />Feelings that product development practices are not appropriate for a services organization. Regularly have to convince individuals of the applicability.<br />
  108. 108. Question and Answer<br />
  109. 109. Thank You!<br />… and following is more to help you plan your next steps<br />
  110. 110. Resources<br />Resources: www.netobjectives.com/resources <br />Webinars/Training Videos (PowerPoint with audio)<br />Articles and whitepapers<br />Pre/post course support Supporting materials<br />Quizzes<br />Recommended reading paths<br />Blogs and podcasts: blogs.netobjectives.com<br />Annotated Bibliography<br />After-Course Support (students only)<br />Additional Training<br />Two User Groups<br />http://tech.groups.yahoo.com/group/leanagile <br />http://tech.groups.yahoo.com/group/leanprogramming <br />Join our e-mail list to receive regular updates and information about our resources and training of interest to you<br />
  111. 111. Bibliography<br />Science of Lean-Thinking<br />Managing the Design Factory, Don Reinertsen<br />Principles of Product Development Flow: Second Generation Lean Product Development, Donald Reinertsen<br />Lean Thinking: Banish Waste and Create Wealth in Your Corporation, Revised and Updated, James Womack, Daniel Jones<br />Lean Management<br />Leader’s Handbook: Making Things Happen, Getting Things Done, Peter Scholtes<br />Creating a Lean Culture: Tools to Sustain Lean Conversions, David Mann<br />Lean Learning<br />Managing to Learn, John Shook<br />
  112. 112. Net Objectives Services<br />
  113. 113. Best Practices Curriculum<br />Exec Mgmt<br />Lean Agile Overview for Leaders<br />Senior Management<br />IT Mgmt<br />Agility for Managers <br />(if not taking Implementing Scrum for Your Team course)<br />Lean Software Development For Management<br />Scrum Master Practitioner<br />IT Management<br />Business Mgmt<br />Business Management<br />Business Product Owner<br />Lean-Agile EnterpriseRelease Planning<br />Implementing Scrum for Your Team<br />OR<br />Implementing Agile Development With VSTS for Agile Teams<br />Lean Software Development<br />Analyst<br />Analyst<br />Lean-Agile Testing Practices(if not taking Implementing Scrum for Your Team course)<br />OR<br />Agile Planning and Estimating with User Stories<br />Process<br />Scrum Master CertificationBy Net Objectives<br />Process<br />Advanced Agile<br />Tester<br />Tester<br />Effective Object-Oriented Analysis and Design<br />(if needed)<br />Acceptance Test-DrivenDevelopment<br />Design Patterns for Agile Developers<br />Advanced Software Design<br />Technical<br />Emergent Design<br />Developer<br />Sustainable Test-Driven Development<br />TDD Database Boot Camp<br />Technical Training: C++, C#, Java<br />
  114. 114. Net Objectives Courses<br />Lean Software Development<br />Lean Software Development for Management<br />Lean Software Development<br />Lean-Agile Software Development<br />Agile/Scrum<br />Implementing Scrum for Your Team<br />Implementing Scrum for Multiple Teams<br />Scrum Master Certificationby Net Objectives<br />Lean-Agile Enterprise Release Planning<br />Agile Planning and Estimating with User Stories<br />Agile Life-Cycle Management with VersionOne<br />Product Owner Certification by Net Objectives<br />Implementing Agile Development with Microsoft™ Visual Studio Team System™ <br />Agile Software Development<br />Design Patterns Explained<br />Emergent Design: Effective Agile Software Development<br />Design Patterns for Agile Developers<br />Sustainable Test-Driven Development<br />Acceptance Test-Driven Development<br />TDD Database Boot Camp<br />Advanced Software Design<br />Lean-Agile Testing Practices<br />Test-Driven ASP.NET<br />Effective Object-Oriented Analysis and Design<br />A Top 5 CourseA New Course<br />For more information, see: www.netobjectives.com/training<br />

×