This is a presentation to Senior and Executive Managers which is used to explain how Agile Software Development processes and practices benefit them, their organization and their customers.
Why Teams call analytics are critical to your entire business
Benefits of Agile Software Development for Senior Management
1. The Benefits of
Agile Software Development
for
Senior and Executive
Management
David Updike
February 2014
Agile Lean Kanban
http://www.AgileLeanKanban.com
2. About David Updike
An IT veteran since 1980’s
Agile Coach since 2008
Developer for 19 years, Architect, IT Delivery Manager,
Scrum Master and former Vice President of Agile Transformations
Member of Agile Alliance, Scrum Alliance, DFW Scrum User Group
and Agile Leadership Network
Blogger at http://www.AgileLeanKanban.com
Certified Scrum Master (CSM) since 2006
Involved in Agile Transformations at American Airlines, Southwest
Airlines, Sabre Holdings, The Broadlane Group, AT&T and others.
3. What we know
As Senior Management you don’t/didn’t pick Agile Development processes
and practices because they were new, different and have cool development
techniques
You have different objectives
•
reducing average time-to-market of software development projects
•
increasing return on investment (ROI) in information technology
•
increasing end-user effectiveness and satisfaction
•
lowering costs and risks
•
adapting to a changing business landscape
•
higher quality software products
•
and even a more satisfied work force
4. But first, how does using Agile…
utilize Schedule
Budget
and
Feature Scope
5. Traditional Development is Plan Driven
FIXED SCOPE
(features, functionality)
FIXED
TEAM, BUDGET
(costs)
FIXED
SCHEDULE
(time)
With a given team you MUST complete a set amount of Scope by a fixed
deadline. To do this a team executes Big Up Front Analysis & Design (BUF)
Historical consequences
• Inaccurate detailed early estimates & plan leading to IT Death marches at the end
• IT Death marches and meeting a set scope lead to fragile code bases / bad software
• All the above leads to attrition of unhappy valuable people with deep domain knowledge
6. Agile Development is Value Driven
FIXED
TEAM, BUDGET
(costs)
FIXED
SCHEDULE
(time)
VARIABLE SCOPE
(features, functionality)
A given team uses “just enough, just in time” evolutionary design to deliver
the highest value functionality with the best quality by the set date.
Differences
• The Business (via Product Owner) decides on most valuable features for each Iteration
• The team proceeds at best possible speed given a very high quality bar
• We deliver on time and on budget every time with the most valuable features
7. What is often heard…
“But we must have ALL of our desired features.”
Do we?
8. Standish Group Study on Used Features
Features and Functions Used in a Typical System
Lesser
Value
Greater
Value
If you really want these
features that’s OK,
However they probably don’t
all need to be in Release 1
Maxim: Our customers don’t use everything we put in front of them equally.
9. What is ISN’T often heard IS…
“When will the product have enough capability to
release it to our customers.”
Instead we wait for implemented scope
which increases time-to-market
10. How does using Agile…
reduce Time-to-Market
and
increase Return on Investment
11. Reducing Time-to-Market and increasing ROI with Agile
12 months
Month 1
Month 2
Month 3
Month 4
Month 5
Month 6
Month 7
Month 8
Month 9
Month
10
Month
11
Month
12
VVV
$$$
VVV
$$$
VVV
$$$
VVV
$$$
VVV
$$$
VVV
$$$
Normal Traditional Development
One Release, 9 months of development
= 9$ or V
Agile Development
Release 1 3 months MVP
V
$
V
$
Release 2
Reduced
Time to
Market
Increased
ROI
V
$
3 months
Use real customer
feedback from
Release 1
improve Release
2 product.
VV
$$
VV
$$
Release 3
VV
$$
3 months
= 18$ or V
Use real customer
feedback from
Release 2
improves Release
3 product.
Same 9 months of development makes 9 more $ or Value units for
the company (and maybe more than that with a better product)
V = a unit of Value
$ = a financial unit
MVP = Minimum Viable Product
12. Agile Development involves incremental delivery
Agile Development
Scrum Methodology Example
Release X
Release
Planning
Defined
Release
Features
2 weeks
2 weeks
2 weeks
2 weeks
2 weeks
2 weeks
1
day
DEPLOY
1
day
1
day
1
day
1
day
1
day
An option could exist allowing you to
go to Production part way through a
Release.
D
E
M
O
D
E
M
O
2 Week Iterations
with
Short Daily
Planning Meetings
D
E
M
O
D
E
M
O
D
E
M
O
Release
Features
Complete
Next
Release
Planning
Undeveloped
Feature
Developed
Feature
13. One method using the Standish Group Studies
An E x a m p l e
F e a t u r e s a n d F u n c t i o n s U s e d i n a Typ i c a l S ys t e m
Identify these
as your
Release 2
Identify these
as your
Release 1
(True Minimum
Viable Product)
Identify these
as your
Release 3
Identify these
as your
Release 4
14. Comparing the serial and incremental
approaches to development
Comparing the financial
risk of a serial approach to
development with an
incremental approach (the
numbers are relative).
Scott Ambler
http://en.wikipedia.org/wiki/Scott_Ambler
http://www.agilemodeling.com/essays/examiningBRUF.htm
15. How does Agile use this to…
increase end user effectiveness
and
satisfaction
16. Lightweight planning
allows the team and
stakeholders to start seeing
working software sooner
and improvements are
made based on this data.
Short feedback loops like
this allow the team to
improve software quicker.
17. Business and IT work together
throughout the project.
Changes are proposed based on visible
working software that benefit a specific
end user.
The project flexes to accommodate the
changes based on prioritization of the
Business (Product Owner) ensuring
development principles are not
sacrificed.
18. Quick Feedback Loops, periodic
Demonstrations as well as Team
Retrospectives allow improvements
to be made to the product and
process during development.
Feedback comes from…
The Product Owner
The Delivery Team
Product Stakeholders
Real Users/Customers
Usability studies
19. Allowing flexibility and changes to
the functionality under construction
allows the team to improve the
experience of the end user which
increases their effectiveness and
their satisfaction.
20. How are changes incorporated
1) In Release Planning they fill the Release
with what they think can be accomplished.
2) Throughout the Release changes are
proposed to and by the Business Product
Owner.
3) It is the Product Owner’s responsibility to
weigh the changes and if they are
important enough they add it to the
Release while they take out (or lower the
priority of) something of equal size.
22. Saving costs by not implementing what won’t be used
Features and Functions Used in a Typical System
You probably
don’t need
these
features.
23. Face-to-face collaboration
and close cross team
communication reduce
risks of miscommunication.
Where co-located face-to-face collaboration is not possible,
as in distributed environments, teams use other practices to
overcome this obstacle.
24. Early focus on risky areas of the
Product (functional and technical)
enable the team to mitigate these
risks early instead of late in product
development which could jeopardize
production implementations dates.
Also, frequent demonstrations of
working software exposes risks forcing
them to be handled.
25. An underpinning of Agile is
transparency. Incremental
progress is highly visible by
everyone through
demonstrations of the growing
software as well as charts and
metrics thus allows better project
governance.
26. The Defect Cost Curve shows agile techniques
are less costly than traditional techniques
Mapping the potential costs of
addressing defects found by
various detection techniques
(the agile techniques are in
green, the traditional
techniques are in red).
Scott Ambler
http://en.wikipedia.org/wiki/Scott_Ambler
http://www.agilemodeling.com/essays/examiningBRUF.htm
28. Agile IT Teams define what the delivery of
Quality means before beginning a project
and call themselves out if this level is not
maintained. The teams deliver software
that this pace can support.
All features are developed to this Quality
definition (usually called a Definition of Done).
Example:
All code is checked in and code reviewed.
Code will be covered by 70% automated unit tests.
All Test Cases pass (automated where possible).
All Performance Tests pass.
All Acceptance Criteria are met.
All code meets Coding Standards & Conventions.
No Critical, High or Medium Defects exist.
Functional Test Cases are fully tested by QA (automated).
29. How does Agile allow business to…
adapt to a changing business
landscape
30. Create the Product your customers need, not
just the one that was planned at the beginning
As you see the software being created you
should be able to change your plan so that a
better product is created. The lighter the
planning method and processes the quicker
changes can be made and waste is reduced.
Your competitors don’t just sit there waiting for
you to deploy new software. You have to
have to ability to quickly adapt to a changing
marketplace.
31. Change the future plan as needed
With IT Teams focused on delivering
software to a defined high quality bar,
the business has the flexibility to
change future high-level requirements
to meet the needs of a changing
business climate.
32. Allowing changes to the Backlog of functionality
Agile Development
Release X
Release
Planning
Defined
Release
Features
2 weeks
2 weeks
2 weeks
2 weeks
2 weeks
2 weeks
1
day
DEPLOY
1
day
1
day
1
day
Change
Backlog
as
needed
Change
Backlog
as
needed
Change
Backlog
as
needed
Change
Backlog
as
needed
D
E
M
O
Release
Features
Complete
2 Week Iterations
with
Short Daily
Planning Meetings
D
E
M
O
D
E
M
O
D
E
M
O
D
E
M
O
1
day
1
day
Next
Release
Planning
Can change
future Stories
in the Backlog
Undeveloped
Feature
Developed
Feature
From Scott Ambler: Until you understand what motivates senior management, you have no chance of presenting a convincing pitch to them.http://www.drdobbs.com/architecture-and-design/pitching-agile-to-senior-management/199300107?pgno=2
No problem with freezing the Date!
No problem with freezing the Date!
No problem with freezing the Date!
No problem with freezing the Date!
From Scott Ambler: http://www.drdobbs.com/architecture-and-design/pitching-agile-to-senior-management/199300107?pgno=2
No problem with freezing the Date!
From Scott Ambler: http://www.drdobbs.com/architecture-and-design/pitching-agile-to-senior-management/199300107?pgno=2 Also see www.ambysoft.com/essays/whyAgileWorksFeedback.html