Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

Executive Presentation on Agile Project Management by Boardroom Metrics Inc.

12.043 Aufrufe

Veröffentlicht am

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

Veröffentlicht in: Business, Technologie

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?