Todd Little A Framework for Agile Leadership Stand Back and Deliver Making Ship Happen

Managing the Coming Storm Inside the Tornado When will we get the requirements? All in good time, my little pretty, all in good time But I guess it doesn't matter anyway Doesn't anybody believe me? You're a very bad man! Just give me your estimates by this afternoon No, we need something today! I already promised the customer it will be out in 6 months No, we need it sooner. Not so fast! Not so fast!... I'll have to give the matter a little thought. Go away and come back tomorrow Ok then, it will take 2 years. Team Unity Project Kickoff

We’re not in Kansas Anymore My! People come and go so quickly here! I may not come out alive, but I'm goin' in there! The Great and Powerful Oz has got matters well in hand. "Hee hee hee ha ha! Going so soon? I wouldn't hear of it! Why, my little party's just beginning! Developer Hero Reorg Testing

Hurricane Rita

On Time To Spec Within Budget

Long Ago Excellent! Pharaoh will be quite pleased to learn that you’ve completed construction under budget and ahead of schedule.

Da Plan, Boss – Da Plan

Long Ago and Far, Far Away…

Long Ago and Far Away

Agile Manifesto We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:  Individuals and interactions over processes and tools  Working software over comprehensive documentation  Customer collaboration over contract negotiation  Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more.

Agile Manifesto Revisited: Dealing with the Right  Processes and tools that support agility, individuals and interactions (e.g. wikis, collaboration environments, etc.)  Documentation as a consumable rather than as a deliverable.  Contracts that are written in a manner consistent with collaboration and agile delivery  Plans that anticipate and expect change

We increase return on investment by making continuous flow of value our focus. We deliver reliable results by engaging customers in frequent interactions and shared ownership We expect uncertainty and manage for it through iterations, anticipation, and adaptation. We unleash creativity and innovation by recognizing that individuals are the ultimate source of value, and creating an environment where they can make a difference. We boost performance through group accountability for results and shared responsibility for team effectiveness. We improve effectiveness and reliability through situationally specific strategies, processes and practices. We are a community of project leaders that are highly successful at delivering results. To achieve these results:

Declaration of Independence from Bureaucratic Project Management When in the Course of project events it becomes necessary for Project Teams to dissolve the political bureaucracies which have burdened them, a decent respect to the opinions of mankind requires that they should declare the causes which impel them to the separation. We hold these truths to be self-evident, that all projects are not created equal, that they are endowed by their creation with uncertain and complex characteristics. That project teams are most effective when they value Life, Liberty and the pursuit of Happiness.

Interdependence and Leadership  Value  Customers  Uncertainty  Individuals  Teams  Context

Leadership Models Strategy Collaboration Delivery Cultivate Innovation Embrace Change Decisions Real Options

 Blatant waste of time that Todd thinks is funny  Context and Uncertainty  Finale Agenda

It Depends  Uncertainty: We expect uncertainty and manage for it through iterations, anticipation, and adaptation.  Context: We improve effectiveness and reliability through situationally specific strategies, processes and practices.

Hurricane Rita

Uncertainty  We expect uncertainty and manage for it through iterations, anticipation and adaptation.

Project Differences Project Complexity Uncertainty Dogs Cows BullsColts

Project Differences Project Complexity Uncertainty Simple, young projects. Need agility Tight Teams Dogs Complex, mature market Need defined interfaces Cows Bulls Agility to handle uncertainty Process definition to cope with complexity laissez faire Colts Low High

Plenty of Bull

Bull Product Release

Reduce Uncertainty or Complexity UncertaintyComplexity Opportunities to Reduce Uncertainty:  Use proven technologies  Reduce project duration Opportunities to Reduce Complexity:  Collocate the team  Break project into sub-projects AttributeScore Market███ Technical███ # Customers█████████ Duration█████████ Change███ AttributeScore Team Size█████████ Mission Critical█████████ Team Location█████████ Team Maturity███ Domain Gaps███ Dependencies█████████

Partitioning Dog Project Cow Project Colt Project Bull Program Remember: Loose Coupling and Strong Cohesion

Bull Program, Dog Project Project Complexity Uncertainty Dogs Cows BullsColts

First Integration Release Project Complexity Uncertainty New acquisitions Dogs Integration data model Cows Bulls The Integration Release Existing Products Colts Low High

Integrating Software by Integrating People Developers’ Conference Yearly PMM Quarterly Weekly Creating the Future

Y2K Release Project Complexity Uncertainty None Dogs The overall Program Cows Bulls None All Products Colts Low High

Products Lifecycle Paths A B C

Project Leadership Guide Market Differentiating High Low Mission Critical Low High Invent Manage Offload Create Change Embrace Change Eliminate Change Control Change Ad HocAgile OutsourceStructured Deploy

Portfolio Management Project Complexity Uncertainty

Leadership Development Process People Technology Business

Leadership Development Project Complexity Uncertainty Dogs Cows BullsColts Low High Business & Technology People & Process

Leadership Development PeopleProcessTechnologyBusiness Read Write Read DeleteWrite

Not all dogs are the same

 Create a place where people want to be not have to be  Make sure everyone has what they need to succeed. Great Leadership

Agile Leadership

Contact Todd Little    Stand Back and Deliver, Pixton, Nickoliasen, Little, and McDonald, published by Addison Wesley, due out in early 2009

Frameworks Model Strategy Collaboration Project Governance Business Value Embrace Change Real Options Cultivate Innovation

Your Questions? Stand Back and Deliver

Waterfall has context too!  Small Waterfalls

Waterfall has context too!  Medium

Waterfall has context too!  Face Gate

 Glacial Waterfall has context too!

 Bring in the Gurus

Penal Management Institute Now that I am a Penal Management Professional I can show them how to improve these Convicts’ Maturity Model

Business Process Value Chain Interdependence Market Product Development Sales Specifications DevelopmentDelivery Business Need DevelopmentDelivery Internal IT Product Company Contract Model

Overall process flow Adaptive Activities Inputs Pre- conditions Project Sanction RTM Outputs Post- conditions Released Software CORE Activities Iterations

Core Practices  Aggregate Product Plan  A/B/C List  Quality Agreement  Continuous Integration  Expert User Involvement  Project Dashboard

The Aggregate Product Plan sets the high level vision and expectations Project: OpenWells Davenport Project Code: Product: OpenWells Target Date: 3/30/2004 Version: Release Date: 3/31/2004 Product Manager: Marcus Ridgway SDD: David Field Vision: Version 2.0 of Well Operations reporting and data analysis application. Will bring powerful new query, graphing and reporting capabilities. Comprehensive D&WS input data and output reports will be supported including integration to Production suite. Platforms: Windows 2000 /Oracle Windows XP / Oracle 9i Windows 2000 & XP /MSDE Features: 18 additional reports Addtnl apps - Data Anlyzr, NG Profile, Autoprint Extended Rig Equipment support Knowledge Management - Technical limit drilling, lessons learned, non-productive time, and equipment failures Application enhancements (spreadsheet support and tailored well services tab and others) Strategic Fit: Integration Workflow ( Prototype, plan, actual) Top quartile technology Target Markets: Existing DIMS customers US Independents NOCs Government and regulatory organizations Companies requiring integrated offering w/decent wellbore schematic requirements Service companies

The A/B/C List sets proper expectations A MUST be completed in order to ship the product. B SHOULD be completed in order to ship the product. C MAY be completed prior to shipping the product if time allows. Only “A” features may be committed to customers. “A” features must fit in a p90 confidence schedule. No more than 50% of the planned effort can be allocated to “A” items

A A/B/C List 50%100% Backlog Plan Typical Delivery 25% AB C B C D 50% 25% Target Delivery Date

A/B/C List 50%100% Backlog Plan Uncertainty Risk 25% AB C B C D 50% 25% Target Delivery Date A

A/B/C List

We use a Quality Agreement similar to Thomsett Attribute “A” Very Important “B” Important “C” Not Very Important Completeness of Functionality X Completeness of Testing X Reliability X Performance X Installation X Usability X Integration X On Line Help X Training X

Product Innovation Flow Adaptive Activities Project Sanction RTM CORE Activities Idea Filter Hot Items A Backlog Burnup Sales Services Customer Support Product Backlog A Items Iteration Backlog Flexible Scope Backlog Newly Discovered Items Most Items for consideration in next release B & C Release Backlog B/C/D

From the home office in Duncan, Oklahoma Top Ten reasons why we are late in 2008 Dubai, UAE

10: Requirements, what Requirements? What you want, baby I got it R-E-Q-U-I-R-E Find out what it means to me Top Ten reasons why we are late in 2008

9: Dependencies on other groups that were late Top Ten reasons why we are late in 2008

8: Over-optimistic Schedule Estimation Always look on the bright side of code Always look on the bright side of code The code’s a piece of $#!^, when we look at it We can always overlook a minor kink.... It probably compiles, it might even link... Surely that must mean it doesn’t stink Top Ten reasons why we are late in 2008

7: Those weren’t MY estimates How low can you go! Scheduling Ritual Top Ten reasons why we are late in 2008

6: Not enough testers or documentation resources. Who needs them anyway? We put those bugs--I mean features-- in there on purpose. Besides, it was difficult to program, it should be difficult to use. Top Ten reasons why we are late in 2008

5: Offshore and Outsourcing issues My source code lies over the ocean, My source code lies over the sea. My source code lies over the ocean, Oh bring back my source code to me..... Bring Back, Bring Back, oh bring back my source code to me, to me Bring Back, Bring Back, oh bring back my source code to me Top Ten reasons why we are late in 2008

4: One word, Ch-ch-ch-changes Top Ten reasons why we are late in 2008

3: I can’t get no, System Admin  I can’t get no, CM action  ‘cause I try, ..and I try,  ….and I try,  ……and I try…. Top Ten reasons why we are late in 2008

2: You didn’t give me the headcount that you promised Top Ten reasons why we are late in 2008

1: Weren’t you doing the backups!? Top Ten reasons why we are late in 2008