When we talk of agility, we often refer to number of user stories or story points delivered, or burn down charts or velocity, etc. I call them 'lower-order agility' and howsomuch interesting they are, they make no sense to the 'higher-order agility' at business level. Why is that outrageous claims of performance, productivity and quality improvements at lower-order agility don't translate to commensurate higher-order agility? In this talk, I explore some of these issues. I also propose some ideas on how the whole notion of portfolio planning should be seen in the context of higher-order agility. I delivered this talk on 19 July 2012 at the launch of Agile Leadership Network, Bangalore chapter, hosed by Valtech at their office.

1. Business Case for Agile
– Time for ROI Check –
Tathagat Varma
Sr. Director Biz Ops, OPD and Strategic Programs
Yahoo! India
19-July-2012, Bangalore

2. my professional belief system
• Goal: The goal is software that delivers real value
to the business and the users it serves. Software
just by itself is, thus, not a value.
• Means: Methodologies are simply a means to
organize work and assign resources to deliver
better software, and not an end by themselves
• Judgment: “When the terrain disagrees with the
map, trust the terrain” - Swiss army manual

3. What is (my definition of) Agility?
• Accomplishing end-objectives
“B” through a series of mid-course
corrections
• Accomplishing = the focus is on results and
not on intent, desire or behavior
• End-objectives = agility by itself is just a
Progress
means to accomplish end-
objectives, which include time to
market, cost and quality constraints, etc.
• Mid-course corrections = embracing mid-
“A”
course change and adapting to them in
Time real-time keeping the focus on end-
objectives

4. Let’s examine today
• Holy Grail of Software Development
• Impact of The Agile Decade
• Today’s Business Drivers
• Where’s the gap?
• What next?

5. Holy Grail of Software Development
• Better: higher
quality, more
reliability, higher
performance, more
usable…
• Faster: speedier
development
• Cheaper: no budget
overruns

6. But the reality?

7. What Fred Said
• No Silver Bullets – Essence and Accidents in
Software Engineering – Fred Books, 1986
• “There is no single development, in either
technology or management
technique, which by itself promises even
one order-of-magnitude improvement
within a decade in productivity, in
reliability, in simplicity.”

8. Silver Bullets so far…
• Ada and other high level languages
• Object-oriented Programming
• Artificial Intelligence
• Expert System
• Automatic Programming
• Graphical Programming
• Program Verification
• Environment and Tools
• Workstations
• Structured Programming
• CASE Tools

9. …and the search goes on!
• Reusability
• CMM / PCMM / CMMi
• Six Sigma
• ISO9000 / ISO TickIT
• Outsourcing
• Agile
• < …the next shiny object… >

10. Preamble to Agile Movement
Software Crisis, 1965-85: The major cause of the
software crisis is that the machines have become
several orders of magnitude more powerful! To put
it quite bluntly: as long as there were no
machines, programming was no problem at all;
when we had a few weak computers, programming
became a mild problem, and now we have gigantic
computers, programming has become an equally
gigantic problem. — Edsger Dijkstra, The Humble
Programmer

11. Software Crisis
The causes of the software crisis were linked to the
overall complexity of hardware and the software
development process. The crisis manifested itself in
several ways:
• Projects running over-budget.
• Projects running over-time.
• Software was very inefficient.
• Software was of low quality.
• Software often did not meet requirements.
• Projects were unmanageable and code difficult to maintain.
• Software was never delivered.

12. and the response?
Frameworks, Standards and Certifications

13. …and the result?…good start…

14. …but poor finish!

15. Why?
The World had changed! Software increasingly
became more business-critical, and delays, cost
overruns and poor quality were significantly less
acceptable then before!
• Process: Long-lead development process ineffective in
a dynamic and global world
• Management: Command and control model
unsuitable for fostering collaboration required to
solve complex problems
• Technology: Advancements in computers, compiler
technology and debugging and testing tools greatly
improved the economics of software development

16. Advent of Agile Methodologies
• 1970: Royce critiques Waterfall and offers improvement ideas
• 1986: Barry Boehm proposes Spiral Model
• 1971: Harlan Mills proposes Incremental Development
• 1987: Cleanroom Software engineering
• 1991: Sashimi Overlapping Waterfall Model
• 1992: Crystal family of methodologies
• 1994: DSDM
• 1995: Scrum
• 1996: Rational Unified Process framework
• 1997: Feature Driven Development
• 1999: Extreme Programming Explained
• 2001: Agile Manifesto is born
• 2003: Lean Software Development
• 2005: PM Declaration of Independence
• 2007: Kanban-based software engineering
• 2009: Scrumban
• 20xx: Something new !?! (hopefully!)

17. Impact of The Agile Decade
• 2008: 82% of 3,061 participants in DDJ indicated somewhat higher or much higher
productivity
• 2008: David F Rico reported 29% better cost, 91% better schedule, 97% better
productivity, 50% better quality, 400% better satisfaction, and 470% better ROI
than CMMI
• 2009: Jeff Sutherland on Nokia Test: ROI > 11,000% first year
(http://jeffsutherland.com/nokiatest.pdf)
• 2011: VersionOne survey: Prior to adoption, respondents said Productivity and
Time to Market ranked as their top reasons to adopt agile. But experienced agile
users said actual benefits were primarily project visibility (77%) and ability to
manage changing priorities (84%).
• 2012: Valtech survey at Agile India 2012 reports 90% report a significant
improvement in ‘outcomes’
• 2012: IBM Agile Maturity Report: Benefits of Agile include ability to adapt to
change (79%), better customer engagement (62%), improved deliverables
(56%), improved communications (55%), and better visibility into project (52%)

18. …and the other side of coin?
• ”Bring up the topic of Agile with other experienced IT people and I
would estimate 90% of the feedback is negative.”
• 2012 IBM Agile Maturity Report:
– Lack of stakeholder participation (36%), lack of management support
(34%).
– organizations that struggled the most with traditional projects, also
struggled with Agile – 36% of the respondents with the lowest
traditional success rates (below 20%) also had the lowest Agile success
rates, and 49% of that category had less than 40% of their Agile
projects succeed.
– By contrast, organizations with the highest traditional success rates
also had the most successful Agile projects – 71% of the companies in
the 80%+ category for traditional were in the 80%+ category for Agile.
– The top three drivers for selection of the Agile approach to be used
(team experience, sponsor’s choice, department experience) are
environmental, not needs driven

19. Agile Dilemma?
• "The Agile movement is designed to sell services," says
analyst firm Voke Inc. in a brand-new report analyzing
the movement, presenting findings about its use and
providing insight to organizations considering its
adoption.
• In addition, the report includes data supporting what
Voke calls the "Agile Dilemma," described as "the
inherent risk and confusion created by the business
desire for speed and flexibility misinterpreted as a
mandate to participate in the developer-centric
movement called Agile, which may not be appropriate
for all organizations or projects.”

20. Agile Realities (?)
• 64% of survey participants found the transition to Agile confusing, hard, or slow.
28% report success with Agile.
• Out of over 200 survey participants, we received only four detailed comments
describing success with Agile.
• Overwhelmingly, 40% of participants that use Agile did not identify a benefit.
• The primary benefits identified were faster releases (14%) and more feedback
(13%). Some participants (7%) also noted that Agile developers were happy due to
less future planning and less documentation.
• Survey participants report that developers use the guise of Agile to avoid planning
and to avoid creating documentation required for future maintenance.
• We received some unprecedented scathing and shocking comments about the level
of competence, professionalism, and attitudes of some members of the Agile
movement.
• Be aware that the Agile movement might very well just be either a developer
rebellion against unwanted tasks and schedules or just an opportunity to sell Agile
services including certification and training.

21. Some hard questions…
If gurus are promising and practitioners are
reporting such dramatic improvements at team
level:
• Do they also reflect at business level?
• If not, why not?
• If not, is agile ‘successful’?
• If not, what can we do to bridge the gap?

22. Today’s Business Drivers
Speed Innovation UX
• “Move fast and • “Great just • “Focus on the
break things” isn’t good user and all
• “Done is better enough” else will
than perfect” • “Creativity follow”
• Minimize total from every • “Every Detail
time through corner” Matters”
“Build- • Pivot (or
Measure- Persevere)
Learn” Loop

23. Accelerating Pace of Tech Adoption

24. Accelerating Pace of Tech Upgrade

25. Age of Hyper Innovation

26. Profitability of Industries

27. Decline in Gross Profits over time

28. Let’s create some controversy 
• Lower-order Agility (“Efficiency”): team
level agility that improves overall
economics of software development
• Higher-order Agility (“Effectiveness”):
agility that improves overall economics
at business level

29. Are they talking yet?
• Claims of team-level performance
improvements in the wild ranges of
5x-11,000x !!!
• However, mature businesses in most
industries typically only grow single-
digit y-o-y !!!

30. Do we see the disconnect?
Higher-
order Agility
Lower-order
Agility

31. Why is this gap?
• I believe the way agile movement grew
bottom-up, it alienated all things
management. Think of “Chickens” 
• At deep-down execution level, the only
notion of agility is how fast and how
much code is getting delivered, and not
correlated with how fast and how much
the real dollars are coming home!

32. Conclusions
• We have largely addressed efficiency
issues at software team level
• However, lower-order agility is NOT
translating into higher-order agility
• ROI != $$$ Saved
• ROI = $$$ Earned
• How do we link lower-order agility with
higher-order agility?

33. What Next?
• Agile Portfolio should talk of NPVs, IRRs and DPBPs.
• POs should think in terms of NPV goals. Backlog and
stories are only a means to achieve NPV.
• Think of each sprint as the NPV to be created. If you
can’t articulate NPV at each sprint, you are essentially
doing a waterfall at business level!
• Each sprint is meant for validating the hypothesis
around NPV goal associated with it.
• If you don’t meet it, go back and iterate. If NPV goals
are unattainable, pivot.
• When NPV/IRR/DPBP goals are attained, project is
considered successfully complete.

34. References
• http://en.wikipedia.org/wiki/Agricultural_productivity
• http://www.gray.com/news/blog/2012/02/09/global-economic-
crisis-driving-foreign-manufacturers-reconsider-us-full-version
• http://mjperry.blogspot.in/2010/04/productivity-improvements-
destroyed-6m.html
• http://www.emeraldinsight.com/journals.htm/journals.htm?articlei
d=1752311&show=html&WT.mc_id=alsoread&PHPSESSID=1s1nm9
atk8aeleii4lf1nkevp6
• http://4.bp.blogspot.com/_PcL18ufT4EE/TGgWVpibvEI/AAAAAAAA
Ahg/E9ezID8plWk/s1600/Graph.jpg
• http://whatthecrap.wordpress.com/2008/08/04/obamas-new-ad-
marxism/
• http://adtmag.com/articles/2012/07/13/report-says-agile-a-
scam.aspx

35. References
• What’s the ROI of Agile Vs. Traditional Methods – David F
Rico, http://davidfrico.com/rico08b.pdf
• What’s the ROI of Agile Methods – David F
Rico, http://www.afei.org/WorkingGroups/ADAPT/Documents/rico0
8a[1].pdf
• Business Value of
Agile, http://www.slideshare.net/people10/selling-agile-to-
business-proving-hard-roi
• Ten Year Agile Retrospective: How can we improve in the next ten
year, http://msdn.microsoft.com/en-us/library/hh350860.aspx
• https://www.ibm.com/developerworks/mydeveloperworks/blogs/a
mbler/entry/reworking_the_agile_manifesto14?lang=en
• http://www.slideshare.net/choldorf/agile-portfolio-planning

36. Connect
Blog: http://managewell.net
Email: Tathagat.Varma@gmail.com
Slides: http://slideshare.net/managewell
Twitter: http://twitter.com/TathagatVarma
My Articles: http://managewell.net/?page_id=2