Lindsay Velecina: 0:03

Welcome to the scrum.org community podcast, a podcast from the home of Scrum. In this podcast we feature professional scrum trainers and other scrum practitioners sharing their stories and experiences to help learn from the experience of others. We hope you enjoyed this episode.

Patricia Kong: 0:20

Hello, everyone. Welcome to the scrum.org community Podcast. I'm Patricia Kang. I'll be hosting today's podcast and with me, I have professional scrum trainer, John Riley. Hello, John. Hi, Patricia. As John, the story that we want to share today in the podcast was out of our work. And our conversations that I feel have been a little bit quiet these days these days in the Agile industry. And it was about software development, software delivery. So we were talking about delivery development, what does it mean craftsmanship, all those topics. And one of the one of the stories that you shared with me your your recent experiences that got you onto the pod was about a non software based experience in Scrum. So today, we're gonna go through that, and I am really excited that you're going to share that with us. Well,

John Riley: 1:22

thanks. So yes, it's actually a very exciting effort. So thank you for allowing me to share this. Cool.

Patricia Kong: 1:28

So one of the things I must say that grabbed me quickly. So we're talking about something that's going on and on software, and we'll go through the details. But one of the things that I thought was really, really interesting was one these people were interested knew about Scrum. And I think, you know, you can go into why that that really spoke to them and their experience. But the goals and the missions that you pointed out, really spoke to me. So the mission that you said this company had, and this was in construction materials. So really different than than software delivery in terms of just the the materials, but their mission was to beat mother nature. What does that mean? Yeah,

John Riley: 2:08

actually, that was our product owner's vision. So the vision was to beat mother nature. And so I was intrigued immediately when he was telling me that. And basically, what he was really concentrating on was 3d printed houses. So the problem was that 3d printed houses that, you know, you can basically put them up very quickly and very cheaply compared to anything that is manufactured. And the problem, though, is that they've still requires a solid foundation, some of these foundations can crack or erode very quickly. And so that was what he was telling me as his story. And what I got to do is I got to tell him about the scrum framework, and how we can create value very quickly through iterative development. And I was talking about the software context of it. And he said, Well, can this be used in non software? And my answer was, well, yes, it's actually designed to do that as well. But I have never actually tried it. So that was the motivation for both lists to start to go to new business together. Oh,

Patricia Kong: 3:21

double chances. Here's like a few notes. Probably you've never tried this. And we'll see what happens. So this was during the pandemic, right? This was that complexity? Yes,

John Riley: 3:33

yes. So we actually got started and got funding and everything rolling, kind of in the middle of the pandemic. So that was kind of another motivator for us and that no one else was working. And, you know, everyone was staying home. So yeah, that was another motivator.

Patricia Kong: 3:49

did you guys meet in person or?

John Riley: 3:51

Yeah, we actually so yeah, so we met in person. So you know, we were all messed up and everything. But part of the advantage was that we were our main site was construction site in the middle of downtown Columbus. And so, you know, we still had to practice our social distancing, and all that kind of stuff. But it was a lot easier since we were outside.

Patricia Kong: 4:13

Yeah, Columbus, Ohio, because you guys have funny land in Ohio theory.

John Riley: 4:17

Yes. So yeah. Columbus, Central Ohio is very much a test market for a lot of things. And so, yeah, our land is quite unique in the United States. And so it was a great test ground.

Patricia Kong: 4:29

Right. Alright. So beat mother nature. That was the mission. They're looking to they have funding they're going in and there was a goal that you talked about, which was around building materials building revolutionary material. What was that about? Yeah, so

John Riley: 4:47

the actual the actual when turned up to be the product goal was to come up with a revolutionary building material. So that was the actual practical and nonspecific, and very, very much speaking to all of us, but being very vague at the same time. So it was very interesting.

Patricia Kong: 5:09

So that makes sense to them. So now you're taught like when you're just like, here's this thing, this scrum framework, and you know, we have a goal, what do you want to do? And it's not going to be, we're not sure if we're gonna be able to hit it. It's not, you know, is this, I would imagine the type of people who are working in construction, and you're talking about some very scientific things, they want things to be precise and exact, you know, did they? Did they get the notion of all this theory you're spewing?

John Riley: 5:36

Yeah. Well, you know, that's kind of interesting that you bring that up, because our team, the developers were, you know, mostly scientists and engineers, so material scientists, chemical and civil engineers, and, you know, most of their day to day lives, were around setting up a safe environment and being able to, you know, have all the parameters controlled as much as possible. So it was a different way of working for everybody, we were really going to, you know, break new ground and always here.

Patricia Kong: 6:17

So you're so you guys are kicking off the project or the product. And now you're getting into sprint one. So you have the team, what was what was your What was your role? Or accountability? If you were on the team? Yeah.

John Riley: 6:34

So yes, I was the scrum master on this team. So immediately, the product owner said, you know, I want you to be our scrum master. And so I said, Okay, all

Patricia Kong: 6:45

right. So you were the Scrum Master, you have this, this product goal? What about the stakeholders? Who are those? Yeah,

John Riley: 6:54

stakeholders are mostly building contractors. And there are also some for people, and yes, that is an actual role. For persons. They were, you know, mostly involved with project management, if you want to parallel that's to somewhere in the, you know, somewhere in a common industry, but But yeah, so mostly building contractors and forming some finance people.

Patricia Kong: 7:24

Was there any tension? Because when I think about those different personalities? Yeah,

John Riley: 7:31

there's tension right from the start. So we all came from different environments, different walks of life. And so yeah, I mean, I can't, I can't describe the tension that we all had going into that first sprint. All

Patricia Kong: 7:47

right, let's talk about the first sprint. What did that look like? What was the sprint goal? Yeah. So

John Riley: 7:52

very interesting. So the first sprint goal was refined the product backlog. So they all decided on this during our first sprint planning, and me as the scrum master, with all my years of training and coaching and everything, I immediately just said, people, you can't do that. You have to come up with something at the end of this sprint, and they chose a two week sprint. So I'm thinking there's, you got to have something. It's got to be tangible and so usable. And so I was getting a lot of pushback. And so I just reluctantly agreed. I said, Okay, fine. This is going to be our first sprint goal. So first sprint goal, if we find a product backlog, we ended up happening was, it actually turned out to be something that was that was very useful in the end, because what we ended up doing was we ended up embracing the need to prototype. So as we started to, quote, refine all of these product backlog items, we were able to kind of set up some ground rules about how we were going to prototype and what it meant to actually refine the product backlog. And so we kind of did that in parallel, which was actually kind of I mean, revolutionary in itself, in that prototyping was shown to be something that you could actually make something transparent. And show Hey, we're on the right track, or we're not on the right track

Patricia Kong: 9:31

is a piece of material, right? So it's kind of Yeah, yeah,

John Riley: 9:35

it was something right. It was something that's like, oh, yeah, I can do that in an hour. Okay, prove it. Well, it actually took, you know, an hour and 15 minutes, but whatever, you got some data on it. And then I was able to say as a scrum master. Well, this is kind of how we're measuring things as outcomes rather than outputs. And how was that for you? Right? Oh, well, okay, this wasn't that bad. So we were able to do that for Sprint one. Oh,

Patricia Kong: 10:00

So what did this I mean? It feels like, you know, they're like, I'll accept this challenge. But how was how would this have typically looked if they were doing it in the way that they do it. And they're normalized free Scrum. Okay,

John Riley: 10:15

so, so really, we had to know how to work with each other, because chemical and civil engineers, even as the developers on the team, they had a certain way of working and looking at how they were going to have their standards upheld, for example. And so they actually had to collaborate together to know how to work towards something that was usable and useful by the end. So really, that was that was one of the things that we had to understand up front. And there was also this whole idea of what was a safe space. So we all had our own, our own idea of what a safe space was, and that was very much needed for the engineers. And so that's when we actually decided to have a physical barrier for the developers to make sure that we had an idea of this is where we need to be able to concentrate on getting something done. Because a lot of the times the four people were really, you know, kind of messing around with the the developer saying it doesn't work doesn't not work, what's going on. And so we needed to make sure that we had the, the safe space space defined. So

Patricia Kong: 11:46

then I'm imagining if you have to have a safe space, that previous Lee, if they weren't using Scrum, or whatever environment you had set up for them, it does sound like you're saying, you know, they would just do something and throw it over the wall. And let's see if people accept it. That's kind of what it sounded like, and then probably deal with the cost.

John Riley: 12:08

Yeah, that that's a that's a good way to put it. But there was also that sense of urgency, right? Because they, they they set the two week sprint for that first sprint. And so they actually had to know that they had to do something within two weeks, but they had to say to do it.

Patricia Kong: 12:27

Alright, so at the end of the two weeks, what was what did you get how to feel? Did you? Did they under I mean, I'm trying to think about like a piece of material as a prototype did, what was what would the definition of Done look like? What are all those things? Yes. So

John Riley: 12:43

that was part of where we said, Yeah, we did get something but everyone started calling it the blob, because it was supposed to be salad, this salad building material, construction material. And when someone held their hands, it was almost like a piece of putty because it would just kind of ooze into something. And so they decided, well, you know, two weeks isn't enough, we're going to make this three weeks. So they decided to make it a three week sprint. But, you know, besides the importance of prototyping, it was really a hard lesson that they needed a clear definition of done because no one either on the team or the stakeholders, were really happy with the quality that came out of that for a sprint. You know, the other outcome with this, this first sprint is that there were several people on this whole effort that were ready to leave and just quit. And really, it was our product owner that stepped forward and said, and he pulled everything, everyone together as a team. I mean, he looked like a head coach, that was just, you know, ready to get all this troops ready to go out to the field. So that's really was the outcome of the first sprint, it wasn't that great. But in the end, it turned out to be a very good foundational sprint.

Patricia Kong: 14:04

I mean, that's, that's what we want promote a good first sprint, isn't it? So I can imagine this is the middle of a pandemic, you guys are in some open space construction site, you're trying to build some blob. You're dealing with a lot of different personalities. Sometimes it sounds like people are poking poking the bear a little bit. What other types of impediments Did you observe and how did you how did you how did you wrestle with them? Yeah,

John Riley: 14:31

that's that's a great question. Actually. I remember one impediment that actually wasn't an impediment that I call the shouting incident where I just arrived rafter daily scrum, and I see them just shouting at each other in the middle of this construction site, the engineers in the building contractors and so I get in the middle and I say hey, do you people know that you are shouting at each other? And they looked at me and one of them said he worked We're just working here. And so I was thinking, Okay, well, I'll get out of the way then. So it's kind of a hard lesson for me as a scrum master to know, hey, they're just collaborating, you have to, you know, be approached when you're dealing with impediments, it really has to be to the developers to be able to, you know, identify what is an impediment and what is not. And I actually remember this one time, the opposite side, when one of the engineers kind of put his hands in the air once and said, Oh, we don't have the right materials to make this, this is an impediment. I can't continue. And you're basically taking this giving up stance. And I said, Well, you know, that kind of took a little bit of active scrum mastering for me saying, Look, you have to learn how to circumvent this impediment or think of a workaround, you can't just give up. That that's not that's not part of what Scrum is, you have a commitment to this goal. And so let's talk about it's a DAG, the gather one run and make sure that we were upholding empiricism and being able to make everything transparent. And so we actually did get around that and kind of set that precedent saying, you have to learn how to go get get around your impediments.

Patricia Kong: 16:22

That's, that's really a lesson in self management for you and them. But what that made me think about what so you have this one person, this developer, right, because on on on a development on a development team, when we're working in software, we're saying, hey, cross functionality, or everybody needs to know something, and we can teach each other. And that's not the case here, right? There's people were really specialized, and need to be specialized and certified in certain areas that you can't just say, Oh, I'll teach you some of this. And that really makes me think about how we talked about cross functionality in a team. Yes,

John Riley: 17:03

yes.

Patricia Kong: 17:04

So that you're talking about the daily scrum. So they're, they're screaming, collaborating. And I remember you telling me about how they would basically their what they would always inspect and move around physically was this blob. And you said they when they were doing like, even just talking about the product backlog, they will just mess around with this, this piece of material. What that looks like,

John Riley: 17:30

yeah, so we end up scrapping the blob, but it was actually a lesson in the in the, the increment, as it were in Scrum. So that was part of where we had to kind of had to have that as a model. So the what the developers decided to do was to kind of work individually as you know, with their own disciplines, but then be able to come up with something that could be considered and then additive to as the increment to the final product. So basically, what it looked like is that we had the the increment as it is, as it existed outside, and we had to double why's that we were using one was for the developers. And the other was for the stakeholders. We we'd coined the developers, the developers double wide the lab, and then the stakeholders double wide was the war room. And so the lab was really set up to be that a laboratory. And so that was really their safe space where they could be able to work on some stuff in the interim, kind of like we would use branches and code and in, you know, in software development environments. So that was what it looked like. And then we had a lot of a lot of testing that was done. And the way that we tested things was we actually without going into too much detail we we surrounded our testing around ISO standards. So this was actually another part of the product effort that became kind of revolutionary in that it became we used some already industry recognized standards as our testing platform. So that the the ISO standard that we happen to be working on for a given sprint, for example, is how we would know that we had actually met our definition of Done. So that's kind of how we we really tested things was through ISO standards.

Patricia Kong: 19:41

And ISO is International Organization for standards. Exactly. Yeah. Yeah. And that was that was your element for your DOJ. So that's super interesting to just set it to that level.

John Riley: 19:55

Yeah, I mean, the thing is, is that you know, there are some accrediting body Is with ISO. So we weren't able to, you know, get complete ISO certification. But the thing is, is that with the way that we had our iteration set up that we could make things ISO ready, so that we because we had enough cross functionality on the team and outside the team, being the stakeholders to know that if something was a would meet the standard or would not meet the standard.

Patricia Kong: 20:26

Okay, so non software building construction, we've talked about DOD, you told us about the team. So you had events you talked about? Well, you talk about one event, but was there any parts of Scrum that the team just said, Oh, that's not for us? Or can we change this? Because we're not a software development team?

John Riley: 20:45

Well, I mean, one part of Scrum, the whole part of Scrum was that and something that I tried to let everyone know is that Scrum is a framework, it is just a simple framework, and especially building contractors wanted to treat it as a contract. And here, you know, you have to have a 50. Now, yes, it does say that I'm not going to argue with you. But there's reasons why it is like that. It's just about reducing risk, and making things and eliminating waste and making things transparent. So that then can be inspected, and you can adapt. So, you know, there was there was that part of it that a lot of people, it took a lot of people, some time and energy to get over that. Most of the other stuff about the scrum framework that people didn't like, were mostly just terms. You know, for example, the developers did not want to be called the developers, they want to be called engineers. I said, fine. Your engineers, you know, some people. Yeah, we actually had a session on that. And you know, what, okay, what are we going to call ourselves? You know, and, you know, there are several things that we voted on, we handled that voting session on that. So there was that. And then there was actually one part of, you know, when I was introducing the values, and there was some, some contention, I'll just say about some of the values. And so we, you know, some someone said, I'm, I can't remember who at this point, but they said, Well, what if we use functionality or discipline as a value? And like, that's fine. I mean, all you're really trying to do is you're just trying to establish the trust bond, and going back to it and saying, you know, is this upholding our, our values as a team? So that was really it, it was, so it was mostly, you know, the contract part? And then some of the terms.

Patricia Kong: 22:38

I could see some people getting really deep into Oh, they didn't like the scrum values. But that I mean, you, you described it well, in terms of terms, and what do we do for us as a team and what works for them? So what were some of the things we saw the differences, we've talked about some of the things that they thought were different, where they're just for you from coming from a software background, and obviously, as a scrum trainer? And we could say, even expert, what were some of the parallels that you sound like? What was resounding for you? Because this was this was a risk on your side as well as the client side?

John Riley: 23:14

No, yeah, absolutely. So yeah, there were actually a lot of similarities that I was seeing between this environment that we created here and a software environment, one of the things that became apparent was this need for a test first mindset. So basically, trying to think of the test first and thinking about quality, and always thinking about quality, and quality is always on your mind. And that was with these ISO standards, that that was a big turning point, definitely, in this effort, was because we always had to look at those standards. You know, some of the some of the other things that I found interesting was I had never worked with civil engineers before, but they were very familiar with being able to have an iterative development cycle and also be able to collaborate and be, you know, be be have a cross functionality, multidisciplinary, you know, teams, right. And so the chemical engineers had a problem of kind of one, I'll just say, not a problem, but more of a learning curve with that, but they were really into the risk management and compliance. So they were always thinking about, well, how is this going to affect it when a person does this, that or the other thing, and so they brought that into the team space? You know, I also heard some, you know, some of the practices were kind of, I'll just say they're test driven development, like, you know, I remember that they brought up something called pilot plant testing, and that was usually something that was brought up in This was just another kind of a small scale kind of testing environment that would be used before it went to the larger scale, which, you know, and that was that was interesting, because we were able to know earlier what the ISO standard was that we were going to do before the P by the product backlog item actually got, you know, was actually developed or actually, you know, more was known as, you know, as more information came in. And the thing is, you know, we did have bug fixing, too, it was just a lot more expensive, because they needed to do some data analysis and modeling techniques that I had never heard of before. But you know, this just upheld the whole quality standard that we were able to come come up with, as, as the Sprint's went on, in that we don't want to do any kind of bug fixing. Yeah, so

Patricia Kong: 25:59

Well, I want to pull on that a little bit. Because this, this made me think of the conversations that I was having. And actually one of our our fellow PSU has been Thorpe had posted something up around this and the notion of trade offs in engineering and how, you know, we're talking about, let's say, in software, there's a bug, it could, it could affect, and his, in his example, his story was about how he had he had a bug in his code and made like a helicopter catch on fire. And so this is really impressionable in his mind, of what quality means and testing. And we're talking about, you know, an industry of what we see, with all the technology, pacemakers, and all that stuff. We're talking about materials here, and I'm, I'm sure with all these things that you're talking about where, you know, it's kinda like the test, first mindset, that trade off. When a lot of people hear and think about Scrum and Agile, they're just like, do whatever is good enough. There are not the wall. We're not sure we'll figure it out later. I was there. You know, would there any parallels there? Where's that struggle? Where Yes, we can flex a little bit on this. But no, you know, we're trying to get things right. And we're spending a lot of money to do it. So I'm wondering if they're, you know, when you look at a software team, whereas when you're looking at this team, did you see any, any differences or similarities there?

John Riley: 27:16

Yes, definitely similarities. So I would, I would say that, you know, we were constantly reminded, along with quality, that this was a foundational material, meaning that your whole building was going to be set upon this material. So everyone who was in this building, no matter how tall it was going to be, was going to be at risk if the quality was to suffer. That said, what do we know what was good enough? And the way we knew it is, is if all of us who had some kind of experience with a certain aspect of the SOC, that we have happened to be working on, was able to say, Yes, this is ready to be certified. And we didn't know because it takes a lot of time to certify something from another certification body to to be able to be ready. But that's how we knew that using all of our knowledge and experience that this is going to be ready with all the the tests that we happen to set up. During our experiments. I mean, one time we had a UN, which I'd never seen it before, a earthquake table to test it for earthquakes. And so I had never seen this device before. And so that was one of the things where we said, okay, yeah, it's standing up from earthquake, as far as we know, it's ready. So it can be the standard can be set for for when we come to that point.

Patricia Kong: 28:51

Mm hmm. It sounds like you're really impressed by this, this engagement are there, you know, has has this experience, how has this experience affected you? As a scrum master as a developer as a practitioner?

John Riley: 29:09

Well, it's actually given me it first. It's given me and an appreciation for all of the disciplines that were on this effort. I mean, I have a huge, huge appreciation for the work that building contractors, engineers, and anyone that's involved with a building a building has, they actually have very little when they start and so they actually have to do a lot of things to make it come together. But, you know, one thing that has really strengthened my love for software is just this adherence to quality and being able to deliver a usable, useful quality increment at the end of the sprint is the most important thing. And, you know, another thing is the collaboration, I mean, usually have good ideas, but they're most likely not as good as all of us together as a group, you get people who are very familiar with their own way of working. And you can come up with something that is actually more awesome than anyone could ever think of. But yeah, I think the most important thing, or one of the most important things is that, you know, the terms are different. And all of our being a developer on a software project, and a developer or engineer on this effort. The terms are different. I mean, they have different practices, different terminology. But when it came down to it, setting up a test was very important. Having collaboration, very important. Being able to do things iteratively was important. And also some of the things that they decided they were going to automate, you know, the need for automation became very important as well, to make sure that we were going to be able to get something incremental at the end of the sprint. So those are both fundamental in both domains. So you know, I had a very, very strong appreciation for all that.

Patricia Kong: 31:28

Lots of parallels. Then, before, before we wrap up, John, I'm just wondering, so I'm thinking about the listeners? And what would your advice be to someone who is trying to help you know, a group or a team or someone who's thinking about using something like Scrum or agile, but they're not in the software space? What would your advice be to someone who's either, you know, tickling, tickled with the idea or trying to tickle someone with that idea?

John Riley: 32:04

I would say, to be able to understand what the three principles of empiricism, self managing teams, and professionalism actually mean. And you really don't have to know a lot as a group, we didn't know anything. Just bring your best to the effort. And as long as you uphold empiricism, self managing teams, and professionalism. You should do fine.

Patricia Kong: 32:39

Thank you. And that would be one example of how you didn't have their experience, but you were able to guide them in their direction. I know that's a big topic right now. Do you have to have all that experience and to be able to coach?

John Riley: 32:52

Absolutely, absolutely. cross functional and cross discipline very important.

Patricia Kong: 32:56

All right. Well, on that note, thank you, John Riley, thank you for sharing all these details in this story. And thank you to all our listeners. I bid you a good morning, good day and good evening. Thank you.

John Riley: 33:09

Thank you, Patricia.