2. www.synerzip.com
Disclaimer
• Just my perspective
• For the most part, nothing here is my
original IP
• Nothing ground breaking, many of you
probably already know all this
• (Shamelessly) leveraging visuals from
others, but given due credit where due
Confidential
3. www.synerzip.com
The Problem
Confidential
Source of data: Standish Group, CHAOS Manifesto 2011 http://aimconsulting.com/overcoming-agile-failure-six-ways-beat-odds/
• Users/Customers
• Engineers/Team
• Executives/Investors
4. www.synerzip.com
Root Cause
Evolving/Changing
Business Requirements
• Multiple, inconsistent inputs
• Change is usually good though
Inherent R&D Nature of
Software Development
• Software performance issues
• Changing/New technologies
Technology Environment
with Many Moving Parts
• Dependence on external
technology components –HW/SW
• Constantly changing environment
Distributed Teams
Needing to Collaborate
• Team communications
• Need for complementary skills
Confidential
• Unlike other engineering
disciplines (e.g. manuf, bldg
const), building software is
harder and more complex
• If not managed properly, a
lot can go wrong!
• Needs to be properly
managed – with appropriate
level of process discipline
• Agile approach works very
well in most cases
Building Software is Complex
5. www.synerzip.com
Deeper Look – Stacey Matrix
Confidential
Source: Strategic Management and Organizational Dynamics by Ralph Stacey in Agile Software
Development with Scrum by Ken Schwaber and Mike Beedle
6. www.synerzip.com
What is Agile?
Agile approach accounts for unique nature of software
development. It is a…
•software project management approach that encourages
delivering in short cycles, with frequent inspection, feedback,
and adaptation
•leadership philosophy that encourages team-work, self
organization, and accountability at team level
•disciplined engineering approach to software
development that results in rapid delivery of high quality
software
•business approach that focuses on delivery real business
value (=customer needs) above all.
Various flavors are practiced – SCRUM, XP, Kanban etc.
Confidential
7. www.synerzip.com
Agile Manifesto - 2001
“We are uncovering better ways of developing software by
doing it and helping others do it. Through this work we have
come to value:
– Individuals and interactions over processes and tools
– Working software over comprehensive documentation
– Customer collaboration over contract negotiation
– Responding to change over following a plan
That is, while there is value in the items on the right, we value
the items on the left more.”
Kent Beck Mike Beedle Arie van Bennekum
Alistair Cockburn Ward Cunningham Martin Fowler
James Grenning Jim Highsmith Andrew Hunt
Ron Jeffries Jon Kern Brian Marick
Robert C. Martin Steve Mellor Ken Schwaber
Jeff Sutherland Dave Thomas
Confidential
8. www.synerzip.com
Waterfall Approach
Confidential
• 6+ month
• Too linear, with no learning/feedback cycle
• Expects all requirements upfront
• No value based prioritization of features
• Often results in over engineering
• Often testing/quality compromised
9. www.synerzip.com
Agile Approach
Confidential
• First working software in 4 weeks or less
• Emphasis on learning/feedback
• Embraces changing/evolving requirements
• Consistent focus on high-value features
• “Just-enough” engineering, with emphasis
on frequent refactoring
• Focus on repeated testing/quality
12. www.synerzip.com
The Problem w/ Agile –“What”
1. Assumes that the right software
requirements are available to engineering
team at the beginning of every sprint
2. Unreasonably, relies upon a single
“Product Manager”
1. He/she magically knows what to build?
2. Single throat to choke!
3. In reality, often, even the users/customers
don’t know what they really need, until they
see it
Confidential
20. www.synerzip.com
Parallel w/ McKinsey Work
• 2-weekly progress reviews w/ clients
• Starting with a story board
• Hypothesis driven data collection
• Data driven conclusions, hard nosed,
empirical
Confidential
21. www.synerzip.com
Key Points for Executives
• Software projects need to be managed differently
– Leverage Agile + Lean Startup concepts
– Short build cycles with customer/use feedback loop
• Most often, figuring out “What” to build is more important,
than actually building it
• Planning is valuable, but dogmatically sticking to a (old)
plan is asinine
– New information will inevitably surface
– So, regularly re-plan, taking new info into account
• Avoid the myth of maximizing resource utilization - don’t
build feature bloat
– Usable feature is an asset, but software code is a liability
• Software is never done! So, plan for on-going investment,
not just one-time
Confidential