This presentation was provided by Bill Trippe of Publishing Technology Partners, during the NISO event "Project Management for the Information Community: Managing and Communicating the Process, Session Six," held on Friday, March 29, 2019.

1. Project Management Trends in Publishing: Agile is
the New Norm and That’s a Good Thing
Bill Trippe, Publishing Technology Partners

2. Briefly About Me
• Consultant focused on publishing technology—focusing on people,
processes, and technology
• Founding partner of Publishing Technology Partners
• Former Director of Technology at MIT Press
• Over the years, majority of clients have been STM societies and
associations
• Trained in waterfall methodology, an adherent to the idea of
maturity models in all things technical, but all in on agile since
2012

3. The Results Are In
0%
10%
20%
30%
40%
50%
60%
Leaning Toward Agile Hybrid Pure Agile Leaning Toward
Waterfall
Pure Waterfall
Methodology
Methodology

4. Why are publishers going to agile?
• Publishers are running more systems, working with more outside
vendors, and developing more software themselves
• Publishing CIOs/CTOs have a portfolio planning problem: how to
run many projects more efficiently, flexibly, visibly, and
predictably
• Predictability and visiblility are often the most important things—
and these are Agile’s biggest strength
• Want to know how the project is doing? Come to the demo at the end of this
sprint (and don’t wait months for the waterfall “big reveal”)

5. How is publishing different from other
industries?
• Many products, sometimes requiring more systems
• A society that produces journals, books, standards, e-Learning, and multimedia
• Customers are often paying for and consuming digital products—
sometimes en masse
• The content and metadata flows into supply chains, where standards
must be met
• You don’t want to be the metadata manager the day the wrong book cover ends
up on the Amazon landing page
• Putting aside the evil empire, margins do not typically allow for enough
technology investment

6. How is publishing similar to other industrties?
• Browser and mobile dominate
• Customers expect to see you in every channel
• Legacy systems still abound
• Resources are scarce and expensive
• Change is a constant
• Technical investment is an imperative

7. For all these reasons agile makes sense
• More software needs to be developed
• Quickly
• Flexibly
• Visibly
• Predictably
• Engaging all stakeholders throughout the process

8. A tale of 28 freshmen
• Freshman seminar on running creative enterprises
• Goal—teams of four students develop a proposal for an app
• Combine content and interactivity
• Develop 20-30 user stories
• Develop a style tile for the look and feel (http://styletil.es/)
• Choose the stories that will constitute the Minimum Viable Product
• Choose the stories that will remain in the backlog for future planning
• Conduct a SWOT analysis on the product
• Strengths/Weaknesses/Opportunities/Threats
• Deliver the results in a presentation and supporting report

9. First class
• Five slides on agile methodology (thanks Maureen!)
• Ten minutes to develop an idea for an app
• (In fairness, they knew this part was coming)
• Brief pitch of the app for class reaction
• Did I mention these were incredibly good ideas?
• Gave them a template for writing user stories and asked them to
write five in class
• Did I mention they were really good user stories?

10. Second class
• They pitched their style tiles
• Did I mention they were great?
• Explainer on MVP, no more than 15 minutes, using LinkedIn and
WhatsApp as examples
• Did I mention they get what an MVP is?
• Explained my SWOT thinking to them
• Had worked with SWOT before so not new
• Used LinkedIn as example
• Had them develop two of each for their app
• Did I mention they get it?

11. Third class
• Now remember they started on a Tuesday, picked up the work on
the following Tuesday and were now presenting it all on that
Thursday (Yesterday! Bless them!)
• Final pitch, short form and long form
• Style tile
• 30 user stories
• MVP
• SWOT analysis
• Backlog—what didn’t make it into the MVP

12. My point?
• Besides the fact that I love my students?
• They understand the process intuitively
• It’s not just they are digital natives; they are
• Consider most were born 6-7 years after Amazon launched
• It’s not just that they are business students; they are
• It’s that agile gives them a framework to converse about
technology as both users and business people
• And! They. Had. Fun. At the end of the first class they gave
themselves a round of applause.

13. Enough about them; what about you?
• I said at the beginning that technology change is about people,
processes, and technology
• Agile brings the business people and technical people together in
productive and useful ways
• Ongoing communication
• Record of decision making through tools such as Jira
• A project body of knowledge enabled by the process and the
platforms (Basecamp, Pivotal Tracker, GitHub, Confluence, etc.)

14. Client example
• STM society publisher
• Began the transition to digital beginning in 1998
• Successful by every measure—reputation, revenue, innovation,
new product development
• Moving to agile BUT
• Intentionally don’t do the software development themselves
• They staff projects with some combination of a project manager,
product manager, and business analyst

15. Two very similar projects, two vendors
• Both vendors ostensibly “agile”
• Both with excellent reputations
• Both approximately the same size
• Both projects at the same scale
• One went superbly, the other had modest success
• What was different?

16. Two very similar projects, two vendors
Vendor A (modest outcome) Vendor B (excellent outcome)
Basecamp for document sharing, informal
Google spreadsheet for user stories
Shared intranet for document management
(Sharepoint), comprehensive Excel
spreadsheet for user stories and backlog
Daily scrums via Webex Thrice-weekly scrums via Webex
Uneven team participation on vendor end Highly focused participation on vendor end
(all hands at all times)
Diffuse tracking of activity against user
stories and outcomes
Constant refocus back on user stories and
outcomes
Issues lingered, response lagged Issues were driven to conclusion or tradeoffs
were made
Technical work may have been a B- but
perception was a D-; stakeholders at times
“wandered off” because of lack of focus
Technical work may have been a B+ but
outcome was in fact a success—stakeholders
engaged throughout decision-making

17. Lessons learned for client
• Articulation and refinement of the use cases is critical
• Tools less important than process (though also recognized doing larger
projects requires a tool such as Jira)
• Constant focus on stories, testing, and outcomes is also critical
• Diffuse tracking allows problems to linger
• Also true in waterfall but easier to “course correct” in agile
• Stakeholders will stay engaged when you honor their time commitment
• Vendor A lost the stakeholders when they didn’t come to resolution—or help
drive a decision
• Vendor B maintained the stakeholder commitment and enthusiasm by fixing
problems or driving a reasonable decision

18. Finally, that system isn’t going away
• The system you begin to deploy today could be in place 10 years
from now and longer
• For a major system, you will be doing some level of development
for perhaps just as long
• Agile helps here as well—incremental development and continuous
refactoring and improvement
• Used well, the tracking and document management/wiki
platforms will support users and developers for all of that time
• Documentation, knowledge bases, and hacking your wiki