Using Agile Methodologies


Published on

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

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
  • Using Agile Methodologies

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