Agile Project Management Dr Rajiv Kishore Associate Professor

Agile Project Management Dr. Rajiv Kishore, Associate Professor, UB School of Management; (716) 645 -3507; rkishore@buffalo. edu Project Management Institute Buffalo Chapter; March 14, 2006 Agile Project Management

Agenda • The Mistakes We Continue to Make! • Agile Philosophy and Principles • Jim Highsmith’s Agile Project Management (APM) Model • Some Prominent Agile Methods • Agile Success Stories • Issues and Challenges • Discussion March 14, 2006 Agile Project Management 2

IT Project Success Rates Failed 15% Successful 34% Success Factors: 1. On-time 2. Within budget 3. Needs Met Challenged 51% (2004 Standish Group International, Inc. Data (http: //www. softwaremag. com/L. cfm? Doc=newsletter/2004 -01 -15/Standish) March 14, 2006 Agile Project Management 3

The Complete Software Systems Life Cycle Project Phase Post-Project Use Phase Software Systems Development Software Systems Use Post-Project Failures The generally talked about category of system failures March 14, 2006 Agile Project Management But the roots for these system failures lie in the project phase 4

Post-Project Failures • Digital Equipment Corporation (1980 s) – The Classic XCON System Failure; sales people resented using the expert application system for configuring clientordered computer systems » Usefulness and ease of use: field study evidence regarding task considerations, Mark Keil, Peggy M. Beranek and Benn R. Konsynski, Decision Support Systems, Volume 13, Issue 1, January 1995, Pages 75 -91 • Providian Trust (1995) – Implementation of Access Plus, a Trust and Custody Management Software, fails during implementation and use; massive resistance by Personal Trust Managers » http: //www. hbsp. harvard. edu/b 01/en/search. Results. jh tml? Ntx=mode%2 Bmatchallpartial&Ntt=providian&N=0&Ntk= main_search March 14, 2006 Agile Project Management 5

Post-Project Failures (contd. ) • Foremostco (2000) – Inventory and Logistics system failures during use seriously affect logistics and inventory management of perishable plant and nursery inventory » http: //www. hbsp. harvard. edu/b 01/en/search. Re sults. jhtml? sid=AKL 24 WNI 0 PYCQAKRG 5 DCELQBKE 12 GISW&Ntx=mode%2 Bmatchallpartial&Ntt=foremost co&N=0&Ntk=main_search • AT&T Wireless (2003) – Botched CRM system upgrade, system crashes during customer number porting » http: //www. cio. com/archive/041504/wireless. html March 14, 2006 Agile Project Management 6

Post-Project Failures (contd. ) • Global Telecom Company (2005) – Perfect technological implementation of CRM system, but system misaligned with users’ needs and goals; system “misused” and “gamed” by the salespeople and failed » http: //www. cio. com/archive/071505/leadership. ht ml • . . . March 14, 2006 Agile Project Management 7

WHY? March 14, 2006 Agile Project Management 8

IT Project Failures: Top Project Risk Factors (From Keil et al. , CACM, November 1998) March 14, 2006 Agile Project Management 9

The Risk Categorization Framework (From Keil et al. , CACM, November 1998) March 14, 2006 Agile Project Management 10

Quadrant 1: Customer Mandate • High perceived relative importance • Low perceived level of control • Risk Factors – Lack of top management commitment – Failure to gain user commitment – Lack of adequate user involvement – Failure to manage end user expectations March 14, 2006 Agile Project Management 11

Quadrant 1: Risk Mitigation Strategies • Create and maintain good relationships with customers • Promote customer commitment to the project • Establish and maintain relationships with customers and senior management • Build trust with users by meeting commitments • Solid political skills March 14, 2006 Agile Project Management 12

Quadrant 2: Scope and Requirements • High perceived relative importance • High perceived level of control • Risk Factors – Misunderstanding the requirements March 14, 2006 Agile Project Management 13

Quadrant 2: Risk Mitigation Strategies • Manage ambiguity and change; specify what will not be included in the project • Distinguish between desirable and necessary functionality • Ensure that the project is driven by users and not the developers March 14, 2006 Agile Project Management 14

A New Solution: Agile Methods March 14, 2006 Agile Project Management 15

Fundamental Goals in the Agile Movement • Delivering innovative products to customers, particularly in highly uncertain situations • Creating working environments in which people look forward to coming to work each day March 14, 2006 Agile Project Management 16

The Agile Manifesto • “We are uncovering better ways of developing products by doing it and helping others do it. Through this work we have come to value: – – Individuals and interactions over processes and tools Working products over comprehensive documentation Customer collaboration over contract negotiations Responding to change over following a plan • That is while there is value in the items on the right, we value items on the left more” » http: //agilemanifesto. org/ March 14, 2006 Agile Project Management 17

Individuals and Interactions • It is ultimately unique, talented, and skilled individuals – individually and collectively – that build new products and services • Processes provide guidance and support and tools improve efficiency; however, they cannot replace people who develop products • No process – not even the most rigorously defined and followed process – can make up for mediocre individual capabilities March 14, 2006 Agile Project Management 18

Working Products • Large, front-loaded projects prone to failure because their teams proceed in a linear fashion without reliable feedback from customers • Requirements document verifies that a team has successfully gathered a set of requirements • Delivering a set of working product verifies that the development team can actually deliver something tangible to the customer • Agile methods stress the delivery of versions of actual products – Working features provide dependable feedback that requirements documents cannot March 14, 2006 Agile Project Management 19

Customer Collaboration • In highly volatile, ambiguous, and uncertain NPD efforts, a collaborative customerdeveloper relationship is key to success • Customers define value – they are the ones who use the products either for end use or to create further business value • Don’t confuse customers with other stakeholders (e. g. , project sponsors, regulatory agencies, etc. ); they define constraints whereas customers define value March 14, 2006 Agile Project Management 20

Responding to Change • This is characterized by – Envision-Explore versus Plan-Do – Exploration versus Production – Adapting versus Anticipating • Many IT projects turn into disasters because companies adopt the mantra “Plan the Work and Work the Plan” March 14, 2006 Agile Project Management 21

The Agile Manifesto Reexamined March 14, 2006 Agile Project Management 22

The Evolution of Methodologies • All methodologies are based on beliefs about what is at the organizational core • In the 1970 s and 80 s, it was Process – so Process-oriented methodologies • In the 1980 s and early 90 s, it was Data and Information – so Information Engineering type methodologies • In the 1990 s, the core became Objects that encapsulate both data and processes – so object-oriented methodologies • In the late 1990 s and 2000 s? • People – this is arguably the most important organizational asset and truly at the core of any organization! - Enter Agile Methods!! March 14, 2006 Agile Project Management 23

The Evolution of Methodologies (contd. ) • Many companies in India have been very quick to reach CMM level 5 – WHY? – Smart, innovative, talented, and determined people can achieve almost any results • Other methods (e. g. , Mib. ML) that focus on people, their roles, their interactions, and their knowledge, etc. are also being developed and tested – Enterprise integration using the agent paradigm: foundations of multi-agent-based integrative business information systems; by Rajiv Kishore, Hong Zhang and R. Ramesh, Decision Support Systems (forthcoming) – Mib. ML: A Conceptual Modeling Grammar for Integrative Business Information Systems Using the Agent Metaphor; by Hong Zhang, Rajiv Kishore, Raj Sharman, and Ramesh, under journal review March 14, 2006 Agile Project Management 24

Moving from Anticipation to Adaptation • Traditional product development methods are based on a process of anticipation – Define – Design – Build • Agile methods are based on a process of adaptation – Envision – Explore – Adapt • Very similar to the biological evolution process – Experimentation (mutation and recombination) – Exploration (survival of the fittest) – Refinement (producing more of the survivors) March 14, 2006 Agile Project Management 25

Anticipation versus Adaptation • Anticipatory (or Newtonian) approaches aim to produce predictable results – The CMM model is built on this approach – The issue: predictable result may not be an innovative emergent result • Adaptive approaches (based on Complex Adaptive Systems theory) create emergent results that are innovative – Agile methods are built on this approach – One of the overarching goal of agile methods is to deliver innovative products that deliver outstanding customer value both today and tomorrow – creating innovation is creating something new that we can’t fully anticipate; it is an emergent result based on a vision March 14, 2006 Agile Project Management 26

Why the Pressure for Adaptation? • Supply Push – Falling costs of experimentation – New tools and technologies available that can enable implementing the agile principles • Demand Pull – Need for innovative products – Need to deliver what customers want at the time of shipment, which is usually not the same as what the development team “guessed” during planning March 14, 2006 Agile Project Management 27

Agile Principles March 14, 2006 Agile Project Management 28

Agile Guiding Principles Deliver Customer Value Champion Technical Excellence Employ Iterative Feature Delivery Product Delivery From Jim Highsmith, Agile Project Management: Creating Innovative Products, Addison-Wesley, 2004 Leadership-Collaboration Build Adaptive Teams Simplify Encourage Exploration March 14, 2006 Agile Project Management 29

Deliver Customer Value • Meet customer expectations – Remember expectations are not the same as requirements; requirements are tangible, expectations are intangible • Delivery rather than plan/control/compliance – Control focuses on fixing mistakes and explaining discrepancies when plans are viewed as correct • But are plans correct? Can innovation be planned? – Compliance-biased models produce reports for managers, accountants, government agencies, legal departments, etc. , and delivery of results falls to second place – Agile methods perform “just necessary” compliance March 14, 2006 Agile Project Management 30

Employ Iterative, Feature-Based Delivery • Iterative development – Build a partial version of a product and then expand that version through successive timeboxes followed by reviews and adaptation – Timeboxes force closure, they force the team to make something concrete • Feature-based delivery – Customers don’t really care about tasks that are to be performed or are completed; they understand care about the features that will be developed and delivered – They are forced to focus on tasks (behavioral control) rather than on product features (outcome-based control) in the absence of feature-based delivery – Feature-based delivery also induces double-loop learning – It also results in progressive risk reduction March 14, 2006 Agile Project Management 31

Champion Technical Excellence • Project managers must be champions of technical excellence • If the core purpose of agile methods is to create innovative products, and if competent individuals are a key part of delivering those products, then it is impossible to support a principle that advocates technical mediocrity March 14, 2006 Agile Project Management 32

Leadership – Collaboration Management • You cannot manage men into battle: You manage things, you lead people » Admiral Grace Hopper • Management deals with complexity, leadership deals with change • Project managers have to be both – managers and leaders March 14, 2006 Agile Project Management 33

Encourage Exploration • Exploration is difficult, it causes FUD • Create a safe environment in which people can voice outlandish ideas, some of which may be off the wall but some may turn out to be not so outlandish after all • Encouragement isn’t enough: Put your money where your mouth is: – 3 M has a policy to give researchers a percentage of company time to investigate ideas of their own – Google gives 10% of company time for explorating new ideas March 14, 2006 Agile Project Management 34

Build Adaptive (Self-Organizing, Self-Disciplined) Teams • In a self-organizing team, individuals – take responsibility for managing their own workload – shift work among themselves based on need and best fit, and – participate in team decision making • Self-organizing teams are not necessarily selfdirecting teams • Self-organizing requires and breeds self-responsibility – this minimizes control overhead because instead of using process-based controls, individuals are using self-control • Self-organizing means you need people who possess a high degree of self-discipline to begin with March 14, 2006 Agile Project Management 35

Simplify • Simplify the rules and let individual intelligence and initiative prevail! • The epitome of simple rules is in Nordstrom’s employee handbook – a 5’x 8’ index card that outlines Nordstrom’s goal of providing outstanding customer service and lists the company rules – “Rule #1: Use your good judgment in all situations. There will be no additional rules” (Collins and Porras 1994) • Simple rules can lead to complex behaviors such as innovation and creativity – Simple rules force social interaction among team members to coordinate, resolve problems, and generate new solutions – Intellectual capital (knowledge and innovation) is generated through social capital (social interactions) March 14, 2006 Agile Project Management 36

Jim Highsmith’s Agile Project Management Model March 14, 2006 Agile Project Management 37

The APM Process Framework Envision Release Plan Speculate Adaptive Action Explore Completed Features Adapt Feature List Final Product March 14, 2006 Agile Project Management Close 38

Envision • Determine the product vision and project scope, the project community, and how the team will work together March 14, 2006 Agile Project Management 39

Speculate • Develop a feature-based release, milestone, and iteration plan to deliver on the vision • Speculating is not reckless risk taking; it is to conjecture something based on incomplete facts or information March 14, 2006 Agile Project Management 40

Explore • Deliver tested features in a short timeframe, constantly seeking to reduce the risk and uncertainty of the project March 14, 2006 Agile Project Management 41

Adapt • Review the delivered results, the current situation, and the team’s performance, and adapt as necessary • This is not control and correction; they imply one of two things – initial plans were wrong and they need to be corrected; or – initial plans were correct but execution was wrong and that needs to be corrected • Adapt implies modifications or changes to cope with uncertainties that are inherent in innovation March 14, 2006 Agile Project Management 42

Close • Conclude the project, pass along key learnings, and celebrate! March 14, 2006 Agile Project Management 43

APM Keywords • Envision, not initiate, to indicate the criticality of vision • Speculate replaces plan because plans indicate relative certainty and prediction • Explore, not manage • Learning emphasized through explore and adapt March 14, 2006 Agile Project Management 44

1) Envision Practices • Product Vision – Product vision box and elevator test statement – Product architecture and guiding principles • Project Scope (Objectives and Constraints) – Project Data Sheet • Project Community – Get the right people – Participant identification – Customer team-developer interface • Approach – Process/Practice tailoring March 14, 2006 Agile Project Management 45

Practice: Product Vision Box March 14, 2006 Agile Project Management 46

Practice: Elevator Test Statement • 2 -3 lines about your product that you can tell anyone, especially senior executives, while traveling with them in the elevator; should have – – Target customer Need or opportunity The product in brief (name, category) Key benefit to the customer, compelling reason to buy – Unlike existing products (what is unlike) – Our product (statement of primary differentiation) – Competitive advantage for you March 14, 2006 Agile Project Management 47

Practice: Product Architecture • Feature Breakdown Structure • Will help you identify platforms, components, interfaces, module elements March 14, 2006 Agile Project Management 48

Practice: Guiding Principles (GPs) • GPs are not measurable requirements or constraints but conceptual guides • Not vague either • User friendly! What does that mean? • A GP will state “The target user for this medical device, an entry level medical technician, should be able to use the basic features of the product with minimal training” March 14, 2006 Agile Project Management 49

Practice: Project Data Sheet • May include – – – Clients/Customers Project Manager Product Manager Project Objective Statement (scope, schedule, and resource info) Tradeoff Matrix (for scope, schedule, cost, resources, . . . ) Exploration factor – a measure of the uncertainty of the project Delay cost Features Client benefits Performance/quality attributes Architecture Issues/risks March 14, 2006 Agile Project Management 50

Practice: Get the Right People • Getting the right people is THE CSF • Get the best people – As per Boehm, the top 20% people produce about 50% of the output • Right people – Capability – Self discipline – this comes from internal motivation, not external mandates and control March 14, 2006 Agile Project Management 51

Practice: Participant Identification • Identify all project participants • Some participants include: – – – – – Executive sponsor Project manager Product manager Lead engineer Management Customer team Project team Suppliers Government March 14, 2006 Agile Project Management 52

Practice: Customer Team. Developer Interface Product Manager Project Manager Product Vision Feature ID Customers Feature Priority Requirements Conversation Developers Acceptance March 14, 2006 Agile Project Management 53

Practice: Process and Practices Tailoring • Defines the approach the team members will take in working together • Self-Organization Strategy, not command control; need to decide – Collaboration with customers – Collaboration between feature teams – Collaboration between geographically dispersed teams – Roles and responsibilities • Process Framework tailoring • Practice selection and tailoring March 14, 2006 Agile Project Management 54

2) Speculate Practices • Feature Breakdown List – Product Feature List (enhanced, refined from the Envision phase) – Feature Cards – Performance Requirements Cards • Release Planning – Release, Milestone, Iteration Plan • Iteration 0 • Project Risk Analysis • Next Iteration Plan March 14, 2006 Agile Project Management 55

Practice: Product Feature List • A feature is generally defined as a piece of a product that delivers some useful and valuable functionality to a customer • A feature list provides a comprehensive list of all product features March 14, 2006 Agile Project Management 56

Practice: Feature Cards • Medium to gather basic information about features, record high-level requirements, and develop work estimates – – – Feature identifier and name Feature description Feature type (Customer domain, technology domain) Estimated work effort for delivering that feature Requirements uncertainty (erratic, fluctuating, routine, static); an “exploration factor” for a specific feature – Feature dependencies – Acceptance tests March 14, 2006 Agile Project Management 57

Practice: Performance Requirement Cards • Document key operations and performance requirements of the product to be built – Performance id – Performance name – Performance description – Difficulty in achieving (H, M, L) – Acceptance tests March 14, 2006 Agile Project Management 58

Practice: Release, Milestone, and Iteration Plan • Presents a roadmap of how the project team intends to achieve the product vision within the project scope and constraints defined in the project data sheet • Release Plan – Features on rows, Iterations on columns, cells are days or weeks of effort • Iteration Plan – Can be shown as a feature card whiteboard layout March 14, 2006 Agile Project Management 59

Three Types of Iteration Plans • A complete plan with features assigned to every iteration • A two-iteration plan utilizing only a next iteration and then everything thereafter • An iteration by iteration plan (for highest exploration factor projects) March 14, 2006 Agile Project Management 60

Risk Analysis and Mitigation • Mountain climbers take risks • Mountain climbers who get into the most trouble are those who don’t understand the risks! • APM techniques help mitigate various kinds of risks; e. g. , schedule risk is mitigated by – Heavy team involvement in planning and estimating – Early feedback on delivery velocity – Constant pressure to balance the number and depth of features with schedule constraints – Close interactions between engineering and customer teams – Early error detection/correction to keep a clean working product March 14, 2006 Agile Project Management 61

3) Explore Practices • The essence of an agile project manager’s role is not creating Gantt charts or status reports (although doing that remains a part of her job); it is creating a high-performance exploration team from a group of individuals • Exploration involves risk-taking • Managers should promote a risk-taking culture by making risk-taking less risky! (e. g. , no penalties for failures) March 14, 2006 Agile Project Management 62

Practices • Deliver on Vision and Objectives – Workload management • Technical Practices – Low-cost change • Project Community – Coaching and team development – Daily team integration meetings – Participatory decision making – Daily interactions with the customer team March 14, 2006 Agile Project Management 63

Practice: Workload Management • To the extent possible, team members should manage their own workload • Each individual and team as a whole are accountable to deliver the results they have committed to in the iteration plan • Coaching may be necessary when a team is implementing a new practice or a new technology • PM needs to monitor without micro-managing, primarily by establishing and monitoring performance goals (features, quality targets, required practices) rather than tasks March 14, 2006 Agile Project Management 64

Practice: Low Cost Change • “When product development and support teams gives lip service to technical excellence, when project and product managers push teams beyond quickness into “hurrying, ” a technical debt is created” (Highsmith, 2004) • Four techniques overcome technical debt – – Simple design – valuing adapting over anticipating Frequent integration Ruthless testing Opportunistic refactoring – updating a product’s internal components whenever needed (improving the design), without changing externally visible functionality March 14, 2006 Agile Project Management 65

Practice: Coaching and Team Development • Helping the team members continuously improve their domain knowledge (technical, business), selfdiscipline, and “teaming” skills • Six key building blocks of coaching and team development are – Focusing the team on delivering results – Molding a group of individuals into a team – developing trust among them – Developing each individual’s capabilities – Providing the team with required resources and removing roadblocks – Coaching the customers – Orchestrating the team’s rhythm March 14, 2006 Agile Project Management 66

Practice: Daily Team Integration Meetings • • • Coordinate team member activities on a daily basis Meetings are held at the same time and place every day Meetings last less than 30 minutes – target 15 minutes All core team members attend all meetings Product and project managers attend as peer participants, not to gather status Other managers usually do not attend these meetings, and if they do, they are observers, not participants A team member or the PM facilitates the meetings Meetings are used to raise issues and obstacles but not to pursue solutions Each participant is encouraged to address three questions: – What did you do yesterday? – What are you planning to do today? – What impediments are in the way? March 14, 2006 Agile Project Management 67

Practice: Participatory Decision Making • At GE/Durham (jet engine plant), every decision is either an A decision, a B decision, or a C decision – A made by manager – B made by manager but with input from affected people – C made by consensus by people directly involved and after great discussion – The plant manager makes only about 10 -12 A decisions in a year! • Participatory decision making (every one participates) is different from consensus decision making – Consensus does not mean unanimous, it means preponderance of agreement March 14, 2006 Agile Project Management 68

Participative Decision Making • Win-win decisions • The Diverge-Groan-Converge framework of participative decision making – Somewhat similar to the notion of forming, storming, norming, performing • Decision Gradient – – – In favor OK, but with reservations Mixed feelings Not in favor, but will commit Veto • Intel’s PDM – “disagree and commit” is a common used phrase March 14, 2006 Agile Project Management 69

Practice: Daily Interaction with the Customer Team • Ensure that the development efforts stay on track to meet the needs and expectations of the customer • Feedback is critical to exploration because, without it, experiments veer off into costly and unproductive directions • Being the customer on an Agile project is not a fulltime job • When exploration factor is high, this is absolutely crucial • Not only customers, interactions with all stakeholders is necessary to obtain resources and ensure support March 14, 2006 Agile Project Management 70

4) Adapt Practices • Plans are hypotheses about the future, feedback provides a test of the hypotheses – So frequent and reality-based feedback is necessary • APM can save money because failing projects can be terminated early – Provided you face the reality early! March 14, 2006 Agile Project Management 71

Three Key Questions • Are customers getting value from the project? • Is the project progressing satisfactorily? • Is the project team adapting effectively to changes imposed by management, customers, or technology? March 14, 2006 Agile Project Management 72

Practice: Review and Adaptive Action • Reviews done to ensure that frequent feedback and high levels of learning occur in multiple project dimensions • Reviews provide a break from the fast-paced and intense activity period during iterations • Evaluate and make adaptations in the following four areas: – Product functionality, primarily from customer team’s perspective – Product quality, primarily from the technical team’s perspective – Team performance – Project status March 14, 2006 Agile Project Management 73

Customer Focus Groups • Demonstrate ongoing versions of the product to the customer in order to get periodic feedback on who well the product meets customer needs and expectations • Like acceptance testing • Schedule early in the beginning of the project to ensure right customers are available • Change requests are generated and recorded here • A wider customer audience is involved in this (e. g. , 10 -12 people compared to two who may be involved in the iteration) • Typically two to four hours but can be more depending upon the product March 14, 2006 Agile Project Management 74

Technical Reviews • Keeping cost of the project low through technical excellence • Poorly designed, poor-quality, defect-prone products are expensive to change and therefore inflexible to customer change requests • Periodic technical reviews, both informal and regularly scheduled, provide the project team with feedback on technical problems, design issues, and architectural flaws • Should be simple, barely sufficient, minimal documentation, short sessions, lots of interaction March 14, 2006 Agile Project Management 75

Team Performance Evaluation • Team members self-organize • Team members self-discipline themselves, i. e. , operate within the framework they themselves decide • Team performance evaluation touches on these two points • Evaluate on two dimensions with ratings as above standard, at standard, below standard – Performance – “Did we do the best job we could do in the last iteration? ” – Behavior – “How well are we fulfilling our responsibilities? ” and “How well is the organization fulfilling its responsibilities? ” March 14, 2006 Agile Project Management 76

Project Status Reports • The number and frequency of reports and the information in the reports need to match the size, duration, and importance of the project • Parking Lot reports (with feature cards on the wall) – By feature – By month • Scope and value status can be shown as progress bars on the cards • Other reports similar to traditional project management • Adaptive, not corrective, action. Who knows whether the plan itself was correct! March 14, 2006 Agile Project Management 77

5) Close Practices • Celebrate! – Shows appreciation for all those who worked hard on the project – Including key clients in the celebration helps declare that the project is over, done, finalized, thus providing a sense of closure – Projects that go on and on are terrible for team morale • Clean up open items, finalize documentation and production or manufacturing support material • Conduct a project retrospective – Learning from mistakes is a very powerful form of learning March 14, 2006 Agile Project Management 78

Prominent Agile Models March 14, 2006 Agile Project Management 79

Agile Development Models • Scrum • Dynamic Systems Development Ecosystems • Crystal Methods • Feature Driven Development • Lean Development • Extreme Programming • Adaptive Software Development March 14, 2006 Agile Project Management 80

Scrum • Developed in the 1980's and 90's primarily in OO development circles as a highly iterative development methodology • Most well known developers were Ken Schwaber, Jeff Sutherland, and Mike Beedle • Divides development into thirty day iterations (called 'sprints') • Focuses on project management aspects and applies close monitoring and control with daily Scrum meetings • Much less emphasis on engineering practices March 14, 2006 Agile Project Management 81

Scrum March 14, 2006 Agile Project Management 82

Agile Success Stories March 14, 2006 Agile Project Management 83

Success Stories • Equity One (a publicly traded REIT) – solution that would allow the geographically dispersed Equity One staff to generate and retrieve property operating reports » http: //www. altova. com/cust_Agile_Equity. html • A billion dollar chemical manufacturer – building an enterprise data warehouse » http: //www. cariboulake. com/stories. html • Large County Government agency – application with four primary subsystems delivered in phases: Jail, Court, Supervision, and Administration » http: //www. cariboulake. com/stories. html March 14, 2006 Agile Project Management 84

Success Stories (contd. ) • Objective Systems – migrating existing GUI from Windows to the Linux and Unix platforms » http: //www. sourcextreme. com/objsys-success. html • Colubris Networks – implement an enterprise-critical, product lifecycle management (PLM) solution » http: //sme. agile. com/customers/pdf/cs-colubris-20041005. pdf • On. Stor – Product Lifecycle Management solution » http: //sme. agile. com/customers/pdf/cs-onstor-20041005. pdf • Egg Technology – Development of “Egg Money Manager” to support its personal financial services » http: //www. mercury. com/uk/pdf/success/egg_success. pdf March 14, 2006 Agile Project Management 85

Issues and Challenges March 14, 2006 Agile Project Management 86

The Pros and Cons of Agile Pros • System functionality is more in line with needs • Faster release cycles • More satisfied technical personnel • Higher customer commitment • Highly suitable for projects with undefined and/or changing requirements March 14, 2006 Cons • Schedule and costs are less predictable • Systems may be harder to maintain • Architecture may be less robust and less stable (although proponents don’t agree with this • Works best in small projects – this is a major issue • Tremendous user commitment is required Agile Project Management 87

Scalability to Large Projects? • Questionable; issues of coordination • Coordination is managing interdependence; three types of interdependence – Pooled • can be coordinated simply by standards – Sequential • Activities are linked sequentially • more complex coordination needed • Can be done using hierarchical coordination (e. g. , project managers) – Reciprocal • very complex coordination needed • Intensive technologies and the entire group is needed to achieve desired outcomes (e. g. , hospital ERs) March 14, 2006 Agile Project Management 88

Scalability to Large Projects? • CMM and other methodologies use standards and hierarchies as coordinating tools • Agile uses group meetings as the coordination tool – Issue – managing large group meetings – Tools and technologies for large group meetings are not yet there – We also don’t understand collaboration and coordination very well in large geographically distributed teams March 14, 2006 Agile Project Management 89

Acceptance of Frame Breaking Ideas • Agile requires frame-breaking • Innovations, especially those that require frame-breaking, have a slower diffusion process – Think object-orientation – Nearly four decades since the ideas were first developed (Simula 67)! • But the diffusion process for agile is on March 14, 2006 Agile Project Management 90

Sources and References • I have drawn from a number of sources in this presentation and it is difficult to list all of them here • Some citations were provided in the presentation • Jim Highsmith’s book “Agile Project Management: Creating Innovative Products by Jim Highsmith; Addison-Wesley, 2004” has informed this presentation quite a bit. The APM model presented today is covered in much more details in his book • Another excellent source for learning about agile methods is the website titled “The New Methodology” http: //www. martinfowler. com/articles/new. Methodolog y. html March 14, 2006 Agile Project Management 91