Presented on May 30, 2008 at the 2008 Meeting of the Society for Scholarly Publishing. Theatrical 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

7. … we stewed an “agile approach”

14. OODA, cheap DC comics version

15. OODA, expensive O’Reilly book version

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

17. Thank you, sir, may I have another … 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

18. So, where did that speed come from? 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

19. Our obligatory process diagram

25. Our agile “mythology” scorecard Agility requires no discipline “ Fail fast” or “fail early and often” is a speed-enhancing attribute; “gotta build it to break it” (best to break it sooner) Agility is a silver bullet OODA worked (though no one explictly knew it was OODA) Agility is just for programmers People first, then methodology, then tools – the best route from fragile to agile for us Agility means “perpetual beta” User stories and personae were critical to getting at REAL functionality with VALUE “ Agile Myths” We Debunked “ Agile Myths” We Confirmed