This document summarizes the experience of Tribune Technology in adopting Agile methodologies like Scrum. It describes how the organization consolidated different IT teams across properties into centralized teams in 2008. An initial attempt to adopt Scrum for all projects led to issues with too many projects, lack of dedicated resources, and treating all project types the same. Over time, the organization learned that Scrum is best for software development and not all project types. Standards and tools were introduced to provide more structure. The organization realized Scrum is not a silver bullet and they need to prioritize the business needs, not just backlogs. Dedicated team members and travel for distributed teams are also important factors for success.

1. Agile and Corporate Clash
a case study of Tribune
Shawna Cullinan
Tribune Technology

2. Old Organization
 1000+ Tech employees
 Each property has their own IT Staff and projects (Orlando
Sentinel, LA Times and Chicago Tribune to name a few)
 Within each property, line of business projects, interactive
projects and support are separate units (each has a PMO,
Developers, help desk.)
 Known as a publishing/news organization
 Redundant/duplicate project – each property has similar
goals

3. 2008 – Consolidation and Restructure
 The business merges, but splits between two organizations
(Tribune Interactive and Tribune Technology)
 Consolidation of resources and departments (1 PMO team,
1 QA Team, 1 Dev Team, etc.)
 Centralized in Chicago
 Reduce staff by half
 Elimination off-shore teams and consulting firms
 Most departments are shared between TI and TT

4. New Organization
 500-600 employees in Technology after consolidation
 Focus is being a „Media‟ Organization
 Distributed teams across the US
 Departments are consolidated verticals (QA, Development,
PMO…etc.)
 Shared resources between 2 business units (TT and TI)
 PMO contains a mixed skillset (some waterfall, some agile)
 Support multiple parts of the business including broadcast,
publishing and online media
 We are in Bankruptcy!
 New start - let‟s be agile!!

5. Waterfall Methodology
 Waterfall tends to overproduce, create too much inventory
(documents, features, code, etc.) Too Much Waste!!
 Because requirements are all determined up front, when a product is
delivered, only a subset of predicted features are actually frequently
used by the users
 Once Product is delivered to the client either the business or
requirements have changed.
Time
Budget Quality

7. What is Scrum?

8. The Agile Model
Scrum is not a Methodology
Scrum is a framework
How your team adapts and how good or not-good it is becomes highly
visible
Your team gets to continuously improve
Quality is NOT Estimate
negotiable!!
Scope Importance

9. 2008: Agile adoption
2008: Attempt to move everything to scrum:
 Mandatory Scrum classes are held across technology
 Throw away old processes
 Implementation and Development projects are treated the
same
 Current long-term projects are overhauled to follow Scrum
process
 Project Plans become backlogs
 Went from heavy thick documentation to little or no
documentation
 Teams are iterating and adapting

10. Issues
 Too many projects and resources aren‟t dedicated
 Multiple tools are used for tracking, QA, and
collaboration (Legacy)
 Implementation and Development projects are
treated the same… they are NOT the same.
 Duplication continues to occur (no collaboration
between projects)
 Projects are started with no designs, backlogs or
analysis

11. We Iterate
 Each major project is sources with a “triad”
 Scrum Master
 Product Owner
 Solution Architect (Tech Lead)
 Standardize utilizing Jira for tracking tasks and bugs
 Standardize on SharePoint for document repository
 Planning meetings, daily standups and demos become
mandatory
 Standard Status Reports are created and sent to all execs and
teams

12. Looking for Answers … The PMO Vs. Agile
 When and how does an idea become a project?
 What do we need to know when to staff a project?
 How long will a project require resources
 How do I get money for my project?
 How do we communicate progress to executive
stakeholders?
 At what point do we kill a failed project?
 How do we know we are working on the right things?
 When do we retire a product?
 Once a project is completed how do we calculate
success?

13. Further Pain Points
 150 projects are slated to be completed
 70 development projects and 68 developers
 One-off & Out of the Blue requests
 Products are all based in different technologies so
resources are limited
 Too many cooks in the kitchen
 Attempting to „operationalize‟- how do we support all of
these products?
 Endless (or useless) Discovery
 We never retire or turn anything off
 Critical projects are in trouble

14. Executives Unhappy
 Frustration from executive management
 Don‟t understand terminology or artifacts
 Can‟t find documentation in one location
 Lack of standardized reporting
 Missed deadlines are not clearly communicated
 Missed deadlines are occurring often
 No project plans

15. We Iterate, Again.
 Begin Time Tracking (nobody is happy with this)
 Grasp of all of our resources and skillsets
 Resource planning meetings from the managers
 Projects are required to be submitted through an evaluation
system where they are put in a queue and validated and
prioritized (Required fields help to define the projects)
 Improve tools and require PMO to fill out basic set of
documentation.

16. Executive Team Sets Expectations
 Get things done ASAP
 CAR (or capital ask) must be made before any
spending can be done on the project
 Project Plan must be delivered with the CAR and
it must state dependencies, resource gaps and
timelines
 Technical Requirements and functional specs

17. Going Back to PMO Basics
 Time to adapt and realign our strategy
 Organization of Projects into Programs
 Organization of Programs into Portfolios
 Alignment of Work with Strategy
 Create a Common Framework and repeatable process
 Common set of tools and artifacts
 Align “Technology” to support an over arching
roadmap and vision
 Solution Life Cycle project created to create
standardized, artifacts, tools and reporting

18. Enough to provide the ability to be efficient, effective,
controlled and repeatable.
Not too much that we're not flexible or able to produce
quickly.
The key is automated, integrated, standardized and simplified.
The goal is the value of standardization with as little overhead
as possible.

19. Zooming Out

20. Project Types

21. Standardization
 Some requirements are due up front
 Light project charter – Mission, goals and objectives of product
 Capital Request form (any hardware, travel, etc.)
 Project plan (which should include the info after first release
planning meeting)
 Resource ask (Roles and responsibilities - who do you need to make
up the team)
 Technical SWAG – (Some wild A– Guess) so that we can see size of
project.
 Standardize our toolset
 Project Request system (form and database)
 Project Tracking, burndown and QA done in Jira
 Project Documentation stored in Project Server
 Automated reporting – pulling from project server for risks,
milestones and resourcing issues

22. Oh no!
Suddenly things feel less Agile
•Realization - Scrum doesn‟t work for ALL types of project work
• Software Development – Scrum works!
• Purchased Software
• Infrastructure
•Agile=small iterative cycles of development and continuous
improvement
•We get to continue to improve (both within our teams as well as
an organization)
•Standardization and communication is just as important.
•We have a ways to go. Admitting that is the first step!

23. Retrospective
 Scrum is not the silver bullet. We have to work at being
agile!
 We need to prioritize our business, not just our backlogs!
 Teams needed dedicated members
 Travel is key for distributed teams – and is now accounted
for in the budget. NOTHING will replace face time.
 Standardization is key. Team members and executives
depend on a repeatable process within a team and between
teams

24. Tools and Tips – before the team is
assembled
 Every project should have an elevator or mission Statement
 For (target customers) who are dissatisfied with (the
current market alternatives), our product is a (new product
category) that provides (key problem-solving capability).
Unlike (the product alternative) we have assembled (key
"whole product“ features for our specific application)
 Highest priority features
 Product box idea. (Think this way for sprints,
phases/releases, and when product is ‘done’.
 All Stories / requirements should align to these
 Short Term Vs. Long Term Goal (ROI if available)
 Avoid big bang rollouts as much as possible
 Assumptions and Constraints
 Constraints and assumptions
 Resource needs
 Dependencies
 Stakeholders / Business owners and what they care about

25. Message
 Scrum is a GREAT tool to expose issues. There are still standards.
 Don’t combine planning and tasking
 Don’t miss standups
 Protect your team!
 Use Scrum for the right type of projects. It doesn’t fit every model
 Look at the large picture. It is easy to get caught up in the details
 Understand your audience – Just like you may not read code don’t expect
your executives to know scrum terminology!

26. Questions, Comments
Thank You!
Feel free to email me
seokizaki@sprintmail.com