2. Context Driven Agile Leadership Managing Complexity and Uncertainty Todd Little Sr. Development Manager

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

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

5. Landmark sells shrink wrap software for Oil and Gas Exploration and Production Users are Geoscientists and Engineers Subsidiary of Halliburton Energy Services Integrated suite of ~60 Products ~50 Million lines of code Some products 20+ years old 80+% of project team stays on same product Common Model Representation Well data Production data Seismic data Velocity data Reservoir / Fluid data Structural / Stratigraphic data Common Model Representation

6. Landmark wanted to understand and improve our software development process Maximize our Value Delivery Scaling to project conditions Manage Uncertainty and Complexity Organizational commonality without being overly prescriptive –Core processes –Adaptive processes –What is “barely sufficient?”

7. 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. Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas

8. Auditor Manifesto We are uncovering painful ways of auditing software teams and enjoy making others do what we tell them. Through this work we have come to value: –Processes and tools over individuals and interactions –Comprehensive documentation over working software –Contract negotiation over customer collaboration –Following a plan over responding to change That is, while there is value in the items on the right, we value the items on the left more.

9. Number of people involved Criticality (defects cause loss of...) Comfort (C) Essential money (E) Life (L) +20%... Prioritized for Legal Liability 1 - 6- 20- 40- 100- 200- 500- 1,000 C6C20C40C100C200C500C1000 D6D20D40D100D200D500D1000 E6E20E40E100E200E500E1000 L6L20L40L100L200L500L1000 Prioritized for Productivity & Tolerance Cockburn’s Crystal Methodology according to (project size, system criticality, team priorities) Discretionary money (D) Agile Sweet Spot

10. Balancing Agility and Discipline Boehm and Turner

11. Boehm and Turner Observations on Balancing Neither agile nor plan- driven methods provide a silver bullet Agile and plan-driven methods have home grounds where each clearly dominates Future developments will need both agility and discipline Some balanced methods are emerging It is better to build your method up than to tailor it down Methods are important, but potential silver bullets are more likely to be found in areas dealing with –People –Values –Communications –Expectations management

12. Agile Manifesto 5 Years Later: Dealing with the Right Processes and tools that support agility and individuals and interactions (e.g. wikis, collaboration environments, etc.) Documentation that leads to working software. A focus on 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

13. Landmark studied its project portfolio and identified several project and team attributes Project Complexity –Team size –Mission criticality –Team location –Team capacity –Domain knowledge gaps –Dependencies Uncertainty –Market Uncertainty –Technical Uncertainty –Project Duration –Dependents

14. We scored the Complexity Attributes on a scale from 1 to 10 Attribute110 Team Size1100 Mission CriticalSpeculative Safety Critical with significant exposure Team LocationSame RoomMulti-site, World Wide Team Capacity Established Team of experts New team of mostly novices Domain knowledge gaps Developers know the domain as well as expert users Developers have no idea about the domain DependenciesNo dependencies Tight Integration with several projects

15. And we scored the Uncertainty Attributes Attribute110 Market Uncertainty Known deliverable, possibly defined contractual obligation New market that is unknown and untested Technical Uncertainty Enhancements to existing architecture New technology, new architecture. May be some "R" Project Duration1-4 week24 months Dependents/ Scope Flexibility Well defined contractual obligations or Infrastructure Independent

16. We cross plotted the results and divided the chart into four quadrants

17. Refactored for Simplicity

18. This looked a lot like the Boston Matrix

19. So we named it the Houston Matrix and gave animal names to the quadrants

20. We looked at an overall process flow and how it would be adaptable. Adaptive Activities Inputs Pre- conditions Project Sanction RTM Outputs Post- conditions Released Software CORE Activities Iterations

21. We Identified a set of Core Processes for all projects to use Aggregate Product Plan A/B/C List Quality Agreement Continuous Integration Expert User Involvement Project Dashboard

22. The Aggregate Product Plan sets the high level vision and expectations Project: OpenWells DavenportProject Code: 010265 Product: OpenWellsTarget Date: 3/30/2004 Version: 2003.11.0.0Release Date: 3/31/2004 Product Manager: Marcus RidgwaySDD: David Field Vision: Version 2.0 of the new 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 8.1.7 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

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

24. A A/B/C List B C A B C D 50% 100% Backlog PlanTypical Delivery 50% 25%

25. A/B/C List

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

27. So we named it the Houston Matrix and gave animal names to the quadrants

28. Don’t throw novice project managers at a bull project

29. Brooks’ law in action: throw a developer at a late bull project

30. Project Complexity and Uncertainty influence how to scale our agile process One size doesn’t fit all The assessment tool is a guide Landmark’s portfolio balance –10% Bulls –10% Cows –20% Colts –60% Dogs

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

32. Nickoliasen Model for Idea Filter (Executive Summit ADC 2004) Market Differentiating High Low Mission Critical Low High Partner Or convert To Mission Critical Focus and Allocate Resources Who Cares? Achieve Parity

33. Products Tend to follow a Lifecycle path A B C

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

35. Business Process Value Chain Innovation Discovery of unanticipated features or other innovative ways of improving the product CCA Integration Attention to cross product integration issues CBB Development Velocity Speed of development of new product features CBA Quality Product reliability BAB Customer Responsiveness Business agility - ability to respond quickly to new customer needs CCB Predictability Focus on accuracy of release date ABB Project traceability Audit ability of project process. Traditionally very important for outsourcers. ABC Cost Importance of a low Cost structure AAC

36. Portfolio Management and Dealing with Darwin (G. Moore) Market Differentiating High Low Mission Critical Low High Invent Deploy Manage Offload Create Change Embrace Change Eliminate Change Control Change Ad HocAgile OutsourceStructured

37. Follow the Yellow Brick Road Oz never did give nothing to the tin man, that he didn’t, didn’t already have

38. Early Release of Bull Project

39. Bull Program, Dog Project

40. Don’t mistreat your cows

41. The Agile Project Leadership Network Declaration of Interdependence (www.apln.org) 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. David Anderson, Sanjiv Augustine, Christopher Avery, Alistair Cockburn, Mike Cohn, Doug DeCarlo, Donna Fitzgerald, Jim Highsmith, Ole Jepsen, Lowell Lindstrom, Todd Little, Kent McDonald, Pollyanna Pixton, Preston Smith and Robert Wysocki

42. SoftwareBeyond Software Project Leadership Project Execution Pair Programming Continuous Build TDD Collaboration Change Empowerment APLN Relationship of the APLN to the AgileAlliance

43. Interdependence and Leadership Context Uncertainty Value Customers Individuals Teams

44. Boehm and Turner Observations on Balancing Neither agile nor plan- driven methods provide a silver bullet Agile and plan-driven methods have home grounds where each clearly dominates Future developments will need both agility and discipline Some balanced methods are emerging It is better to build your method up than to tailor it down Methods are important, but potential silver bullets are more likely to be found in areas dealing with –People –Values –Communications –Expectations management

45. Security and Value (Great Boss, Dead Boss) + Tribal Security - Individual Security Civil ServicePurpose OutcastsAnarchy + Tribal Value - Individual Value      

46. Agile Leadership

47. Don’t over stereotype: e.g. Not all dogs are the same