Presented on May 30, 2008 at the 2008 Meeting of the Society for Scholarly Publishing. DIrector's Cut.

1. How One Publisher Changed Its Approach to Online Development in 45 Days ADVENTURES IN AGILITY Larry M. Belmont Manager, Online Development labelmo at aip dot org Society for Scholarly Publishing 30 th Annual Meeting, Boston, MA May 30, 2008

8. … we stewed an “agile approach”

19. OODA, cheap DC comics version

20. OODA, expensive O’Reilly book version

22. Our 1 st OODA loop Installed an agile “framework” (people, process, tools); planned a 1 st iteration and an agile user testing/feedback loop Decide Studied the competition, to see what they had on the abstract page that we didn’t, and what we could add quickly; ID’d customer and user wants and needs; increased Web 2.0 savvy; assigned values to deliverables Orient Noted that 46% of Scitation user sessions started on the abstract view; began cultivating a vision that our platform was made up of 2 million article homepages where the users engaged us and one another, and where we engaged them Observe Implemented the 1 st iteration Act What We Did OODA Component

23. Here’s how it turned out 20 business days Plan and implement Version 1.6 8 business days Implement version 1.5 37 business days Assemble the team; retool approach, applications, and presentation framework (GUI) to facilitate “working agile”; plan version 1.5 14 business days Plan and implement Version 1.7 10 business days Plan and implement Version 1.8 12 business days Plan and implement Version 1.9 How Long We Took What We Did

24. How did we change our MO? Practice designer-centered design Practice user-centered design Run the project via meetings, e-mail, and reference a 50-page “plan” and document it on the LAN Run the project on the web and reference a 1-2-page “roadmap” and document it on virtual writeboards Wait until everything is hard-wired together before alpha testing Test end-user functionality modularly as it’s built – and course-correct as we go Slow-cook requirements via multiple meetings, mockup reviews, documentation reviews Quick-cook requirements in social environments (wiki, basecamp) Produce exhaustive Visio wireframes and workflows Prototype on paper (easy to change) Wait until everything is changed and re-wired together before beta testing Engage key internal stakeholders and customers/users at every stage Declare work done and move onto next thing without reassessing value or need to modify/optimize behavior Never consider work really complete; continue evaluating feedback and surveying users to drive followup iterations What We Used to Do What We Do Now

25. Our obligatory process diagram

31. Our agile “mythology” scorecard Plan-driven projects are always un-agile User stories and personae were critical to getting at REAL functionality with VALUE Agility is a silver bullet “ Fail fast” or “fail early and often” is a speed-enhancing attribute; “gotta build it to break it” (best to break it sooner) Agility requires no discipline OODA worked (though no one explictly knew it was OODA) Agility is just for programmers People first, then ideas, then tools – the correct route from fragile to agile Agility means “perpetual beta” Some form of 80/20 analysis increases design speed and helps plan product iteration(s) “ Agile Myths” We Debunked “ Agile Myths” We Confirmed