Oddly Influenced

Brian Marick 0:02
Welcome to Oddly Influenced, a podcast about how people have applied ideas from outside software to software. Episode Six: James Shore and boundary objects.

Brian Marick 0:22
Episode One described the idea of boundary objects, an idea most associated with Susan Lee Star. In this episode, I interviewed James Shore as he describes how he's used the idea in his own work. We drop a lot of names – of people, of books, of articles – in this episode. You can find links in the show notes.

Brian Marick 0:43
I did somewhat better in my interviewing this time, but I still botched things like the refresher on boundary objects. So let me give it now.

Brian Marick 0:52
Boundary objects are things that people use to coordinate cooperative work toward a goal. They typically arise in the process of doing the work and are used to keep doing it productively. Star calls them "the stuff of action."

Brian Marick 1:05
How do they help? Star says that these collaborators belong to different "social worlds." A lot of the reason boundary objects work is that they have a common meaning or interpretation that everyone across social worlds agrees on. But that meaning is nonspecific enough that people can elaborate on it in their own social world. Conflict is avoided when all the social worlds agree not to argue each other's elaborations.

Brian Marick 1:34
In a retrospective paper, Star complains that people often talk as if these various meanings are all there is to boundary objects. In my botched summary, I used the city of Portland Oregon as an example. To a surprising lot of people in the US, Portland, Oregon means an urban hellscape that was literally burnt down by Black Lives Matter and Antifa. Jim lives in Portland, which was not burnt down, and he attaches rather different meaning to his hometown. That doesn't mean Portland is a boundary object. Jim is not collaborating with these people towards any goal.

Brian Marick 2:11
As you'll see, Jim doesn't make this mistake. Still, he's characteristically humble about his understanding of boundary objects. I'm editing most of that hesitation out because I think he's wrong. His description of his idea made me think "I understand boundary objects better," rather than "he's got it wrong."

Brian Marick 2:29
--- musical break ---

Brian Marick 2:31
So we're speaking today to Jim Shore, who I've known for a while. I don't have any recollection of why I know him or where we met. However, back in the day, when I was a consultant, I bought 20 or so copies of the book he wrote (with a person whose name I forget), called /The Art of Agile Development/. And when I went on consulting gigs, I would take those books and give them to people, as I believe that it was the best book explaining XP-ish style Agile development. He has since written a second edition, which he was kind enough to send to me, and I was lazy enough not to have actually read yet. Because I'm not doing Agile consulting anymore. In any case, I have high regard for his opinions about all things Agile, and with that embarrassing introduction, I will have him justify his existence.

James Shore 3:41
Thanks. Thanks, Brian. No pressure, I gotta say. Although you didn't read the second edition of the book, it is actually really good. It's a complete rewrite, ground up. You know, it's been 14 years, I think, since the first edition came out. And the Agile community has learned a lot since then. I took all of that, and I put it all into the book. It's really a how-to guide: How do you do this stuff? We have all these people talking about how to do it poorly. But how do you do it?

James Shore 4:11
Well, anyway, so justify my existence... I don't think I can justify my existence. But I go by James Shore online, and my friends call me Jim. And Brian, I do count you as one of my friends. We've known each other.... Yeah, like you, I can't remember where where we first first met. I think it was just, you know, through the Agile conferences. The community was a lot smaller back then, when when it got started, and in some ways better.

James Shore 4:40
So yeah, that's if there's a justification for my existence, its that I've I've been around for a while. I've seen a lot. I do a lot of hands-on practical work with companies who want to do Agile well, and I do that as a programmer as part of programming teams, and as a consultant for people who need that kind of experience and expertise.

Brian Marick 5:01
Okay, Jim tells me that he has used the idea of boundary objects, which were introduced in episode one of this podcast. And so I invited him on to give us, basically, stories of how he's used the idea of boundary objects in his consulting practice.

James Shore 5:26
When I heard you talk about boundary objects, what I heard you say back in the dawn of time, was that it is a shared representation that multiple people create together. And a shared physicalized representation. That can be in a virtual environment like Miro, the online whiteboarding tool. But at the time, we were talking about, typically, cards on a table.... Cards on a table, which Agile absolutely loves, and everybody's forgotten about. And so that idea of index cards on a table, that was the boundary object. Invite multiple people. Contributing to that boundary object, they were creating a shared understanding. So that's what I understood boundary objects to be.

James Shore 6:11
I use boundary objects, at least the way I understand boundary objects, in a lot of different ways. But they all sort of come back to that core idea of index cards on a table. Or these days, because everybody's remote, I use Miro, there's also Mural, there's other shared whiteboarding tools, but Miro is the one I use. It's got all kinds of stuff in it. But I effectively use it just for the fact that you can make index cards or sticky notes and put them on a big giant shared table.

James Shore 6:43
In Agile we are working with, ideally, cross-functional teams. I use them anytime the team is coming together to create a shared understanding of some sort. And the the biggest one, I think, is what I in the second edition of the book called a Visual Plan, but people used to call Release Plans.

James Shore 7:10
So in a release plan, what we're going to do is brainstorm things that we want to accomplish, and we're going to write those down on index cards. And we're going to put them on the table. And we're going to organize them in a way that tells us what's important and what's not important, and gives us some idea of our sequence.

James Shore 7:31
I learned this from Alistair Coburn. He called it his project planning jam session. And he would take all these cards, all these story cards, and he put them on a table. At one of the two ends of the table was the things we were going to do first. The other end of the table was the things we were going to do last.

James Shore 7:47
I do it a little bit differently now. But let me tell the story of the project planning jam sessions, because I saw the same thing over and over. And then I can talk about how that's changed.

James Shore 7:59
So what I saw in these project planning jam sessions is that I would invite people to brainstorm. There's a brainstorming technique I use called simultaneous brainstorming, which is that rather than having one person be the note taker, everybody writes their ideas down at the same time onto their own deck of cards, one idea per card. Then when they're done with the card, they just toss it in the middle of the table. And the advantage of this is that it moves much more smoothly and quickly than when you're bottlenecked behind one note taker. And so people write down their ideas about what stories should be.

James Shore 8:35
And I'm inviting the whole team to this. Because I'm doing Agile, right? (Don't get me started.) That whole team involves a wide variety of perspectives. We've got programmers in the room, we've got people with domain expertise in the room, we have people who are really thinking about how what's going to make this product special and successful. In the room, we have people who are thinking about what are the things that can go wrong. And what do we need to make sure we don't forget in the room. And these people might have different titles. Or they might all have the same title, they might all be programmers, but they we have all these perspectives in the room. And so we're getting a lot of these different perspectives down on cards. And so these are being tossed out on the table.

James Shore 9:21
And eventually, if we're doing this in person, that brainstorming starts to slow down. And I invite people to organize [the cards] so that the most important ones are at one end of the table, and the least important ones are at the other end of the table. And they have to be in a single row. Whenever there is a conflict – *this* is more important than *that* – one has to come first. How do you decide? Well, just flip a coin if you have to. (Nobody ever flips a coin.)

James Shore 9:53
I think it's worth noting that I no longer do my release planning this way, because I think it puts way too much emphasis on priority and not enough on value. But I did do it this way for a long time. And I think the experience is educational.

James Shore 10:07
And so, this single prioritized list that we're creating, that's the boundary object, as I understand it. And I've done this a bunch of times, because my practice is really hands-on. (I don't do training so much as "hands on, let's do immersion" work. So we work on the actual thing that the companies need to do, often over the course of several months. And this is one of the first things that we do.

James Shore 10:40
What happens invariably, is, people really get into it, and they write a bunch of stories. And some of the stories are, frankly, terrible. They are things like, "we need to install this database" or whatever. And so at that moment, when I start see those pop up, I say to the less technically-inclined, or less programming-inclined folks in the room, "Does this make sense to you?" And they'll say, "Well, yeah, and [I] maybe sort of understand it's important." And I'll say, "Well, how important is it?" They'll say, "I don't know."

James Shore 11:12
So at that point, I say to the more programming-inclined person, "What is the real value of this? What are you trying to get at?" That's our first what I would call "boundary object conversation," that's our first opportunity to get people on the same page.

James Shore 11:31
What I'm trying to do is get every story to be expressed in terms of the business benefits it provides, so that the people who have more of a business focus can make appropriate prioritization decisions. So that becomes a big focus of conversation, because a lot of programmers don't have that experience of thinking in terms of business value.

James Shore 11:52
The other thing that's neat about working in person is that little conversation knots will form. And this is something that does not happen online, although there's tools – one of them is called gather.town – which attempt to reproduce it by giving you a little avatar that moves around on this sort of eight-bit game board. When your avatars are close together, you hear the people who are nearby, and when they're far apart, you can't hear them. So you do have the ability to sort of create discussion rooms, like you can in Zoom, without having somebody to put you in that discussion room kind of permanently. So it's better. And I use that when I have to. But in person, what you get is these really natural conversation knots where people would point at this and say, "What do you think?" and somebody would come over, and they'd have a little conversation about it. Meanwhile, other people are having other little conversations. (There's maybe 8-10 people in the room.) So some of these little conversations are about "What is actually valuable? What do we actually care about? What does value look like? How can I rephrase this thing that I know is technically important in a way that will make sense to people that care about value but not the underlying technology?" And by so doing, increase, bring up my understanding of what's important from a business perspective.

James Shore 13:09
Fairly quickly, the front end of the table, the one that's really important, has a really nice clear list of "we have to do this first, we have to do this first, we have to do this first." And the back end of the table, the least important part, has a fairly clear list of "we don't care about this, we don't care about this, we don't care about this."

James Shore 13:27
And in the middle is this giant, cloudy, ugly mess of cards, because those are the ones that are important, but not important enough to do right now. And so it's not obvious [which of those] comes first. And this is actually what moved me to doing this planning in a different way. Because, frankly, that stuff is usually far enough in the future that we don't need to know what comes first.

James Shore 13:52
But back in the day, I would have people prioritize [the mess in the middle]. And that would lead to some interesting conversations, in fact, and some hard choices, as people would put them in a line. And the end result of this was a good shared understanding of what it is that we're going to do, and what order we're going to do it in. And how is everything that we need to do actually important from a business perspective.

James Shore 14:14
So that's my first example of a boundary object. And I think the important part here is not the structure of the exercise, and not the outcome of exercise – although that's valuable, and we depend on that. What's really important is the creation of this thing, the creation of the plan – which I'll call a boundary object. Because through that shared creation... with a little bit of facilitation, which I have to do in the beginning, but I very quickly teach the people I'm working with how to do on their own... with a little bit of facilitation and "forcing questions" like "No, it has to be in a single order" and "it has to be something that the business representatives on the team, really, truly understand and value." These simple constraints create this amazing shared understanding. And that's my understanding what boundary objects are all about.

Brian Marick 15:06
Okay, as the sort of designated authority on boundary objects, I can put that into the boundary object idea. Take the database person: what you're doing in this process is you're saying to that person, "it is okay for you to care about the database, and it is ok for you to think about how the database fits in to the overall plan." But it is not *required* that anybody else think about it. So when you, programmer-type person, think about the system you're building, you think about it as boxes, and arrows and database shapes. But that's *your* way of thinking. What we're working on here is the way that *everybody* can think about what this is.

James Shore 16:11
One of the points in brainstorming, I think, is to expand and contract. So when you start out, you've got to collect all the ideas, and you have to truly not critique them. (And that's why I want these database ideas to come out.) And then there's this filtering exercise, when you take the ideas and you turn them into something that's actually useful.

James Shore 16:31
And so it's not so much that I don't want the programmer thinking about databases – I do want him or her thinking about databases. What I want them to do, though, is then figure out, "well, what does that really mean from a value perspective?" And I think if that "we need a database" card was never created, or the business equivalent of it was never created, we would be missing something. There would be something important that was lost. So it's very much we want that – and then we want to refine it.

Brian Marick 17:05
Okay, next.

James Shore 17:08
So, so that's the project planning jam session, which I called release planning in the first edition of the book. Now I do something called Visual Planning, which is similar, but is more focused on "what's value?" So instead of doing this exercise to break everything down into bite sized stories, and then make this giant thing... Now it's more focused on "what are the things that we're going to deliver that have value?" I used to call [those] "minimum marketable features." Now I call them "valuable increments". That's something you can actually ship in some way that brings real value to the company. (And there's some nuance to it that I won't get into now.)

James Shore 17:44
That gets organized into [more of] a picture. A good example of this sort of picture is Jeff Patton's Story Mapping. [Patton's justification for story mapping:] He talks about how people come up to this shared understanding, and then they'll chop it up into little stories. And it's sort of like: you end up with leaves all over the ground, and you've lost track of what the original tree looked like. And I think that's a very valid criticism.

James Shore 18:07
That's one of the ways reasons I've shifted away from the project planning jam session approach. [It] tells you priority, but you lose the context of "where did all these things come from? and how do they fit together?"

James Shore 18:18
But you can take the same basic idea and even the same basic structure. And rather than making a single ordered list, you can make a picture. One way to doing that is Jeff Patton Story Mapping, as I mentioned. Another way of doing it is Gojko Adzik's Impact Mapping, which is sort of a mind map approach to this.

James Shore 18:35
My preferred approach is what I call Cluster Mapping, which is just "let's take the ideas and put the ones that seem related close to each other and just make a picture that looks like whatever we want." Again, creating that picture is creating shared understanding. But now rather than shared understanding of what needs to be done and when (which I think is a less Agile way of thinking about it), now, it's a shared understanding of what's important to us. And once we have that shared understanding of what's important, figuring out what to do next is actually not that hard. If there's any question, the onsite customers can make that decision usually just at the drop of a hat.

Brian Marick 19:23
Okay. From the perspective of boundary objects, I can't think of anything profound to say about that, except: "Good job." It sounds like an improvement.

James Shore 19:37
It is an improvement, I think, which is why that's what I'm doing differently in the new edition.

James Shore 19:45
Another type of boundary object is something I lifted from Diana Larson. It's called Purpose. And Purpose consists of three pieces. It's Vision, Mission, and... Diana calls it "mission test," but I call it Indicators. [Purpose is] a short document that says, "This is how we imagine the world is gonna be different as a result of our work together. This is what we're working on right now and expect to accomplish in the next, oh, three to six months. And these are the indicators we're going to use to know if we're on the right track." And unlike the other boundary objects that I create, which are mostly cards on a board, this one is just a written document. But I think it's still serves that same purpose of creating a shared understanding.

James Shore 20:44
Now whether or not it qualifies as a boundary object, I don't know. But let me read an example to you of what what it looks like, to make it a little more concrete.

James Shore 20:56
"Team Sasquatch helps teams collaborate over long distances. Our customers achieve the same high quality interaction that occurs when teams share an in-person workspace. With normal screen sharing tools, one person becomes the bottleneck for all discussion. With our tools, everyone can participate. It makes long distance collaboration effective and enjoyable, allowing us to earn revenue through subscription fees from loyal customers."

James Shore 21:17
So that's a discussion of sort of what's the long term value. And then the Mission.

James Shore 21:22
"Our first mission is to create buzz. Our goal is not to generate substantial revenue at this time, but to prove viability and create excitement about our unique perspective on remote collaboration. We will do so by creating a tool for simultaneous collaboration that replicates the experience of working with index cards at a table. It isn't a product management tool, a tracking tool, or a retrospective tool. Instead, it's a freeform sandbox that can fulfill any of these purposes. It's focused on collaboration and simplicity. It exudes quality. It doesn't provide chat or video conferencing capabilities, but instead remains focused on the core functionality of a sandbox for simultaneous collaboration."

James Shore 21:57
So that's now this is what we're going to do right now. And I do want to say that this is based on a real product that I created way back in the day. that I remember. So boy, I and my business partner, we were about 10 years ahead of our time, or maybe 15 years ahead of our time, and we probably should have just stuck with it.

James Shore 22:19
And then there's several indicators. I'll just share one of them.

James Shore 22:22
"We will share our initial markups and plans with at least 20 potential customers. We will be successful if at least 70% of them say it solves collaboration problems they are facing. This will indicate whether our approach is viable."

James Shore 22:33
And then it goes on to talk about more in-depth indicators. So this is just a document. But it's the kind of thing I like to post prominently in my team rooms. Or if I have a virtual team room, post prominently on our planning board.

James Shore 22:50
The way it's created... if it was just created by a business person somewhere in the organization, then handed to the team, I don't think it would be a boundary object. What makes this a boundary object is that it's created through collaboration.

James Shore 23:09
I have exercises that I go through with people when we create this. I try to get a cross section of the team, but a lot of emphasis on people with business perspective, including the team sponsor, and we have a conversation aboutwhat is it that's really important. People will brainstorm. Again, we'll do some simultaneous brainstorming. And we'll write down stickies with "what are the real important elements? What are the things that we're not trying to accomplish?" I think it's just as important in this sort of thing to know what we're not doing, as well as what we are doing. And you'll have noticed that in the mission. It said we're doing this and we're not doing these things.

James Shore 23:48
Because the point of this Purpose document ultimately is to provide the North Star for the team, which in a really high functioning agile team is making its own decisions about what to deliver. So this North Star is how the executives in the organization steer the team. Or allow the team to steer themselves, I think would be more accurate. [It] provides guidelines and guide rails for the team.

James Shore 24:14
So we try to get the sponsors in the room with team members, [plus] typically on-site customers, [and] often some other team members who are interested as well. They create this draft together. Then the draft goes to the team. And there's this sort of in depth conversation about "what does this mean? Is it achievable? What do we think about it?" And the team takes the draft and creates the final draft that actually becomes the real Purpose for the organization.

James Shore 24:51
I think this is an interesting example because this is a boundary object. It's not cards, but it's still created through that collaborative mechanism.

Brian Marick 25:03
I hooked on to your phrase "exudes quality." Because I can see both programmers and testers perking up at that in a particular way. If I were a tester "exudes quality" tells me my job is going to be more important than usual on this project. And if I were an exploratory testing kind of person, [it] would direct the kind of testing I looked at. Because that's a property you want users to appreciate, even if not consciously, you would direct your testing effort toward that end.

Brian Marick 26:03
And looking at it as a programmer, what I might be thinking is "this allows me to have my normal desired level of enthusiasm for internal quality, justifying it to myself by saying, well, the hiddenness nevertheless will bubble up and kind of exude out to the whole world." So this allows me to be more enthusiastic about my job,

Brian Marick 26:40
Star and Griesemer (the original boundary object people) talk about "meaning." I'm wondering if, maybe more than "meaning", the word "enthusiasm" would be useful. You are collaborating toward an end. A successful boundary object allows people to follow their own enthusiasms and think of them as contributing to the whole.

Brian Marick 27:13
In the example of the Berkeley Museum, they had to go to some lengths to get the amateur collectors to stay enthusiastic about collecting pelts and sending them to the museum. And there was a delicate sort of dance between the scientists who wanted lots of data, and the collectors who basically liked going out in the wilderness and trying to trick animals into traps.

Brian Marick 27:46
Does that resonate at all with you as part of what you're doing?

James Shore 27:51
Yeah, I would say so. I think it's very clear in the purpose document, because that is meant to be something to inspire the team and to provide direction.

James Shore 28:01
You talked about programmers caring about internal quality. Of course, I believe that the higher the internal quality, the better the results, the faster your team goes. So I want that to be high at all times. But I could see, for example, a user experience designer on a team saying, "oh, yeah, I'm really excited about being part of this because I want to create something amazing."

James Shore 28:20
And of course, inevitably... well, we've got limited resources, because nobody has unlimited resources. And then there will be trade-off decisions to be made. When that happens, this document will guide those trade-off decisions. "Well, we are aiming to exude quality. So let's maybe trade off on doing less but higher quality, higher external visible quality."

James Shore 28:44
[Enthusiams also matters] for the previous example of the visual plans, and even the linear release plans from the product planning jam session. I wouldn't say that [they] lead to the same level of excitement, enthusiasm, that a really well crafted Purpose statement does. But what it does do is create this "Yeah, we know what's going to happen." And an excitement around "we're ready to get to it", like "we do have the shared understanding of what things mean, and how it works together."

James Shore 29:21
The third type of boundary object I wanted to mention is sequence diagrams...

Brian Marick 29:26
Before you do that. [Dramatically:] I really miss Agile. I sure miss the time when agile was about the sort of things you are doing. And I want to say I envy you.

James Shore 29:40
It *is* kind of heart rending, because Agile was this beautiful idea that was about making the world a better place for people who are doing meaningful work – in the late 90s and the early 2000s. And it got co-opted and right around, I'd say, 2007 2006 2005, that started to disappear. And now it's almost gone.

James Shore 30:10
But the thing is... I read sites like Hacker News, which are filled with people who think far too highly of themselves. And actually, the conversation is changing even on those sites: from "Agile is this disaster" and conflating [it] with Scrum, to people actually beginning to understand that agile isn't just Scrum. That there is more to it than that. So I have hope, but I'm an inherently optimistic person. And the reason I'm an independent consultant is because I get to choose my clients. And so I don't work for the ones that don't want to do a good job.

Brian Marick 30:46
Well, you have saved this from just being a pair of old guys bemoaning the good old days. But you said your third example.

James Shore 30:57
Right. So my third example is sequence diagrams. And I think you were talking about the excitement, that the energizing aspect of a good boundary object, and I think that is true. I think there's something [like that] even for sequence diagrams (which I'll explain in a moment).

James Shore 31:15
I think there's something exciting about a meeting of the minds. Whenever I am part of a true meeting of the minds, I get this sort of frisson in my in my chest like "Oh, yeah, this is good." Maybe that's because I'm a consultant and a coach, and I'm there to help people achieve that meeting of the minds. And it just makes me feel so good to see it happen.

James Shore 31:39
So I don't know if other people experienced that. But when we create a good boundary object, and everybody's like, "Oh, yeah, yeah, this means *that*", it's really neat. Even when it's something as simple as, "what are we going to do this week?"

James Shore 31:56
But I think the third kind of boundary object I want to mention [is] because it's different than the other two. It's the sequence diagram. This boundary object is still a co-creation. But rather than being a meeting of the minds of a bunch of different people with a bunch of different perspectives, I think this is what Jessica Kerr calls a "symmathesy". Your listeners may not realize I had a short-run series called "The Art of Agile Development book club" where we went through the book. And I had guests on. We talked about different topics that were raised in the book and used that for conversations. And Jessica was one of them. We were talking about DevOps.

James Shore 32:39
You had the opportunity to be [a guest], Brian, but you turned me down.

Brian Marick 32:44
Oh. Okay.... Because... I'm sure because I said, "I have nothing left to say about Agile."

James Shore 32:51
That is exactly what you told me.

James Shore 32:53
So. Jessica talks about the symmathesy, the idea that the people and the computer are coming together to create a joint understanding. That the people teach the computer and the computer teaches us. Or the computing system teaches us.

James Shore 33:13
She's really thinking in terms of operating large systems where you've got multiple microservices, and you've got your logs and your monitoring and your alerting and your observability. The way you are setting those systems up [is] so that you can first create the system and then learn from how the system behaves in practice, because these really large complex systems are effectively impossible to fully know. As can be observed by anytime a big service like Amazon goes down: they always say, "well, unexpected interaction between this thing and this thing."

James Shore 33:51
These systems are so complex that you can never predict all of them, but you can learn from the actual behavior of the system. And I think that is also conducive to creating boundary objects. Now we've got a shared understanding from both what the computer is teaching us and from what we know. And sequence diagrams are a technique that I've used.

James Shore 34:13
For those of your listeners who don't understand what a sequence diagram is, a sequence diagram is something that you do when you're examining a program and you're trying to understand how it works. What you do is you start out with a piece of the program called a "class." And you'll make a vertical line with the name of the class at the top and a vertical line down. The class is going to be asked to do something by something else in the program. that's called a "method call." You write an arrow pointing to the line of class with a method call name on it.

James Shore 34:45
Then you look at that method, which is going to be lines of code, maybe 10, maybe 1000, maybe 100. You're gonna read through it and you're gonna see what method calls *this* [method] is making to other classes. When you find one, you're going to draw another vertical line to the right, and you're gonna draw a horizontal arrow with the name of that method call.

James Shore 35:03
And then you're going to recursively do it again. So you're going to look at that next class's method, read through its lines of code. And do that until you've traced out how the program works throughout the entire chain of all the method calls, and how they all fit together.

James Shore 35:20
This isn't something you do often. But it's something that you do when you have a particularly challenging design problem and you don't understand how the program really works, or you don't understand how to make it better. And I find when things are really complicated and tangled up, creating this "sequence diagram" is really useful to create an understanding. I can do it myself, but I'll often do it with my pair partner, or if I'm doing mob programming or ensemble programming (which is multiple people working together at the same time), we'll do it all together.

James Shore 35:57
Now, there are electronic tools that will take your software, and you'll tell it do a sequence diagram, and it will automatically generate that sequence diagram for you. And the output of those tools to me is worthless. Because the value of the sequence diagram, and what makes it a boundary object, is that by "tracing through" you're really studying and you're talking with your partner or partners. "What does this mean? What do we think about this?" You're creating the shared understanding of how it works, such that the actual diagram at the end is almost irrelevant.

James Shore 36:33
It's not entirely irrelevant. It's actually really useful to look at it. I'll typically do it on a whiteboard, because I'm old school that way. And I like to take pictures of it and show it to people who didn't participate and say, "Look how pretty this is." And "isn't this amazing." I have that same excitement you were talking about earlier, Brian. I love the experience of creating understanding where there was none before. But it really comes out of the creating this diagram in collaboration with the other people on the team. But also in collaboration with a computer, which was why I chose this as the third example: because it's so different.

Brian Marick 37:10
What you're doing there is you're taking a hard problem, which is understanding how things happen. And you're using a tool to create an understanding, but the understanding is in your head. It's not in the sequence diagram, right? I don't think I've ever read a sequence diagram that really made me feel that sense of understanding.

Brian Marick 37:34
Something I learned from Mike Feathers way back when is that what you should do when you're explaining [a diagram] to someone is recreate it instead of plopping it in front of them and then talking about it.

Brian Marick 37:56
Okay, that's probably a good place to stop. Do you have any last words for our listeners?

James Shore 38:05
To me, the essence of the boundary object is the co-creation of a shared understanding. I have found immense value from that co-creation.

James Shore 38:14
If you have a situation where one person creates a model, and then shares it out, that's not valuable. If you have a situation where one person defines a word and imposes that on others, that's not valuable.

James Shore 38:30
What's valuable is the conversation mediated by a co-created model. To me, that's what "boundary objects" is all about. And if those aren't boundary objects, I don't care, it's still worth doing.

Brian Marick 38:42
Exactly! My opinion about all of the stuff that I've been doing my entire career has never been either "Is this theory true?" or even "do I really understand this theory?" It's "does this give me useful ideas that I can try out?" And so to that extent, clearly, with boundary objects and you, it's worked perfectly. Because you got value. That's all we care about.

James Shore 39:15
I've got value. I've got value and the people I work with and introduce it to get a lot of value out of it. There's so much value in coming together to create shared understanding, because that is so hard.

Brian Marick 39:27
Okay, well, thank you. And I will now press the stop button.

Transcribed by https://otter.ai