A primer of the concepts behind "Agile" for a business audience. Developed as part of the Products Are Hard event series.

1. Agile for Executives

2. Original Agile Manifesto
Conversation & understanding > Processes & tools
Working software > Complete documentation
Stakeholder collaboration > Contract negotiation (“CYA”)
Responding to change > Sticking to a plan

3. Agile vs. Traditional Ethos
Traditional “Waterfall” Agile
Plan-driven
Focuses on documenting & predicting
outcomes
Exalts deadlines & output
Lengthens cycle times from idea to
production
Resists change
Value-driven
Focuses on understanding & executing
priorities
Exalts priorities & throughput
Shortens cycle times from idea to
production
Embraces change

4. What will (and won’t) Agile do for an organization?
Agile methods do... Agile methods don’t...
Make us more responsive to changing
market priorities
Allow better predictability of output for
the foreseeable time horizon
Improve accountability
Make priorities and risk calculations
more transparent
Make engineers write more code per
day or designers make creative output
faster
Obviate the need to make good
decisions about priorities and customer
needs
Allow the rest of the organization to
continue to assume they can know what
will be delivered in 12 months

5. Change is normalized Dynamic process for a dynamic reality
Agile methods assume priorities are
dynamic in response to changing market
conditions, resources, and ideas.
No more “scope creep”
Waterfall assumes we can know up-front
everything we want built in order to nail
down costs and timelines. When things
change it’s considered disruptive and
takes us off the plan we have been
tracking to.
!
Agile accepts that predictably hitting
long-term deadlines is not possible
without compromising scope, quality, or
cost. Agile operationalizes and
normalizes that we want to adjust to new
ideas and conditions.
Markets change quickly.
We should too.

6. Smoothing the productivity curveProductiveOutput
Time
Agile Waterfall
Agile = steady, predictable pace of productivity
Waterfall = “death marches” followed by lulls

7. Process Differences
Waterfall Process Agile Process
Flushed out “PRD” documents
Erratic handoffs and negotiations over
deadlines and scope
Hard to track on-time delivery until it’s too
late to fix
Infrequent opportunities for formal review &
improvement of process and priorities
Fosters taking shortcuts to hit looming
deadlines on large swaths of functionality
Prioritized pipeline of atomic line items
Regular rhythm of collaborative commitment
and improvement
Easy to see if we are delivering what was
promised on each cycle
Regular opportunities for formal review &
improvement of process and priorities
Encourages steady, high quality delivery of
bite-size pieces of user value

8. Shorter cycles = more chances to improve
Agile = Regular rhythm of prioritizing and optimizing
Ideation Documentation Negotiation Execution Assessment
Waterfall = Serialized hand-offs come in fits and starts

9. Risk and Value Risks are contained
Fixed, short cycle times allow
regular checkpoints to assess
priorities and process and make
changes before it’s too late.
Value trade-offs are laid bare
Explicitly prioritized, atomic line
items disambiguate the relative
costs and benefits of
prioritization decisions.

10. No more hidden black holes
of time that kill productivity
Accountable Effort Regular Cycles, Transparent Priorities
Everyone on the team knows what
everyone has promised to get done in
any given interval (typically 1-3 weeks).
Per-Cycle Surfacing of Impediments
Team members have regular rituals for
bringing to light organizational
obstacles, recurrent interruptions, and
other obstructions to focusing on the
priorities of the business.
!
Explicit Resource Allocation
Team members should understand what
percent of their time is expected to go
into the specific priorities of a given
backlog, and each team can be sized
and configured commensurate with
business value and urgency.

11. Agile Myths “Agile means no documentation or
deadlines!”
“Agile means doing small bits of
optimization on existing features instead of
working on big, new, innovative features!”
“Agile means we won’t have sound
architecture and engineering practices!”
“Agile means we won’t be able to plan our
product releases or marketing campaigns!”
“Agile alleviates the need for product &
engineering leadership!”
“Agile makes us faster!”

12. Many Agile idioms evoke the
wrong things, particularly when
you think you’re getting “Faster”
rather than “Responsive” and
“Predictable”
Beware of Agile jargon “Sprint”
Implies: going as fast as you possibly can
for a short distance.
!
What you want: regularized, repeatable
intervals for assessing priorities and
making delivery promises.
!
Alternatives: Set; Interval; Cycle; Period
“Velocity”
Implies: you can measure how fast the
team is and give incentives for everyone
go faster.
!
What you want: a way to make good
predictions about what can be
accomplished in each interval on a regular
rhythm.
!
Alternatives: Capacity; Load Factor

13. Challenges of Agile Forest for the trees
Agile “story” pipelines are designed
to be quite granular and can be
hard to digest as a whole if you’re
not immersed in the team. Agile
product managers may need to
communicate the big picture
separately.
Product roadmaps
We wish we could prescribe what
needs to be launched within 12
months, but we rarely can. Agile
roadmaps emphasize priorities over
deadlines and are updated
frequently. The farther out we look
the more uncertain and abstract are
the goals.

14. (continued)
Challenges of Agile Continuous Accountability
Teams used to operating as a black
box can develop work habits that
are uncomfortable to change in an
Agile environment.
!
Executive Expectations
Outside the team the temptation is
to assume “going Agile” will have
magical effects on how much we
produce on any given day. Others
may also think the team can be
interrupted from their flow because
they are Agile.
!
Optimizing the Wrong Things
For instance, resist the urge to
increase velocity through incentives
to chew through more story points.

15. Engaging Agile Teams Respect Their Rhythms
Agile teams must be allowed to
keep their cadence absent an
emergency. Ask them when in their
cycle is best to engage.
!
Review the Backlog & Attend Demos
A well-functioning Agile team will
have laid out foreseeable priorities
clearly and will show what they have
accomplished in each interval.
!
Advocate to the Product Owner
Agile teams usually have one
person who owns prioritization.
Working with that person to
develop stories for your priorities is
key.