Your SlideShare is downloading. ×
Using Agile Methodologies
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Using Agile Methodologies


Published on

Slides from Dave Kellogg's presentation at the Outsell Signature Event 9/22/08 in Half Moon Bay, California

Slides from Dave Kellogg's presentation at the Outsell Signature Event 9/22/08 in Half Moon Bay, California

Published in: Technology, Business

1 Like
  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide
  • A topic, for reasons we’ll see, that I am very passionate about. Always felt that the more publishers / information & media companies intermix content with software to deliver value – with things like content applications, the embedding of workflow, role and task-aware information product built using methodologies like contextual design … the more i see that, the more i think i can bring teachings and lessons from not only our customer world but also the software world in which i have lived for so long
  • Transcript

    • 1. Using Agile Development and Cross-Functional Teams Dave Kellogg Chief Executive Officer 9/22/08
    • 2. Topics
      • Background on the topic
      • My personal tale
      • Customer stories and learnings
    • 3. Agile Software Development
      • Agile software development refers to a group of software development methodologies that promotes development iterations , open collaboration, and process adaptability throughout the life-cycle of the project. It chooses to do things in small increments , with minimal planning , rather than plan at length. This helps to minimize the overall risk, and allows the project to adapt to changes more quickly. There is also an emphasis on stakeholder involvement . Meaning at the end of each iteration, the stakeholder is consulted about the product and comments are noted.
    • 4. The Agile Manifesto
    • 5. The Iron Triangle Scope (functionality, quality) Schedule (the date) Resources (cost) “ The tighter you grasp the more you let slip through your fingers”
    • 6. The Mythical Man-Month
      • “Brooks’ Law”
      • Published in 1975
        • (Not person-month)
      • Over 250,000 copies sold
      • Every* engineering VP I’ve ever met loves it over a beer
      • And then goes ahead and asks for more resource for late projects
      “ Adding resource to a delayed project makes it later” * Sauf one at Business Objects and at Mark Logic
    • 7. Topics
      • Brief background
      • My personal tale
      • Customer stories and learnings
    • 8. Ingres 6.0 (Circa 1990)
      • Ingres 5.0
        • Quel-based, single-threaded, local database management system
      • Ingres 6.0
        • From Quel to SQL (catch-up to Oracle)
        • And, WYAI, single to multi-threaded (catch-up to Sybase)
        • And, SITSL, from single-server to multi-server (one-up Sybase)
        • And, WYAI, from local to distributed (one-up Oracle)
        • And, SITSL, with a gateway to IMS (uniqueness)
        • And, SITSL, it needs to go 100 TPS (catch-up and one-up Sybase)
      • Results
        • Delivered years late
        • Didn’t work until 6.3
        • Several fired engineering VPs and managers
        • Company sold to ASK for $100M (<1x revenues)
      WYAI = while you’re at it. SITSL = since it’s taking so long.
    • 9. Business Objects 4.0 (Circa 1995)
      • BusinessObjects was originally a DOS query and reporting (Q&R) tool
        • Arch-enemy Cognos had a Q&R tool and an OLAP tool
      • BusinessObjects 4.0 specification
        • Complete re-write from DOS to 32-bit Windows
        • And, WYAI, add an OLAP functionality (catch-up)
        • And, WYAI, dynamically create micro-cubes (one-up)
        • And, WYAI, add multi-source reporting (one-up)
        • And, SITSL, add new administration and security
      • Results
        • Release so bad customers thought motherboards were broken
        • Stock dropped from $105 to $6/share
    • 10. Business Objects Tosca (Circa 2001)
      • Tosca project
        • From desktop architecture to web server-based architecture
        • Complete product rewrite
        • And WYAI, new, better server-based dynamic hypercube
        • And WYAI, create and integrate enterprise reporting solution
        • And SITSL, add 50 new features
      • Results
        • Never delivered; project abandoned
        • Engineering director stopped coming to work
        • Spent $1B to acquire Crystal Reports
    • 11. Why Do I Tell You All This?
      • You can find no deeper
      • convert to agile methodologies
      • (which we obviously use – and to great success – at Mark Logic)
    • 12. Topics
      • Brief background
      • My personal tale
      • Customer stories and learnings
    • 13. Case 1
      • Rewrite of existing successful STM product
        • Accommodating role-in of top-up acquired product
        • Complete infrastructure replacement
      • Distributed development team in 3+ locations
      • Separation of missions and roles by center
        • Team 1: content integration and cleansing
        • Team 2 and 3: application development
      • Matrixed corporate standards boards overseeing the business unit
      • Rich functional specification based on customer observation and contextual design methodology
      • Results
        • Project scrapped
        • Networking benefit: I now know people at many different publishers
        • New team favored quick-hit, small cycles
    • 14. Lessons from Case 1
      • Beware excess project decomposition and distributed teams
        • Communication is critical
      • Beware the urge to purge
        • Complete re-writes are sometimes – but rarely – necessary
        • If you are doing one, you shouldn’t do any WYAIs
        • Best case I’ve seen: WebIntelligence – minimal feature set
        • Hard “no” often liberates creativity
      • Often, you’re better off introducing a new product to avoid major legacy feature burden
      • The quick-hit, small cycles may keep the teams’ jobs but is it a slow-death solution?
    • 15. Case 2
      • New team, new product
      • Web 2.0, web-facing, consumer news site
      • Tech lead and VP/CTO drove the agile approach given
        • Big fans of agile given prior experiences
        • The dynamic nature of the project: unknowable requirements
        • “What seemed so important 9 months ago.”
      • Long Beta; feature experimentation
        • Logging all user actions for analytics
        • LinkedIn profile extraction
      • Launched on-time and on-budget
        • Commercial success TBD – but enabled
    • 16. Learnings: Timeboxing
      • The single most important thing in my opinion
      • Forces decomposition mind-set
      • Forces periodic delivery
      • Forces prioritization
      • Reduces last-train faux urgency
    • 17. Learnings: Trust
      • Perceived loss of accountability
        • 750 page specification
        • Ability to monitor 99.5% compliance with requirements
      • So what?
        • Are we trying to maximize revenue or accountability for failure?
        • (Hint: you can fire them anyway)
      • Which is the bigger leap of faith?
        • Working closely with a team to periodically deliver working software?
        • Handing someone a tome and waiting 2 … 3 years?
      • Our “normal” thinking is inverted!
        • Rewarding negotiation more than anything else
        • See “Beyond Budgeting” for related business rants
    • 18. Learnings: Communication
      • Frequent communication a key element
        • Scrums, stand-up meetings, small teams
      • Elimination of some roles
        • The liaison communicators
        • More direct engineer to user conversations
      • Interpretation and reinterpretation of requirements
        • Think: design for assembly or maintenance
      • Some people can’t hack the change
        • Defend past roles
        • Dislike communication
      • Value reality
        • Reduce fear of delivering bad news
    • 19. Conclusion
      • The principles
        • Breaking the iron triangle
        • Remembering the mythical man-month
      • The horror stories
        • I’ve shared mine
        • Yours are better
      • The reality
        • Agile works
        • Agile requires change
        • Agile can be adopted on small scale and then rolled out
        • You owe it to yourself to try agile development