1. ADVENTURES
IN AGILITY
How One Publisher Changed Its Approach
to Online Development in 45 Days
Larry M. Belmont
Manager, Online Development
labelmo at aip dot org
Society for Scholarly Publishing
30th Annual Meeting, Boston, MA
May 30, 2008
2. About AIP
• Founded in 1931 as a service organization …
– Charter: to diffuse and advance the knowledge of physics
and its application to human welfare
– Service mission: to supply economy-of-scale publishing
services to Member Societies
– Currently has 10 member societies, 23 affiliated societies,
and several other organizations under its umbrella (most
have a publishing program)
• A publisher in its own right …
– 10 journals, conference proceedings, database products
• Scitation …
– AIP’s online hosting platform; on the web since 1996
– Aggregation of 180 publications for 25 publishing partners
3. About me
• 27 years in publishing, all at AIP …
– 9 years in print journal production (most as a
technical copy-editor)
– 3 years in desktop publication production
– 15 years in electronic/online products (8 as a
manager)
• Currently an online product development
manager in a business unit
• Not a programmer; more of a technical
projects manager/product manager
4. Our goals
• Increase development speed in order to meet
customer and customer constituency demands, as
well as our own needs to evolve our services more
regularly
• Position ourselves to innovate or deploy new
features quickly in response to unpredictable
“market conditions,” major paradigm shifts (like
Web 2.0), or good ole competitive one-upsmanship
5. The enemy is us
• Project (micro)management
• “Perfect-plan-ism”
• Fear of failure (culture of “that won’t work”)
• Distributed decision-making
• Monolithic release mentality
• Design by committee
• Disconnect from users and customers at all
but latest stages
• Compartmentalization, thick-walled bizunit-
bizunit and bizunit-IT silos
6. From many schools of agility …
• Observe – Orient – Decide – Act (Boyd’s “OODA
Loop”)
• Observe – Model – Test – Reflect (Kolb’s “Learning
Model”)
• Plan – Do – Check – Act (Shewhart’s “QC Cycle”)
8. Agility demands the right roles
• The Agile “X Organization”
– The Leader, a/k/a “Big X”
– The Stakeholder
– The Timekeeper
– The User Advocate
– The Visualizer
– The Architect
– The Coder
– The Bulletproofer
– The Tester
– The Gatekeeper
9. What was our “Big X” like?
• Did not act like a certified project manager;
more of an engager-resonator-cultivator-
harmonizer
• Articulated clear intent/goal (co-signed “the
contract of leadership” with the team)
• Asked the team to accomplish the goal, but
did not tell them how to do it
10. Team attributes
• Highly motivated, highly skilled
• Zen-like, intuitive understanding (“feeling it”)
• Mix of experienced hands, fresh POVs
• Rank did not dictate leadership role(s)
• Business-technology blend
• Self-mobilizing at all levels
• Cross-pollinating
• Credibility, mutual respect, passion, trust
• Subjugation of personal agendas
11. Team behaviors
• Highly verbal
• No blame, no fear
• No assumptions, projections, conceits
• Dialogue over monologue
• Sublimation of egos, but wide berth given to
passionate POVs
• Devil’s advocacy tempers evangelism
• Belief in user input and test-driven
development as primary design driver
12. A little inspiration
• Korean War jet pilot John Boyd believed the perfect
fighter plane’s key characteristic was agility – the
ability to change its energy state rapidly to move
from patrol to attack mode, and for a pilot to do the
same mentally to gain advantage once engaged in a
dog-fight
– Pilot advantage hinged on highly intuitive Observe-Orient-
Decide-Act (OODA) looping
– The more agile pilot was the one who could change the
situation more quickly than his opponent could update his
orientation to it (“getting inside” the enemy’s OODA loop)
– OODA grants us the ability to balance continuity and
change (a pretty good definition of agility)
13. What do aerial warfare and projects
have in common?
• Shared “adversaries”
– Rapid, unanticipated changes that lead to
disorientation
– An uncertain environment
– Constant threats to any initiative gained
– Time itself
• OODA helps in dog-fights and projects
– Allows us to control the environment (esp. change)
– Can help identify threats faster
– Is iterative by design
16. Our 1st OODA loop
OODA Component What We Did
Observe 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
Orient 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
Decide Installed an agile “framework” (people,
process, tools); planned a 1st iteration and
an agile user testing/feedback loop
Act Implemented the 1st iteration
17. Thank you, sir, may I have another …
What We Did How Long We Took
Assemble the team; retool approach, applications,
and presentation framework (GUI) to facilitate 37 business days
“working agile”; plan version 1.5
Implement version 1.5 8 business days
Plan and implement Version 1.6 20 business days
Plan and implement Version 1.7 14 business days
Plan and implement Version 1.8 10 business days
Plan and implement Version 1.9 12 business days
18. So, where did that speed come from?
What We Do Now What We Used to Do
Prototype on paper (easy to change) Produce exhaustive Visio wireframes and workflows
Practice user-centered design Practice designer-centered design
Quick-cook requirements in social environments (wiki, Slow-cook requirements via multiple meetings, mockup
basecamp) reviews, documentation reviews
Run the project on the web and reference a 1-2-page Run the project via meetings, e-mail, and reference a 50-
“roadmap” and document it on virtual writeboards page “plan” and document it on the LAN
Test end-user functionality modularly as it’s built – and Wait until everything is hard-wired together before alpha
course-correct as we go testing
Engage key internal stakeholders and customers/users Wait until everything is changed and re-wired together
at every stage before beta testing
Never consider work really complete; continue
Declare work done and move onto next thing without
evaluating feedback and surveying users to drive
reassessing value or need to modify/optimize behavior
followup iterations
20. Keys to speed: paper
• Went “retro” for planning, design, and
visualization
– Used index card bleachers to organize the high-level project
components
– User stories were literally story-boarded
– Used presentation boards and Post-Its in multiple colors like
Colorforms to arrange GUI elements – and wire-framed the
results
– Used dozens of 3x5 index cards and Post-Its to map the deeper
logic underlying screen flows
– Captured certain visualizations with a digital camera on the spot
and posted them to the project Basecamp as a point of reference
for the team
21. Keys to speed: new “environments”
• Ergonomics, creature comforts
– Dual monitors
• Development framework
– AJAX
– Apache Tiles
– Spry
– XML
• Management framework (still playing with these)
– Basecamp, JIRA (web-based project collaboration)
– Jabber (IM-like messaging and conferencing)
– Pbwiki, Confluence, Drupal (online documentation)
– surveymonkey (online user feedback collector-analyzer)
22. Keys to speed: the “war room”
• Leveraged the social-ness inherent in teams
• Provides an extremely high signal-to-noise ratio
23. Keys to speed: optimized meetings
• Daily meetings of the action team (team
leaders, developers, designers)
– 15 minutes or less
• Twice-weekly meetings of the entire team.
– 30 minutes or less
• All other communication handled on the
teamlet level, via short-burst online chat/IM or
face-to-face
24. Keys to speed: “eating the elephant”
• To build is human; to iterate, divine
• Build first out of necessity, and then iterate
aggressively to grant user flexibility, comfort,
and – if desired – luxury:
– Dirt track single-lane cobblestone road two-
lane asphalt road Autobahn
• Start with one “story,” and then …
– Rewrite it
– Rewrite it again (embrace “change”)
– And (possibly) again
25. Our agile “mythology” scorecard
“Agile Myths” We Confirmed “Agile Myths” We Debunked
People first, then methodology, then Agility is just for programmers
tools – the best route from fragile to
agile for us
OODA worked (though no one explictly Agility is a silver bullet
knew it was OODA)
“Fail fast” or “fail early and often” is a Agility requires no discipline
speed-enhancing attribute; “gotta build
it to break it” (best to break it sooner)
User stories and personae were Agility means “perpetual beta”
critical to getting at REAL functionality
with VALUE
26. How we plan to stay agile
• “A good plan … executed now
is better than a perfect plan
executed next week”
27. It’s alive!
• Project your agility – allow the public/users/potential
partners to look behind the curtain at select
products way before even “soft” launches:
– Allow them into your “Labs”/“Skunkworks” – virtual
sandboxes for new, experimental, or evolving features
– Introduce the proposed alongside the old, and let the
users compare
28. Thanks!
AIP
Agility in Practice
Learn more at http://www.aip.org
The director’s cut of this presentation is available
at http://www.slideshare.net/secret/1hFBfq9FGEZEAj
CREDIT WHERE IT’S DUE
Redrawn version of John Boyd's OODA Loop by Patrick E. Moran.
Agile Lifecycle and other diagrams, courtesy Scott W. Ambler, Javapolis.
A lifetime of project-management inspiration via http://www.lessons-from-history.com/
Other images and sound bytes from the Great Internet Hard Drive.
