Business Case for Agile - Time for ROI Check
Upcoming SlideShare
Loading in...5
×
 

Business Case for Agile - Time for ROI Check

on

  • 2,576 views

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, ...

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.

Statistics

Views

Total Views
2,576
Views on SlideShare
2,576
Embed Views
0

Actions

Likes
1
Downloads
62
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

CC Attribution-NonCommercial-ShareAlike LicenseCC Attribution-NonCommercial-ShareAlike LicenseCC Attribution-NonCommercial-ShareAlike License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Business Case for Agile - Time for ROI Check Business Case for Agile - Time for ROI Check Presentation Transcript

    • Business Case for Agile – Time for ROI Check – Tathagat Varma Sr. Director Biz Ops, OPD and Strategic Programs Yahoo! India 19-July-2012, Bangalore
    • 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
    • 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 aProgress 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
    • Let’s examine today• Holy Grail of Software Development• Impact of The Agile Decade• Today’s Business Drivers• Where’s the gap?• What next?
    • Holy Grail of Software Development • Better: higher quality, more reliability, higher performance, more usable… • Faster: speedier development • Cheaper: no budget overruns
    • But the reality?
    • 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.”
    • 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
    • …and the search goes on!• Reusability• CMM / PCMM / CMMi• Six Sigma• ISO9000 / ISO TickIT• Outsourcing• Agile• < …the next shiny object… >
    • Preamble to Agile MovementSoftware Crisis, 1965-85: The major cause of thesoftware crisis is that the machines have becomeseveral orders of magnitude more powerful! To putit quite bluntly: as long as there were nomachines, programming was no problem at all;when we had a few weak computers, programmingbecame a mild problem, and now we have giganticcomputers, programming has become an equallygigantic problem. — Edsger Dijkstra, The HumbleProgrammer
    • Software CrisisThe causes of the software crisis were linked to theoverall complexity of hardware and the softwaredevelopment process. The crisis manifested itself inseveral 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.
    • and the response?Frameworks, Standards and Certifications
    • …and the result?…good start…
    • …but poor finish!
    • Why?The World had changed! Software increasinglybecame more business-critical, and delays, costoverruns and poor quality were significantly lessacceptable 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
    • 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!)
    • 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%)
    • …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
    • 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.”
    • 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.
    • Some hard questions…If gurus are promising and practitioners arereporting such dramatic improvements at teamlevel:• 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?
    • 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
    • Accelerating Pace of Tech Adoption
    • Accelerating Pace of Tech Upgrade
    • Age of Hyper Innovation
    • Profitability of Industries
    • Decline in Gross Profits over time
    • 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
    • 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 !!!
    • Do we see the disconnect? Higher- order Agility Lower-order Agility
    • 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!
    • 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?
    • 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.
    • 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
    • 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
    • Connect Blog: http://managewell.net Email: Tathagat.Varma@gmail.com Slides: http://slideshare.net/managewell Twitter: http://twitter.com/TathagatVarmaMy Articles: http://managewell.net/?page_id=2