Business Agility And Software Development Alan Chedalawada

Business Agility & Software
Lean-Thinking
Alan Chedalawada

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

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…

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

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?

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

Speed of Business Value
Develop Faster
Deploy Faster
Use Faster!

Trends for Business Value Realization

Type 1
release
release
release
Business value realized
Time

Type 2
release
release
release
Time

Type 3
release
release
release
Time

Type 4
release
release
release
Time

Business Value Realization Trends

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

Challenges with Software Development

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
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

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

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

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

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.

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

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

The Lean Enterprise
Value
Flow
Lean
Enterprise
Make
Sustainably

Enterprise Agility
Business Agility
Management Agility
Team Agility
Technical Agility

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

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

Organizational Impacts
Business

Prioritize features by highest business value
‘drive’ the development efforts to incrementally deliver
Value Stream Owner

Development Organization

Focus on SPEED in delivering software functionality
Must include functionality, maintainability, and extensibility
Requires excellent engineering practices

Management

What is the best way to achieve Fast, Flexible, Flow
Continuous Standards Improvement
Organizational guiding principles, Impediment removal

Organizational “Boundaries”

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

Focus on Business Evolution vs. System Evolution
Example - whiteboard

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?

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

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

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

Critical Success Factors to Agile

Clear business vision, continuous planning and oversight
Dedicated and empowered business leader
Project scope can be partitioned into independent pieces that can be delivered separately

Process
People

Continuous planning, discovery and development
Prioritization of technology spending to highest business value
Boundaries to empower teams
Resolution of impediments to speed and flow
The right business leads
Allocation of business SMEs to support projects
Skills excellence and optimized team performance

End Session

Business Driven Software Development

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

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

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

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.

Key Business Roles

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

4 Stages (containers)
Business Portfolio
Business Product Portfolio (MMFs)
Release Product Backlog
Sprint Backlog(s)

Business Portfolio – Container 1

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

Minimum Marketable Features – Container 2

Decompose MMFs into Business Features

Release Product Backlog – Container 3

Release View cont’d.

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

Example
Whiteboard

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

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

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

Product Development Staffing
Intact teams  invested in the product’s success

Long term domain learning
Long term software understanding
Team members learn to work well together

Product Development Scheduling

Product Champion / Product Manager
Regular convergence points (gates)
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

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

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

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

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?

Break

Product Backlog Management

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

Basic Agile Flow
*Sprint = Iteration
s

Key Roles

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

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

Focus on Business Evolution vs. System Evolution
Example - whiteboard

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,…)
Team Stories are added (infrastructure, process,…)
Business Stories are added (documentation, training, …)

Stories are Sized
Stories are chosen to expand based on business value

Business priority
Architectural interest
Technical Risk

All Stories/Tasks are sized by those who do them…

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?

Technology Precision

Transition to Product Backlog / Release Planning

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
…

Sprint Backlog(s) – Container 4

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

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?

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?

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

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

Sprint 4: Feature Burn Up by Release
This graph shows

Num features actively in work
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

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
Less work on features for future releases

highBusiness Priorityl low
% Complete
FEATURES
Business view: Feature completion by priorities

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

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.

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.

Question and Answer

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

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

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

Net Objectives Services

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

Net Objectives Courses
Lean Software Development for Management
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