Agile and Corporate Clash a case study of Tribune
Shawna Cullinan
Tribune Technology
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
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
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!!
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
What is Scrum?
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
Estimate
Scope Importance
Quality is NOT
negotiable!!
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
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
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
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?
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
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
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.
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
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
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.
Zooming Out
Project Types
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
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!
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
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
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!
Recommended
