Podcast Ep. 98: What is Professional Scrum?

Share on facebook
Share on twitter
Share on linkedin
Share on email

Episode Description:

In today’s episode of the Agile Coaches’ Corner podcast, Dan Neuman is joined by his co-host and collaborator, Sam Falco, to discuss the topic of professional Scrum.

What does professional Scrum refer to? What is professionalism? What does a Professional Scrum Master look like? What does it look like to practice Scrum professionally through principles and values laid out in the Scrum Guide? What does professionalism look like on a Scrum team? Sam and Dan answer all of these questions, and more, in this episode.

Listen on Google Play Music

Listen on Apple Podcasts

Key Takeaways

  • What does professional Scrum refer to?
    • Ken Schwaber’s definition: “A professional is someone who works for money and follows the rules established for the profession. Professionals act and work according to standards where they exist. They also embrace and embody a set of ethical principles established by their profession.”
    • Adhering to the rules set forth in the Scrum Guide
    • The Scrum values fulfill the role of the “ethical principles” in the software development industry
    • A mindset of professionalism and a commitment to a certain set of standards
    • An emphasis on communication and empathy between business and development (so that you can ensure that you are delivering what the customer actually wants and can use)
    • Professionalism includes really understanding why you’re doing the things that you are doing
  • Examples of professionalism:
    • If you are trying to release a product for customers by a certain date, how do you use the Scrum events, the Sprint planning, the daily Scrum, and the Sprint review within the Sprint timebox to make sure that you’re on track? 
    • In the Sprint review, identify which adjustments and decisions are needed, and iterate
  • Important notes about doing Scrum professionally through the Scrum Guide:
    • It’s not just about having the roles, artifacts, and events in place; you also need to be cognizant of the rules that bind these three things together
    • Commit each Sprint (as a team) to a goal, not a scope
    • When a Sprint goal is a laundry list of things to do, it can become overwhelming — it is much better to commit to a goal and negotiate your scope as you go throughout the Sprint
    • Focus on delivering the goal and delivering the value
    • It is important that the organization gives the Scrum team(s) space to be professional
    • “Professionalism is not just for the Scrum team, just as the Scrum values are not just for the Scrum team; they’re for the organization to live and make space for.”
  • The responsibilities of a Professional Scrum Master:
    • They are responsible for coaching the Product Owner, the team, and the organization on how to use Scrum in an effective way
    • The Scrum Master should not be a glorified administrator
    • The Scrum Master should be working with the entire organization to help it achieve business agility and valuable outcomes rather than just lots and lots of output
    • Look for ways in which the organization is inhibiting your team’s further growth and success
    • Look for the areas and opportunities in the organization for further agility
  • Aspects of professionalism on a Scrum team:
    • Strong collaboration (i.e. the Product Owner and the team need to collaborate, and the Scrum Master needs to collaborate with the team, the Product Owner, and the organization)
    • “What does it mean to be a Professional Scrum Developer?” It’s more than “I’ve got my work done”
    • The team should not be working siloed
    • At the daily Scrum, the team should be collaborating on the most effective thing to do that day to get closer to the Sprint goal, figure out who needs help, and understand who’s doing what
    • Toward the end of the Sprint when development work is winding down, it is important that developers are helping the test activities happen
    • “The development team is not just the people that are writing the code; it’s all of the people on the Scrum team that are needed to deliver that increment, aside from the Product Owner and the Scrum Master.”
    • It is important to find the balance between being a “busy body” and being a “T-shaped person”
    • A healthy team spirit is vital
    • Redundancies in skill sets of team members are incredibly valuable
    • Being open to learning new things beyond your expertise and having the intellectual curiosity to step outside of your role makes for a healthy, well-rounded team

Mentioned in this Episode

Transcription [This transcription is auto-generated and may not be completely accurate in its depiction of the English language or rules of grammar.]

Intro: [00:03] Welcome to the Agile Coaches’ Corner by AgileThought. The podcast for practitioners and leaders seeking advice to refine the way they work and pave the path to better outcomes. Now here’s your host coach and agile expert, Dan Neumann.

Dan Neumann: [00:16] Welcome to this episode of the Agile Coaches’ Corner. I’m your host, Dan Neumann, and joined by fellow host of this fine series that we have going here, Sam Falco.

Sam Falco: [00:27] How’re you doing, Dan.

Dan Neumann: [00:28] You’re not supposed to laugh when I say fine series. We’re just making it up as we go along. We might as well have some fun and we’ll see where we go from there. But today’s topic is going to be about what is, what is meant by this thing, professional Scrum anyway.

Sam Falco: [00:55] Right, right. I get that question from time to time. As I teach Professional Scrum Master, Professionals Scrum Foundations, why do you have the word professional in there? What does that mean?

Dan Neumann: [01:09] Because certified was taken.

Sam Falco: [01:10]
Because certified was taken well, there’s all trademark battle going on right now. I don’t know if you’re aware of this.

Dan Neumann: [01:16] I’m not surprised, but yeah, let’s, let’s explore that.

Sam Falco: [01:20] Um, Scrum Alliance sued Scrum, inc, which is the creator of Scrum at scale and they were alleging trademark. Um, what’s the, what’s the word infringement infringement. That’s the word. And I think some other stuff, I read the filing and I read the injunction because I’m a huge nerd and I like to read court things and I didn’t follow it at all. But right now what they got an injunction for is that Scrum inc can’t use the term licensed, so licensed Scrum Master, licensed Product Owner, et cetera, because it, according to the court finding, trying to parse my words very carefully here, the court found that there was enough evidence to suggest that Scrum inc had deliberately blurred the lines to cause market confusion. It’s been a fascinating fight that I’m glad that I’m not involved in an organization that has a dog in that fight, but it has been interesting.

Dan Neumann: [02:28]
No animals were harmed in the making of this podcast. Yeah. Okay. Yeah. Um, yeah. So anyway, um, now if anybody’s interested in more metaphors, they can go back to a previous episode about the choice of metaphors to use, but let’s go back to the professional.

Sam Falco: [02:47] I believe that the initial title for the courses, there was some, you know, to do about it and they chose the word professional because it would not infringe on certified. Um, and I don’t know, that’s just what I read someplace I’m guessing, but it also has a distinct meaning. The mission of Scrum.org is to enhance professionalism in software development. And so what we are talking about a very specific sort of thing, not just a trademark Dodge, right,

Dan Neumann: [03:19] But, but it’s a handy feature that professional’s also not synonymous with certified. So, opinions are our own, not those of AgileThought or any other organization. Yeah, exactly. So professional, like I used to and still do say, well, what’s, what’s a professional. Like as soon as you get paid for something you’re a professional, I don’t know what the Olympics there was, you know, amateur versus professional college students, you can argue whether the scholarship is actually getting paid or not. And certainly they’re not getting nearly the pay that they’re they’re, um, labor produces revenue. That’s a sub, but is it more than just getting paid?

Sam Falco: [04:09] Yeah, I think it is. Um, well there’s a whole class distinction that gets brought up when you talk about professional versus trade. And I don’t want to get into that because that is way too esoteric. Uh, but the idea that the professions were, you know, more rarefied and you had to study for them, whereas if you were, uh, perhaps an electrician, then that’s a trade, not a professional. I specifically chose electrician cause my dad was a master electrician. There was professionalism in everything he did. So I find that artificial distinction troublesome.

Dan Neumann: [04:44] Yeah. So almost that sounds synonymous with like the white collar blue collar type.

Sam Falco: [04:49] It’s very snobbery. Yeah. There’s, there’s very snobbish attitude towards it. I like for our purposes today, I liked the definition that Ken Schwaber put forward in his forward to mastering professional Scrum. And I have it here, so I’ll just read it. He’s got some asides that I’ll cut. “A professional is someone who works for money and follows the rules established for the profession. Professionals act and work according to standards where they exist. They also embrace and embody a set of ethical principles established by their profession.” End of the quote. And I really find that a useful way of looking at it is aside in the according to standards where they exist is for example, adhering to the rules, set forth in the Scrum guide and ethical principles. He points out that the Scrum values fulfill that role or can fulfill that role for us in the software development industry specifically when we’re practicing Scrum.

Dan Neumann: [05:52] So treating it as, as a profession, I guess, distinct for more of a mindset of professionalism and then the practices of professionalism versus I don’t amateurish, you know, amateur software development, amateurish Scrum.

Sam Falco: [06:09] Sure. A book I read and I mentioned this many, many episodes ago and now I’m drawing a blank. So I’ll have to put it in the show notes, but it was about the early gaming industry and the development of computer games for home consoles and how, one of the things that came across in that was how wild West that industry was and how unprofessional it was. You’re hired, go make a game. And you turn in whatever whenever. And you know, the, there was really no oversight, no commitment to a specific set of standards. And Scrum gives us a way to communicate better with business people have some empathy so that it is not the us versus them, that software development so often is, you know, those business people, anytime you find yourself saying the phrase of those people, you are on thin ice. But we hear that all the time. Yeah. Inside and outside of Scrum, right. It’s brought down from them. Yeah. And I think Scrum by having the role of the Product Owner and really encouraging, although it’s not written in the guide, but the really the encouragement is that the Product Owner is someone from the business, knows the business is, has the entrepreneurial mindset necessary to developing a world class product that we have communication and empathy between business and development so that we are sure that we’re delivering as sure as we can be that we are delivering what a customer actually wants and can use.

Dan Neumann: [07:53] Well, that’s why you want, when you, when you are doing your best guess at what the customer wants and uses, then you actually get them to use it. You get feedback loops and you try and make those as short and as valuable as possible.

Sam Falco: [08:05] Yeah, we validate by releasing. And that is of course, one of the reasons why in the principles, we value working software as our primary measure of progress. And the cadence should be from a couple of months to a couple of weeks, but the preference to the shorter cycle.

Dan Neumann: [08:27] So you were talking about, um meeting, obviously there’s the getting paid component of it, as well as the, uh, adhering to a set of standards and ethical principles. And I think back to maybe some of my earliest times with the Scrum framework, there are decidedly unprofessional things that I am pretty sure I was committing as part of those thee thou shalt stand up during the daily Scrum, the, you know, even some of the use of things like ceremonies or going through the mechanics of these activities without actually making sure the value is achieved or at times missing the point of the exercise. Aside from it’s a time box, you know, exercise for XYZ.

Sam Falco: [09:08] I think professionalism includes really understanding why we’re doing all of those things. And yeah, when I was first a Scrum Master, we did the things because I had heard you did it that way. I was a Scrum Master for a couple of years before the Scrum guide came out. So I was working off whatever I could scrounge up in books and from hearsay and didn’t even have a class for a couple of years. So I heard you stood up, as you said. So I enforced that, which was a stupid thing to enforce. Now I didn’t just come in and say, team, we’re standing up. I actually asked them, would you please humor me and do this? Because I think it will help our daily Scrums run smoother. And we tried it as an experiment. So, but there were other times when I completely fell down, here’s the purpose we’re doing it. Cause it, cause it says, so. Yeah. But understanding why we’re doing these things and doing it to create, to achieve a goal, a valuable goal, it makes a huge difference.

Dan Neumann: [10:16] It does. And an example that comes to mind, you know, if we are shooting for a, to release a product to actual end customers by a certain date, how do we use the Scrum events, the Sprint planning daily Scrum and the Sprint review kind of within the Sprint time box to make sure that we’re on track and then the Sprint review also, Hey, here’s how we’re trending. What adjustments, what have we learned to the product backlog? And we make some tough decisions about maybe what stays in there or out, or we find the increment of value and get rid of some unvaluable backlog items. And we iterate towards that goal as opposed to, you know, we fixed time scope and resources, and now we’re going to death March it to that goal, but we’re going to do it in the two week Sprint.

Sam Falco: [11:03] And that is something that I’ve seen a number of times where clients will say, well, we know exactly what we want, so we’re going to spend time creating this massive thing of requirements and then estimate it. And then that’s the date. Whoa, that’s not a healthy way to approach things. And I think if we, if we don’t challenge that, but don’t point out the dangers of that, then we are acting unprofessionally because we are setting up an expectation of delivery that we don’t have any reason to know we can meet. And I think it’s perfectly acceptable. I think it’s actually required to say, we can’t know that I’m not going to promise you something when I can’t know that I can deliver it. And this is one of the ways that Scrum can be a huge benefit. And it’s one of the ways we can limit risk to organizations is to say, let’s figure out what’s an important thing to do right now. We’ll build that for a Sprint or two, whatever your risk tolerance is. You know, if it’s a month and we want to do it in two Sprints or it’s, whatever that may be. And then we can evaluate where are we? And then we can give you maybe a slightly better idea of when we might be done with the massive thing that you want. And you will understand as well, how, what you want may change rather than going in and saying, you don’t know what you need because that’s the, the, the other version of that is we’re not going to come up with an extensive backlog because you don’t know what you need. No one wants to hear that. We can’t say this is what you think you want right now, your mind may change because we find that it often does. So let’s build a little something and we can structure our contracts in such a way that if that’s not going in the direction you want, we can change direction. Or if you decide that, yeah, I don’t want to go this, do this at all. We can terminate early with, you know, some, uh, cushion on either end. So that’s the contracting, you know, the, the people who are doing the work, I guess not sure what contract language I should be using here. The people who are doing well, cut loose. Yeah.

Dan Neumann: [13:25] Even if it’s internal, even if it’s internal, there’s an implicit contract.

Sam Falco: [13:29]
You know the idea that we’re not just going to lay people off or we’re just not gonna stop paying you suddenly, but we’re going to make it worth your while to set aside some time and people to do a job. And if it ends early, you haven’t turned down other work in the meantime. And so your, your SOL, meanwhile, you, the buyer are not on the hook for, well, we had a $10 million budget for this project. And by God, we’re going to spend $10 million when after 500,000, you realize this is not what we want and we can’t use it.

Dan Neumann: [14:03] And so teaching it, taking the professionals about teaching about empiricism, teaching about, you know, the cone of uncertainty, where early on, when you’re making those forecasts, Hey, we think we can be done by here, uh, that, that you realize that you’re making that with knowing the least you’re going to know, because next day, next week, next month, next six months, you’re going to know more about it.

Sam Falco: [14:28]
Yeah. Especially if you have a massive backlog, I don’t think there’s necessarily anything wrong, nothing inherently wrong. I just, I guess I should say with sitting down with the customer and trying to map out what they, what they want, but put it on a roadmap that indicates the uncertainty of the farthest out stuff. And I don’t think there’s anything wrong with getting a team to a look at that body of work and say, here’s our best guess right now. Here’s our estimate right now. It’s a guess because we haven’t gotten started on it. And even if you have a team that’s been together, here’s what our velocity might be. But I think you should give that as a range. We might do 15 points per Sprint. Let’s say we’re using points. We might do 30. Sure. If we do 30, it’s going to take this long if you know, given all of this. But, and then caveat that with, at the end of the first sprint, we’ll have some data that will help us be a little more accurate, but not much. And at the end of the second Sprint, we’ll have more et cetera. Uh, and then, you know, after about 10 Sprints, we’ll have a better idea, but even then we can’t know, show them that, you know, as you, as you said, the cone of uncertainty.

Dan Neumann: [15:38] We talked a little bit about the standards and in Scrum, that standard is the Scrum guide. At least that’s yes. I think we agree. That’s our humble opinion. Okay. Other other people may have equally humble opinions, but, but for now we’re saying, Hey, that standard is the one we would go for when we’re talking about, are we doing Scrum professionally? And then the ethical principles within that, the Scrum values.

Sam Falco: [16:01] And let’s talk a little bit about the Scrum guide. It’s not just having the roles, the artifacts and the events in place. That’s great. That’s like the minimum you need, but there’s also the rules that bind all of this together as a, I think the way the Scrum guide puts it. And so things like that, they get overlooked. We commit as a team, each Sprint to a goal, not to a scope. And too often, the Sprint goal is here’s a laundry list of things, do them all. And then that’s when you get situations like people starting to really freak out about their estimates and how can we get more accurate, the estimates and all this churn. Re-estimating things afterwards, how do we get credit for work that spills over into the next Sprint? Well, if you are committing to a goal and negotiating your scope, as you go throughout the Sprint, that becomes less of a worry, the team starts to get a pretty good handle on what it can do over time. So yes, your forecast may be more or more accurate over time, but it’s never going to be a hundred percent. Don’t sweat it, deliver on the goal, deliver the value, and that can be teams. But I find that often that is organizations that are not giving Scrum teams the space in which to act professionally either. There’s pressure put on, to behave in ways that are less than professional. And so professionalism is not just for the Scrum team, just as the Scrum values are not just for the Scrum team they’re for the organization to live and make space for.

Dan Neumann: [17:48] That’s where I see the Scrum Master, especially in a professional Scrum Master, so the professional Scrum Master, as I just stipulate with my hand and started to throw things across the room, but the professional Scrum Master has a lot of responsibility for coaching the Product Owner for coaching the team for coaching, then the organization in how to use Scrum in an effective way.

Sam Falco: [18:18] Yeah, that is key. I see. So often where Scrum Masters are at best sometimes administrators for the team, you schedule the meetings, you run them. Why can’t you handle five teams? Oh my God. And you’re not doing anything with the Product Owner. And you’re certainly not doing anything with the organization. Um, yeah, that’s a problem. The Scrum Master needs to be doing way more than that. And working with the entire organization to help it achieve business agility, to help it achieve valuable outcomes rather than just lots and lots of output.

Dan Neumann: [18:54] Definitely. I’m thinking actually I got an email from a reader. Maybe we’ll put a pin in this for a future episode. They were saying, Hey, they’ve got a fortunate situation if you will. And that they have three, uh, described them as high performing teams. They’re doing very well. And as a Scrum Master, they’re sitting there looking at themselves and going, Oh boy, is the organization perceiving my role now as obsolete, which is an existential crisis to your paycheck at some point. And so I think we’ll want to talk about what Scrum mastery with nimble organizations with well-functioning Scrum teams looks like at some point.

Sam Falco: [19:33] Yeah. And I’ve seen that bit of dubious advice that a Scrum Master should be trying to work themselves out of a job. And I disagree. I don’t think we should expect anybody to do that in this role. And I think that that comes from that narrow interpretation of Scrum Master as team coach only does not get involved elsewhere. And so yeah, once a team is hitting on all cylinders, what are you going to do? Well at that point, me as a Scrum Master, I’m starting to look for what are the ways in which the organization is inhibiting. My team’s further growth, further success. What else could we do? Or just where are other opportunities in my organization for further agility, go talk to, Hey, HR, do you want to do something different about your recruiting? You know, what are your, what are your pain points?

Dan Neumann: [20:24] Recruiting. Compensation, manipulation. I mean a bonus structures. Yeah.

Sam Falco: [20:30]
Yeah. Or go talk to the legal department. Hey, you know, when you write contracts, then we run up against them. Let’s. Do you want to experiment? What would help? So there’s a lot more for a Professional Scrum Master to do than just be a team coach. And I don’t mean to imply that being a team coach is somehow lesser. I’m just saying that when you get to a point where there’s only so much help the team needs because they are as self-organizing as they’re going to get, they are cross-functional, they are getting it done. They come to you with impediments rarely. And when they do, it really is an impediment. They have tried to solve it. Okay. You don’t need to be with that team all the time. You need to be doing something else.

Dan Neumann: [21:11] Yeah. And much more, um, a much greater extension of the professional focus then, uh, like you said, there’s, there’s lots to do with teams, especially as teams are getting going, Scrum is new, et cetera. And perhaps the focus shifts to a different facet of the Scrum Master role.

Sam Falco: [21:29] Yeah, absolutely. So another aspect of professionalism on the Scrum team is collaboration. So we’ve already talked about how the Product Owner and the team needed to collaborate. We’ve talked about how the Scrum Master collaborates with the team and the Product Owner of the organization, but we haven’t touched on is what does it mean to be a professional Scrum developer? Now we have a class and our marvelous colleague, Eric Landis teaches the professional Scrum developer course, but it’s more than I got my work done. It works on my machine, pitch it across the wall and hope that QA doesn’t find anything. QA is part of the professional Scrum development team. Anyone who is needed, all of those cross functional skills that are needed to deliver a valuable increment are part of the team. And we need to be collaborating, not playing in our own little sandboxes siloed and just throwing things across to each other. So professionalism also includes that idea that at daily Scrum, we are collaborating on what’s the most effective thing to do today to get closer to our Sprint goal? Who needs help? Who’s doing what? What is important? We have those three questions that are suggested in the Scrum guide, but it’s more than just, this is what I did yesterday. I’m going to do this thing and I do, or don’t see any impediments. But what I want to see from professionals from developers is things like one developer says, I’m working on coding this area, and I’m, I’m really shaky on this particular library. And another developer says, I know that library inside and out, why don’t we work together on it rather than I’ll take it? Why don’t we work together on it so that we build skills together. That kind of thing is what I’m looking for. And for at the, you know, towards the end of the Sprint development work is starting to wind down. Developers are helping the test. Activities happen. And at the beginning of the Sprint, testers are helping developers get, get started, understanding where they’re going to test working together to deliver value, rather than just not coordinating.

Dan Neumann: [23:41] You, bring up something I wanted to amplify, right? Which is the development team is not just the people that are writing the code. It’s all the people on the Scrum team that are needed to deliver that increment aside from the Product Owner and the Scrum master, they have, they have different roles. That’s one piece. And I think the other facet of professionalism. So even if you have all the individuals on the team, it’s finding that balance between, um, I guess the, the term busy body comes to mind and I’m not sure how well that term, you know, means anything outside of the U.S. but somebody who’s really wanting to get involved in all the different things, because they’re curious or have an opinion, or just feel like they should be offering something to everybody versus truly having T-shaped people where they have depth in an expertise, but they also have capabilities outside of that single expertise. And they can collaborate effectively towards those. I think it’s, it’s that balance between, uh, you know, we, we don’t all have to be involved in every thing on the Scrum team, but you know, at the same time, we don’t want people to, um, ignore things that are outside their specialties. Look over there and go, boy, it looks like you have a problem that stinks for you. Things are great over here.

Sam Falco: [25:06] Um, yeah, we, we really want to just encourage that team spirit. The idea that we should have some redundancy in skill sets is also nice speaking as someone who was once the only QA person on the team in an environment where developers did not test. And so guess what? I had to schedule my vacations around the sprint cadence, because I couldn’t be gone at the end of a Sprint, which was just crazy. Fortunately, I was on a team where while the environment of the organization had that attitude, that my team members and I had a really good working relationship. And someone realized that after like the second or third time, I was like, Oh man, I wanted to go on vacation. Then what I’m going to have to shift it. And one of the developers said, well, that’s just crazy. Why would you not do that? Let’s figure it out. And so we did, but yeah, we want that, that mix of skills, it’s fun. It’s fun to grow our skill sets. It’s fun to grow our expertise. And it really is fun to be able to do more than just one thing.

Dan Neumann: [26:11] Well, that’s actually so brief tangent, that’s our idea of fun, but I have met people whose idea of fun is really, this is the one thing I do. And I think that creates some interesting challenges.

Sam Falco: [26:22] True. I had not considered that aspect of it. And yeah, there are people who just want to do.

Dan Neumann: [26:28] Short of maybe that person, isn’t a great fit for a Scrum team and that’s okay. You know, not everybody digs Scrum. One of the guys who stood up in my wedding, he didn’t dig Scrum. He went, he went, he did end up going somewhere else. Ironically, he’s now a functional manager and they quite agile organization doing Scrum. But yeah, that was about a 10 year journey.

Sam Falco: [26:50] Sometimes people are uncomfortable with learning new skills because, well, there’s all sorts of reasons. Like one of the things that I get pushback sometimes from, from developers, meaning coding developers is QA is seen as lesser. I shouldn’t have to do testing because that is for the testers and they are, that’s beneath me and we have to, well, that’s a terrible way to think of your coworkers for starters and we need to work on that.

Dan Neumann: [27:21] I mean, you could get in an autonomous vehicle that hasn’t been taught. Yeah. That’s an option. Yeah. So, right. So, so you’re right. There’s that, there’s the, um, there can be this implicit, um, hierarchy, right.

Sam Falco: [27:45] And we also have to look at how are people incentives. If the incentives in the organization are you do the job you were hired to do and don’t learn anything outside of it. Well then people aren’t going to be comfortable doing that. So is there an incentive there maybe we look at, is there some insecurity I’m afraid to learn that that can be tied in with incentives. Other, other things also look at what’s motivating people. I mean, some people really are motivated by, I want to get better and better at this one thing. Okay. That’s great. But also let’s look at how does that affect the team and is that the best thing? We’re not saying you have to get expert at everything. We’re just saying, learn a little bit outside. So that, for example, a developer who does not want to learn testing, well, maybe you run some tests, especially if there’s a recycle where you think you’re done in the QA, find something, and then you think you’re done in the QA, find something. Maybe you learned to prevent that cycle by looking at how does a tester think how the test you’re going to think about this. Likewise, if you’re a tester and you’re continually sending things back, maybe you want to think about how is that coded? I worked with a QA guy on a team and this was maddening for me because when I would find a bug, he would find five for the same thing, because this was a specifically, a Microsoft word edit where we were hijacking Microsoft word features, right? So bold, doesn’t work bold. Doesn’t work at the top. Doesn’t work underlined, doesn’t work, strike through doesn’t work. These are four different bugs for him. I’m looking at going, I know how this is coded. That’s one bug. Yes. Formatting does not work. And so having that intellectual curiosity of stepping outside of my role as a tester to know how is this, what’s the architecture of this? How do coders think, and how will this coding work helped them. Because I could give much better information to my developers.

Dan Neumann: [29:39] And that’s where getting people that are going to validate the software, sitting down side by side with people that are going to create the software and exchanging ideas. Hey, here’s the, here’s how I think the software should work when you’re done with it. And there’s a chance to bring that testing forward. It’s not quite test first, but it’s like, here are the tests that I think I’m going to execute. And here’s the little bit of how I was thinking slowly, the developer, when I’m a QA tester, whatever the title may be and just saying, well, let’s look at this story. Here’s here are some of the tests I’m thinking that will, that will be necessary, helping them decide it. They’ll tell me if there is, if we’re using test driven development, here are the unit tests that are going to be run. And it really is a fun collaboration. It’s a more dynamic and it results in higher quality software. And it results in a lot less animosity where you just, again, kick things back and forth. I’m remembering when my sister and I would have to do dishes when we were kids and there was this one glass baking dish that would like stuff would stick to it. If it was wet, you wouldn’t see it. And so it was wash it, dry it, find stuff, go back. And we would just get yelling at each other.

Dan Neumann: [30:47] Oh, I’m twitching because I can tell you where I was in the kitchen when my sister and I, my sister was a tyrant and she is almost four years older than me. She was always bigger than me. Um, yeah, so much abuse at the hands of my sister. Maybe I’ll get her out. Maybe I’ll get her on it someday. She manages HR. Anyway, we’ll just leave that. We could explore that another time. So let’s put a bow on this for, for the purpose of today’s exploration of fessional and professional Scrum master. So they have standards, professional standards that are adhered to. Get paid and follow a set of ethical principles and so much more than just kind of following the, um, the mechanics of the roles withing Scrum. Well, thank you for exploring that. We’ll we’ll welcome people’s questions about professional Scrum, whether it’s Scrum developers, Product Owners, Scrum master, any of those Scrums.

Sam Falco: [31:51] Thanks for having me.

Dan Neumann: [31:52]
Thanks for your time, Sam.

Outro: [31:54] This has been the Agile Coaches’ Corner podcast brought to you by AgileThought. The views, opinions and information expressed in this podcast are solely those of the hosts and the guests, and do not necessarily represent those of AgileThought. Get the show notes and other helpful tips for this episode and other episodes at agilethought.com/podcast.

Stay Up-To-Date