What’s Hard about Agile? November, 2006

1. What’s Hard about Agile? November, 2006

2. Who are we? • Key • 1000+ branches • $90B assets • 20,000 associates across 14 states and Europe • Key Technology Services • 1500 associates across 2 major domestic development centers and 3 offshore centers • Enterprise Technology Development • $140M development budget • 1000 developers • 800+ apps (20% mainframe/80% distributed) • Near 100% “debt”

3. Specific Challenges to Key • Because we’re a bank • Much of our competitive advantage comes from time to market on software • Security, Reliability, Accuracy are pretty important • Because we have many businesses • We’re attempting to move culture across many diverse groups • Because we’re regulated • We still need to comply with the rules established by FBR, OCC, SEC, etc.

4. Where we were • Punish failures as opposed to rewarding successes • Command/Control culture • Strong centralized PMO • Waterfall RUP • CMM 3’ish • Specialized skills/buy shop • Highly matrixed organization • Functional requirements • “Ball over the wall” mentality • Focus on business cases  ‘commitments’ • Commitments  ‘analysis paralysis’

5. Key’s approach • Introduce the concepts to the entire organization • Sell the idea to clients first • Change success criteria to making customers happy by accelerating business value • Get to the strategy table • Look for leverage, not incremental value • People over process – software development is not a technology problem • Coach, don’t train • No rollouts; “inside out” implementation • Let teams make the decisions • Discourage the “obedient” mind set • Focus on effectiveness, not efficiency

6. What we did • Disband the PMO and eliminate time cards • Eliminate the centralized testing team - Holding teams accountable for their own quality • Externally train (CSM) a few folks to be coaches - Provide Internal Coaching and Training (Jumpstarts, Overviews and Scrum Master) • Create agile enablement teams –reduce systemic overhead • Build Team Space • Work with “dock” teams • Train and coach Product owners • Host internal discussion groups • Created sandbox environments and ‘try without penalty’ policy • Mainframe teams incorporating scrum practices • Get external help (practices, coaching)

7. Agile is a big change • Management will resist • Clients are skeptical • Some like “throwing things over the wall” • Some don’t want to commit the time and effort • Some like the “Project Commitment” model • Getting to dedicated teams is hard • “30 Day Waterfalls” are hard to avoid • Vertical development is counter-intuitive • Getting to “generalists” is hard • Team accountability is new and difficult for many • Tested, documented, working code in 30 days is a difficult discipline

8. Things we should have done earlier • Train managers to support teams • Recognized that the first team is easy • Make it clear that we expect technical leadership • Thought about the problem where clients want waterfall, or just don’t ‘do’ projects • Included teamwork training from the outset • Put disciplines in place for multi-team projects