Agile Transformation at Nickelodeon Digital

We began our Agile transformation at Nickelodeon Digital in 2011 and along the way have faced device and platform proliferation, increased competition due to upheaval of traditional content distribution models, and growth in our Agile operation. This paper will detail how we evolved team structure alongside product vision in a shifting business landscape, the development of our innovation program, and our transition to a scaled Agile model.

The Nickelodeon Digital team creates playful and surprising virtual experiences for kids and families everywhere they are. Our portfolio includes the Emmy Award-winning Nick App, the Nick Jr. App and its companion Apple Watch App, and the direct-to-consumer Noggin App across a diversity of platforms including iOS, Android, Web, Apple TV and Roku—with more in development.

To tell our story, I will share the following:

• Our move to Agile, how we realized continued coaching was a critical part of our process, and what we did to reinvigorate our practice
• How product vision and the need to scale our engineering capabilities influenced the way we organized our teams, and the challenges with each configuration
• Creation of our innovation program, 70/20/10, and its place and importance in our organization
• How the growth in products we supported triggered our move to a scaled approach, and what that means for Nickelodeon

The timeline in Figure 1 in the attachment shows the key moments in our journey as described above.

The author is the technology portfolio lead for Nickelodeon, where among her responsibilities she oversees the Agile program and project management team.

The Digital division is a cross-functional group within Nickelodeon, composed of several functions: Product Management, User Experience Design, Engineering, Project Management, QA, Content Development, Content Programming, Audience Development, Analytics, Consumer Insights, and Operations. We have stakeholders and partners spread across the rest of Nickelodeon, such as our on-air linear counterparts and brand creative groups, as well as throughout Viacom, our parent organization.

In creating our digital products, we strive to relentlessly improve the user experience, and maintain a deep tradition and culture of user research, focus groups, consumer co-design, and user testing. Playfulness is in our DNA. We are the home of the Do Not Touch button, and unique content types such as “alphamations” – 5 second funny, adorable, and educational animations for the pre-school set. Our April Fool’s stunt allowed our users to virtually slime our websites and apps, using Nickelodeon’s trademark green goo that oozes its way across everything we do.

The impetus for our Agile journey began in late 2011 with a collective desire across Product Management, Engineering, and Project Management to have a more efficient way of working. Product managers were authoring dense bibles of Product Requirements Definitions (PRDs), engineers wanted a different way to manage estimates and dates, and project managers felt like taskmasters, driving the team against schedules that they didn’t fully understand or own. We were also noticing a trend of Agile adoption by leading technology companies, and Agile was being adopted in other areas of Viacom. Our own process wasn’t serving our needs, and we wanted to be able to iterate quickly, remove overhead, and feel less bureaucratic.

With the help of Viacom’s technology Project Management Office (PMO), we identified an Agile process partner to outline how we would get our Agile program off the ground and pitched it to our executives in early 2012. There was some skepticism about jumping on the Agile bandwagon, but having the leads of Product, Engineering, and Project Management pitching a more efficient process was a critical part of gaining the approval to move forward, along with an executive training. With executive approval, we formed our first dedicated, cross- functional teams and began building our Agile practice using Scrum.

Our first year of Agile involved varying challenges and degrees of mastery among teams. One team took five sprints to ideate and build varying prototypes for a key show launch that was expected to deliver much sooner, the lesson being to timebox ideation if schedules do not allow. Another team launched our first major project using Scrum, Viacom’s first mobile responsive website. That project highlighted how we were transitioning from traditional ways of scheduling and tracking, and we sought coaching to help build our release plan in lieu of a traditional project schedule. Missing requirements were a large risk and so we took a couple days to conduct story writing workshops, so that Product Owners could flesh out undefined stories in the backlog.

We started to find our rhythm and continued to build our products, including our first native mobile apps, the Nick App on iOS and Android. As we were heads down on pushing towards new product launches, we made the mistake of letting our coaching lapse, and with it, our focus on continuous improvement. Teams were practicing Scrum, but without someone looking over the health of the program overall, teams started diverging on best practices since the initial training. New team members with less Agile experience were left to fend for themselves in interpreting Scrum and establishing their story-writing and estimating techniques, as were new teams who were formed in response to resource reallocations and business priorities. In addition, we were not looking at improvements we could make overall; retrospectives happened at the team level, but we were not inspecting how we could improve our practice as a group.

In 2014, we took a step back and realized that we needed to reset our teams and reinvigorate our practice. We established an Agile steering group consisting of the function leads (Product, Engineering, and Project Management) who maintained and worked on a backlog of overall Agile program initiatives, as well as a budget for regular coaching hours, making our coach available to anyone who wanted to consult with her at any time, and evangelizing her presence in department meetings. We kicked off our Agile reboot with an in-depth assessment and re-training of all teams.

3.3.1       Pre-Scrum: A Sales Driven Organization

As our Agile adoption got underway, cultural shifts in our organization were taking place as were industry changes, and we modified our team structure in response to these changes. Product thinking was changing to a focus on building products that would deliver value to our users first while still accomplishing business goals, which would in turn increase engagement and drive sales.

3.3.2       2012: Product Driven Teams

We first built our teams around our website features and products: Videos, Games, Community, and Shows. Projects that didn’t fit into these areas such as technical infrastructure projects and projects for smaller sites were run as more traditional projects. Operational teams ran as separate teams, some of which moved to Kanban due to the short duration of the task requests and quickly changing nature of their priorities.

In theory, the scrum teams covered both Nick and Nick Jr. audience groups. However, time spent on our core business focused on kids 6-11 dominated the attention of the Agile teams, while Nick Jr. work fell in priority. In addition, the Product Owners who served as points of contact to the rest of Nickelodeon interfaced with the rest of an organization structured around audience channels, not by products. It became apparent that by organizing ourselves around products and features, we were in mis-alignment with the rest of Nickelodeon and were losing focus on the customers.

3.3.3       2014: Transition to Audience Driven Teams

We re-organized our teams around audience groups in 2014, creating full teams for each platform we supported, starting with Web, then iOS, followed by Android. Emerging platforms at the time such as Xbox 360 and Roku were supported by smaller teams consisting of a Product Owner, PM/ScrumMaster, and third party partners for technical development. We made hard decisions to sunset or consolidate support for one-off features, sites, and brands that were not core to the strategy. We created a separate Operations team outside of the Agile teams to support day-to-day content operations, so the Agile teams could stay focused on the feature backlog. Teams became responsible for the remaining production and support work, further consolidating those operational teams into the Agile teams. The Agile teams also supported their own technical infrastructure projects.

Even as we created efficiencies, we were starting to stretch the limits of our existing structure. By 2015 we had sixteen sites and apps that we were supporting, with new market opportunities in technologies we had expertise in, such as Android TV and Apple TV, but did not yet support. The engineers were not sharing code and were re-implementing the same features across multiple apps. We were unable to quickly swarm around our biggest problems and highest priorities, as our engineers were divided up amongst our many teams and roadmaps.

3.3.4       2016: Audience-Driven Teams, organized by Technology Platform

To address our technology challenges, we pivoted again at the end of 2015 and began pooling our engineers into teams based on technology platform. We started with the Apple Platform team, whose scope expanded to include the entire Apple ecosystem such as AppleTV, not just iOS. This structure represents our current configuration. The team consists of Engineers, UX designers, PM/ScrumMaster, and an Apple Product Owner. To stay aligned to our users, the three Product Owners for the audiences maintain expertise in their customers and operate outside the team, and meet during backlog grooming to jointly prioritize their requests into a single Apple Platform Team backlog.

We initially created separate audience Scrum teams consisting of Product Owner and UX designers, but found that our process was starting to feel more like waterfall. UX designers were not collaborating directly with the engineers as they had in the past; designs were being thrown over the fence to the platform team, and design reviews were happening at the end of the sprint instead of continuously throughout. We added UX designers back to the platform teams, who have started to see benefits of design sharing and re-use, similar to the engineering benefits. The ScrumMaster plays a large role in ensuring that the rituals such as daily scrums and backlog grooming stay efficient with a larger number of participants.

We applied these lessons learned from the Apple Platform team and created the Web Platform team the following quarter, and as of this writing we are about to platform the Android team.

This has been a huge shift in the way we work, and mid-year into the transition, we are still working through the implications. Engineers are looking for commonality and efficiency, while product managers are trying to maintain audience expertise and differences where relevant. These goals are seemingly at odds, and we need to ensure we stay focused on the audience now that we have realigned by platform. We also need to find ways to ensure the audience focused team members, who now sit outside the Scrum team, can provide input and collaborate with the platform teams. In addition, to gain the benefits of pooling engineers, we also have to first build each platform and get all of our sites and apps onto those platforms, which is no small task.

We are realizing some benefits of the platform approach. Senior engineers and subject matter experts are able to mentor junior engineers across multiple products and projects; previously the best person to provide guidance to a junior team member was not always on the same team. This has resulted in more efficient delivery of key features such as A/B testing.

Some metrics we are looking to use to evaluate the success of the new structure are using a morale rating to assess whether the team thinks things are working better than before, and increased roadmap delivery, which we will measure at each quarterly retrospective.

As we became better at Scrum and our process for execution, we started reflecting on creativity and innovation. Roadmaps were data-driven and felt dictated by strategic priorities, business cases, and executive approval. This was rightfully so, but where was the fun? How could we carve out space for the teams to be creative and innovate – infusing the playful essence of Nickelodeon into our process and product – while still achieving what we needed to get done?

One of our efforts at stimulating innovation involved a two-day “Design Studio” workshop in May 2015 for the entire group. We divided the group into cross-departmental teams including groups across the company with the assignment to propose ideas unencumbered by day-to-day operations and constraints. Activities involved creating user personas, user empathy maps, and brainstorming techniques, with the groups refining their ideas to a final presentation that were judged by a panel of executive stakeholders. The session did produce big ideas as well as many good ideas for smaller individual improvements, but we wanted another mechanism to keep innovation flowing in the day to day activities of the teams, beyond this one-time event and other events we have run such as internal hackathons.

We created a task force to identify the best way to implement such an innovation program into our processes, and created a framework we call 70/20/10. The numbers propose a percentage of work dedicated to the types of work we envisioned – 70% of the time should be spent on “Stuff We Need to Do”, 20% of the time on “Stuff We Should Do”, and 10% of the time on “Stuff That’s Crazy Fun.” The 70/20/10 concept was not a novel idea; Google’s famous “20% time” policy encourages employees to spend 20% of their time on any projects they thought would benefit the company. However we needed to figure out how a concept like this could best work for us.

The task force further defined these categories as follows: “Stuff We Need to Do” is the time dedicated to our product roadmap – core business tasks such as new features with known scope and value, as well as performance improvements and bug fixes. “Stuff We Should Do” includes projects related to the core business that require exploration or new approaches to existing features. “Stuff That’s Crazy Fun” includes projects that may challenge our definition of value or be unrelated to the core business, bringing ideas from the bottom up.

To work on a 20% project, Agile teams volunteer based on interest and ability to generate validated learning and consider solutions across the portfolio, enlisting help from others as needed. The teams are encouraged to demo early and often, testing their ideas through prototypes and usability or A/B tests, with the results shown to the group. Rules for the 10% projects are slightly more constrained since the assignment is more open-ended – Agile teams agree on scope and timebox the effort to deliver a prototype. Stories are created and pulled into the sprint like any other feature, and results are demoed to the group. The 10% work is blue sky – teams are not asked to justify the work with business value; this is the place for crazy, fun ideas with no clear solutions, no clear roadmap and no clear benefit!

April Fool’s Day on 2016 provided the first ideas to come out of the 70/20/10 program that successfully made it to our live apps and sites. A developer on the Nick Web team had finished his committed stories before the end of the sprint, and instead of picking up another ticket from the backlog, used the remaining day to prototype a prank for April Fool’s Day – what if a user could use their cursor to virtually cover the Nick website in green slime, a “slime cursor”? It was shown to other teams and stakeholders and was a hit – it was fun and unexpected, and invited our users to play, true to the spirit of Nickelodeon. The product managers across the teams more fully fleshed out the requirements and acceptance criteria, and we rolled it out across the Nick Web, Android and iOS apps during our Kids Choice Awards event. We are also creating a version for our Nick Jr. platforms. The actual April Fool’s Day stunt was extended from this idea – when the user clicked on certain areas of the site or app, the site appeared to “break”, with pieces appearing to crumble down the screen.

70/20/10 has worked primarily to produce small, bite-sized features, but for larger initiatives with creative questions that still need answering, we’ve found that those need more structured assignments. We have created task forces dependent on the need; one task force involved our entire UX design team taking three days to brainstorm and present solutions. Another task force consisted of a cross functional team given 90 days to produce a prototype ready for a usability test.

Even though we are addressing the larger creative questions with a more coordinated approach, the 70/20/10 provides value beyond the resulting incremental features on our roadmaps. The April Fool’s stunts showed how teams can generate small, spontaneous ideas that inspire our products and users. It permits, encourages, and empowers the teams to explore the unknowns, which stimulates a larger creative culture and is a large driver for morale.

We first started discussing scaling Agile and SAFe in late 2014, to address how we might better work as a group instead of as individual teams. The idea of synchronizing our teams to release trains did not appear to apply, as most of our teams delivered standalone sites and apps that did not seem to rely on the other teams for delivery. The exceptions were the Services and Ads & Reporting teams which supported all our teams and products, and while there was always room for improvement, for the most part we felt we were managing those streams appropriately. SAFe was a dense body of knowledge that seemed to be overkill for our situation.

We revisited the idea of a scaled approach again during latter half of 2015 as a possible way to address the challenges we were feeling supporting the multiple platforms – lack of collaboration and knowledge sharing across the 16 sites and apps we were supporting with limited resources. Together with our coach, we came up with a lighter weight application of SAFe, limited to a 3 day increment planning session to map out the upcoming quarter.

The first challenge we faced was to gain support in the group and have the functional managers and leads in Product, Engineering, and Project Management understand the value of a scaled approach. We invited them to several workshops to lay out pain points and issues they were experiencing – teams working in silos, teams blocked by dependencies on others, lack of collaboration, and discussed how a joint planning session could help in these areas.

The leads were in favor, so the next step involved communicating the approach to executive management and getting approval to try it. We outlined our goals of improving collaboration and planning for dependencies, with our deliverable being a roadmap estimated by the teams. We were given the go-ahead to proceed with the first meeting, with the understanding that we would evaluate its effectiveness after the session.

We faced several logistical challenges in pulling the scaled planning together, such as getting involvement from over a hundred participants, including people from our main office in New York, and individuals in remote locations such as Canada and California. We utilized travel budgets and our Agile budget for reserving space for the session. We did not want people to perceive the several days away from their desks as a waste of time, so we allowed people to bring laptops and get work done in the time periods where they were not actively involved. Due to timing and scheduling constraints, we did our first planning after the increment had already started, so the first planning session was more about validating our existing roadmaps which had already been presented to executives, and making adjustments to those as we learned more in our planning. We also had new team members included in the planning, some of whom had not had formal agile training before. Our coach facilitated the session and was on hand to monitor and help where needed, as well as senior team members who led some of the activities such as story writing. In addition, none of our team had been trained in SAFe, so we needed to work closely with our coach to come up with a format for the workshop.

There was tremendous positive feedback from the teams after our first planning. People felt like they were able to influence planning as opposed to just receiving the results after it was completed. We also understood our methods and team dynamics better and created a presentation to communicate this additional information (excerpts attached in the submission) to department VPs and our SVPs. Now as we are about to complete a full year of doing scaled planning, it feels like a necessary piece of our process – we carve out time for people to dedicate to planning, and everyone who wants to have input is present, including our stakeholders outside of Digital. We also have begun presenting executive summaries after each planning session, including a retrospective on how we delivered against our plans, and we also have shortened our workshop to two days instead of three.

For our senior leaders, ramping down productivity for all the teams is a big investment and carries some risk. However, they can see the benefits of having an intensely focused session where all team members participate in planning out the details of work for the near-term. It’s a highly efficient way to use in-person dialogue to dig into opportunities and constraints that lie in the road ahead for each agile team as they progress towards their product goals, and pays off in the long run by reducing surprises. Furthermore the scaled agile sessions allow the entire organization to see in detail which problems and opportunities their peers will be focused on. Emerging from the sessions, it is extremely valuable to have a prioritized list of work at a detail level for 90 days that the team has a high level of commitment to. We feel confident in sharing that information with executive stakeholders as a contract for delivering value to our customers that ideally ladders up to annual organizational goals. It is an essential part of drawing a through line from tasks to strategy at all levels.

Viacom has begun expanding scaled planning to include the teams that support our digital components such as our video player and content management system, as well as to additional brand groups beyond Nickelodeon. Challenges we hope to address, particularly in the component area, include collaboration amongst the hundreds of team members in the brand and component groups, identifying dependencies, aligning these multiple groups and priorities amidst limited resources, creating budget traceability, and providing a common framework to give visibility into what projects teams are actually working on. These areas have been pain points that our executive leadership have been wanting to solve, and we secured their buy-in by communicating these goals as well as our successes in Nickelodeon.

For Nickelodeon, we want to continue building on scaled planning – looking back at the previous quarter in each retrospective, assessing our delivery through agreed upon metrics, and removing any impediments that might prevent successful delivery next quarter. We will monitor our platform team model, with the goal of realizing efficiencies with larger teams and staying focused on the customer. And we will continue our 70/20/10 program to create small, fun moments that inspire our products, users, and teams, while creating task forces for larger creative questions.

A constant challenge we face is developing the effectiveness and maturity of the teams. Team dynamics are ever changing due to new people joining the team or external factors; for example recent facilities changes have temporarily dispersed all the team members who were previously on the same floor to multiple locations and floors for six months, reducing “water cooler” conversations and interactions that often serve to connect the dots between team members. Our project manager/ScrumMaster role has traditionally focused on project delivery, but continuously improving our teams may require an increased role in internal coaching on a day to day basis, beyond the spot checks our external coach provides.

For those embarking on an enterprise agile program, we offer the following advice:

• Invest in continuous training and coaching. After your Agile program kicks off, ensure there is budget for continuous training and coaching. Team members come and go, and teams disband and re-form. New team members may need training or a refresh on the basics, and newly formed teams will often need to run their first sprints on “training wheels” with a coach’s help. Seasoned teams and team members will undoubtedly have questions or encounter challenges where it is helpful to have a coach to help point them in the right direction. There is always room for improvement, and working with a coach will help stimulate ideas and action to improve.
• Work with a coach who understands your teams, your industry, and your organization, and develop a long term relationship. Choosing a coach feels a lot like choosing a doctor. They need to have experience with your particular challenges – someone who coaches small teams may not be the right fit for a large organization with requirements such as budget tracking, project reporting, or working in a matrixed environment. You need to have a compatible perspective with your coach so that you can come to agreement on possible solutions. And as you develop a history of working together, they start to better understand what does and doesn’t work for you.
• Create and report on metrics or criteria by which to evaluate changes, measure progress, and drive improvement. In large companies that have more than a handful of teams, executive stakeholders are not always able to attend all demos, and want visibility into “how the teams are doing.” Teams and ScrumMasters also may be looking for guidance as to which areas they should be prioritizing for improvement. We are working on establishing standardized, accepted metrics across the teams, summarized in a metrics report, to give stakeholders a view into the health of the teams. One metric we are in the process of rolling out is an Agile Maturity Model assessment, delivered with our quarterly scaled retrospective, to provide guidance for improving our effectiveness at Agile. Another approach we are considering is a “Delivery Factor” at the end of each quarter that expresses points delivered as a percentage of total capacity. For example, 70% of a team’s capacity resulted in points delivered, with the focus on highlighting impediments that our leaders or executives can help remove. Coming up with a few key metrics to report uniformly across several teams is not always straightforward. A metric that highlights an important concept to one team member may seem to send the wrong message to another. We are still working on finding the right metrics for our group.
• Ensure a travel budget for remote team members. While not ideal, the reality is that many organizations utilize remote team members. As we rebooted our Agile practice, we ensured that these team members were able to participate in some capacity in scaled planning sessions and team trainings in person, so that all team members had a common understanding of our methods and practices.
• Create a cross functional Agile steering team. A task force of team leads from the different functions can drive advancement through collaborating on a backlog of improvements to make or organizational impediments to remove. This is also a good forum to get agreement on program changes; 70/20/10, team platforming, and scaled planning all were discussed in this group.