Executive Presentation on Agile Project Management by Boardroom Metrics Inc.

Executive Presentation on Agile Project Management by Boardroom Metrics Inc.

• 1.
  Agile Software Development What CXO’s Need to Know
• 2.
  Problem: Software ProjectsFail Standish CHAOS Report, 2010 Reasons for failure: • Incomplete requirements • Lack of user involvement 37% • Lack of resources 42% • Unrealistic expectations • Lack of executive support • Changing requirements and specifications 21% Successful Failed Challenged • (Note: “Appropriate technology unavailable” is not one of these)
• 3.
  Developing Software isDifficult Software development is Analogies to construction more like R&D than factory and manufacturing are not assembly lines useful People do not know what Trying to design everything they need until they in up front invites massive see/use it change Business-technology Yet organizations are collaboration and siloed, relying on alignment is essential document handoffs and restrictive sign-offs
• 4.
  How Waste CreepsIn • Detailed planning/design at the beginning of a project results in constant revisions • Over half the features developed never get used • Large amount of work must be redone – Because of the ineffectiveness of document handoffs – Because users do not see the product for months/years • Team waiting time (for equipment, answers) • Task-switching and multi-tasking • Unresolved “technical debt” makes subsequent releases challenging (plus, they take longer and longer)
• 5.
  It All Seems“Set Up” to Fail
• 6.
  The Solution • Short cycles (1-4 weeks): – At the beginning of each cycle, figure out what are the most important things to do right now – Demonstrate what was done at the end of each cycle (make it available for use if appropriate) • Welcome feedback (and act on it) • The team focuses on one thing at a time, until it is done • Defer requirements definition until just before you build them • Create cross-functional teams that include both business and technical people • Promote adaptive planning and a people-centric approach
• 7.
  When to Use Agile (for anything complicated or complex) Traditional (waterfall) - Stacey Complexity Graph
• 8.
  Traditional Approach “Ibelieve in this concept, but the implementation described above is risky and invites failure.” - Dr. Winston Royce (“Father of the Waterfall”), August 1970
• 9.
  Agile Example: SCRUM
• 10.
  Adaptive Planning -Pivot • Imagine developing a social media monitoring system Iteration 3: UI adapted to retail market Iteration 2: All Target: Police and Public Facebook posts Safety Intelligence Services Iteration 1: Facebook group posts Iteration 4: Twitter Feedback: Still no police subs, but retailers take note Feedback: Interest, but no police subscriptions Feedback: 10 retail Feedback: 100 retail subscriptions sell subs
• 11.
  People-centric •Trust motivated people – Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. • Face-to-face communication – The most efficient and effective method of conveying information to and within a development team is face-to- face conversation. • Self-organizing teams – The best architectures, requirements, and designs emerge from self-organizing teams. - Extract from Agile Manifesto, 2001
• 12.
  What it Takes Dedicated teams Drop the matrix, or at least multi-tasking Readily available Virtualization key; consider development and test cloud computing (e.g. environments Amazon Web Services) New metrics for No more EVM, % progress, status complete; still have RYG Business people If you are spending $10m assigned to IT projects and can eliminate $1m in waste, why not?
• 13.
  Summary •Contrary to popular belief, agile development is for complicated/complex projects • People-centric approach that advocates self-organization and adaptive planning • Acknowledge that this is a sea change • And that it will take time and significant effort/commitment for the organization to transform • Questions/Comments/Concerns?