Ken Rubin

Speaker: Miljan Bajic  00:56 

Who is Ken Rubin? And how did you get into this agile training, coaching consulting business, maybe not many people I think know who Ken Rubin is and how much you’ve contributed to our communities. So if you could please share, like how you got into this space and tell us maybe what your journey has been and who Ken is? 

Speaker: Ken Rubin  01:19

Great to be here with you today. My background’s pretty straightforward. I started off as a software engineer. And first of all my degrees are in computer science, typical path through companies, I was a developer, a project manager, VP of engineering. I was also a VP of Marketing, VP of Sales, running a number of smaller software companies. I have done 10 startups in my career, took two of them public on NASDAQ. Last was back in 2000. During that really crazy period of time, I did a two-year tour of duty with IBM in the mid-1990s, where I had a 130-person team, we’d run around North America building large distributed object systems.

And that’s really my starting point, not at IBM. But if you go back to the late 1980s, I helped bring small talk out of the research labs at Xerox PARC. And we formed a startup company called Park Place systems. And anybody who’s old enough to remember that will recall that we were sort of early market object-oriented development languages, development tools, class libraries. And that’s really where agile started for me. I think a lot of people know that a good part of the Agile community finds its roots back to small talk development. Actually, I started doing small talk long back in 1986. Before I joined Park Place, they just hired me in because I had small talk experience, which was rare back in 1988. And I’ve been doing Agile since the early 1990s. In terms of the training and consulting part, at park place, initially I was in the training and consulting department until I grew it. And so basically from 90 to 95, I ran the training and consulting department at park place and so we had a team of people who go out and we train people in small talk and object-oriented development and we were sort of the forerunner of core 

Agile principles. First time I ever did something like scrum was in 2000 formally, at that time, I was working for a startup in Colorado called Genomica. And we built software for statistical genetics, some fairly sophisticated life scientists’ software, and I inherited a team of about 90 people, wasn’t functioning all that well. We gave scrum a try, and it worked out much better for us. So it’s now 21 years of doing Scrum and Kanban and doing coaching along the way. So that’s sort of my route and all of this.

Speaker: Miljan Bajic  03:40

So what is it maybe just something that triggered my thought in my head, which is like, you have Boston area where Jeff and Ken where and then you have Denver, and there’s a lot of history around Agile Scrum in Denver. Was there anybody particular that you partnered with or it was just something that was evolved naturally? So did you partner with anybody like Mike Cohen or anybody that’s in that area early on?

Speaker: Ken Rubin  04:14

I did. So I left California in 1995 and came out to Colorado, took that job with IBM, which was what brought me out here. Over the course of time when I first got here, after I left IBM, and went to this company called eventually to Genomica. The day my son was born, in 2000, I was in the hospital room and my wife had just given birth, I got called by, the CEO said, you need to come to the board of directors meeting. I’m like my wife’s in the bed.

We needed a board of directors meeting. So I went to the board of directors meeting that in Boulder, and they go yeah, we just hired the VP of engineering. And in addition to your other responsibilities, I was sort of the equivalent of like COO, I ran a lot of the other groups and she’s like, now you need to run engineering, you’re allowed to hire a new VP of engineering if you want. And I highly suggest that you do. And so I ended up hiring Mike Cohen.

Speaker: Miljan Bajic  05:10

Oh, wow.

Speaker: Ken Rubin  05:13

And so Mike came in, we work together at that point. And that’s how we introduced Scrum and to Genomica back in 2000. And for people that are familiar with the Colorado Front Range, which is the part just east of the Rocky Mountains here. It is an intensely agile area. A lot of agile talent out here. And so it’s been a great place to live for the past 26 years,  just involved with all that, park place was actually in the Bay Area. So in the early days, it was all Bay Area. Really, for the past 25 years back in Colorado.

Speaker: Miljan Bajic  05:50

All especially agile, I think and in terms of how we know agile today there’s a lot of Scrum Alliance, offices, headquarters out there. So it is interesting. So thank you for sharing that. I didn’t know that. I just assumed that there probably was collaboration and a lot of sharing going on. Given that just there’s so much going on there. How do you define business and organizational agility? Different people define it differently. How do you look at business agility or organizational agility?

Speaker: Ken Rubin  06:27

It’s a great question. So to me, it’s the ability of an organization to inspect and adapt, right? To succeed in sort of a rapidly changing, and most certainly ambiguous, and one of my favorite terms turbulent environments. And I got to say you, the past 20 months have been the most amazing test of anybody’s organizational agility, right? If you weren’t inspecting and adapting over the past 20 months as an organization, sadly, you might not be here. 

When I think of the restaurants around me here in Colorado, some really good restaurants are gone, just gone. They didn’t adapt. They weren’t very agile organizationally. Others that were predominantly sit-down restaurants realized that is a going out of business strategy last year, and they pivoted to do a good job of takeout. So that involves a lot, that involve the executive team being involved, it involved with people on the ground who actually have to do the work.

So by its nature, organizational agility pervades more than just one group. What if I said this to you, I have an idea, it’s a great way to build software, you’ll believe it’s a much better approach than how you’ve been doing it in the past. And your goal should be to adopt this and you’re going to be really, really successful. Was I talking about agile? 

Speaker: Miljan Bajic  07:57

No, I mean in a way, but what I’m thinking, and what you’re making me think is like, just change and how, nobody was talking about what you need to do in the last 20 months. It’s just like, you got to adapt. And do you have that ability or not? That’s really what it was about, nobody cared what you did. It was, are you going to change or not? If you don’t change, and for a lot of companies and businesses, it was to survive or not, which makes me think about we talk about like, change takes, time change, at least the way that are perceived, a lot of times it just in my own experience in large organizations, but last 20 months, has made me think about, it can happen really quickly, if you have the right people and the right desire to change.

Speaker: Ken Rubin  08:52

My mindset. I mean, people who are inherently very nimble, in their thinking were able to adapt very quickly. You know what I mean? When I think about it, to me, it’s agile through the value chain. That’s what I’m looking for, for organizational agility. I mean, most organizations are, we start with Dev and IT that seems to be like the natural home, for agile for a lot of companies. But if you stop there, you’re not really going to achieve the kind of desired outcomes, as a business we probably want. We may get our dev and IT groups to be highly efficient at being agile, but they’re sort of they live within an ecosystem. 

And unless that ecosystem itself is aligned, all we’re going to have is sort of a mismatch throughout. You say oh, yeah, we’re agile over here, but over there finance does its own thing and legal does its own thing. And you just kind of go through all the groups and marketing in sales that keeps pushing more work into development, right? You get the idea. Organizational agility is the ability to step back, look at the big picture, and understand as a system. Are we able to inspect and adapt it to really to the environment which we have to operate, which right now still was a COVID environment?

Speaker: Miljan Bajic  10:04

Yeah. It’s interesting, because the reason I asked, I was talking to Evan from business agility Institute and I was asking him, I was looking at the report from last year. And there were three things, it was leadership, mindset, not necessarily tied to the leadership, but just mindset overall. And silos that we’re in identifies the biggest constraints to business agility. 

And you’ve done a lot of work with a lot of different organizations, you train a lot of people, I was looking, you train over 3000 people, you’ve worked with several 100 Companies. What are things that you see that are impeding organizational agility? Are those same things or do you see something different or maybe just a different perspective? I’m curious to know your thoughts. 

Speaker: Ken Rubin  10:56 

Yeah, I know. I think those labels are good ones. I approach it maybe a slightly different way. For me, organizations have an inertia, they’ve been doing something for a while, and it’s hard to stop that. And for some people, I guess they would call that a cultural impediments. Like culturally, we’re not aligned with doing this. That tends to be a fairly big issue in a lot of companies like these, it’s like, well, that’s not how we have done things, we’re comfortable, if they’re in a regulated environment, there’s even more of that, because we know we can pass an audit if we do it this way. 

Not sure if we make a change to that. So and that aligns with sort of the siloed idea, most organizations are by their construction, very siloed, which works against this concept of achieving organizational agility. You have this idea that we should be able to go across the silos and include everybody that we need to get the job done. On that leadership one, I view that as for a lack of commitment at the top of the house. This idea that, hey, we’re going to start doing Agile at the team level, and then maybe percolates up a little bit further. And eventually, you just hit a ceiling. You don’t have the right kind of commitment, which I do think alliance with Evans leadership one, you won’t get there. And then there’s, I guess, they’re just myopic. Myopic, in the sense of it’s about Dev and IT right? That’s what we should be focusing our time on. We’ve already argued organizational agility is by its definition, larger than just that. 

Speaker: Miljan Bajic  12:29

Do you think it’s ignorance or lack of understanding? Because I see that too, in a lot of times, it’s really lack of understanding about what organizational agility is, and what are the enablers and what it takes. And so mostly the Peter Principle in a sense, a lot of times people have gotten to these executive positions. But they really, a lot of times don’t fully understand the concept of systems, right? And understanding the systems and how to strike even business architecture. And that can be an impediment because if you’re not willing to make those structural changes, those policy changes as leaders, then like you said, it’s only going to go so far.

Speaker: Ken Rubin  13:16

I do think, I agree with that. I think it’s a natural consequence of where we are in the adoption curve. Maybe if you think about Jeff Moore’s work on crossing the chasm. And this idea that you got early adopters, right? You get visionaries, then you kind of get to the early majority, the late majority, things like that. Agile and Dev and IT is clearly across the chasm. I mean, almost any company you talk to today says they’re probably doing something agile. 

And you’ve even hit the late majority that people are like, I don’t move into everybody else move. They’re moving, right? But that’s Dev and IT. If you start broadening beyond that, I mean, the scrum Alliance used to do a survey right up. Where are you using Scrum in addition to Dev and IT? And you start to see things like well, HR or finance or legal or marketing things of that type. Now, it suggests that we’ve been in the chasm on that for a while. So you said is it sort of like an ignorance issue. It’s not malice, right? [inaudible 14:19] I think it’s like I thought it was about Dev and IT, right?

Now you’re telling me it can be broader than that. Where the examples point because remember, if you’re an early adopter, early adopters don’t care. They’re the ones making the examples, or the majority those like, I don’t move until I see the proof points where other companies have done it. I think we’re getting more and more of the so you could argue organizational agility is coming out of the chasm to the other side. But it’s been in the chasm for a long time, years. And I think that’s one of the bigger inhibitors right now.

Speaker: Miljan Bajic  14:55

I agree. And so if we also look at it from Agile in the framework side, we’ve been on that side where it’s like, give me the recipe and people are realizing that just one size does not fit all. What do you think on that curve we are with frameworks and coming back maybe to small talk and patterns? Do you think where people are or where are companies with realizing that it’s really contextualizing things and understanding my context, not just saying, give me safe or give me this framework and thinking that there’s this cookie cutter of a methodology what’s called or framework? 

Speaker: Ken Rubin  15:44

I think there’s a lot, there’s a great desire for frameworks. I mean, your scaled Agile has proved that, right? I mean, you put out a framework, and it’s well pictured, right? People look at it, and it appeals to a certain class of individuals. But I’m finding, I got a request the other day from a company, I signed a contract with them to do work, they go, okay, I want to talk about your framework for adopting agile framework. On are you expecting these large pictures like you’re used to seeing I mean, because every time I go into an organization to be of some assistance, there are certain things that we talk about, and it seems to be a theme. 

But every company is different.  And any company that’s ever told me, we’re going to use framework X, what they really meant by that is, we will mind framework X for good ideas. I mean, it’s rare that I encounter a company that’s like, oh, we went all in it, in fact, I did a survey on LinkedIn a couple weeks ago. And I asked the question when it comes to one of these scaling frameworks, don’t use them at all. Now, they’ve got a pretty high response rate, right? Use it, but mine it for good ideas that got the most and use it in textbook-like fashion, like 4%.

Like the multiple hundreds of people that responded to the survey. So I think it’s clear when the industry is on framework, the people like them, people want them, right? And yet, to the extent that they’re a source of good ideas, why not? Mind them for good ideas and create something that is culturally a good fit for your organization.

Speaker: Miljan Bajic  17:26

So maybe to use analogy, you can mind a cookbook for good recipes. But if you don’t know what you’re doing in a sense of like if you’re putting custom recipes together, and you’re like, these are the ingredients I have, and a lot of times in organizations, it can be very appealing, even let’s just say, PI planning and safe, right? It’s a great idea and makes sense. But if I don’t fully understand the context that that pattern or practice has been put into place, then you have an issue a lot of times, and this is what I see in organizations where you have cooks that think that are chefs, implementing this stuff and making something that somebody will say, well, this is agile or this is it.

I don’t want to part of it. Is that also part of that kind of just natural curve of just trying things out and figuring out? If it is, could we assume that better days are ahead, in context that we’ve been learning over the last 10 years? We do have to contextualize that we can’t rely just on cookie cutter frameworks, and that we do need to have people inside our companies that are capable of helping and guiding us rather than continuously relying on consultants, like yourself and myself. Do you think we’re heading in that direction? Do you think that’s the right direction if we are?

Speaker: Ken Rubin  18:57

To back up to an earlier piece you were saying, I would describe what you were saying earlier as cargo cult. And that I think bigger problem today is that people look at these frameworks and they adopt them. They don’t really understand the underlying mechanisms, the underlying why that they’re doing these things, they just becomes mechanics at that point. 

We do that. Why do you do that? Why do you do PI planning? What’s the purpose of that? How do you manage your dependencies? Or why are you doing it that way? If you don’t understand the foundational why that underlies these frameworks, you’re in no position to do anything other than adopt them, and just blindly follow them. 

I honestly had a call today with a company earlier today, where they have an enterprise PMO that they put in place with the only reason of collecting all the data and holding everybody in compliance with the safe framework as they want to execute it and which is supposed to be textbook like. I’m talking to the fellow on the phone and he’s like how’s it working for you? It’s remarkably painful, right,? And we spend a lot of our time just doing things or not doing things.

Because if we do something we’ll be temporarily out of compliance with what we’re supposed to be doing and will look bad because of it, even though it was the right thing to have done [inaudible 20:18] in the frameworks working against you, right to do that. So now, the good news about the person I’m speaking with is, he does not have a cargo cult mentality, he actually does understand the underlying fundamentals as to why we’re doing it. Most people just getting started don’t. So it’s easy just to cargo cult, the thing, right? And just follow it blindly and expect results to happen, it won’t.

Speaker: Miljan Bajic  20:41

And that’s part and what I’m seeing also is people that have gone through that journey from company to company, it’s easier to work when you have somebody that has gone through that, has tried it. And now, like you said, understands it. And it makes a lot easier, I guess to work with those organizations where you have leadership that sees the perspective that you’re trying to help them take. How do you scale? And to add, what are, we were talking about scaling, sometimes it really about the scaling, but what are your thoughts on end-to-end agility and scaling?

Speaker: Ken Rubin  21:22

So this one’s really important to me, because when I go into companies, I’m really curious. How are they organizing? So what is their unit for organizing at scale, right? Because for example, the obvious one that a lot of companies use projects, what a horrible unit for trying to organize at scale, right? I mean, projects are by their nature, fleeting, right? They start in a darn well, better end. All right, at some point, it’s kind of idea behind a project. So if you want to start to think about scaling, end to end agility, the first question every company should ask is, what’s the proper unit f or scaling?

Is it a product? Is it an application? Is it a customer journey? Is it a business capability? if you’re using say, if you’re going to use a value stream, right? So you need some unit that you’re going to focus on. And then the important part and this is the critical piece for me, is you need to create something I call a coordinated ecosystem. And the idea behind that is I’m just trying to align, remember end to end business, trying to align first, against this durable, business focused unit. So if we’re doing products, right? Products ought to be video customer facing, and long lived, durable. So the first thing you want to do is align your ecosystems, right? 

With the instances of this durable unit, whatever it’s going to be, then you want to cross organizational alignment of resources in the order now to get everybody on the bus necessary to do the job, right? We’ll put them in an ecosystem. So if I need legal and compliance, right in there, and I need design, in digital, and all these other groups that are typically aligned with the normal development teams, I need them there, then they ought to be brought into the ecosystem, bring everybody sort of together and encapsulate them.

Speaker: Miljan Bajic  23:17

So that’s almost like trying to minimize dependencies, trying to simplify things in many ways. So maybe before, I do have some question on dependencies, but I wanted to get your thoughts into it, since you brought it up, like organizing by value streams, or by customer journeys or product services. Typically, what I’ve seen asking a question first, like, who are your customers and users and then organizing? Maybe that’s a specific group of products. But how do you look at even if you’re coaching or maybe consultant like, when’s a good time? When is it good to organize by journeys or customer experiences versus product lines versus any. Is that dependent on anything? Do you have any insight f that or?

Speaker: Ken Rubin  24:15

Could actually be a kind of, usually companies choose one that they could. Occasionally I’ll see companies do new value streams or products and customer journeys, for example. Because for example, one organization that I’m working with has two separate conceptual entities that naturally go together column A and B. But they have to do onboarding. And onboarding as a customer journey is pretty much the same, right? Maybe some minor differences. So do you really want to have onboarding be part of A and B? Or do you want to just have a third, which would be a customer journey of onboarding?

Is the onboard a new customer journey? And so they may still have two products A and B or two value streams, A and B, but they complement it with this sort of onboarding journey, because it just makes sense to do that. I’m really looking for; this is a remarkably difficult problem. When people talk about it, like it’s like really easy. Oh, well, if I were an organizer on product, so my favorite question I ask is cool, tell me what your products are? Just write it out, tell me what your products are? And you just watch people fumble. Well, it’s this like, no, that’s not a product, that’s a component.

Well, what about this? Well, that’s not a product, I just asked you a simple question. What are your products? Now some companies can answer that, and they can be pretty definitive about it. And they’re going to have an easier time. I was at one company, took us three months to identify the products, the company. So anybody’s like, oh, let’s just let’s have a brainstorming session this afternoon. And we’ll sort of pound out what the products are. 

Yeah, good luck with that. I mean, that usually doesn’t go that smoothly, in my opinion. So but it’s easier, you got to go down that path, you got to get away from projects, at least something, whether applications tend not to be the best unit, because you get sort of an inverse Conway problem, you start to organize your ecosystems around existing applications, which are already kind of like just as big quagmire of dependencies, a big ball of mud, like, why would I go out of my way to create ecosystems to match an application infrastructure that I have had for decades?

I would say, your systems going to reflect the communication channels of the teams that built it [inaudible 26:40]. Here’s what I want, this is the system structure I want. Maybe I create the ecosystems to get me to that. So there’s a number of ways to approach it, typically, products, value streams, business capabilities, or journeys, are going to be your top choices. And you’d have to figure out in your organization, which one makes sense, if you’re going to save, you’re going to use value streams.

Speaker: Miljan Bajic  27:03

Yeah. Yeah, no, that’s really interesting, because it reminded me and maybe just to go back to what you’re saying, so for instance, onboarding, let’s just say, this happens a lot when I work with insurance companies, you might have a same onboarding process, right? Then you might have a dental insurance and vision insurance, right? So those could be separate. And what you’re saying is, the onboarding process could be the same for everybody. But somebody might just want vision and somebody might want dental, somebody might want all of those.

But the other thing, that’s interesting too, is what you brought up is systems, so like, you could have same system supporting both products in onboarding or different. And that’s a good example of why you wouldn’t want to organize by systems because they’re almost underlying and supporting those products or customer experiences. So I that makes sense to me. And I think that’s what I’ve seen also work well. And I don’t know if that’s a good example, from your perspective, if that’s what you meant.

Speaker: Ken Rubin  28:07

I mean most companies today, at least the ones that I encounter, are doing some form of tech modernization, they’re doing that because their system structure is not fit for purpose. If it was fit for purpose, they wouldn’t be doing tech modernization. So there’s an issue there. So why would you organize around that? 

Speaker: Miljan Bajic  28:27

Another thing I see is some company, especially they’ve been around for too long, have too many products. And in a sense, it’s very difficult to organize when you have a lot of products, and you can’t prioritize, and you have limited resources from IT resources, human capability side. And sometimes it’s tough to get into the insurance space if you’ve sold the plan, 30, 40 years ago, you can’t buy, its always that it’s hard to let go of products. And sometimes the best thing is to shred things off and focus on what your strategy is. Do you see that to or where companies have just too much going on, too many things, products, or whatever it is that they’re supporting, and not enough capability and capacity?

Speaker: Ken Rubin  29:21

Yeah, and I think that problem occurs along multiple dimensions, not just the physical number of products, but think about the just the version, like you mentioned, like the 40 years, it’s been out there. So if you’re a product-based company, one of your questions is, how many versions back device support, right? And in the world of continuous delivery, what constitutes a version, right? So you do it by time, you will support something, a release that we did up to 18 months ago, and anything older than that.

We don’t, that we could be up giving you five updates a day. And on that I call those new versions, right? But you have to have the ability to spin up an environment to match a customer’s environment for a system that was installed 15 years ago, so you can try to replicate the problem. I’ve watched that particular issue, cause enormous grief in companies like, oh, we spend so much of our time just trying to do so. Well, maybe you shouldn’t do that. Oh, but we promised our customers. Yeah, maybe you need to make different promises.

Speaker: Miljan Bajic  30:24

And make some tough decisions when it comes to that. But that’s another thing when, if you don’t have somebody to say like, this is what our direction is, envision this is where the focus is, we have to have a strategy to either get rid of these products or whatever, it’s a strategic decision. But maybe that goes back to the silos. It’s tough to say that, unless you’re either president or part of the board that you’re pushing. I don’t know. But that’s something that I see. Maybe to come back to the organization dependencies. So you’ve recently written a lot about that. You’ve talked about that. What are organizational dependencies, and why are they important?

Speaker: Ken Rubin  31:10

So yeah, this is to me, dependencies are what’s killing company’s ability to structure for flow at scale. And I define the dependencies to be pretty simple. I’ve got these two entities, two activities or resources and there’s a relationship between these two. And it requires some level of coordination in order to achieve good flow. So that to me is where the dependency is. These two things have to collaborate. And we have to orchestrate this in a way that we get good flow. And if we don’t, we can get blocked, which is where the problem comes in and blocked in the way like my team is dependent on your team to do the work.

And if your team doesn’t get it done, when you said you could, then my team is blocked and can’t move forward. And that causes a lot of big problems. So these organizational dependencies, the problem is, they tend to be woven into the fabric of most organizations. Now, those are the dependencies I call structural dependencies. It’s the equivalent like, hey, every time I need to do a UX, I need a UX design, I have my guy here, we’re agile, right? 

We got to have post it notes, or it’s just not agile, right? That’s the feature I want to deliver to a customer, but the UX design team, I have to tear that off. And I have to go over it and put it into the backlog of the UX design team. Well, if every time I have to get a design, I have to tear my post it note and go give it to the UX design team, I have a structural dependency on that, meaning, it’s woven into the fabric of how we’re organized. So then I can use the complementary term, which is instantiated dependency.

So if I have 50 different designs, I need that team to do each one is an instantiation of the structural link, it’s classes and instances, right? The structural dependency is the class and the actual work like hey, design team, I need to design for the onboarding screen, right? And I go give that to them, then that’s an instance of that dependency. Now imagine, if you want to make real improvements in your organization, where you ought to be focusing your time, is on the structural dependencies, not on the instantiated dependencies. 

Speaker: Miljan Bajic  33:31

Almost like a root cause type of thing. 

Speaker: Ken Rubin  31:33

If I get rid of the structure, mean what if I moved a UX designer onto my team? So next time, I have a post it note that pops up, right? I don’t have to tear it up. I could just add it, give it to the team and do it. I have eliminated all future instantiated dependencies. So that one move eliminated 50 instances of that dependency at some point in the future. So if you want to really get on top of your dependency problem, you need to focus on the structural dependencies first. Most people when they talk about dependencies other than feature teams, creating feature teams is a solution, one of the seven strategies for addressing structural dependencies.

But other than that, almost the entire rest of the conversation is all about instances. It’s the instantiated dependencies and blockers. And people use the term blocker and dependency as if they’re the same thing. And they are not, right? A blocker is a dependency that moved into the block state. I’m relying on the UX team to get this done by Monday. I have a dependency on the UX team. If they get it done on Monday, I never got blocked. Sorry, they didn’t get it done on Monday. I got blocked. So your every dependency has the potential to become a blocker, but every blocker is the result of a failed coordination of the dependency that bends. They’re not the same. So most of the world focuses on how do we manage and visualize and deal with instantiated dependencies. And when they become blockers, how do we manage it? I’m like great, what if you could avoid that altogether? 

Speaker: Miljan Bajic  35:17

So besides addressing structural changes, how do you help? I think one of the things that’s very eye opening for people is just when they see the dependencies, and when they see just because a lot of stuff that we do is not transparent or visualized. So what are some of the things may be, is there anything that people can do to at least create awareness about that those dependencies exist? And then the follow up question to that is, there is also economic side and economic consequences of those dependencies, which a lot of times we’ll get leaders to listen more carefully when you’re talking about, the economic impact of those dependencies.

Speaker: Ken Rubin  36:10

Well, let’s go in that order first. The economics of dependencies are pretty compelling. First, they affect three things principally, dependencies, when are out of control, impact your predictability, I think about the predictability, the state of knowing when something’s going to happen, right? In the presence of a large number of dependencies, pretty much predictability is gone, right? Because I can show you the math behind it.

But for every dependency that we add to the problem, we cut in half the probability of completing what we said, when we said we could do it. And it really goes up by exponentially. So if you cut in half every time, so if I have six dependencies, I have a one out of 64 chance of getting it done. So predictability at that level is really, really poor. So what’s the benefit company to having better predictability? What’s the value to you of actually being able to deliver when you said you could? The commitments that you make, and you meet with your customers, so one of the large costs, one of the biggest impacts is predictability. The second is cycle time.

Speaker: Miljan Bajic  37:24

I was going to say, yeah.

Speaker: Ken Rubin  37:27

Constantly getting blocked, right? Then it my analogy is click the click on the stopwatch, to start working on it, click, when you finish working on it, click. That click the click is going to be pretty long time, if you’re getting blocked, I mean, most people who do value stream maps inside their company to look at a particular process, every time I do them, 90% of the time the work is sitting idle, because it’s blocked by some dependency. 

I mean, what kind of improvement could you get? If you could squeeze waste out of the 90% number, you think the value is in having your Scrum teams be tenure, let’s make our Scrum teams 10% more efficient to doing Scrum. They’re idle 90% of the time, they spend 10% of their time doing Scrum, which means you squeeze a 10% improvement out of the 10% of the time you move the needle 1%.

If I could figure out how to address the idle time, usually through dependencies in managing whip better than I could 10% improvement there gives me a 9% return on investment immediately. We’re watching the wrong thing. And then lastly, pressurization. Oftentimes, the existence of dependencies forces us to work in an order that is not optimal for us. I want to do a B, C, then D, but I can’t because there’s some dependencies that are messing up that ordering. So now I have to do B, A C, D and that’s worth 1/10 the value if I do it in that order, that’s unfortunate. Do ABCD, I can’t, the dependencies are going to block me if I try. Combine all that together and you realize your life cycle profits are taking a big hit. So if you’re a senior executive, you ought to be staying up late at night worrying about your dependency problems.

Speaker: Miljan Bajic  39:14

Yeah, no. And like, what I also think is people don’t realize is that dependencies create rework most of the time. And a lot of times because of the rework, it’s a lot more costly to go back and do things. And I think if you just look at the dependencies in it, if you look at the deployment pipeline, and how much just within that many companies, how many dependencies there are where the work, stays. 

I dial and many companies, I don’t know what your experience has been, but nobody has any clue where those are, if you again, just had an idea, where those bottlenecks are windows with things standstill, you will be able to address them. But it’s almost like we talk about MBA and we talk about even in IT, but nobody has that really knowledge of that holistic view of what’s going on and addressing really the underlying issues. It’s almost like, at least in my experience, it’s very reactive from a leadership from people that are, in my opinion, accountable for addressing those dependencies.

Speaker: Ken Rubin  40:29

Yeah, and I agree with that because they haven’t modeled them, right? My approach to doing this is, I work with companies, I do dependency class. And almost always after that, I get called by companies, oh, hey, could you do a workshop, facilitate a workshop to help us do what you talked about in the class? And then the doing part is rather straightforward. It’s like, let’s create a model. I mean, just imagine boxes in lines that says here’s our team, here’s the UX team, and there’s a line that connects the two that says, I got a structural dependency on that, right? But well, stop there.

Then you fill it out with data, right? You collect information, like, well, how often do I make requests across that link? Do I go to a UX team once in a while, once a year, every day, right? How often am I doing that? And what is the cost of delay if they blocked me? If for some reason I make a request, and they don’t fulfill it, right? How likely am I to get blocked? So imagine you’re collecting all this in a big old spreadsheet and then you start to analyze that. And you can start to say, now I understand the picture. And then we look at some of those dependencies and go not worth my effort. We’re not worth doing anything about it, right?

Because if there are structural dependencies, very often you require structural changes to fix them. And hence my point earlier, but if you don’t have people up here committed, it’s not going to work. Because you’re going to get to a point like, well, we’re going to have to restructure these teams, chances are the people on the teams can’t make that decision on their own, kind of go up here. And if you hit that ceiling, then you’re not going to be successful, because you’re going to be stuck in the structural situation you’re at. 

Speaker: Miljan Bajic  42:11

Yeah, but I don’t know, you have a lot more expensive than I do but what I’m seeing is lack of that awareness at that level. So I don’t know if it’s like COO or somebody who’s responsible for that organizational architecture, understanding these dependencies and then helping others understand it. I just don’t see it in organizations, I don’t see the maturity of leadership to understand and look for those things. Do you see that? Maybe on maturity or maybe on the curve? What percentage would you say, of companies actually have leaders that understand it? Because if the tendencies and everything that we’ve been talking about here, is at the core of issues of impeding agility and then if we have like, 5% of people in companies actually understanding this, then that’s an impediment to the agility. Or how do you see it?

Speaker: Ken Rubin  43:15

I’ll say the way it’s coming to my mind right now. They’re praying at the myth, the praying at the altar of the dependency myths. They believe certain myths about dependencies are true. And therefore they believe that it is a manageable problem, because the believes these myths are true. And the problem is they’re myths, and they’re not true.

Speaker: Miljan Bajic  43:40

Or assumptions. I saw you talked about assumptions, is that assumption and what type of assumption would that be?

Speaker: Ken Rubin  43:48

Well, I’ll give you some examples of the assumptions, these myths that they’re like, oh, one size problem, one size solution will fit all types of dependency problems. If I just have a program board up on the wall to show my dependencies and path read string that connects cards, it’ll work for a small number of dependencies, it’ll work for a large number. No, it almost certainly worked for a small number dependencies. Anybody who’s ever done that, with a large number of red pieces of yarn up there knows it doesn’t work. Alright, so that’s one myth. Another myth would be if we could just figure out what all the dependencies are that mostly solves the problem.

Wrong, it doesn’t at all, the problem isn’t our inability to identify the dependencies. I mean, look, I know I have a dependency on the UX team. So I got this magic. So I didn’t know that I knew that. The problem is this, in the presence of a large number of dependencies wins in the organization, it’s the asynchronicity that kills you. It’s the when. I know that the UX team has to do this work. What I don’t know is when they’re going to do it and I don’t control the when, because it’s a shared dependency, so they think you identify them, then you’re good won’t work, or that, oh, you know what, this is just a problem with project management.

If we just hired better project managers and more project management process and had better tool support, we could totally get on top of this dependency problem sorted out. That’s got to be one of the king of the myths. Yeah, I know that’s not a problem. This is not a failure of project management. At large scale, this falls under the category of don’t do that, right? You’re not going to fix it with more project managers. So it’s these kinds of myths, there’s at least nine that I identify and talk about. And the problem is some of them are really damaging, like centralized demand management, oh, my goodness, the killer in most large companies that I visit. Oh, we’re going to do this, it works brilliantly.

I had a call two weeks ago with the companies, they start describing their problem, they’re like two minutes, I go centralized management. Like, what’s that? I go, let me explain what you’re going to tell me next. And you tell me if this is accurate. And I just grabbed, that’s pretty much it. So what should we do, I go stop doing that. We will have you on this call, because we want you to help us figure out to make it work. I go, I can’t, because it won’t work, right? How do you know that? 

Give me a reference, show me papers and say, okay, I don’t have any papers at all but I have this time in the trenches with a lot of big companies that tried to do exactly what you’re doing. And I can tell you the 15 reasons, it won’t work. And you can tell me whether or not you think those are going to be problems for you. At the end of the day, yeah, we have a problem knowing what you do. Because we believe this myth that this will solve your problem and it won’t. To me, that’s what’s going on at the executive level like, this is a manageable problem people, just look, if you can’t do the job, right, I’ll hire people who can.

Speaker: Miljan Bajic  46:46

And it goes back maybe to, it’s a leadership into mindset. And maybe we have about 10 more minutes left, I do want to get one more thing in here, which is related to what we’ve been talking about so far, which is not all cross functional teams are created equal. And you talked about how it’s important to have cross functional teams that are composed of T shaped individuals, essentially minimize those dependencies by having people that can get stuff done and not rely on UX department to finish work. Could you maybe elaborate on that topic a little bit, and why is it important? I call it almost like, maturity, one team and maturity two team.

Like we have cross functional team with bunch of specialists. Like developers and testers. I joke around, maybe it was seven, eight years ago, when developer told me that testing is below the paygrade. They want to test because they were senior developers much better to start item for next sprint that actually helped the team test to get the stuff done. And maybe is that’s a bunch of people that are silos and special cross functional team versus actually having people that help each other, developing those T shaped skills and develop the other skills that can help their teams deliver.

Speaker: Ken Rubin  48:14

Yeah to me, this is a very important topic. And it’s one of the seven strategies for addressing structural dependencies. Let’s make sure everybody’s clear on the terms, right? Because 20 cross functionality is a concept that you’d apply at an ecosystem and at a team level. And I want to put an adjective in front of it, completely cross functional is my goal. So the idea is, if a team is completely cross functional, it has all the skills on the team into achieve that team’s definition of done, whatever that might happen to be, they can get it done. So if I need UX designs to happen, then [inaudible 48:51] it, I got a UX design person on my team, otherwise, we would not be cross functionally complete. And I’d have to be carrying my posting notes, that happened. So that in an ecosystem level, I want the same thing. 

So if I bring all these people from across the organization together into one ecosystem, that ecosystem should be completely cross functional in its abilities. You typically do not apply the term completely cross functional to an individual. Some people try Oh, they’re a full stack engineer. And the idea was, well, they’re supposed to be able to do work at any different layer at their tech stack, and they might, don’t get me wrong but do they also do the legal work and the design work? 

So they’re not completely cross functional. They may be teaching, right? Teaching it on the other hand, typically applies to the individual, not to the ecosystem or the team, although you hear people use it at an ecosystem or team level, an ecosystem that would mean, our ecosystem can do more than one type of work. At a team level could be, our team can work on product A or product B, right? That might be how you hear people using T shaping at the team level.

Speaker: Miljan Bajic  50:02

So essentially, T shaped doesn’t really address the tendencies when you say you have cross functional teams, that you started addressing the tenants, because you’re saying you need to have everything plus when you add the T shaped individual layer to it, it gives you more options to minimize those dependencies.

Speaker: Ken Rubin  50:21

So it makes you more resilient. So for a reason, T shape just means vertically deepen some area, and can work outside their area, but wouldn’t be as deep, so their broad. The benefits of having individuals on your team that are T shaped, you actually do get a dependency benefit. But it reduces the structural dependencies that would happen inside, right? So think about it, let me start with the instantiated dependencies, there’s only one person on our team that does testing. So all the testing work has to go to that individual, there is a dependency within our team on that individual. 

And if we T shaped our people, so that more than one person could do that, I no longer have that unique dependency on that one individual, a bunch of people can do it. And the second big benefit I get is resiliency. If only one person can do it, what happens if she goes out a sec? I guess it doesn’t get done. And we don’t meet our sprint goal. So teams that have people that are comprised of T shaped skills are more resilient, when things go wrong, and can better deal with the variability of the work that is presented to the team from sprint to sprint. 

The sprint we’ve got a little bit more database work in the stories in the next sprint, we’re going to have a little bit more UI work, but that’s okay. Because people are T shaped and they can swarm to where the work is. So I get that kind of benefits, right by doing it. So whenever possible, what I’m looking for is completely cross functional ecosystems and teams, and somewhat T shaped people. I don’t want them to be completely T shaped because then people are going to freak out and go, oh, you’d not be able to do every task. I’m like, I did not say that. I did not need that. I’m just saying wouldn’t it be nice if they could do more than one thing but do a few things.

Speaker: Miljan Bajic  52:17

Yeah, I think, really important point. And also not forcing people to do something that they don’t want to develop, right? Like, in a sense, if somebody doesn’t want to test, then it’s waste of everybody’s time to get people. And that’s a lot of times, it might go back to the mindset where somebody just has that belief or that assumption, they don’t want to develop certain skill. So I think that’s where you have to have a discussion as a team, where are gaps and what are we going to do? If we only have one tester, and nobody wants to test, what options do we have? How are we going to deal with this as a team?

Speaker: Ken Rubin  52:57

Right. Developing the skills is really a team focus.

Speaker: Miljan Bajic  53:02

What would you like to leave us as it’s been almost an hour? What parting message would you like to leave us with here? Anything that I didn’t maybe ask you or anything that you usually maybe tell people.

Speaker: Ken Rubin  53:23

I actually think you hit on the topics that to me are the most important today. To me, it’s all about structuring for flow at scale. Now, my focus on dependencies, just because it’s like the killer problem that’s preventing that, but that dependencies aren’t my goal. So action for flow at scale is my goal. I’m just trying to figure out what in the world is getting in my way, that’s making it difficult for pretty much every company I visit? So if you want to be successful, and I’ll define what I mean, meet your targeted business outcomes. So if your company’s got like OKRs, than aligning with us, then you better figure out what’s getting in the way of you achieving those goals. And if you’re trying to do it at scale, my guess is, its dependencies and too much whipping your system or the things getting in your way. So go focus on those.