Feb Apln OC Shawna C

  • View

  • Download

Embed Size (px)


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

Text of Feb Apln OC Shawna C

  • 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 (OrlandoSentinel, LA Times and Chicago Tribune to name a few) Within each property, line of business projects, interactiveprojects and support are separate units (each has a PMO,Developers, help desk.) Known as a publishing/news organization Redundant/duplicate project each property has similargoals 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,PMOetc.) 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 - lets 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 isdelivered, only a subset of predicted features are actually frequentlyused by the users Once Product is delivered to the client either the business orrequirements have changed. TimeBudget Quality 6. What is Scrum? 7. The Agile Model Scrum is not a MethodologyScrum 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 NOTEstimatenegotiable!! ScopeImportance 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 thesame Current long-term projects are overhauled to follow Scrumprocess Project Plans become backlogs Went from heavy thick documentation to little or nodocumentation Teams are iterating and adapting 9. Issues Too many projects and resources arent dedicated Multiple tools are used for tracking, QA, andcollaboration (Legacy) Implementation and Development projects aretreated the same they are NOT the same. Duplication continues to occur (no collaborationbetween projects) Projects are started with no designs, backlogs oranalysis 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 becomemandatory Standard Status Reports are created and sent to all execs andteams 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. 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 soresources are limited Too many cooks in the kitchen Attempting to operationalize- how do we support all ofthese products? Endless (or useless) Discovery We never retire or turn anything off Critical projects are in trouble 13. Executives Unhappy Frustration from executive management Dont understand terminology or artifacts Cant find documentation in one location Lack of standardized reporting Missed deadlines are not clearly communicated Missed deadlines are occurring often No project plans 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 evaluationsystem where they are put in a queue and validated andprioritized (Required fields help to define the projects) Improve tools and require PMO to fill out basic set ofdocumentation. 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. 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. 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. Zooming Out 19. Project Types 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 releaseplanning meeting) Resource ask (Roles and responsibilities - who do you need to makeup the team) Technical SWAG (Some wild A Guess) so that we can see size ofproject. 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. Oh no!Suddenly things feel less AgileRealization - Scrum doesnt work for ALL types of project work Software Development Scrum works! Purchased Software InfrastructureAgile=small iterative cycles of development and continuousimprovementWe 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. Retrospective Scrum is not the silver bullet. We have to work at beingagile! We need to prioritize our business, not just our backlogs! Teams needed dedicated members Travel is key for distributed teams and is now accountedfor in the budget. NOTHING will replace face time. Standardization is key. Team members and executivesdepend on a repeatable process within a team and betweenteams 23. Tools and Tips before the team isassembled 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. Message Scrum is a GREAT tool to expose issues. There are still standards. Dont combine planning and tasking Dont miss standups Protect your team! Use Scrum for the right type of projects. It doesnt 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 dont expectyour executives to know scrum terminology! 25. Questions, Comments Thank You!Feel free to email me seokizaki@sprintmail.com