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
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. 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. 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)
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
“I believe in this concept, but the
implementation described above is risky
and invites failure.”
- Dr. Winston Royce (“Father of the Waterfall”), August 1970
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?