Executive Presentation on Agile Project Management by Boardroom Metrics Inc.


Published on

This presentation was delivered to a group of senior executives with little or no understanding of Agile methodologies. It was an eye-opening experience!
If interested, please reach out to our firm to discuss how we can help your organization: 1.416.994.6552 or info@boardroommetrics.com

Published in: Business, Technology

Executive Presentation on Agile Project Management by Boardroom Metrics Inc.

  1. 1. Agile Software Development What CXO’s Need to Know
  2. 2. Problem: Software Projects Fail 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. 3. Developing Software is Difficult 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. 4. How Waste Creeps In • 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. 5. It All Seems “Set Up” to Fail
  6. 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. 7. When to Use Agile (for anything complicated or complex) Traditional (waterfall) - Stacey Complexity Graph
  8. 8. Traditional Approach “I believe in this concept, but the implementation described above is risky and invites failure.” - Dr. Winston Royce (“Father of the Waterfall”), August 1970
  9. 9. Agile Example: SCRUM
  10. 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. 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. 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. 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?