 Good morning. My name is Chris Herring to be keynoting DrupalCon. It's such an honor for that to happen today to be able to present the first session here at DrupalCon Portland. So thank you for attending. There's an overflow room I know somewhere so I think we have plenty of seats. So today we're gonna tell you a little story about how we operate in terms of building a product, a Drupal based product that NBC Universal Brands can use to build out their web experiences. But I think I'll give you a little context first. Adam and I work for an organization, a centralized organization, which is called Very Creatively Operations and Technical Services. And I run a product development team that's really focused on building this product. We don't build websites, we build a publishing system that Brands use. A peer team of ours that naturally has some resources to build out web experiences for those brands that don't have their own development resources. But our team's focus is on building that core product. Also with us is Mike Bailey, and they'll do their own introductions when they go. Mike is the director of technology for SciFi, one of our leading brands, and SciFi's been a real partner. So as we get started we're gonna try to answer four questions today. Hopefully we answer a lot more, but please feel free to ask questions at the end. But really the four questions we're gonna try to answer is what did we build? And I'll talk about what we built using the internal open source development model that I mentioned. And I use that IOSS acronym specifically because I'm trying to internal open source is a relatively new term, sort of counterintuitive because we all think about open sources very open and very public. But it's hard for large companies like our own to participate in that model. So we're really trying to harness the same thing, the same ideas and the same processes in turn about what that means. Also if this sounds like a good model to you, you know how can you encourage involvement within your own companies or use this model and use our core product and talk about how agile enables this model to be. So first and foremost what do we mean by internal open source development? Well there's no difference, right? Like I said it's the same thing as regular open source development, but instead of using the general public to achieve some goals we're trying to harness multiple development resources within the company to achieve the same goals, to build this core product that all brands can use. So you know it's no different like I said it's so I think a little context would be helpful. So NBCUniversal the way it's organized is there's more resources like I said, but you know to us instead of building poor functionality that's similar across all of those brands and all those websites it makes sense to build something. We really tried to harness that model by just fostering open communication and being very transparent about what this core team is building. Our product is called Publisher, also very creative because it publishes content for the web. But you know so I think some some really good examples are you know things we all sort of take for granted in this business you know there's an analytics module for measuring web traffic there's no reason for each across all those brands. So you know I use this slide to sort of portray this idea that you know instead of 10 people working on building one small idea we should build one great product that all brands can use. So some of the things that we've built features of what we call Publisher 7 which is obviously based on Drupal 7. Publisher 7 comes with four content types that brands can just use as is. These include things that are specific for entertainment businesses. This module is a dark mod. You have members of the team that actually are a key member of the team or tech lead. You have an identity system we don't use Drupal 7. That also is something that's just obviously there's a trend here. This is what we're trying to do so brands don't have to keep repeating. Mike's going to talk specifically I think about this one piece which is the integration with our video services provider called the platform. One of the big reasons why we use them is our parent company Comcast also. So again we don't want to have each brand have to build those integrations. So I created this slide to sort of give some perspective. I don't have to tell this audience about the Drupal ecosystem and how large it is and how many modules are available but this is not to scale. By the way it's a little Publisher circle there but you know essentially we have 13 developers committing code to Publisher. Only five of them are part of the majority of the people and that's a real success from my perspective. It's not that they commit constantly it's that they have the ability to publish or distribution as we call it comes with over nine most of them are contributing. You know the Publisher ecosystem as I call it is made up of about 15 community numbers so if there's only 13 developers committing code the majority of those communities are QA resources. That number is growing and we continue to have that we continue to hope that that grows as more and more brands use. So the questions I get asked Publisher sounds great. We want to get involved. We want to use it for our site. How do we get involved and what can we do? The best answer I can have for the bureaucracy and that's really virtually really trying to follow that same literally just get involved and one of the I'll just give you a few examples of how we encourage brands. So first of all we have this internal blog that we maintain for the product and talk about. This is really important and it's very easy to I think just setting up a blog the internal customers are at the end of the day. It's just important. It might not get much traffic. It's certainly not a website or anything. It only takes a few seconds a couple of times a month just to update it and get people an idea of what you're working on and it's a great way of fostering communication and always having that single place where you can point people to get more. We also leverage User Voice for getting some sort of feedback and ideas from various stakeholders for the product. User Voice it's pretty good. It's not the best but at least there's a place where somebody can say hey I have an idea for publisher where can I go. As I mentioned we're very serious about documentation. We use Wiki only because not because it's the prettiest, not because it's the best, not because the search is the best, but because it's very easy to update it. It's also very easy for foster. One thing we did is just set up a general distribution. All of our code is on GitHub. We'll personally maintain and again it's just you know when we get together and do our iteration planning or whatever we're doing in terms of. The other thing we've done recently is we set up this idea of an editor. It just takes an hour every other month and what we're doing is we're giving people specifically our most important stakeholders which are the editors that use the product every single day. We're giving them, it's also an opportunity to just demo anything that's changed. It's a very targeted meeting demo if you will or like I said the people that are most important. So that's really all I have for right now. I'm going to turn it over to Mike and he's going to talk to you a little bit about how Sci-Fi uses publisher. Websites like Sci-Fi.com, ChillerTV.com, Glacier, device are taking Sci-Fi games. We also support a lot of other applications that go to someone from iOS, Windows 8, members inside of our company. So we chose Drupal and Open Source as the way to go because we wanted to tap in. There's lots of great developers around our company and MVC. The resources to be able to tap into those developers to be able to really help us all develop our core confidence. Smaller teams contributing together make one big team. Like I said, most of Sci-Fi's at MVC have really small dev teams. A single code base. So this was the idea for us because you see that we operate and manage lots of different properties, we let properties come to a single code base so we can really push it. Outside vendors make our life easier so before this Drupal product we were in a really proprietary system where we couldn't pay a developer enough to so integrate and build stuff along with us and then contribute that back to a big scaling problem. Let's build a site, build an e-commerce site. So I'm going to talk about a module that we kind of built in-house and really kind of encompasses everything from internal open source to source models. So we built this module for the platform, which as Chris said stated is our video platform. It's what delivers video to all of our sites. So not necessarily files themselves but it's the CMS behind it. So we built a module for the platform. Pretty simple module. I'm just going to brush on it pretty quickly, create your feed so everything out of the platform is speed driven. So you know how to say data store. It is the database for building simple views, you know, you render those categories of videos or just the categories themselves. So there's something funny that happened. So we built this module back at the beginning of the year. And some of you might be saying, well, there's already a platform module out there. That's true. They came out with theirs about a week after we came out with them. That's not necessarily a bad thing though. So right now we're actually working with the platform. The features that we need back into the core contribute modules. So this went from not just being an input, extend that module to meet our model. Their model was a little bit different. They imported all those videos into Drupal as a node. And we decided to go a different route because we have so many videos. So that's really a way that we can go across, really got us to a place where we can process that we actually follow. Very expensive. They have those powerful platforms you can build on. Unfortunately for a lot of the folks that bought Aquariumzo, they got in them thinking, well, bad experience for them. Or Aquariumzo's were crashed into bulls or ran off. They don't exist anymore because the people who actually bought them weren't trained properly or didn't have the system to be able to actually harness power. And that's how we kind of see how we apply agility to the projects and the products that we actually try to build. Because we want to direct that power of the platform, the apparent value, the potential value of using the Drupal platform into the kinetic value of the products that we build on, the products that Mike invented and his folks built and the products that Chris built to put in the platform. We want to be able to enable sort of building the folks that are coming up with the ideas to actually push the envelope with using the platform but still do that within the constraints of a large enterprise organization. So although we follow an agile process, our agile process is easy. So what we've done is, and what we've learned over the years basically is important things that you've probably learned as you do your project. And one of them is understanding that collaboration and understanding the needs of who we're built. And so just like we at the Drupal community, but once again we're trying to actually balance that need of our developers and our dev team, the needs of what's again a larger organization that has other constraints. One of the things we learned right away is having multiple individual projects is less valuable than having people work together on. What we've done in the agile is really the list of things that were basically says at the top we're going to put the most important things, the most valuable. We're going to do those first. But since Mike has said he has a team of two and there are other small teams around. And we wanted to come up with a way to harness those teams to actually act as one big team just like we do in the Drupal community. So what we've done is we've come up with a way and we use tools to actually manage our projects, one of them is rally. So although the tool itself isn't important how we've actually organized the tool is and what we've done is made sure that these backlogs for the core product that Chris is responsible for is accessible by all of the teams that he likes that build onto the core platform. So the core backlog, they can actually take stories out of the core backlog and do them in their own teams and that's how we've actually expanded. But that's just not enough, right? So we actually have organized the tools that way. We've agreed that our philosophy is that. But we've actually come up with some steps that we use and once again the idea is to have a light framework. People here process and believe me, I know, they get very frightened that we're going to impose all of these arduous chores on them. There's going to be all this stuff that they have to do to actually get to do their work. And we really believe that working software, people building software is the most important thing. So we want to actually do that and decrease the amount of time people are needing thinking about what they want to do. We really want to plan that early and often. So what we like to do, and we laugh about it a little now, but you'll hear and you'll probably have very similar experiences, that simple things that we think are obvious now to us who are not so simple to be in with one of our teams internally. What we found very often was that we've actually learned over time that it's a very important step in what first things we do when we actually start something to sit down with some people who are going to be building something for working with to very clearly define what it is that our goals are. The vision that the business has, because very often what we think Drupal inherently provides many of the technicals, but our businesses aren't always great at defining or explaining exactly what they want to achieve in a way that really helps us do it well. Our goal at the beginning is actually to sit down with them and say, this is what we think you need, this is what we hear you say, let's agree before we even do work that we're understanding about. And as well as putting together, we want to say it's a really big project, some of the work we do is really big, some of them are very small. I think everyone here, you know, at the last con, I was at an in-unit, we spoke to a lot of folks that had small companies that were starting up to really start building partners and clients. And one of the challenges is really the project, when we start, we find that it starts with free surrender, right? Our stakeholders and our partners and our businesses very often start thinking of new stuff as we start building. And we want to be able to manage that in a way. So defining what success means, we know what we're done. And that's one of the things we talk about first. People kind of forget that if we don't set that expectation early, we very often... Defining the benefit value of everything here. And Chris has a lot of requests going into his way to define what we're going to build next. And that's what makes our resources the most important thing. And so what we've done is actually when we write our requirements, we actually click with what building that is. So for instance, one of the goals in some of our website, they'll watch more videos than they had previously. So if we say that if we create a video carousel and we create the UX in such a way that we think it will encourage people to click on more videos when they're done watching the last one, the benefit of building that thing that way is just as simple as that. And that's something that our business takes a look at and says, oh, okay. Based on our numbers before, we're seeing a benefit. We're seeing the benefit we've asked for. And along with doing this, we're planning an estimate. So at the early stage of our success criteria, we're getting an idea of the complexity. And at this point, we're not saying it's going to take two weeks or five weeks or six weeks. We're kind of saying this is a large effort. Maybe four to six iterations. It's actually kind of right from what we're going to be actually delivering because it's really important to set those expectations up front. And the earlier in the process we are, the less exactly we can be. But we can have some idea of what we want to do in the department on the piece of paper or the conversation about if they missed their deadlines and then they wonder later why nothing's really happening, why they didn't get them. They didn't organize it in the way to actually get that stuff out or get feedback from it right away. That's really important. Very often, we won't get the result we expect. I was involved with a project that we... So we built a form. When we put that out there, it didn't introduce the amount of time. They were on a call by five minutes. So something was wrong. New to 15 minutes. And it turned out, in this case very simply, that the new form did not cascade across all of the service. So most people were... But when we look at these benefits, when we actually define what it is that we expect to get out of it and then we track it, it gives us some clues, some trails to actually say, what it is that we design the page properly or managing scope by value is a concept that's really hard for some folks because, additionally, very often we do these five things out. When we talk about agile, our organization, we talk about when we have the most time to do something which is the beginning of a project. So, in those things that may have more risk, but when we have questions of whether we can get something complete, we talk about what's the most valuable thing to do. No business person ever said, no, I don't want that really valuable thing. Give me that thing that offers no value. We have to talk about maybe sometime once it's out there, and we get that feedback, we immediately write stories. Take risks and innovate without the speed. And planning and estimating again, because this is a big deal for us and I know it's a big deal for a lot of folks that do any projects, but we are estimating and planning all of the time. We're refining our requirements all of the time. We're making sure that the needs of our businesses are being met all of the time and we're planning and estimating all of the time, because at this point in the process, we're at a deeper level of we really understand better now, but this estimate now is closer to it's going to be one iteration. So the first one was kind of a size thing. This one is actually a more of an exact one. Once again, we're working with people and it's not us doing work. So our first estimate comes from talking about what we're doing. We're trying to move away from how long something's going to take and try to move towards how valuable the thing is you're going to get and lastly, that all of us in this community are very familiar with, we do a lot of retrospective, we do a lot of disrespect for them. In our process, there's no separation. We identify what's working, every iteration we talk about. Because we only do things in two iterations, the worst thing that can happen is we try something new and it doesn't work for two weeks. It's a very low risk thing to do and we build that improvement into our process consistently and constantly so we can always improve. So the process that I'm responsible for everyone understanding is not actually a rigid process. It's a flexible framework. Think of it as a net rather than a cage. But be very flexible about how things work for the organization. We actually support and augment the ability for us to do it. Of course, we needed a technical capability to be able to do it. Like I said, I liked Mike's example about building that platform module specifically because without having Drupal really as a base foundation for doing this sort of thing, there's no way that that would have happened, right? Because Mike built that module, contributed to our core product. Other major brands throughout the company take care of that. He might get sci-fi or his focus. We really needed the central. So that's really all I have. By the way, there's several of our 14 members in the room. So afterwards, if you want to find it. And we're really proud of what we built. So I get an opportunity on the stage like this to thank them. They're not all here, but the first brave soul of Drupal County. Yeah, I got to break the ice. Yeah, thank you. So this is something we're kind of going through. So certain aspects of the business that we work with, they've been very amenable to the approach, like getting everything into one. Other aspects have not been. They've been very hesitant. They want to stick the waterfall methodology we've been using. Waterfall feels safe. Yeah, exactly. So until you're going over it. Yeah, exactly. Crashing into the rocks below. So how did you go about getting people amenable to this idea of working on a different timescale and transparency? That's a good question. I'll let Adam take a shot at this as well, but I think the real key there is in order to answer that. I mean, we've really always had to. I mean, I must say it helps to have managerial, it helps to shield the team from all of that. I think failure is key. Or it can say, you know, I've never seen waterfall really work very well. Literally. Now, one person never said waterfall. The first thing they say is the process is that and it just so happens what's wrong with Agile is that people say they're doing it, but they're not. They're just embracing the, I avoid it saying the word for the first six months. Embrace the ideals. Don't embrace, you know, if you can deal with that. That's an excellent question. That's an awesome question. Part of my responsibility is actually the format and the form. But what we've actually talked about is, first of all, we had to have a discussion about design. It's not the drive-by message of people. I mean, it's uncomfortable. Responsive web design. The Chevy Volt is a great example. The concept car was stunning. So what they did in what we do on it, we actually have to apply it in the technology. Hope we're talking about, I know, this idea that let them, give them the URL but let me show them anything. Just tell them to go to it on their favorite device. That's going to be so much more powerful, so much more value. We have a variety of microsites as well. We are rolling into a Drupal implementation for the core site aspects there. We haven't got it on e-commerce yet. Micro-sites. One of the things I'd love to hear your feedback on is what did it look like for you to engage with some of your internal brands? The answer is it wasn't we don't have a single, you know, spin up an instance platform module that is part of our iteration. So that worked really well for them. Now, another brand on the other end of the spectrum has zero technical capability. So, the resources sometimes that comes from a vendor or a partner of ours. We use internal development, site building, and team. I think the hard part, and this is sort of where we're at right now, is keeping everyone. Oh, that platform module doesn't do exactly what I want. I'm just the struggle sort of going forward now that we have really good traction. I can't really answer because I don't know your organization well enough, but I think it depends on the capability, right? So I think we'll shut it down. Thank you very much. I really appreciate you coming. Thanks.