Jim York

Speaker: Miljan Bajic  00:37

Who’s Jim York? How did you maybe briefly get into this Agile space? And then I think I want to discuss some of the topics around product ownership. 

Speaker: Jim York  00:49

How did I get into the agile space? Well, harsh, I guess a little bit of osmosis, a little bit was the way I’ve always kind of thought and my mind kind of works that way. I started off as a management consultant and I found myself building applications, little boutique applications for my fellow consultants who did economic and cost analysis and industrial engineering. And I didn’t have any formal methodology training. I have a mathematics and an English background and with a loss of any guide to follow, I just did what made sense. And so, started off as a team of one kind of did everything soup to nuts from the analysis, gathering requirements, building, design, writing code, testing, doing deployments, operations maintenance, customer support, face it, I was a team of one so basically had to do everything. And the industrial engineers that I worked with, I learned lean concepts from them and I was expected to be an eight hour a day billable management consultant. 

So, all this building of little applications was kind of on my own time and so I had limited capacity and limited time to really work on those things. So, I built things in small chunks and they had to work because people began to rely on them. And over a period of time, I found myself building teams because I couldn’t do it all by myself. So, I recruited similar minded people and with our methodology, we just kind of got into the work and I taught them the way I was doing things. And so certain advantage, no shackles, nobody telling us exactly how to build things. We just did what made sense. 

Speaker: Miljan Bajic  02:50

Did you get into the training piece because you’re one of the earlier trainers?

Speaker: Jim York  02:54

Well, training was part of it as well right so I had to teach people how to use stuff. When I arrived at the company I was working at that time, they only had one PC and nobody was using it. They just bought it and I was the only one using it. Until I started writing these applications and then other people started use it and then the demand expanded and they started wanting to have more computers so I became the network administrator. So, I was teaching people how to use the applications, I was teaching them how to use computers, it was just kind of a natural need.

Speaker: Miljan Bajic  03:30 

You’re dating yourself there. 

Speaker: Jim York  03:33 

I mean definitely. Back in the day, let me just paint the picture a little bit more clearly. I was building the hardware. We bought the first computer ready out of the box but every one that we built after that for the next couple of years, I built by hand and I strangle cables and I installed all the NIC cards and managed all the various connections. You had to manually move pins on the card to get different network addresses and the like. So yeah, I’m definitely dating myself. 

But I found training is to be part of it and I was also coaching. I was teaching others how to work as I was working so I was acting as that advisor, mentor and coach and I was still that eight hour a day billable management consultant. So, I found myself building teams and after a period of time, some clients found I could build teams and they asked me to come help them build better teams. So, I kind of fell into the Agile thing really by accident and through the years I met more and more people and stumbled into the Agile space through extreme programming and Scrum in the late 90s. And in the early 2000s, I had the opportunity to work with Ken Schwaber and others that are early pioneers in this space. I was one of the CSTs that got my stripes by co-teaching with Ken over a number of years and he essentially at one point knighted me and said, go forth and make other CSMs. That’s all there was in those days was certified scrum master training. There wasn’t the product owner or the developer training or any of the advanced classes. You basically took people as far as they could go.

Speaker: Miljan Bajic  05:22

What do you remember about Ken and how did you meet him? 

Speaker: Jim York  05:29

How did I meet Ken Schwaber? Well, let me see. I think I originally met Ken when I took my CSM. It was I believe mid-November of 2004. I went up to Boston, little town outside of Boston. We had a class and I was working for a client at that time and the client was adopting agile in a big way, was a large financial organization here on the East Coast and they were interested in having Ken come and train for them. And I said oh well, I can help with that and I made the arrangements to bring Ken down and to teach the class there and that was December of 2004. And Ken arranged for four of us to co-train with him for that CSM class for that financial services client. I’m trying to remember all the folks who were there. I remember Bill Wake, he was one of the people who was co-training along with us and Bill was also working with me at that time down at that financial services client. 

So yeah, I met Ken through that experience and we became friends and I co trained with him. I also had along for the journey at that time, we had oh gosh Kurt Peterson who helped Ken to improve I should say upon the original CSM class. We incorporated materials with the support and blessing of Mike Cohn. So we always joked about we had Ken Schwaber and Mike Cohn and it was the Dow and the How. So Ken is the philosophical kind of leader so he was the Dow and Mike Cohn is he’s the pragmatist and he was the how you do things. So, we have the Dow and the how and Kurt Peterson, he introduced a theatrical element to this. He had a theater background so a lot of the exercises and improvisational kinds of techniques that you see in the training that many of the trainers still do today have their roots in what Kurt Peterson contributed to the movement. Of course, Kurt worked with Matt Smith an improv artist out of Seattle. And so, we had an interesting blend and eclectic mix that came about and I think I was like number 17 CST.

Speaker: Miljan Bajic  07:57

Yeah, I remember you and I talking there early on.

Speaker: Jim York  08:03

So, we did a separate coaching, right. I mean it was all wrapped in when you were a CST that time you had to be a coach. So, we had a bifurcation in that I guess 2008 when the scrum Alliance created the certification program, the guide level for the coaches. So, we have a certified scrum coach, originally now we’re certified agile coaches and that’s further bifurcated into team coaches and enterprise coaches. I think really, you’re a team coach and an enterprise coach, right? 

Speaker: Miljan Bajic  08:35 

Correct! Because I think I may have been I’m not sure scrum coach and then when they changed it was enterprise Agile coach and then when they introduced the certified team coach, you essentially become a team coach by default or something like that.

Speaker: Jim York  08:51

Right! Well, you would already hit like the peak of the guide level with a certified scrum coach. So certified team coach was kind of a stepping stone towards that or at least that was originally envisioned. It’s kind of changed a little bit since then. 

Speaker: Miljan Bajic  09:06

It is and I think there’s that like distinction and I don’t know what to make of it but like there are enterprise agile coaches, there are trainers but there are trainers that are not enterprise agile coaches and vice versa enterprise agile coaches that are not trainers and I think like you said training and coaching is part of the whole kind of experience and skill set that you need to have as a trainer and coach and another thing that is part of that skill set is understanding business and I think a lot of trainers and a lot of scrum masters and coaches and even sadly product owners don’t really know what product ownership is about. 

So, I thought maybe we spent a little bit of time or a decent amount of time. I really want to dive deeper into the product ownership. So maybe to start with how do you define a product? Because if you own a product and your product own the product backlog, I think it would be helpful to hear your perspective on what is the product?

Speaker: Jim York  10:16

Yeah, the product is one of the big questions that often comes about anytime I’m coaching within an organization and it often comes about during trainings is what’s the product. And I don’t think we necessarily start with the product, I think we really start with who’s the customer, who’s the target customer. And then we think about that customer and using another approach the jobs to be done. So what is that customer’s job to be done? And it’s only when we understand the customer and the job to be done that we can start thinking about the product. And I think about the product is being the thing that satisfies the customer’s need. So, the need that I’m talking about is the need within their job to be done which isn’t currently satisfied, optimally. So, we’re targeting a specific customer, we’re targeting a specific job to be done within that customer’s world and within that job to be done, we’re targeting a space where there’s opportunity for making things better for that customer. 

So ultimately, I think of that product is as not being the tangible instantiation of the product in this moment. I’m thinking of the product is that thing that evolves through time as that customer’s need changes, as new technologies emerge, as new laws or regulations emerge, as cultures evolve and change. All those different shifting dynamics can affect the possibilities of what it is that is needed. 

So, I typically think of the product in a nutshell is the thing that addresses the customer’s need. So that frees us up to come up with a variety of different potential solutions and also to evolve or perhaps even discard and replace a solution because it’s not about the solution, it’s about the thing that solves the need.

Speaker: Miljan Bajic  12:20

Exactly. What’s your thought on customer versus user? 

Speaker: Jim York  12:28

I mean the customer classically is the one who’s buying the product right. They aren’t necessarily the person that is going to use the product. There’s often this separation between the customer, the user and sometimes the word client gets thrown in there. So, client is a little bit more like user except clients typically thought of as being professional services so more of a services orientation as opposed to a physical, tangible product. 

So, the basic difference that I see between the customer and the user or client is the person who pays for it, who actually buys it is the investor in the solution and the person that is taking that solution and using it in their job to be done, whatever that might be. And of course, those two could be the same. I mean you could have the client who is also the person who uses it.

Speaker: Miljan Bajic  13:24

Yeah, and the reason I ask a lot of times in my class is people don’t fully understand the difference. So, I joke around and describe exactly that. Like if I’m buying a bike for my son, he is the user, I am the customer, right and mommy is the stakeholder, very powerful.

Speaker: Jim York  13:42

Very important stakeholder.

Speaker: Miljan Bajic  13:45

And then if I’m buying bike for myself, I’m both customer and user. And in a situation where my son is a user, he loves Spider Man and from that perspective, you want to make sure that you design something for the user but at the same time, mommy has told us that we can’t spend more than 100 bucks. We’re working within maybe a limited budget or we can go back and always ask for more. But in a sense, I’m working with the budget and he is interested in getting the bike that he likes. So, if you’re providing that service or product, you have to think about both, right?

Speaker: Jim York  14:26

Yeah, I’ve often thought of the metaphor of an architect for a product owner. So, back in the day, when we were able to conduct classes at a hotel facility, we’d be in a meeting room typically within a hotel and I call out think about the architect that was responsible for the room that were sitting in. Were they the investor, was it their money? He was like no, that’s somebody else’s money. They’re simply making a design within what it is that investor wants to buy. It’s like okay, alright. Is the architect going to be the user? Are they going to come and use the meeting facility? And they’re thinking well, maybe but probably not. So it’s okay so they need to consider the needs of the investor, the customer, the buyer. They have to consider the user who’s going to be using the space. Alright, so what about the other things that are related to what happens with the space? 

Often I was in Marriott’s, right so it was like okay so Marriott’s, if you were in say a courtyard for example, a Courtyard Marriott, there are certain color schemes and the way that the building looks for most of them. And I say do you think the architect had the ability to just discard those branding standards that Marriot sets for their courtyards or do you think that’s a constraint that they have to operate within? They’re like oh no, that’s a constraint. So okay, so as a product owner, do you sometimes have to operate within branding constraints? They are like oh yeah sometimes. What about zoning regulations? Does the product owner, can they just disregard the zoning regulations? No, they have to comply with them. Okay, so local laws and regulations are things a product owner might need to comply with as well. What about all the disciplines related actually in building this facility?

So, we have structural engineers, mechanical engineers, specialist in HVAC, plumbing, electricity, you name it. So, is the architect an expert in all of those domains? No, of course not. I say oh, but do they have to understand what those things are at a high level? Oh, certainly. They have to rely upon those experts in those domains to provide the information. They’re like oh yeah, absolutely. Is there ever a conflict? Oh absolutely, sometimes there’s fireworks. It’s like good because healthy conflict is essential to getting the right information available so that you can then assimilate that into your decision process. So, what about the actual physical building of this facility? Oh yeah, there were people, there were carpenters and electricians and all these people. It’s like yeah. So does the architect have to nurture that cadre of people who are doing the work so they come together as essentially an ensemble and then they actually work as a team to create this product? Absolutely! And while they’re doing that, do they have to manage that coalition of stakeholders like the investor, the zoning folks, all the other things do they have to make sure that they can hold that coalition together and preserve the integrity of the vision of what this is all about? Like yeah. 

So, I kind of think about what a traditional kind of holistic architecture would do and say you know that’s kind of like a product owner. They have to keep in mind all of these things and I don’t expect them to be expert at all of the various disciplines and domains in that space but I do expect them to pull that together.

Speaker: Miljan Bajic  18:05

What about decision making and from authority standpoint and I don’t know that much. I’m diving into the construction space but I’m not sure or I don’t know what kind of authority I’m assuming.

Speaker: Jim York  18:22

That’s when who you hire but I mean I think the ultimate authority when you’re talking about an architect is really the customer. At the end of the day, it boils down to that individual who’s paying for the product and I think about the extension of that. It’s not necessarily who’s funding it, the initial investor. It’s downstream are people actually going to buy the product because that’s what we’re ultimately looking for is cash flow. And in the absence of cash flow, that product is not going to be sustainable. So, you’re really taking a lien perspective on this. You’re looking at the end of the value stream and that’s ultimately where your funding is going to come from. You might have some upfront investment but that investor is looking for a return on that investment. 

Speaker: Miljan Bajic  19:11

Would that be that like the investor or the customer is delegating that authority to the architect in this instance?

Speaker: Jim York  19:20

I think so. I think a certain trust that has to exist between the customer and the architect or the product owner to kind of move away from the metaphor of the architect. They have to trust that individual is going to be doing the best job they can to make the best decisions based on what they know at the time. And then of course, we want to activate a learning loop because it’s unlikely in the environments where product owners are appropriately applying agile techniques that there are unknowns, right. So, every item in the product backlog is essentially hypothesis. There is no empirical data that the decision around that item what exactly it is and at what level of robustness or quality if that item is a good fit for purpose. 

So, an effective product owner is going to activate a learning loop of quick and hopefully, cheap learning loop where we try something and get a reaction from real customer. And then once we get that reaction then we have some data, then we have something we can work with. 

Speaker: Miljan Bajic  20:31

Yeah, so for that like there needs to be some kind of or at least you know and I think you’ll probably agree with this or in large organizations and it’s getting better people that put into product ownership role don’t fully understand about that feedback loop and that validation. And then the second thing is, they don’t have the authority even if they understood what product ownership is about, they don’t have the authority to actually make the decisions around how do I create some type of what am I trying to validate here? How could I align with people that are doing this as quickly as possible, validate going back to the jobs to be done or the problems or opportunities that we’re trying to help our customers?

Speaker: Jim York  21:19

Yeah, I think that’s one of the biggest shortcomings of the way the role is put in place in many organizations and there’s many different models of product ownership. I tend to take a more holistic perspective, cradle to grave, so addressing the customers need. Needs tend to persist through time. They might shift a little bit but needs tend to persist. So, I think that product owner is owning the product over the entire product lifecycle which is long as we can pivot and address whatever the customers need is and how it’s shifted then, that’s a long tail. I mean this is not a time boxed exercise, this is not a closed ended game, this is an open-ended game and we want to play it as long as we can as long as we’re creating value for the customer. 

So, in order to effectively do that, having a product owner is truly empowered to act in the best interest of the customer and think about both short-term execution and creation of value as long as long-term sustainability of that value and make decisions around that. So, there’s a lot of influences on product owners’ decision-making processes and I encourage those influences. I want to have people with strong opinions, different opinions. We want to get as much information out and available to the product owner so that they can make a better-informed decision. In order to do that effectively, we need to fully empower that product owner and I’m going to use a definition of empowerment that I got from Rob inaudible(23:00) from Australia. He was a project manager. I would say he is a project management guru. He wrote a book called extreme project management. And Rob shared with me years ago probably in 2000 I think it was kind of what is meant by fully empowered and he called these the characteristics of a business sponsor and he used two very visual metaphors here. 

He said the business sponsor needs to have the baseball bat and the bag of money and the baseball bat is the organizational authority to resolve any and all conflict within the product space. So, you could second guess but you had to respect that authority. When that individual made the decision, no one could kind of usurp it or take away from that decision. So, the second is the bag of money. It’s not that there’s endless money but once you have that bag of money, whatever that is it’s made available to the product then that business sponsor can unilaterally decide how to spend the money. No one can tell them how to spend the money. It’s fully in their control. 

So, again, thinking about the product owner role in scrum, the product owner I believe has those same characteristics if we look at the scrum guide and how the role is set up. This is the person who is responsible for the creation of value. This is the individual who is managing the return on an investment. In order for them to be effective and doing that job, they have to have the authority to make the business decisions.

Speaker: Miljan Bajic  24:45

I was talking to Daniel Mesic and I think he articulated it really well, in a sense. One of the things that he said that kind of resonated with me and I’ve heard him say it before but like specifically. He said like the decision rights in scrum are the hardest thing to do and most companies try to implement the process. But to have a product owner that’s truly empowered and like you just described, to have the teams that are self-directing or self-organizing, to have a scrum master that’s a true change agent with that type of authority is very rare for organizations to implement. And yet, they doing daily stand ups and retrospectives when we’re doing scrum and they get 10-15% that he calls improvement and they’re happy and he’s like, they don’t even have to do scrum to get those type of results.

Speaker: Jim York  25:46

I mean there’s tremendous potential in having more effective decisions. If we can truly get the product backlog ordered with the most impactful work at the top, we can pull off Pareto and get an 80/20. And an 80/20 is essentially four times return during that 20% of the effort that we’re spending. In the initial part, we get 80% of the return, that’s four times versus a randomized execution of items in a list. If somebody’s saying oh, we got a lift of 15 or 20% like you’re telling me you’ve done everything in scrum except improve your process and improve your decision making because it’s not just four times the value potential by having a Pareto possible. It’s also that scrum master having the ability to work with the organization to improve its delivery process. And if we can get a shorter cycle time for example, by eliminating a lot of the waste in the handoffs, by working together as a team as opposed to having to go through silos in the organization, when you do that, you can shorten the cycle time substantially easily by multiples at least twice as fast. 

I remember one organization I worked with, they were implementing change requests and they had a manager that would take in the request and they’d say oh, I need an analyst, I need a developer and I need a tester and I need somebody to fix the documentation and they go into this matrix pool of available people and they’d find each of these people and try to find an opening in their schedule and get them all together. And we have a discussion about okay, we’ve got this this request and then we would send a requirements analyst off to have a conversation and document the customer’s request and then this manager will try to find a time to coordinate all the people to come back together again to walk through the documentation of that request and then hand it off to somebody who’s going to do the design changes.

Speaker: Miljan Bajic  27:58

And if you’ve ever done that, you know what that looks like and how difficult that is and you’re always behind and you always feel like driving it and seems like the wrong person is driving all the time. 

Speaker: Jim York  28:13

Well, and you have things that slip through and you have to make fixes and you kind of have to go back. The average cycle time to get even the minus change would be something like oh, change the case of this word from lowercase to uppercase. Literally, their cycle time on average was three weeks to make any change and from all these kinds of minor requests. And what they decided to do instead was we’re just going to take a group of people, a team essentially and have them include the various skills that were necessary to make the average change. So, you’d have somebody who could do analysis, somebody who could do design, somebody who could code, somebody who could test, somebody who could do documentation and that became essentially a pod or a team. And when a requester had a requested pop to top of the queue, they would look and see well, what teams are available. Okay well, let’s assign it to this team and they would call up the customer and say can you show up on Tuesday at 9:30. And so the customer would walk in the door at 9:30 and they walk into a room and here’s these people and they say well, what do you need and they start describing what their needs were and they shortened their cycle time including deployment from three weeks down to three hours. 

Speaker: Miljan Bajic  29:29

Some people don’t fully grasp and I didn’t initially grasp the importance of that feedback loop and that cycle and I don’t know who it was that was describing and said, maybe it was, I’m not sure I was interviewing somebody and they said if I could describe agile in a simple term. It’s about how short of a feedback loop can we create and validate things.

Speaker: Jim York  29:58

And how fast can we learn? And we’re learning about a lot of things that are happening simultaneously, we’re learning about the product, we’re learning about the customers job to be done and how our product fits into that. So, there’s this whole stream of things that are product related where we activate these really fast learning loops but it’s also our processes. So, it’s learning what works and what doesn’t work and how to improve our processes and we also have that human dynamic of our relationships because a lot of the things that are going on with an agile team are kind of a social or emotional level and how do we work with a new requester? Hey, we’ve never worked with this individual before, what are their preferences? Do they trust us? And we learn over time how to accelerate that process of building trust, and learning the dynamics of the human system. How do we work with the various stakeholders and that very quickly grows beyond what was often traditionally thought of as the traditional scrum team which was the coders and the testers and documentation specialists. 

And what we’ve seen in the latest version of the scrum guide this 2020 issue of the scrum guide is that concept of the strong team has expanded to include customer support, operations, maintenance, strategy, sales, marketing. Those are all considered to be developers in the scrum framework and this is the way it’s now expressed in the 2020 version of the scrum guide. But those are new words, that’s not new spirit. The spirit of scrum is the same from the early days that was a whole team concept. It’s simply through implementation over the subsequent years that it got kind of scaled down in more myoptic to being oh it’s just the development groups. And we see some implementations where literally, it’s only coders that are doing scrum and testers and the UX folks and others are kind of shoved off to the periphery not a very good instantiation of scrum and like organizations do that.

Speaker: Miljan Bajic  32:04

You just remind me, in a sense like going back to the 2020 version of this scrum guide and I think I have some personal issues sometimes with the scrum guide, sometimes I don’t. Some of the issues that I have is okay, I understand that we have to dumb it down in order to understand it. But a lot of times, it’s also like unpack the what’s behind it, right? Like why are you putting this in the scrum guide. And I think another example which I like is getting rid of roles and putting accountabilities. I think as we’re dealing more and more with complexity, it’s about understanding complexity and how to understand the patterns and how to context and how to work within the situation that you’re at rather than just say oh, the scrum guide says this on page 10 and therefore, this is what I do right just blindly applying something without fully understanding it. 

And I think it turning back to the roles, getting rid of roles putting accountability, we’re moving towards not almost but as a group of people working to solve problems. It doesn’t matter who’s the scrum master, who’s the product owner, who is the developer, they’re all expected to be able similar to leadership, they’re all expected to come and step into these roles. But it is helpful to at least at times clarify the accountability so it makes sense to focus on accountabilities rather than roles.

Speaker: Jim York  33:37

When we talk about a soccer team, we have we have team members and we have a team member for example that’s called a goalie, right? We don’t talk about who’s going to play the role of goalie. When we talk about the goalie, we talk about their accountabilities, what is the purpose of the role, what is their reason for being on the team and then we talk about their rights and responsibilities and not every team member has the same rights and responsibilities. There’s only one goalie on the field for a given side in a game. If somebody else tries to act in that way you get penalties, right? 

Speaker: Miljan Bajic  34:27

Although when you do play street soccer, anybody can jump in play the goalie. Obviously, you can’t use your hands but at least the one that I played.

Speaker: Jim York  34:39

Oh, certainly. Well, and you can also jump in there and use your hands. You just have to be willing to accept the consequences.

Speaker: Miljan Bajic  34:47

Well, yeah true which reminds me of I don’t know. I think somebody within our community was saying like how they are different versions of scrum and how they are different versions of American football and it made me think about yeah, there are different versions of soccer especially the street soccer that played is different than you know what a professional FIFA rules are around the game but it’s still soccer in the sense. It’s slightly different and I think when you apply that to scrum in that way, are there different versions of scrum the way that they are different versions of soccer? I don’t know it just made me think of that analogy.

Speaker: Jim York  35:37

I think the whole idea of staying true to the spirit of the game is and you and I as coaches. I mean that’s what we do with organizations and the teams that we work with. It’s let’s stay true to the spirit of this and not worry so much about policing the rules so much. But we do want to make sure we realize the underlying intent of this and of course, there’s always fit for purpose with the approach. Is an agile approach even appropriate within the nature of the environment that the organization finds itself? If you’re in the business of cranking widgets and that’s how you make money and that’s how you satisfy customers or there’s not a lot of innovation, agile might not be the tool to pull out of the toolkit. You might want to apply something more along the lines of a six sigma process for example. 

So, I think that’s staying true to understanding the underlying intent of the various tools in the tool box and pulling out the agile tools when we’re in the context where those are appropriate and pulling out the more prescriptive or standard operating procedure or six sigma type of things when we’re in environments that are more complicated and complex.

Speaker: Miljan Bajic  36:53

What are your thoughts when it comes to sticking with the scrum guide 2020 and the product goal? 

Speaker: Jim York  37:03

Yeah, so the product goal I think is an interesting and again, it’s not an ad. The focus has been a core value of Scrum from day one and I’m sure you’ve seen it in the various product backlogs that you’ve seen as a coach is often there’s an eclectic mix of stuff in there that’s pointing in all sorts of different directions at a given point in time. And I think, there are things that are done in the scrum guide that are corrective actions, that are reactive to things that we have seen and I often liken it to trying to catch lightning in a bottle. Trying to capture something is as complex as scrum in into a few words is extraordinarily difficult to do. So, I think we have these various attempts and it’s like thank goodness, we’re agile. We don’t write it down and then say those are the words and we’re sticking to the words. It’s we’re writing down the words and going okay, how did that do and then we observe for a while and see the behaviors. 

So, I think the idea of a product goal I think there’s some really interesting elements in this latest version of the scrum guide, the product goal. I like the words that you must attain or abandon one product goal before taking on another. And it’s like okay, so I’m thinking about all the infrastructure support agile teams that I work with. It’s like what exactly is your goal? And then they’re starting to question things and wonder about their organizational designs and is that truly appropriate. 

So, if the rationale behind putting the product goal in there and being specific that there can be only one and only one at a given point in time and it must be either fulfilled or abandoned before taking on another, if that causes organizations to step back and kind of think about more deeply their current organizational design and if there is perhaps a better way, I think that’s going to lead to a number of interesting experiments over the next couple of years and we’ll see. I mean we’re not going to know.

Speaker: Miljan Bajic  39:15

So, you think the emphasis on product goal is to help organizations focus obviously but also to rethink their structural.

Speaker: Jim York  39:26

Oh, absolutely. Yeah, I think a lot of a lot of the problems that we have is from unnecessary complexity in what we’re trying to do in our organizational designs. If there’s one thing that COVID-19 has done, I think it has made us realize how precious time is and we need to use the limited time that we have available to us especially the limited collaborative time that we have to those things that are most important and to those things that actually require collaboration. 

So, to have the establishment of a product goal, it’s like okay, that’s a simplifying technique. There’s one and only one goal. And of course, that’s not the only way to do things, you can have multiple goals obviously. If you want to be effective in delivering and you’re struggling at being effective at delivering, simplifying things is often one of the first techniques is let’s step back and rather than try to juggle nine balls simultaneously, let’s see if we can juggle one. Can we toss a ball up and down in our hands?

Speaker: Miljan Bajic  40:38

inaudible

Speaker: Jim York  40:41

Once we’ve mastered that then perhaps, we can master doing more items simultaneously. But what’s the benefit of doing that is the additional complexity, is the benefit that we receive offsetting the additional complexity and again, that’s a question that’s out there. I don’t think there’s necessarily an answer for that. I think that’s something organizations need to discover.

Speaker: Miljan Bajic  41:12

Do you think the scrum guide has gotten more explicit on the backlog refinement in 2020 or what are your thoughts?

Speaker: Jim York  41:19

Well, in many ways, I think it’s gotten less explicit but also clearer about what it is that we expect to be going on. I mean product backlogs used to have the different attributes right. You had to have the definition, you had to have the value, you had to have the estimate and the order and then the optional grouping. All that’s gone from the 2020 scrum guide. It’s like no, we’re not going to be prescriptive and tell you what the attributes are of a product backlog item. I don’t know if that’s good or bad that those discrete attributes are no longer there. It’s not going to stop me from having conversations with people about what is value and why should that be something that’s considered when you’re talking about a product backlog item and how do you model that value? How do you compare the value of one item versus another? Is a value something that is an actual or is a value something that’s also like the level of effort, an estimate? So, people begin to realize in those kinds of conversations all of the stuff that goes on in product backlog refinement is all hypothetical. 

Speaker: Miljan Bajic  42:32

At the end of the day, it’s also about building that shared understanding and it’s one of the biggest I think misunderstandings and biggest challenges that most teams face is they don’t fully understand that this goes again back oh, I think we’re supposed to be adding acceptance criteria but the underlying nature is about how are we getting on the same page, how are we building a shared understanding and how can we do that without wasting each other’s time? Like, how can we get to the shared understanding is like taking a lean approach with the smallest amount of waste when it comes to time when it comes to collaboration and a lot of developers hate backlog refinement just because they’re either not well facilitated or they’re just purely waste of time. What do you do? I have my own things that I tried to help teams but how do you help teams with improving their backlog refinement?

Speaker: Jim York  43:35

Well, number one, again simplify. During this last year, I’ve been encouraging product owners to reduce their actively managed product backlog to be no more than six to 12 weeks. It’s like why are you planning out longer term. Now, there might be some good reasons in certain environments where yes, you need to have a longer planning horizon but we’re trying to figure out this new dynamic of how we work together when we’re working at a distance and not in a shared team space and again, that’s nothing new. We’ve always had remote team members, we’ve just kind of never faced up to the fact that that is something that we really need to address within our teams. We don’t necessarily treat them as equal team members but now that everyone is kind of on a level playing field for most people still. There’s a lot of folks that are working remotely. 

Simply simplify and make the work visible. When you have a physical team room, typically have four walls. A lot of teams unfortunately, these days don’t take advantage of the four walls they lock all of their product backlog and their sprint backlog into some sort of electronic tool which is fine. You can put stuff in electronic tool but don’t lock it in there. Get it out on the walls, get information available so people can see it. When you walk into a team room, you can absorb a lot of information visually just by looking around at the four walls and see oh, there’s our mission or a purpose why we exist. Here’s a product roadmap. Oh, here’s the product backlog, here are the things that we’re thinking about doing over the next quarter or two. Oh, here’s the current sprint backlog, I can look and see exactly what’s in flight right now and who’s working on what and you can look around the room and actually see people working on stuff. When you’re remote, now you are dealing with even more limited real estate. Most people are dealing with one maybe two computer screens but a lot of people are looking at one computer screen. So, it’s like well, how are you agile and 24 inches?

Speaker: Miljan Bajic  45:32

Well, it’s not even about agile. It’s just understanding the fundamentals of communication. How do you communicate and collaborate and then how do we through that whole communication and collaboration, how we’re building that shared understanding? That’s really all it’s about.

Speaker: Jim York  45:46

Yeah. So, using the tools that we have available to us and putting the most important information out there and don’t clutter it with lots of other extraneous unnecessary information so having a shorter product backlog. If I’m a stakeholder and requester and I’m looking at that product backlog and I am hey Miljan, my items not on there. It’s like okay then it’s obvious to you we’re not working on that right now. So making things obvious I think is a big part of the product owners job. So Miljan, I really want that. So you’re going to push back on me and say okay Jim, prove to me why it is that your item is of higher value than the items in my current product backlog. And oh, by the way, based on our current rate of delivery, it has to fit in what we expect to get done over the next 6 to 12 weeks. So that’s the section of the product backlog and a lot of stuff grows stale really quickly in an agile environment. Again, we’re working in an environment where there are unknowns, we’re trying to activate those learning loops so we get smarter all the time. So, a lot of the things that we had in the backlog earlier were put there when we were less informed. So many of those get overcome by events just because they become obsolete over time naturally. Other times, they evolve into something different because we have a better understanding as we go through. 

So, I encourage product owners not to build out a really long queue. Keep the queues really short. That improves visibility, that improves the team’s understanding. If I’m a developer and I’m coming to a product backlog refinement activity whether it’s a meeting or just a hallway conversation, if we’re talking about something million that we’re going to be working on maybe in the next couple of sprint’s, hey, you’ve got my ear because well this is another part of a strong belief I have with scrum is that idea of self-managing. I expect teams to become the teams they need to be by the time those items arrive in a sprint planning meeting. So, I want to see it coming and if we are not the team that can do what it is that’s at the top of the queue and is being introduced as a candidate for the sprint planning meeting, shame on us if we did not call out in advance hey, we need training, mentoring, a supplemental staffing because this is just kind of a one off. 

Speaker: Miljan Bajic  48:02

That goes back to the authority and then being able to get that. A lot of times themes are screaming and not getting that because really you implement scrum but you don’t change any authority or how the decisions are made. And at that point, things are going like okay, this is scrum and you talk about it but we have same level of decision making. our hands essentially tied behind our backs and who asked us to do this.

Speaker: Jim York  48:30

Well, we have to test whether there is an interest and actually getting to done right. So, we have to have a really robust definition of done what that truly means and that’s the only way we activate that learning loop of is it a good fit for purpose, right. So if we are going to implement a really robust definition of done and we’re going to activate that feedback loop, what that essentially means that well and this is actually my favorite line in the scrum guide, the 2020 version. “The moment a prime a product backlog item meets the definition of done an increment is born.” I was like so that tells me as a product owner how I need to craft product backlog items, right. 

So, product backlog items have to be such that they can be done within a sprint and when they are done, they become an increment and an increment is something that is useful and valuable to a customer. So once I have a product backlog item reached that definition of done, I can show it to a customer and they could actually use it and give me feedback on fit for purpose. So that’s going to tell me a lot about what I need to do in terms of defining what a product backlog item is. 

Now, when I present that to my team in a sprint planning meeting, if we now look at the way the scrum guide describes the scrum team and who developers are, they are everything soup to nuts from marketing, sales and UX and design and if it requires a DBA if it requires a security auditor, if requires compliance if it requires whatever.

Speaker: Miljan Bajic  50:03

Whatever it takes, you have to get the done. 

Speaker: Jim York  50:07

All of that has to happen within sprint. So, what that means is that as a developer on the team, with the rest of my developers along that whole value stream, we have to all be there in the sprint planning meeting so when that item gets presented and said hey, team, can you take this on in this sprint. We need to be able to look around and consider the entire value stream and say can we do everything and is everybody here? So we’re all agreeing.

Speaker: Miljan Bajic  50:36

And committing right 

Speaker: Jim York  50:39

As a real team not what’s considered traditionally as the kind of the core scrum team but as the real team that’s going to get this thing done soup to nuts. Can we say yes, we will get it done and if we’re working in two-week sprints, we’re going to get it done in a fortnight. If we can’t say that then that item is not going to be ready so we’re not going to bring it into the sprint. And a lot of times, people use this ready concept to beat up the product owner, it’s like shame on you, you didn’t make it ready. Well, ready is not just the product owner’s responsibility. I mean ready also includes the requester. Is the requester going to be available for the inevitable questions that are going to rise through the act of building the thing that they’re asking for? If the requester isn’t available, we’re not ready. That’s not on the product owner. That’s on the requester. Are we the right team? Well, if we don’t have the right people with the right skills, knowledge and experience to do that item, shame on us because we saw it coming through the product backlog and if we didn’t act on that, shame on us. Oh, maybe we did act and we made a request but the organization failed to deliver on the request. Well, then shame on the organization. So, it’s a whole team effort to get these items to ready. 

So if we are disciplined in our sprint planning meeting, we are not going to take on anything that we cannot get to done by the end of the sprint. Now, there are unknowns right so that’s just the nature of the environment. There are unknowns but part of what I consider to be a characteristic of ready is that we’ve reduced the amount of unknowns to a reasonable level where we believe that we’ll be able to sort that out by the end of the sprint. We’re never going to completely eliminate the unknowns but we have to through the process of product backlog refine it, eliminate enough of those unknowns so that we can make a responsible decision that we’re going to take that on and get it to done. So, if we can instill the discipline that means we would not take on items that aren’t truly ready and you could conceivably at the extreme not be ready to do anything.

Speaker: Miljan Bajic  52:47

Well, that’s the thing but like we’ve been so conditioned and like the team’s know in the back of their heads. But like in the past, we’ve been so forced and conditioned to take things on when they’re not ready. We’ve been like trying to just implement scrum and not change the mindset of a developer that should be saying something and isn’t when things are like giving the team’s authority to say no and not forcing them to work on things.

Speaker: Jim York  53:17

That’s the backend, right? So, if the developer is not willing to stand up and say hey, and that can be just learned behavior. They’re not willing to step up because that’s the way things have been done around here and that’s what they’ve learned. When we get to the sprint review and this is another item in the latest version of the scrum guide that’s explicit this time around. Again, it’s been true from the beginning in terms of the spirit but this is now explicit. If a product backlog item does not meet the definition of done, it may not be shown at the sprint review. 

So again, at the extreme, if I’m a developer that doesn’t say hey, we can’t do that, we’re going to have a review where it’s going to be obvious, we fell short if we’re disciplined and true to our definition of done. So, on the front end, we have the possibility of not taking anything in if we fail on that and we take things and even though we’re not ready on the back end, we’ll get caught. We get called out on that.

Speaker: Miljan Bajic  54:17

Yeah, what I like about that is even if I inaudible(54:21), a lot of teams are demoing to themselves, nobody’s shown. They’re not really getting any feedback from the customer. But even that it makes it explicit. Don’t show it to yourself. 

Speaker: Jim York  54:34

Don’t show it, it can’t be shown. So, we talk about feedback loops and accelerating learning. So one of the things I’m always questioning coming in as a coach in my own mind is when somebody says hey, we want to be agile. I’m like well, what does that mean to you? And if what it means to them is that we want to get the done. I mean, we want to have a shorter cycle time and truly get the done and so there’s actually a learning loop here for us as coaches and for the customers, the clients that we work with is that when we work with the teams to instill these disciplines when the team doesn’t accept the things into the sprint because they’re not ready, does the organization hear that feedback and then act on it. If they fail to act on it, that’s a signal perhaps that the organization wasn’t really meaning it when they said it was important to get done. 

And likewise, on the back end, if we show up at the Sprint Review and we have nothing to show because we accepted things into the sprint that we couldn’t truly get to done, that’s going to be obvious to everyone and so that’s going to be new information, perhaps. And again, those same individuals who are saying getting the done is important, they’re going to go okay, we were falling short of that so here’s the information on why we’re falling short. That’s part of the retrospective is where are the opportunities to improve? How can we close this gap between what our current state is not being able to get done and what we think could incrementally get us towards an ability to get to done? If the organization fails to act on that, again, that’s feedback. 

Speaker: Miljan Bajic  56:12

Well, that’s the thing and like I think most organizations they don’t take their definition of done or what they define is definition of done too seriously. So, it’s just like as long as you make progress or you know, just keep working on it. Maybe it’s a last question here as we’re running out of time, what is one advice that you will give the product owners when it comes to product ownership?

Speaker: Jim York  56:41

One bit of advice, you will make mistakes. The measure of an effective product owner is your response and your ability to remediate the mistakes that you make. So, you are human, you will make those mistakes.