Feb Apln OC Shawna C

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!

Questions, Comments

Thank You!

Feel free to email me

seokizaki@sprintmail.com