The software behind the scenes at Food Network and HGTV
A cable television network requires round-the-clock programming, an agile development team, some impressive software and a whole bunch of project management. CIO.com’s Matthew Heusser sat down with Tara Nicholson at Scripps Networks Interactive to find out how this complicated operation works.
By Matt Heusser
It’s a beautiful corporate campus in Knoxville, Tenn., sitting behind a sign for a company you might not have heard, although Scripps Networks Interactive is the home of a few cable TV channels you have heard of – Food Network, HGTV, Travel Channel, DIY Network, Cooking Channel and Great American Country.
Keeping all that television running 24 hours a day, takes more than a little IT. The organization has not only teams, but teams of teams, all working on similar projects and periodic releases. These projects might be small, each a tactical move, and it might be possible for a team to work on two or more projects at one time.
The larger, long-term, continuing investment is the Program. Programs organize releases, which is essentially a new release for an entire website. At Scripps, Programs each have an individual Program or project manager such as Tara Nicholson. Promoted from software test management, Tara Nicholson worked on testing, documentation and user experience before getting the call to manage the Home Category Program at Scripps.
Which brings up some questions. What does a program manager do, anyway? How does Scripps organize its teams? How do they pick projects? How do they plan? Where does “the business” end and IT start? What services does IT provide the business, and how and when does that change?
We met with Tara to find out.
CIO.com: Let’s start with program management – what is the scope of a “program?” Does your program have a specific name?
The Digital department of Scripps Networks Interactive is where we develop our Internet-based products and distribute them. In addition to supporting our broadcast channels, we also publish Food.com, a user-generated content formatted website, the In the Kitchen iOS app, several blogs including DIYNetwork.com’s Made + Remade, current episodes and live streaming on our Watch apps, and exploration into emerging platforms. We are an industry leader in online lifestyle media. We were founded on innovation, and this year we are celebrating our 20th HGTV Dream Home giveaway. How exciting!
The programs are organized around specific brands, groups of brands and strategic objectives. I’m primarily responsible for the Home program, which includes HGTV, HGTV Gardens, DIY Network and Great American Country. I work with software engineering, product, editorial, design and other teams for the delivery of new systems or features.
Many of us “live the brands,” and by focusing on a program, I find the teams embrace the lifestyle – often creating content that comes from the heart, like online products we ourselves want to use, say, for our own DIY projects. Our audiences can engage with us on the Web in ways that weren’t possible in the 20th century, and we love them for it.
CIO.com: How many teams do you manage – and what do the teams do? I imagine they keep the websites up, but are there technology tasks we wouldn’t expect?
Depending on the scope of a project, between five and 15 teams could be contributing to its launch. Most of those teams are internal, but can also include vendors.
We have two primary audiences we serve, the greater public of home-, food- and travel-loving individuals who browse and enjoy the live sites, and the internal content management system (CMS) for the editorial team to create and maintain pages. We have built the system to be open and flexible to give our creative teams the largest opportunity to present their images and articles in an intriguing way while maintaining an attractive, cohesive look. We also manage it to remove obstacles or inefficiencies so that their only challenge is coming up with good content, and not be delayed getting it onto the live site.
CIO.com: What does agile mean to you?
One of my favorite characteristics of this environment, particularly around an agile development implementation, is the types of deliverables we support, such as publication dates, large-scale technology changes, small-scale products or enhancements, maintenance updates and vendor integrations. Projects that support a publication date, such as HGTV Smart Home or Food Network Star, require scope and resources to be adjusted to accommodate an absolute date. Large-scale changes like moving the sites to cloud infrastructure involve many teams working in orchestra over a large amount of time. Each of these types of deliverables are bundled up into each of the programs. We choose a project management solution that is also variable.
We keep focused on the bigger picture by handling maintenance work, break-fixes, by prioritizing it within our roadmap. Bug-free and pixel-perfect software is a myth. We focus our resources on break-fixes that have meaningful impact and are worth spending time away from progress on new products or user interactions.
The Home Program is organized as one-team, which means from those resources, project teams or “pods” can spin up and wind down as the goals warrant. This lets engineers dedicate themselves to one project at a time, lowering the impacts of multi-tasking, and it gives us the ability to shift priorities quickly. The “pod” is multi-functional. We all still have our unique identity and skillsets, but we created habits that enable a good bit of cross-over.
CIO.com: Tell me a specific story about a project – how you estimated the scope, negotiated for resources, planned the work and coordinated the last few sprints?
We were recently launch partners with Apple News, a new app in the iOS 9 operating system. This is an example of a publication date-driven project in which date of completion was fixed, but scope and resources needed to be variable. The time frame from inception to completion was very short. The project “pod” was organized in less than a day by assessing priority of work in progress. The team was able to isolate itself from distractions while the tech lead, product lead and I ran reconnaissance.
Our product people are highly influential on the scope of projects, so that we can get new features like Apple News into the marketplace and see how they perform. This is where the concept of “minimum viable product” shines. Let’s see what our users like and build on that. Scope is determined by asking, “What do we really need to investigate an idea?” The challenge is to identify something that is useful and inspiring, but isn’t so complex that it’s months before trying it out in the marketplace.
Short, direct projects like Apple News use a modified Kanban approach. Higher-complexity, longer-duration projects with a significant number of dependencies lend themselves to sprints and variable delivery dates. Regardless of project characteristics, validation is in line with development. We are always in a deployable state and manage the overhead of the deployment pipeline so that we can deploy frequently.
CIO.com: What does the planning process look like? How do you plan the next release? How do you coordinate teams?
Whether or not we have a business need to deliver new code to production at a high-frequency daily basis, building a method of delivery that is consistent and lightweight enough to do so means we have optimized our resources, clearly understood our delivery infrastructure and appropriately accounted for risks. Let the repetitive tasks of delivery be low cost and low impact.
CIO.com: I realize that there are no typical days, but still, what is a “typical” day in the life of a program manager? Are there any weekly, monthly or other key meetings you attend?
My focus is working together with the engineering team, product team and brand team, determining the right things to spend our time and resources on.
This is also a planning and communication role. Identifying roles on a project – creating the right distribution list has an enormous impact on getting the right information into the right hands to avoid surprises. It seems like such a menial task, but it has real human impact. Over-communication causes important information to be ignored or responsibilities dropped. And, no one likes the surprises that result from lack of information. I try to be creative and concise with information sharing so that it cuts through the clutter.
One of my favorite meetings we call “Team Crushing It.” This is a collaboration meeting where individuals of Product, Engineering, Program and Editorial (but also an open-invite) take the user interaction numbers, and look at what’s performing well or poorly. This could be content or features of the site. We walk out of the session with ideas to test. Some ideas can require engineering, some ideas can be tried right away with the existing tools.
CIO.com: What are some of the challenges you face in program management?
I believe we have great talent in Digital: software engineers, architects, editors, designers, etc. Each of the programs focus on their unique brands and demographics. However there are some similarities, such as the service we use to create servers – our cross-team PaaS toolset, scheduling or monitoring tools, and test automation frameworks, where sharing knowledge offers some big wins. Focusing on individual brands has the potential to create the silo effect many program managers are familiar with. With busy roadmaps, differing processes and schedules, it’s challenging to share meaningful and actionable time together.
CIO.com: Do you have a solution for the silos?
First of all, it’s a journey to integrate siloed teams, not a destination. I don’t claim to have a solution, but I think it is important to build habits in individual and team behaviors that seek the desired information sharing. This can be in the way of structured meetings, like our “CrossWise” series. To draw participants’ attention out of their laptops and into the conversation, the leader(s) of this meeting has to think about what’s in it for the people participating. If the area of expertise is test automation, invite the test engineers, get them talking about recent findings, pain points and ideas. Let the discussion get technical, let them problem solve. Simply knowing who your counterparts are within the other areas of the company and what they excel at helps us see each other as resources.
It’s interesting what a good coffee machine a reasonable distance away will do for cross-pollination of teams. We also do movie days where we code and watch movies, corn-hole tournaments and we are about to try out a board game day.
The project and program managers have a big part to play, with each category in varying size, organization and location, connecting individuals with similar skills in a casual format. Getting the project managers together periodically to talk, we provide that bridge.
One of my favorites, though it’s only once a year, is our two-day internal tech conference. Our own employees present on topics they have a passion for, and attendees block time out of their busy days to learn something new. We call it Techtoberfest (it’s in October), and we’re in our sixth year. We have more fantastic topic submissions than we have time in the schedule. Topics range from video editing, innovation, successful practices, industry trends, etc.
CIO.com: You came from a software testing background. Does that still play a role?
Software quality is evolving rapidly. Automated solutions and shared responsibilities are my top two takeaways.
It’s not reasonable for teams to focus on innovative ideas if they’re bogged down by repetitive manual validation. It is time to learn from failed automation attempts of the past decade and move forward. We treat automation like code, make it scalable, manageable, and version controlled. Delivering automation code in high-value iterative pieces is a necessary discipline to avoid mistakes of the past.
Quality is everyone’s business now. This year, the Home Program moved from a traditional model of quality engineers owning all testing, to aligning quality engineers with the project “pods.” When manual testing is not available on the project, they switch to test automation. We were serious enough about this mission that they are now called “Test Automation Engineers (who also manually test).” Depending on the project, the “pod” might not have a dedicated Test Engineer, which drives the quality conversation earlier, and a validation plan approach that addresses risks is identified by the team.
For the Home Category, the standard sprint doesn’t work for us in all cases. We’ve taken our process platform and made it flexible enough that if a project team needs the layout of sprints, they can do sprints. If they need to all get in a huddle room and put color on the whiteboards, they can do that too.
CIO.com: What do you think makes teams successful?
Cultivating a learning environment. Technology is a fast-paced industry, and so is publication. We have to be quick and smart about what we go after. That requires us to build skills around new distribution channels like over-the-top (OTT) platform development, behavior-driven development practices, or looking for new and interesting features before we need them. The learning environment creates the habit of asking “why” often. When we ask why we do it this way or that way and know the history or the drivers, it challenges the team toward continuous improvement and problem solving with the right solution in mind. There are many contributing factors to successful teams, but in software, a learning environment opens the door to creating a place people want to work and have a sense of ownership.