Valetch Agile Edge event presentation October 1st 09 London

1. Business Agility & Software Lean-Thinking Alan Chedalawada

2. Alan Chedalawada President Senior Enterprise Consultant, Coach, Trainer, CSM Trainer Lean, Scrum, Coaching, Business and Strategy Development MS with honors from Columbia University’s Computer Technology and Application Masters program Lean Systems & Software Consortium – President of Board of Directors alan.chedalawada@netobjectives.com

3. Agility Its about Agility; you can be more agile or less agile in your efforts An agile team is only as agile as the business & management is agile…

4. What Is your Goal (for IT)? Improve Software development & Deployment? - OR - Faster realization of Business value? Software, by itself, is useless _1s

5. Conversation: Value What is Value to the Customer? What is Value to the Business? How are these different? How does this relate to priority? Who defines / identifies value? How is this assessed? What are the primary drivers for the business?

6. Focus on Speed Quality, low cost, speed: all are essential Starting with low cost: Has limited value Causes poor decisions Starting with speed gives insights Requires quality for sustainability – Go fast now & also in the future! Speed and quality result in lower cost

7. Speed of Business Value Develop Faster Deploy Faster Use Faster!

8. Trends for Business Value Realization

9. Type 1 release release release Business value realized Time

10. Type 2 release release release Business value realized Time

11. Type 3 release release release Business value realized Time

12. Type 4 release release release Business value realized Time

13. Business Value Realization Trends

14. Business Value – Financial Institution (example) Grow / Retain Assets Improve Operations Reduce Cost Compliance Mitigate Risk

15. Challenges with Software Development

17. Software is not maintainableArchitectural risks Having the wrong resources Discovering functional needs late in the project* but being unable to build them * Could this be a good thing? _1dd

18. Waste: Building What You Do Not Need Usage of Features and Functions in Typical System Source: Standish Group Study of 2000 projects at 1000 companies _1

19. Building What You Do Not Need Top three reasons software projects fail Lack of user (sponsor) involvement No executive management support Unclear, incomplete, & changing requirements Typical project has 25% change in requirements 65% of features defined in early specs rarely or never used Source: Standish Group CHAOS Report 1994, 2004

20. Which Is More Important? Discovery of what’s valuable? To the Customer & To the Business Building (and achieving it)? You can not build the right thing if you haven’t discovered it first! Not everything is known or understood upfront by Business / Customer (from a systems view) Business should be able to: Specify what’s most important at any given point in time Learn from what is already implemented Learn from their changing environment Update and reprioritize their requirements

21. Change Tolerant Software 60-80% of all software is developed after first release to production. Change-intolerant software becomes brittle and breaks easily after a short time. A software development process that anticipates change will result in software that tolerates change. Disciplined and frequent exploration of design spaces should be a normal part of the development process.

22. Make – Value - Flow Guidance: Value trumps Flow, Flow trumps eliminating waste

23. Primary Focus Faster Business value realization Focus on cycle time, vs. throughput & resource optimization Fewer things in work improves cycle time Guidance: Value trumps Flow, Flow trumps eliminating waste

24. The Lean Enterprise Value Flow Lean Enterprise Make Sustainably

25. Enterprise Agility Business Agility Management Agility Team Agility Technical Agility

26. Lean Agile Software Development Consists of Guiding Principles Core Practices for Iterative development Process for incremental discovery, development and deployment of business value Continual improvement of the ‘System’ Knowledge stewardship

27. Lean-Agile Software Development Process Lean Software Development enables the discovery, prioritization, and deployment of highest business value Agile methods enable the incremental delivery of business value based on the team’s development capabilities Business Discovery must move at the same pace as team’s capacity (velocity) Lean Agile Support & Feedback Project Approval Project Staffing Project Development Project Deployment Visioning Patterns / TDD

29. ‘drive’ the development efforts to incrementally deliver

31. Must include functionality, maintainability, and extensibility

33. Continuous Standards Improvement

35. Iterative vs. Incremental Incremental development Smaller ‘chunks’ at a time (based on business value ROI) Iterative development Solution evolved based on inspection and refinement Whole Teams – all skills needed for discovery, development, & validation of software solution Focus on speed of delivery All efforts are primarily on current increments

36. Focus on Business Evolution vs. System Evolution Example - whiteboard

37. Why Agile? Challenges / Questions Does it work in the real world? Would it work for my company? What must we do? How long until we see results?

38. Challenges & New Approach Current/Old Approach –Project based Fixed Scope, Budget, Schedule Define all requirements without priority Scope evolves, but budget and schedule remain fixed Big Bang Deployment New Approach – Business Value based Discover highest business value, allocate budget here Prioritize based on Business Value, Sequence based on ROI Re-prioritize based on updated discovery, budget follows Team only builds & deploys priority increments

39. Organizational Change Change is situational; change only succeeds if people do things differently; Transition is psychological - 3 phase process Ending – letting go of the old ways and old identity Neutral zone – when the old is gone, but the new isn’t operational 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

40. Success Factors for Business Agility Business Value driven Scope of Portfolio Continual Business Planning Focus on Realizing Business Value!

42. Dedicated and empowered business leader

44. Prioritization of technology spending to highest business value

45. Boundaries to empower teams

46. Resolution of impediments to speed and flow

47. The right business leads

48. Allocation of business SMEs to support projects

50. Business Driven Software Development

51. Lean Thinking: Value Value is what the customer wants What they are willing to pay for (or endears you to them if you are not charging them) What you are trying to produce Information that is used to create value Discovering What to Build Discovering How to Build In the context of the business _1dd

52. Lean Thinking: The Value Stream The flow from beginning to end of creating the value Often cuts across companies, virtually always cuts across organizations It should look at the sequence of steps that transform the original idea into value in the customers’ hands _1dd

53. Business Driven Software Development Business Driven Software Development is where the Business: Owns Scope and Incremental Releases Continually discovers and prioritizes increments by highest business value Continually manages and validates what the development teams are producing

54. Glossary Minimum Marketable Feature – Increment of realizable business value; decomposed from projects, comprised of business capabilities. Business Capability – business functionality ‘supporting’ the business and/or provides value to our customers Business Feature – an increment of business value that is comprised of slices of business capabilities.

55. Key Business Roles

56. We Have Two Pipelines Give Feedback Selecting what to work on Developing It Fast – Flexible - Flow _1s

57. Business Driven Software Development 4 Stages (containers) Business Portfolio Business Product Portfolio (MMFs) Release Product Backlog Sprint Backlog(s)

58. Business Portfolio – Container 1

59. Business Value – Financial Institution (example) Grow / Retain Assets Improve Operations Reduce Cost Compliance Mitigate Risk

60. Minimum Marketable Features – Container 2

61. Decompose MMFs into Business Features

62. Release Product Backlog – Container 3

63. Release View cont’d.

64. Business Planning Product Owner & Customer Team Business Team Business Sponsor / Manager Why What How

65. Example Whiteboard

66. Do You Need to Know the Cost in Order to Prioritize? Business value should be identified without cost; Whether it is prioritized (sequenced) will depend on cost; H-L estimates would be utilized to determine ROI

67. What Is “The Product”? The product is the long term value goal of the business The releases are the interim rollouts of this value to the customers Projects are the means of organizing the delivery of one or more releases

68. Think Products, not Projects Major Release Maintenance Completion Dot upgrade First Production Release Beta Release Alpha Release Start of Project Internal Release Feasibility Concept Projects Up-front funding Scope fixed at onset Success = cost/schedule/scope Team disbands at completion Documentation tossed over-the-wall to maintenance Short Term Thinking Products Incremental funding Scope expected to evolve Success = profit/market share Team stays with product Team uses its own documentation Lasting Value

70. Long term software understanding

72. Regular convergence points (gates)

74. Product View: All Types of Development All work is prioritized and done by the same team(s) New functionality Enhancements Maintenance Defects Change Management

75. Project Priority Challenges Project-Driven Approach Can we do this?

76. Project View: By Project Business Value The project has been prioritized. Making good progress on completing features in release.

77. Product Portfolio View: By Business Value Same project, within program, sorted by business value Q: Why is so much work being spent on lower priority features?

78. Break

79. Product Backlog Management

80. We Have Two Pipelines Give Feedback Selecting what to work on Developing It Fast – Flexible - Flow _1s

81. Basic Agile Flow *Sprint = Iteration s

82. Key Roles

83. Responsibilities of a Product Owner Determine what Stakeholders Want Decide what They Actually Get Drive the Team at a Sustainable Pace Write Stories Representing This Explain The Stories to the Team Approve the Functional Tests Validate That We Got What We Wanted Release the Product These responsibilities are often separated into different people Business people, Customer SMEs, Analysts and Testers

84. Iterative vs. Incremental Incremental development Smaller ‘chunks’ at a time (based on business value ROI) Iterative development Solution evolved based on inspection and refinement Whole Teams – all skills needed for discovery, development, & validation of software solution Focus on speed of delivery All efforts are primarily on current increments

85. Focus on Business Evolution vs. System Evolution Example - whiteboard

87. Team Stories are added (infrastructure, process,…)

89. Architectural interest

90. Technical RiskAll Stories/Tasks are sized by those who do them…

91. Considerations / Questions New application vs. enhancement? New technology? To our Company? To Team? What skills do I need? And who… from external groups? Identify ‘Tent Poles’? External Vendor dependencies? Special security risks? Business team with understanding? Budget gaps? Or constraints? Schedule? SI initiatives?

92. Technology Precision

93. Transition to Product Backlog / Release Planning

94. ATM Project Team Business Product Management Sales Spt Structure Function Team Training Marketing Support Domain Model Conversions Dev/SCM/Test Environments User Training Rewrites Dev Process User Docs Refactorings App Framework Business Framework … Tools Adapt Processes Maintenance Docs … … Work Breakdown Structure (WBS) Login Withdraw Cash Deposit Check Transfer Funds Refresh Cash Drawer …

95. Sprint Backlog(s) – Container 4

96. Teams Pull from Business Needs Team Business Owner & Tech owner Business Owner Why What How Customer / User Feedback

97. Things to Look For Is ‘Done’ on stories achievable within a sprint? How often does the team adjust estimates? (size) How often does the Top-line change? Are all risks visible? Meeting the sprint commitments? Pace?

98. Is it Complete? All work is represented All dependencies are noted All risks uncovered – stories / tasks created to mitigate All discovery managed – stories / tasks How long (in sprints) does it take to complete your Product Backlog? Is it ever complete?

99. Making It Visible Risks Issues Uncertainties Impediments Dependencies Should be known and shared between and among teams Mitigate with Stories in the Backlog

100. Burn-Up Chart to Show Progress Same data as erstwhile Burn-Down chart Clearer to see what happened

104. Less work on features for future releases highBusiness Priorityl low % Complete FEATURES Business view: Feature completion by priorities

105. Product Backlog Topline – Sprint 4 1465, May Elevation variance 1472 138 point short fall 1460, Security Depository variance Nov. 2007 Planned August 2007 committed May 2007 complete Dec’07 Feb’07 Sep’08

106. Challenges when evolving to Enterprise Agility Principles vs. Practices. Working on shifting perspectives. Shifting from a project focus/internal view. Lack of clarity around what constitutes a product and slow movement towards this view. Engaging business. Seen as IT “stuff” and sometimes viewed as something that is being forced on the business. Support teams in a large enterprise. Many dependencies. Preventing unhealthy rogue adoptions. It’s the shiny new object that everyone wants to play with.

107. Challenges cont’d. 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. Difficult to break the focus on resource utilization. Feelings that product development practices are not appropriate for a services organization. Regularly have to convince individuals of the applicability.

108. Question and Answer

109. Thank You! … and following is more to help you plan your next steps

110. Resources Resources: www.netobjectives.com/resources Webinars/Training Videos (PowerPoint with audio) Articles and whitepapers Pre/post course support Supporting materials Quizzes Recommended reading paths Blogs and podcasts: blogs.netobjectives.com Annotated Bibliography After-Course Support (students only) Additional Training Two User Groups http://tech.groups.yahoo.com/group/leanagile http://tech.groups.yahoo.com/group/leanprogramming Join our e-mail list to receive regular updates and information about our resources and training of interest to you

111. Bibliography Science of Lean-Thinking Managing the Design Factory, Don Reinertsen Principles of Product Development Flow: Second Generation Lean Product Development, Donald Reinertsen Lean Thinking: Banish Waste and Create Wealth in Your Corporation, Revised and Updated, James Womack, Daniel Jones Lean Management Leader’s Handbook: Making Things Happen, Getting Things Done, Peter Scholtes Creating a Lean Culture: Tools to Sustain Lean Conversions, David Mann Lean Learning Managing to Learn, John Shook

112. Net Objectives Services

113. Best Practices Curriculum Exec Mgmt Lean Agile Overview for Leaders Senior Management IT Mgmt Agility for Managers (if not taking Implementing Scrum for Your Team course) Lean Software Development For Management Scrum Master Practitioner IT Management Business Mgmt Business Management Business Product Owner Lean-Agile EnterpriseRelease Planning Implementing Scrum for Your Team OR Implementing Agile Development With VSTS for Agile Teams Lean Software Development Analyst Analyst Lean-Agile Testing Practices(if not taking Implementing Scrum for Your Team course) OR Agile Planning and Estimating with User Stories Process Scrum Master CertificationBy Net Objectives Process Advanced Agile Tester Tester Effective Object-Oriented Analysis and Design (if needed) Acceptance Test-DrivenDevelopment Design Patterns for Agile Developers Advanced Software Design Technical Emergent Design Developer Sustainable Test-Driven Development TDD Database Boot Camp Technical Training: C++, C#, Java

114. Net Objectives Courses Lean Software Development Lean Software Development for Management Lean Software Development Lean-Agile Software Development Agile/Scrum Implementing Scrum for Your Team Implementing Scrum for Multiple Teams Scrum Master Certificationby Net Objectives Lean-Agile Enterprise Release Planning Agile Planning and Estimating with User Stories Agile Life-Cycle Management with VersionOne Product Owner Certification by Net Objectives Implementing Agile Development with Microsoft™ Visual Studio Team System™ Agile Software Development Design Patterns Explained Emergent Design: Effective Agile Software Development Design Patterns for Agile Developers Sustainable Test-Driven Development Acceptance Test-Driven Development TDD Database Boot Camp Advanced Software Design Lean-Agile Testing Practices Test-Driven ASP.NET Effective Object-Oriented Analysis and Design A Top 5 CourseA New Course For more information, see: www.netobjectives.com/training