Agile for Executives

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

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

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

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.

Smoothing the productivity curve Productive Output Time Agile Waterfall Agile = steady, predictable pace of productivity Waterfall = “death marches” followed by lulls

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

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

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.

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.

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

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

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.

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


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.