Nicole Bryan

So, just quick introductions. I'm Nicole Bryan. I run product at Tasktop Technologies. I'm super excited to be here today, mostly because of my partner in crime. I love speaking with Carmen, and I'm excited to hear him walk through his journey of going from project to product.

Carmen DeArdo

Thanks, Nicole. And I formerly led the DevOps initiative at Nationwide. Nationwide, the United States version of Nationwide, not the European version of Nationwide. It's a financial institution: Nationwide is on your side, all that stuff.

So it's a large company: 8,000 folks in IT, thousands of applications. And we started an Agile journey about 12 years ago. So I think what we found as we started through this Agile journey, and we got some good results, and I think you heard some of it today. You heard it from Capital One when Amy was talking. It wasn't enough. We still were not getting the business engaged.

DevOps was seen as an IT thing. You can go from code to cloud, which is great and necessary. It's going to be table stakes, just like Agile. But you have to go across the entire value stream. If you can't start to optimize the concept of idea through feedback, you're not going to be able to compete with the disruptors in whatever industry you're in.

And so what's the problems? And I guess I would just sum it up in business really didn't understand how their value was flowing through the value stream, or even have a kind of a concept of that. IT was still this cost center, like, "How can we reduce our IT costs?"

We even have benchmarks from Gartner that are like, "Well, we spend more on IT than our peers." Well, if I was going to buy a stock between two companies of relative size and strength, and one was investing more in IT and one less, would I actually think the one less was a good thing? So our whole model around IT and IT as this cost is not going to make you successful going forward.

So we're going to talk about this concept of moving from a project to a product, which is really where we need to go: a value stream kind of view of things. And I'll say right up front, we do not have this figured out. For a big company like Nationwide, which is a Fortune 100 company, who didn't start out as a unicorn, as Gene would say, this is a hard problem. It's a hard problem not just from technology. It's a hard problem from an organization, from Conway's Law, just from not thinking and engaging with the business.

So let's look at each one of these dimensions. If I check my watch every so often like this, making sure I give Nicole, who's the star, enough time.

So budgeting. If you think of it from a project perspective, everything comes, it's a new project, it's a new budget. I'll talk a little about my Nationwide experience coming from Bell Labs, but it was like, at the end of the year, everything ground to a halt. So after Thanksgiving, it was like, "Oh, we're closing down." And then in January, it's like a whole new year, and it's like, well, did our customers go away for three months? They're not expecting changes? I didn't get that concept.

And that was all based, and it's not like every project is bad. It's not that way. But the whole mindset was projects, budgeting around projects, and it wasn't a continuous funding concept. It wasn't a concept of, okay, we're investing in some product. As things go, we may decide to invest more. We may decide to invest less. Our priorities may change. We didn't have the ability. It was much harder when everything was project-centric to do that.

Time frames. Again, projects are temporal things. They come and go. When I first came to Nationwide, they wanted me to get Agile working in a consistent way. Well, they did Agile on a project. When that project was over, everybody went back. ThoughtWorks got their money. We had nothing in our environment anymore that would allow us to sustain an Agile capability.

Products are around. You want your customers to have a relationship and experience with your product. If it's an insurance product, you may buy it once, like an auto policy, but you're going to manage it. You're going to add cars. You're going to subtract cars. If you have kids, you have claims. So you need to have that product life cycle that's going to sustain you. And that's really what's going to sustain your environment and allow you to be successful over time.

Speaking of success, again, there was this concept of a cost center. How much is IT going to cost? How much is it going to cost? Our project managers are under lots of pressure to manage their costs. We had portfolio leads who had two projects. If one was 10% over budget and one was 10% under, you would think that would be good. But no, they were both no good because they were outside of 5% variance. It's like, what are we doing here? Is this really adding value to what we're delivering?

When really, when you think about it, we all know that it's profit. If you don't think you work for an IT company, then you're probably not going to be working for long, because somebody who believes they're an IT company and is an IT company is going to take your business. In Columbus, Ohio, right there, we have Root Insurance. We have a bunch of startups that are coming on, and they're taking insurance away from companies like Nationwide because they can. And you're going to have to adapt, because if you don't disrupt yourself, someone is going to disrupt you. So the whole mindset of IT as not a positive thing, but as a cost thing that has to be minimized, has to change.

Another thing when I first came to Nationwide was, as I said, everything was organized in projects. So if a project had people from five applications, they would take one person from there, two people from there, and a quarter person from here, which I don't know how you figured that out, but that's what the Clarity allocations were, so obviously you're getting a quarter person.

So we would bring those to the team. The team came to the work. People were moved to the work, and they would storm and norm and hopefully perform, and then the project would end. And again, you'd have to go through that process again. What works long-term is set up a team, align them with your value stream, and bring the work to them. Have a high-performing team with those teams' norms that you can empower and flow the work to those teams.

So it seems like a simple concept. And when I brought this up maybe a decade ago of, instead of taking people to the work, let's bring the work to the team. But that created unbelievable change in how we even did timesheets. Because we didn't know how to do that. We didn't know how a team of people could sit together and submit a timesheet on a release instead of 10 different projects.

We had people with their timesheet would come up on Friday afternoon, and they'd have to pick 10 projects to assign 40 hours to before they went home for the week. And so you want to talk about engagement. And it's like, "Why am I doing this, Carmen?" It's like, "Okay, I don't know." But we had to do the accounting. I understand the accounting, but there has to be a better way, right?

And then prioritization. Again, from a project perspective, and I'm going to talk about this a little more, when you actually think of work, there's four types of work. There's business value work. There's also technical, I don't really like debt, but it's technical debt or it's technical investment. It's defects. And it's risk. Risk remediation, as Equifax all taught us how important that is, if we didn't already know that.

But yet from a project perspective, most of the focus is on business capability. And we've had discussions, I've been in discussions where project managers are like, "Well, if we just refactored this code, we can make everything else go faster after this." "Well, why do I want to do that? I don't want to pay for that. I don't want to pay for that with my project."

If you're thinking about things from a product perspective, you're going to make those investments. You're not going to pit, well, what's my priority of doing a defect or doing a risk mitigation or a technical investment versus, I want to do scope? Because everything now is based on what is the focus of that product, what is the focus of that value stream, what makes sense from a product perspective to invest in.

You may have systems that are legacy, and you're going to invest more in defects and risk and not as much on functionality. You may have new products, or products that are newer in their life cycle, where you're going to invest more on those business side. Those should be conscious decisions that you're making from a value stream perspective, not a slice of a project that are affecting those experiences and those systems.

And then visibility. A lot of the things around projects were black boxes. You're in Microsoft a lot. Until we actually had anything hit the backlog of our Agile team, where you could actually see the stories, it was all magic. From the customer having an idea to it actually having work in the backlog of our team, no one could really tell me how that happened, except that there was lots of meetings. I mean, well, we create this document, and then we have this meeting, and we go through a lot of this, and eventually, we end up with features and stories.

And there was no visibility to that. So it was very hard to actually track that idea, which has a certain value associated to that value stream for that product, and where it was at any point in that life cycle, and where maybe things could be slowing down.

And then again, I talked a little bit about the risk side of it and the fact that, yes, you're trying to do a lot of definition of what's happening up front. And then you can do change requests. I get it. But it still wasn't as continuous as going through regularly and saying, "What is my priority? How am I prioritizing these cards in my backlog?" Some are associated with risk, some are associated with scope. Some is a currency issue. We just found something in a Struts library that needs to be changed. There is no project that you have to worry about at that point. The product manager is making a decision: we're going to mitigate these. This is the priority of them. GDPR. Where's Alan? We all know, especially over in Europe, a lot about the GDPR side of things. And how do you factor those in and prioritize them? It's a lot easier if you're thinking of it from a product value stream perspective.

So these will be in the deck. So again, I talked a little bit about Bell Labs, where I worked most of my career before Nationwide. And obviously, there was no DevOps. But we had these concepts already of product network-centric teams, like the 4ESS switch, the 5ESS switch, some of the core network elements. We had a quarterly funding model. I get it that you may have a yearly budget. That doesn't mean you can't look every quarter or every few months and say, "Is this the right way to fund these capabilities, these products?" And adjust it.

We have agility. We've invested all this money in the agility of our teams. We're not taking advantage of it, though, because we're not applying it to how we plan our work. We were always focused on the next release and work being brought to us. And we already had, by virtue of the System 7 network and things like that, well-defined APIs, and we were able to do independent releases.

So I came to Nationwide. As I said, it was this new world of lots of projects. Most of our money was spent on projects except for, quote, "run work." Like, that's separate too. Isn't this all hitting the same system? And shouldn't it all be prioritized? And shouldn't it be worked the same? Because when you're in the code base, you may want to refactor things to handle both new features and defects.

Lots of times in these meetings, the application integrity between that person, that person, that half person, and that quarter person on this project, and then the five other projects that are impacting those systems, very hard to manage. You couldn't see all those dependencies.

And we were in what I call this cycle of dependency: large batch sizes, lots of dependencies. Dependencies are friction to acceleration. And while I know we want to jump to this new world of microservices and everything's independent, if you're in a company like Nationwide, that's going to take time. So you need to be able to see those visibilities to where you can start to go to more frequent release cycles.

So the idea here was, let's think of things from a value stream perspective. I said, I get that we have silos. But if you're really going to have a true product owner, they have to have control over the things on the left-hand side. You have to be able to trust them with prioritizing and funding. Not some PMO. Once you decide we're going to invest in this product, they have to be able to make those decisions.

The team itself, it has to be as cross-skilled as possible. Now, the fairy tale, it's not a fairy tale, because you're going to have a two-pizza team that's going to make all the changes to support a value stream. That's not going to happen in a large organization. I get that.

But the more you can empower that team and do things like innersourcing, and I don't really have time to go deep into that, but where you allow that team to make changes to other systems using Git with pull requests and improve those things, that's a powerful model I think that organizations are going to need to go to, to allow these teams to be more empowered and more independent, again, so they can actually go fast.

Because if you ask a team what's slowing them down, they're typically waiting. They're waiting for work. They're waiting for somebody else to do something. They're waiting for infrastructure. How do you understand what those wait states are and how do you mitigate them?

So again, create that flow, which, in our case, started to be involved with having the business, as you heard some of the talks previous, actually sit with the team. And one example was we had eight weeks of meetings that actually, when you boiled it down, was really only eight hours. But when you tried to align all the schedules and everything else, it took us eight weeks to do some ideation and story mapping to where we could actually start to do the development.

By having the business sit with the teams and extending our Kanban further left, we're actually able to do that in two days. So that's just one example of eight weeks to two days, and it has nothing to do with code to cloud. This is all the left-hand side of the value stream. And how can you start to focus on that?

So how do you get started? I'm going a little bit long here. Sorry, Nicole. I feel like I'm talking really fast.

So again, you're not going to have all the answers to start, but start small. Empower that team as much as possible. Experiment. You're not going to get it right the first time. That's okay. The work that you need to change how you're doing work, you need to make that visible, too, as Dominica DeGrandis talks about. All your work has to be visible.

Show the business, look, yes, we are changing some of the things. We have story cards for the ways we're doing things differently. Very powerful to show and tell with executives. Let them see the excitement from the team who's able to experiment and do things differently. That changes culture more than anything I've seen in a large company.

Celebrate your success. Tell your stories. Those stories are valuable in a large enterprise. And then you're going to have to have patience because it's going to be rocky. But if you stick to this, I think you're going to be successful.

And with that, I'm going to hand it over to Nicole.

Nicole Bryan

Okay. Carmen has challenged me because he already told me I had too much to cover, and now I have less time to cover it. This is why I lead, so it's a bit nice.

So hold onto your seats. I can talk really fast even though I'm from Texas, so go with me for a little bit.

So Carmen has clearly laid out a very compelling story behind the need to move from project to product. But there's one more really critical piece to the puzzle that you need to have, and that's what I'm going to talk to you about today, and that's abstractions.

So when you start to talk about product and you're going to start to talk about value streams and value stream management, you're going to hear a lot of times people talking about modeling and mapping. Why is that? This is really just various ways to articulate the importance of abstractions.

So I'm going to read you 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." So put that in your back pocket. We're going to come back to that.

So I want to make sure to first... This is my favorite animation. It kind of puts you to sleep. But the goal of your organization, of course, is to deliver more value to the business. But in order to do that, you have to be able to measure. You have to know how long did it take for this feature to get through the value stream. How much wait time was there for defects? These are the things that are important for you to be able to understand and thus improve your value stream, your product's value stream.

So keep that in mind as well. Your goal is to be able to measure.

But here is the tricky bit. This is the super tricky bit. Value streams and product thinking actually require, they implore you, they beg you, they're just pleading, think from the business perspective. The business perspective. Measure the business outcomes, not from the technology perspective. And that presents a core dilemma that I actually believe goes un-understood often, and is precisely why abstractions are such an important element as you embark on this product and value stream way of thinking.

Why? Because no matter how important the technology perspective is, and it is of equal importance, it will never line up to the business perspective of how you're delivering products.

So I think it's easier to understand this if I go through an example. So I'm going to use one of the Tasktop's products, Tasktop Integration Hub. At Nationwide, it would be auto insurance policy or life insurance policy. So this is my product. This is the thing that I sell and that I want to measure business value against.

So we know that every product has a value stream. And this is the value stream for Tasktop Integration Hub. These are all of the activities used to perform and have flow go through your value stream. So things like triaging, reviewing, estimation. And so this is Tasktop's value stream for the Tasktop Integration Hub.

Now, here comes the dilemma. The dilemma is that in order to measure the value stream's delivery, you have to be able to capture and extract the right information from within the physical constraints of what your IT organization has to deal with. And there are constraints because they come at things from the delivery perspective, the delivery view of the world, not the business view of the world.

And so for this one single product value stream, it actually is delivered via seven artifact types. It's actually more. I had to reduce it. And with Nationwide, we're working on one of theirs, and they already have 27 artifact... 27 or 23? I don't know. Twenty-something. A big number.

Seven artifact types that span six different tools, and within those tools it spans 10 different projects and crosses eight teams. And I can assure you that our product's value stream is not near as complex as Nationwide's value stream. And the other thing to keep in mind is this is just one product. One product: seven artifact types, six tools, 10 projects, eight teams.

So now you see the core of this dilemma, the two separate perspectives. So how do you overcome this dilemma? Well, that is where this notion of abstraction really becomes apparent. And on your journey from project to product, you need to have in your back pocket this thing called product modeling.

So if you remember nothing else today, just minus all the stuff you'll remember that Carmen says that was super important...

Carmen DeArdo

Very forgettable.

Nicole Bryan

...just remember product modeling.

So as I said before, what's super important is the measuring. And measuring, when you're talking about value streams, is really about measuring artifacts. Those artifacts are the digital footprint that contain all the information you need in order to be able to measure your value stream. So product modeling really becomes an exercise of figuring out which artifacts matter.

So in our case, there's seven artifact types and 10 projects spanning six different tools. I have to have a way to map that to the business view of my product, and that is what product modeling is all about.

Remember the quote that I said to put in your back pocket: "The essence of abstraction is preserving information that is relevant in a given context and forgetting information that is irrelevant in that context." And our context is the business perspective, the business perspective of a single product.

And so product modeling is necessary so that you can measure from the business perspective, but not impede the realities of the complex IT organization that you have in your organization.

So just to make it a little bit more concrete, imagine you have four tools in your value stream. You probably actually have quite a few more. The act, maybe it's an art, product modeling. Could it be an art, maybe?

Carmen DeArdo

Sure.

Nicole Bryan

What you actually have to do is carve swaths through your tools to identify which artifacts matter. So the way in which you do that is you define conditions under which this artifact or this set of artifacts matter. And in fact, you have to do that for every single tool in your toolchain.

So to make it even a little bit more... Does it sort of look like a swath? Not really.

Carmen DeArdo

Yeah, it does.

Nicole Bryan

I looked it up. Technically it is a swath.

So to make it a little bit more concrete, imagine that these are your four tools involved in your value stream. So for Jama, what you want to do is you want to gather all the requirements. They have the concept of sets, all requirements from sets A, C, and F in project 159.

From Jira, epics that are assigned to component A from either project D or project E or project F. From Micro Focus, risks and tests that were created after January 1st, 2017. And from ServiceNow, support tickets from application H and J only if the status is past the accepted state.

So you go through this exercise of defining the conditions under which these artifacts should be there. Why? Because this is what you want to be able to measure.

I think I'm going to do it.

Carmen DeArdo

I had confidence in you.

Nicole Bryan

So that was a lot to take in. But again, if you remember nothing else, remember the concept of product modeling. And if you do that, you will actually be able to answer these 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 tech debt?

So I wanted to make sure and have concrete actions for you all to take away with you on your journey from project to product.

So the first thing that you need to do is start connecting. Get your tools talking to each other. That is step one. And actually, in order to connect your tools, there's two other abstractions that I'm not going to be talking about here today, but you have to be able to model your artifacts and model your statuses. Those are your first steps. So you've got to get going on connecting your tools.

And then the second thing is, don't make a big deal out of it. Model your products on paper. Do a paper and pen exercise. Get the right people in the room in order to do this, which is very difficult to do because you have to have people that understand the IT structures and the constraints that they live within, as well as people that understand the business view of your product.

Do it as a paper and pen exercise. We're actually working on this with Nationwide now, which is a very interesting exercise. But get going on modeling your products. Do it on paper. Don't make some big fancy technology thing out of it.

So in conclusion, Carmen already outlined many things to get you started on your way from project to product. And I would just like to add one more, which is to make sure to model your products.

That's it. Thanks, everybody.

Oh, that's not it.

Carmen DeArdo

That's not it.

Nicole Bryan

That's not it.

We just wanted to hear the applause.

Carmen DeArdo

Yes. Well, it was only Nicole. I don't need applause.

Nicole Bryan

That's not it. This is the help we're looking for. How are you defining products? I would love to talk to any of you in this audience. I will be around all week. I would love to talk to you about how you define your products from a business perspective and how you're going to align that from an IT perspective.

What is the relationship between business products and IT systems? What are good examples of an Agile product funding model? I know Carmen is super interested to learn and hear more about that. And how are you making the flow of work across the value stream visible from a product perspective?

So any of those questions, we would love to talk to you all more about in the coming days.

Now we're really done.

Carmen DeArdo

Now we're really done.