Business Agility And Software Development   Alan Chedalawada
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

Business Agility And Software Development Alan Chedalawada

  • 1,884 views
Uploaded on

Valetch Agile Edge event presentation October 1st 09 London

Valetch Agile Edge event presentation October 1st 09 London

More in: Technology , Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
1,884
On Slideshare
1,872
From Embeds
12
Number of Embeds
2

Actions

Shares
Downloads
65
Comments
0
Likes
2

Embeds 12

http://www.slideshare.net 11
http://blog.valtech.co.uk 1

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
  • CommonSlides
  • Get the vanguard definition of business capability
  • Reverse of customer value vs. business value
  • Questions – do we use FIT in LAT?

Transcript

  • 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
  • 16. The Risks of Software Development
    Building more than you need
    Building lower priority items
    Building the right thing wrong
    Poor quality of software
    • Software is buggy
    • 17. Software is not maintainable
    Architectural 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
  • 28. Organizational Impacts
    Business
    • Prioritize features by highest business value
    • 29. ‘drive’ the development efforts to incrementally deliver
    • 30. Value Stream Owner
    Development Organization
    • Focus on SPEED in delivering software functionality
    • 31. Must include functionality, maintainability, and extensibility
    • 32. Requires excellent engineering practices
    Management
    • What is the best way to achieve Fast, Flexible, Flow
    • 33. Continuous Standards Improvement
    • 34. Organizational guiding principles, Impediment removal
  • Organizational “Boundaries”
  • 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!
  • 41. Critical Success Factors to Agile
    • Clear business vision, continuous planning and oversight
    • 42. Dedicated and empowered business leader
    • 43. Project scope can be partitioned into independent pieces that can be delivered separately
    Process
    People
    • Continuous planning, discovery and development
    • 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
    • 49. Skills excellence and optimized team performance
  • End Session
  • 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
  • 69. Product Development Staffing
    Intact teams  invested in the product’s success
    • Long term domain learning
    • 70. Long term software understanding
    • 71. Team members learn to work well together
    Product Development Scheduling
    • Product Champion / Product Manager
    • 72. Regular convergence points (gates)
    • 73. Long term release schedule
  • Think Products, Not Projects
    Value-Based Decisions
    All requirements are not created equal
    Learning-Based Processes
    Deploy early, deploy often
    Long Term Thinking
    Design for maintainability
    Global Optimization
    Software, all by itself, is useless
  • 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
  • 86. Product Backlog
    A constantly evolving, prioritized, collection of business and technical functionality that needs to be developed into a system (Use Cases, Stories, Tasks, Features…)
    • Really only four priorities: frontburner, backburner, fridge, and freezer
    Initial elements of Functional Requirements are Features
    Features are fleshed out and decomposed into Stories/Tasks
    Can use a WBS to organize and find other Stories (now or later)
    • Functional Architecture Stories are added (refactoring,…)
    • 87. Team Stories are added (infrastructure, process,…)
    • 88. Business Stories are added (documentation, training, …)
    Stories are Sized
    Stories are chosen to expand based on business value
    • Business priority
    • 89. Architectural interest
    • 90. Technical Risk
    All 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
  • 101. Sprint 4: Feature Burn Up by Release
    This graph shows
    • Num features actively in work
    • 102. Swarming well on incremental delivery?
    Q: In Sprint 4, likely to succeed in release?
    • Why so many activities for future releases?
    % Complete
    FEATURES
    Business view: Feature completion
  • 103. Sprint 5: Refocused Based on Priorities
    In Sprint 5, Product Owner refocuses team based on business value priorities
    • Increases likelihood of success in earlier releases
    • 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