Feb Apln OC Shawna C

489 views

Published on

Agile & Corporate Clash: Case Study at LA Times by Shawna Cullinan

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
489
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
4
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Feb Apln OC Shawna C

  1. 1. Agile and Corporate Clash a case study of Tribune Shawna Cullinan Tribune Technology
  2. 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. 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. 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. 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
  6. 6. What is Scrum?
  7. 7. 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 improveQuality is NOT Estimatenegotiable!! Scope Importance
  8. 8. 2008: Agile adoption2008: 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
  9. 9. 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
  10. 10. 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
  11. 11. 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?
  12. 12. 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
  13. 13. 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
  14. 14. 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.
  15. 15. 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
  16. 16. 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
  17. 17. Enough to provide the ability to be efficient, effective,controlled and repeatable.Not too much that were not flexible or able to producequickly.The key is automated, integrated, standardized and simplified.The goal is the value of standardization with as little overheadas possible.
  18. 18. Zooming Out
  19. 19. Project Types
  20. 20. 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
  21. 21. 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 continuousimprovement•We get to continue to improve (both within our teams as well asan organization)•Standardization and communication is just as important.•We have a ways to go. Admitting that is the first step!
  22. 22. 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
  23. 23. 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
  24. 24. 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!
  25. 25. Questions, Comments Thank You! Feel free to email me seokizaki@sprintmail.com

×