Nicole Bryan

[00:05] Great. We're super excited to be here. My name is Nicole Bryan. I run product at Tasktop, and I'm really looking forward to having this time with you all. I can tell none of you all must be car enthusiasts, because you skipped the Jaguar Land Rover talk to listen to us. So I'll hand it over to you, Kevin.

Kevin Fisher

[00:24] Thank you, Nicole. My name's Kevin Fisher. I'm an AVP within Nationwide's IST group, and I'm happy to be here with Nicole. The way we're going to work on this presentation is I'm going to talk for about 12 minutes, and then Nicole has really the meat of the message. It's about making the switch from project to product. You heard about that this morning from CSG. You heard about it from Mark Schwartz if you went to his talk. You're going to hear about it later today from Mik Kersten, and he has a new book about this.

[00:52] At Nationwide, many of you know us by our public-facing advertising campaign for our personalized insurance products, but that's only a portion of our business. We're actually a very large commercial insurer, plus a very large financial services company around retirement plans, annuities, life insurance, and that sort of thing. We like to protect what matters most to you: your home, auto, life, boat, your kids, your retirement. We're based out of Columbus, Ohio, and we have about 10,000 people in IT, so it's a pretty big ship to turn when we talk about making the change from project to product.

[01:28] These are the five impediments that everybody is challenged with, and you'll hear it as a common theme today. IT is generally disconnected from the business. We heard it from the night presentation all the way through this morning about getting IT and the business to work much more closely together on common goals and objectives. Leadership tracking is generally activity-based tracking. I know the switch at Nationwide to get our leaders talking about outcomes, what business outcome do you want to achieve, and having IT at the table when you do that. Mark Schwartz has a whole book about that called A Seat at the Table, which I recommend. I also recommend his other book, The Art of Business Value. But that's a big thing for at least a large company like us.

[02:11] Project funding is fundamentally broken. Like I said, we're a large, 35,000-employee company. We still fund projects on an annual funding cycle that usually takes 18 months. Business IT is usually viewed as us working on our own agendas or our own items, and in a lot of ways, a black box. That black box is generally the focus area: well, we need to get the developers more productivity; we need to make the developers more productive.

[02:42] When we think about that, there are all these elements to changing that conversation and that dialogue, from budgeting, time frames, how to measure success, how you allocate work to teams, how you prioritize work, how you make that visible, and how you manage risk. I'm going to go through these really quickly because you all have seen these and many other things.

[03:02] We all want to switch from linear-based projects to more cyclical products. When I think of this particular diagram here, I like to tell a story that our CIOs routinely go outside the company to visit other companies and learn. A couple of years ago, they did a trip out west. They visited what we call the unicorns: Google, Amazon, Microsoft, all the startups that are doing quite well. When they left the building, they had a sense of, we need to go figure out how these companies do a better job of long-term planning, because we don't think we do a good job of long-term planning. What they learned is they actually don't do long-term planning. They came back and coined a phrase: sense and respond. We need to do a better job of being able to sense what's happening in the marketplace and respond to those trends. We don't do a good job today because, as I mentioned before, we have an 18-month funding cycle. It's hard to sense and respond when everything takes 18 months to get new funding.

[04:00] Which leads to how you actually manage your work. We all know project mentality is linear. It requires an absolutely perfect sense of forecasting ability that no one possesses, and you're bound to be disappointed in multiple avenues. However, if we adopt more of a product mentality and learn from things like The Lean Startup by Eric Ries, where we have a hypothesis, we fund a hypothesis, we do a test, we measure that test, and then we sense and respond, we know good things will happen.

[04:34] We know that measuring success the old-fashioned way, either hours burned, dollars burned, that sort of thing, activity measures, is not successful. We've learned that through, what now, 17 years of Scrum and XP. We know that when we start the conversation with the business with business outcomes, and we can align technology solutions to those business outcomes, good things happen.

[04:59] We know that when we bring people to the work, it's not as efficient as when we bring work to the people. We've strived over the last three years to really have a stable alignment of IT resources. In 2016 at Nationwide, we made the decision that all of our work would be done with Scrum and XP, and we aligned around 200 agile teams, plus or minus a couple. Essentially, we have a nice stable plant, a stable factory to do work.

[05:28] We know through multiple years of working with all the agile methods that, pick your favorite flavor of agile, it's better than waterfall. We all know that. We know that project visibility through big visible charts, like you saw the lean program structure in CSG this morning, is fantastic. They have all work depicted visually. They can bring the business partners in and have a trade-off conversation visually. That's much better for everybody involved. And then, if we do this well, as you heard from Nike, we can manage risk in a very iterative way. You heard it from CSG: continuous compliance, not compliance theater at the end. We know that that will be better.

[06:10] Specifically for us, this might sound familiar to many of you, especially if you work in a big company, especially a big company like ours that's 100 years old. We have 100 years of bad habits to overcome. Prior to 2005, all work was done in projects. Teams were being constantly formed and stormed to meet those projects, which meant for the first three months out of the year, nothing happened because I'm storming and forming. Then my first status report says, great, the team is now formed, and I haven't really spent any of the money, so I'm not going to spend all the money by the end of the year. Since I was managing success by how much money you spent, that was bad.

[06:50] Lots of time was spent in project-related meetings talking about things that either people could not affect or were just unproductive conversations. Application integrity was hard to manage, dependencies were not visible until the last moment when things went bad, and there were very large batch sizes and very long cycle times.

[07:10] Our transformation has taken about 10 years. We're 10 years in and we're not perfect by any means, but ours was a development-centric transformation, meaning we focused on the development process first. We applied Scrum and XP practices to all of our work, and that took us many years. Like I said, that took us until 2016 to do. Then we said we need to focus on DevOps and continuous deployment. Those two things are great, but they are very IT-centric aspects to improving your whole value chain. There's a missing component there: the business. To get truly fast, we need to have the business involved, and we want continuous flow. That means they have to be involved.

[07:53] When we think about words like product value stream and all that kind of stuff, in our world, that's not the way our business-IT relationship was formed. It was still a very contractual relationship. To get them to open their hearts and minds to a better way, we know there's a better way. We know we can leverage lean. We can look at other industries to figure out a better way. But to get them to understand the value of doing hypothesis-driven planning, where you do small ROI-based funding, fund a hypothesis, let us put it in the marketplace, let us test and learn, let us actually truly embrace that sense-and-respond mentality that you saw with other companies, one of the main trigger points for us was being able to have some metrics on our flow, to have a very rudimentary view into lead time and cycle time and where people are spending their time.

[08:46] I have a question for you. In a very simple value chain of idea, to work gets decomposed, a developer works on it, testing happens, and you deploy, what percent of time do you think we spend in that development phase, where people are actually hands-on-keyboard writing? Five percent. Anybody else want to go higher or lower? Thirty? I wish we were 30. How about two and a half?

[09:19] Once we know that number, the conversation changes. The conversation changes from, what are you doing to make your developers more productive, to, all the stuff that surrounds them, what are we doing to make that more productive? What are we doing to eliminate waste there? If we want to go from idea or concept to cash, as Mark Schwartz said just a few minutes ago, what are we doing to help that? If the development piece is only 2.5% of the time, there's a lot of waste and opportunity in the rest of that time period. That is so important to create flow. Part of it is all about decomposing that work into small batches.

[10:00] The second thing that having this measure allowed us to do is start having real conversations with our business partners. I'm talking business unit presidents and their cabinets, thinking about small batches. The best we could do is 90 days, which is fine. I'm taking people from three years to 90 days. This is a big improvement for us. The bar was low. But thinking about things in 90 days, and we have had, in the last six months, success getting them to rally around and start thinking about things in 90-day chunks. What value can we deliver to our distribution partners, our customers, our associates, what have you, in 90 days? It doesn't have to be a firm, hard, fast 90 days. Ninety days is not the new word for project. But it's breaking their mindset that everything has to be a three-year commitment, and more importantly now, how can I measure that flow?

[10:55] That's really the main piece of the value of this presentation that Nicole is going to come talk to us about: how do we measure that flow and decompose the work so that we have a real view into what's happening?

Nicole Bryan

[11:12] Cool. Thank you. Before I get started, I want to ask a couple questions. A year ago, how many of you all would have thought about the notion of moving from project to product? A year ago, not today. A year ago. Okay. Three years ago. And today. Okay. It's an idea that is clearly taking hold. If this many people believe that they see the value in it, there must be a reason why we need to be embarking on this journey.

[11:54] Now I'm going to ask you a second question. How many of you all feel like you have concrete steps, concrete things that you can go do today to start moving in a product direction? Okay. I'm hoping that at the end of the time we've got here today, I'm going to leave you all with something concrete that you can go back to your organizations today and start working on, and it's called product modeling. How many of y'all have ever heard of this concept of product modeling? Okay, cool. If nothing else, you may think it's crappy, but you'll learn something new to take back.

[12:36] I have to make this joke because Kevin and I have been chatting about the fact that our talk is very boots on the ground. It's concrete, it's applicable, and then the first slide I'm going to show uses the word abstractions, which is pretty much the furthest thing from concrete. But Kevin described what they're going through in some of their experiences. When you start to think more about moving to product, you're going to hear a lot more about value streams, value stream management, and a lot of use of the words mapping and modeling, mapping and modeling, mapping and modeling. Really what those words are are various ways to recognize the importance of abstractions.

[13:24] I'm going to read this quote: "The essence of abstractions is preserving information that is relevant in a given context and forgetting information that is irrelevant in that context." Put it in your back pocket because we're going to come back to that in a bit.

[13:40] Kevin made it incredibly clear what the goal is around flow, which is to be able to measure flow so that you can hopefully deliver more to your customers. I heard all of y'all's voices when he said 2.5%. That's measuring your flow, measuring what's going through your product value stream. The whole act of product modeling, what I'm going to be talking to you all about, is done in order to have the best possible, the most accurate measuring that you can. By the way, I completely agree with what Kevin said: it's impossible to make it 100% accurate. Throw that away and go for the 80/20 rule of getting relatively good metrics.

[14:27] Here's the tricky bit. You know that you want to measure your flow, but here's the tricky bit. Value streams and product thinking intentionally require you, they're just begging you in every way possible: please think from the business perspective. Please think from the business outcome perspective. Well, here's the problem. The problem is that you end up with this core dilemma because you do have two different perspectives. The technology perspective, the IT perspective, is at the core fundamentally always going to be different than the business perspective. Until and unless you own up to that, you're never going to have success in being able to measure your value stream.

[15:13] It's kind of a tricky concept, so I'm going to go through an example, and hopefully the example will help bring to light what we mean by having these two different perspectives and thus requiring the act of product modeling. I'm going to use as the example one of Tasktop's products, Tasktop Integration Hub. This is the business perspective on our product. This is the thing I sell. This is the thing I'm wanting to improve the speed with which I can deliver value.

[15:46] Every product has a value stream, the set of activities that you do in order to deliver value for that product. This is the value stream for Tasktop Integration Hub. You see things like investigation, implementation, story breakdown. And by the way, this is the end-to-end. We've heard a number of talks now also about making sure that you're not just focusing on the code, the 2.5%, but on this full, entire set of activities. So this is the Tasktop Integration Hub value stream.

[16:23] Now here comes the dilemma. In order to measure your value stream's delivery, you have to capture and abstract the right information from within the physical constraints that the IT organization is working within. I know that sounded lofty or kind of crazy, but it really does make sense when you start to break it down, so I'm going to break it down for y'all.

[16:52] This one product value stream has at least seven different artifact types in it. Actually, it has the four core flow units in it, and Mik is going to be talking more about this later today: features, defects, tech debt, and risk. But there are also many other artifacts. Why is this important? Because the artifacts are your digital footprint, and I'm going to come back to that in a bit as well. This one product value stream has seven different artifacts, and those seven different artifacts actually live in six different tools. I actually took out some of the tools as well to simplify it. So now we're starting to see how the IT perspective is different from the business perspective: seven artifact types, six tools.

[17:42] This part is super confusing, and I'm getting the evil eye from Carmen over there already: across 10 different projects. This is not the use of the word project the way we've been discussing it. This is the boots-on-the-ground, concrete meaning. When you're in Jira, when you're in Rally, when you're in VersionOne, when you're in ServiceNow, you go in and configure a container to contain your work, and it's often called a project. Those seven artifacts live in six different tools that cross 10 different projects and eight different teams. Tasktop is nowhere near the size of Nationwide, not even by many orders of magnitude.

[18:24] Hopefully you see that there is this distinction. The business perspective was one product, and I want you to measure and improve how you're delivering that one product. How in the world am I going to do that when the reality is that it's seven artifact types, six tools, 10 projects across eight teams? That's where product modeling comes in.

[18:50] Let's go back a little bit and make sure to remember why we're doing this. Your goal is to be able to measure your product's value stream. As I mentioned earlier, the way in which you do that is via the artifacts. They are the digital footprint. Those artifacts are the things that know how long things have existed. The way that Kevin was able to measure, and Nationwide was able to measure, how they got to that 2.5% is they're looking at status changes in their artifacts across all of their tools. That's how you do it.

[19:21] Easier said than done. What you have to do is figure out the right way to determine which artifacts matter, which artifacts should I be measuring. You need a way to map those seven different artifact types across 10 different projects, spanning six different tools, and that is in fact what product modeling is. It's a very concrete thing.

[19:46] What I'm going to do now is give another little example around how you can do product modeling. To bring it back to the original quote I said to put in your back pocket: the essence of abstraction is preserving information that matters in a given context and forgetting information that is irrelevant in that context. We now fully understand that the context we care about is the business context. We need to make sure that we're abstracting the right information to meet the business needs.

[20:21] Essentially, the act of product modeling is that you have to go into all of the tools that are involved, and it's really an exercise in carving swaths through those tools to know which artifacts actually matter. What you do is define the conditions under which an artifact matters. So one of the four flow units: feature, defect, risk, tech debt. You have to go through each one of your tools and identify the conditions under which the artifacts should matter.

[20:59] I know that's a little bit abstract, no pun intended, so I'm going to give a bit more of a concrete example. Imagine that your product value stream has these four tools in it: Jama, Jira, ALM, and ServiceNow. You're using Jama for requirements, you're flowing information to Jira for execution on the development teams, you're using Micro Focus ALM for testing, and ServiceNow for help desk and trouble tickets. But all of these tools are utilized in delivering value for one product.

[21:34] In this case, you may say, all right, with Jama, I need to get requirements from sets A, C, and F, only from project 159. That's the project, and those requirements are the ones that matter. For Jira, it's epics that are assigned to component A from either project D, E, and F. Those of you all that are big into Jira will understand that a lot of times component is a very important piece to being able to do your product modeling. ALM: I only want artifacts that are risks and tests that were created after January of 2017. In the case of ServiceNow, support tickets from application H and J, and if the status is past the accepted state.

[22:17] That is a real, semi-real example of how you do product modeling. I know that doesn't sound trivial, but that is the work necessary so that you can actually answer these types of questions: how long did it take for this feature to get through the value stream? How much wait time was there for defects? What is the distribution between defects, features, risks, and technical debt? If you do product modeling, you will be able to answer questions like this. I want to make sure and give you all very concrete actions to take today.

[22:54] Before I do that, I want to tell two quick stories. One, we've actually been working with Nationwide on doing product modeling for a little while, and I can tell you, and Kevin can attest, that it does take a little bit of, oh shoot, hmm, wait, let's try it again. For that reason, I encourage everyone to start just trying it. We've been using spreadsheets. We've been using spreadsheets and video calls to go back and forth and try to figure out how to model the products.

[23:30] My second story is that BMW, Renee is here, and he's going to be talking a bit about this tomorrow. BMW has done an unbelievable job of doing product modeling. It's the most sophisticated one that I've seen so far. I'm hoping that some of you all will come talk to us afterwards and say, no, no, we've been doing product modeling, we just didn't know we were calling it that, because I'd love to hear more stories about how you're doing this. But come talk to Renee because BMW has been doing some very interesting work around that.

[24:02] So actions to take today. One of the key things: you noticed I had four tools up there, Jira, Jama, Micro Focus ALM, and ServiceNow. At the core, you're never going to be able to successfully do your product modeling if you aren't also connecting the tools together so that your artifacts are flowing, so that you can get the accurate state changes across all of the different tools. The first action you can take today is to get your tools talking. Connect your tools. I'm not going to talk about this today, but that involves a whole other kind of abstraction around artifact modeling. If anyone wants to talk about that, I would be happy to chat about that as well. Artifact modeling is a very powerful way to be able to flow information between tools.

[24:52] The second thing is, go in there, model your artifacts, model your statuses. I should talk more: modeling statuses is also very interesting and provides great insight. One of my favorite stories of that is, I can't remember which company it was, but they were like, yeah, we've got all of our statuses and people are using it. Then come to find out that all of the developers were just going in right before the end of the iteration and moving everything quickly from one state to the next. Which, okay, that's not really what we're going for.

[25:24] The last thing I encourage everyone to do: do it the old-fashioned way. Don't get fancy. Keep it super low-tech. Get spreadsheets. Get yourself talking to the business about how they view the product. Tell me, how would I carve out what piece of this goes for this product? Then sit down with spreadsheets, go through all the different tools that you've got in your organization, and figure out how you would define conditions to actually begin modeling your products.

[25:58] With that, hopefully you all have something concrete now that you can take away and say, not only do I know about project to product, but I have something I can start doing with everyone today. That's it. Thanks.