80. Building a scrum team

Welcome back to another episode of The Rabbit Hole. Today we welcome Blake Deboer, also from Stride, to help us unpack the topic of Scrum! Scrum is an Agile framework, a topic we have covered at length previously on the podcast and we get down to what exactly Scrum is and what it consists of. Our conversation covers the pillars of Scrum and the tools, either digital or physical that are necessary to carry it out. We also chat about the real implementation of Scrum beyond its principles and then discuss issues of trust and flexibility in this context. Blake offers plenty of great insights and resources for our listeners to get to grips with this issue, so for an important and fun episode be sure to tune in!

Key Points From This Episode:

  • A little of Blake’s background and experience.
  • Defining Scrum and laying out how it fits into Agile.
  • Looking at the first pillar of Scrum, transparency.
  • Inspection, the second pillar of the Scrum framework.
  • The third and final pillar of Scrum, adaptation.
  • Equipment and tools necessary to carry out the framework.
  • Weighing physical versus digital tools when employing Scrum.
  • Actually implementing of the Scrum principles in real life.
  • The importance of trust in the process of launching Scrum.
  • Extending this idea of trust to product owners and stakeholders.
  • Rigidity and flexibility within Scrum.
  • Further reading and resources for learning about Scrum.
  • And much more!

Transcript for Episode 80. Building a scrum team

[0:00:01.9] MN: Hello and welcome to The Rabbit Hole, the definitive developer’s podcast in fantabulous Chelsea, Manhattan. I’m your host, Michael Nunez and today, we’ll be talking about building a Scrum team. We spoke at about Scrum a couple of times that includes, if you want to go back to Episode 23, we talk about Scrum, Kanban and prioritization.

I’m sure there are other instances where we spoke about Scrum but today, we’re going to get in depth into Scrum. Building a team, we’re going to define what a Scrum and what are the key principles and players and terms that you want to know to implement Scrum. We have a guest. I am here with Blake DeBoer.

How’s it going, Blake?

[0:00:38.5] BD: it’s been great.

[0:00:38.6] MN: Blake, tell us a little bit about yourself.

[0:00:40.2] BD: I’ve been a software engineer for a little over four years. Worked for two and a half years at a dev shop and then the last year and a half, I’ve been at Stride, worked in both, Waterfall, software development process and also for Agile teams and last two clients have been Agile transformations and implementing formal Scrum process. Seen before and after’s and the pros and cons of the different processes.

[0:01:06.3] MN: Awesome. You got a sense of building it from the ground up?

[0:01:10.8] BD: Yeah. Done that a couple of times and felt the pain along the way.

[0:01:15.6] MN: Well, we’ll get right to it. For our listeners, can you define what is Scrum?

[0:01:20.5] BD: Scrum is an Agile framework, there’s a lot of ceremonies associated with Scrum. People usually look to the artifacts of Scrum as what Scrum is but Scrum is like I said, an Agile framework and all that Agile software development really is, is a series of four values and 12 principles. Something like one of Agile values is, people and process, people over process and tools.

There’s also three pillars of Scrum that usually aren’t talked about a lot but really reinforce the reason why all of those Scrum ceremonies take place and it drives from empirical - empiricism like an empirical research and those are transparency, inspection and adaptation.

[0:02:06.6] MN: Awesome. We have the three pillars of Scrum and we’re going to tackle them one at a time. Let’s go over the transparency pillar, could you tell us a little bit about that?

[0:02:19.3] BD: Yeah, again, it comes – Scrum really like focus, it takes an empirical approach, a scientific approach to the way we work and one of the most important parts if you’re doing some scientific study or experiment is you want to have good data to look at. To see how you’re working.

In Scrum, like transparency is really important, there’s transparency at several levels, there’s transparency in terms of a board of we’re going to visualize all of the work that the team is doing and that not only helps the team see where they’re working or where bottlenecks might be.

It also helps stake holders, product owners, people outside the company.

[0:02:59.0] MN: Right.

[0:03:00.0] BD: They can see, I see that the team’s working on this. We also have transparency in the back log. We can again, a visualization of all the work that needs to be done and we can see, we can attach business value to each of these pieces of work, we can attach cost to each piece of the work.

And presumably, if you have one person who has a perfect idea of the value and ideally like the perfect time-cost associated with that work, they can make rational decisions about we should do this first and then we should do this.

[0:03:34.6] MN: Right. You can see if you breakup the work into multiple or different features that you want to introduce to your user base, you can determine, okay, we’re going to start with this particular feature because we see that users are really suggesting or recommending this one thing. Then we’re going to start working on this other thing and if the feedback that you got from the first feature is actually a lot more successful then the business can make a decision to continue working on that feature next or introducing new features outside of the first one.

[0:04:04.3] BD: Right. They have transparency, right? They see what the team is working on so they can redirect their focus and they also have, the transparency you’re talking about is like the transparency in like, are users using this? Do they like this? That’s kind of even like outside of Scrum but the same idea applies and too often, the anti-pattern that happens a lot in companies is teams will do work and there will be stake holders, but they’re operating independently of each other.

The team’s going ahead and doing the work and they get lots of requests from different people and they just try to juggle it and take their best guess as to what work needs to be done. And no one’s actually looking at the big picture and saying, why are we spending all this time doing this thing that doesn’t have that much value or we could do some of this that has a lot of value.

[0:04:54.6] MN: Blake, you mentioned earlier, number one was transparency, number two is inspection. Could you elaborate on that?

[0:05:02.8] BD: Yeah, definitely. We kind of touched on parts of this process already because this is all these things tie back to each other. Second part, when you thinking about being scientific about the way we work is after you have this data, like let’s actually look at it. Let’s literally do some inspection and see what needs to change. What of the most obvious ways that that’s done in Scrum is through a retrospective.

At the end of a sprint and real quick, a sprint is a time boxed period of time where you, a team commits to doing X amount of work in a time boxed period of time. At the end of that sprint, you will have the team retrospective and you will look back at the sprint and you’ll literally inspect how did we do, how is our process going.

Then it also it ties into adaptation which we can talk about where you actually like, improve on your process. Inspection also happens at like another level at sprint review is like – is a great time and is probably the most pure example of inspection happening on the team. At the end of two weeks, right before you do the retro, you have your sprint review ceremony and that could be either the product owner demoing to stake holders or the team demoing to product owner.

I mean, the ideal is product owner demoing to the stake holders and at that time, the stake holders will say, this is great, you missed something here or this gives me an idea, maybe we can do this and that’s like literally inspection that you’re having like into the work. Let’s look at this working software.

[0:06:43.4] MN: Right, everyone as a team and as an organization gets a chance to inspect the work that gets done.

[0:06:49.2] BD: Yes.

[0:06:49.4] MN: Awesome. Final pillar that keeps the Scrum standing stable is adaptation. I think adaptation just sounds like something we both mentioned throughout explaining the other two where you know, you look at the feedback that you get from the retrospectives and things that worked and things that didn’t work and use that to continue doing the good things and discontinue using the bad things, is that correct?

[0:07:13.5] BD: Yes, that’s true. It’s easier said than done and we can talk about how do you actually like, make sure that you’re creating good action items out of your retrospective that actually get done and change actually happens?

[0:07:29.3] MN: I see.

[0:07:30.4] BD: It’s really easy for a retro to come in like let’s talk about his, let’s talk about that, yeah, we should do some of this, we should do some of that and then retro ends and you start your next sprint and nothing’s really going to change.

[0:07:43.5] MN: Yeah, no action items actually get actioned or like gets executed rather and it’s just – it just sits ins some bucket.

[0:07:51.6] BD: Yeah.

[0:07:51.4] MN: I see. I mean, it does take some – I don’t want to say willpower but it takes like some energy to keep people accountable to ensure that we’re adapting to good behavior.

[0:08:04.5] BD: Yeah, we can - if we want to talk about like implementation and like how to do Scrum well, we can get into some of the details on that.

[0:08:12.9] MN: Before we get into that, I wanted to ask if there were any specific equipment that is needed in order to have a viable Scrum team.

[0:08:19.8] BD: That is yes, the short answer is yes, what actual equipment is required, is up for interpretation. Scrum doesn’t make any prescriptions as to exactly the equipment that’s needed but what you need is you need a backlog. I already slipped up and said physical.

It doesn’t matter if it is physical or in a digital format, use some project management software. You also need a board to track the work that’s being done. You need to have a board that on the left hand side and again, either physical or digital, here are all the stories that we want to do.

Here is the stories that we’re working on right now and this is the work that’s completed.

[0:09:07.1] MN: Right. Yeah, like pillars that they’re like workflows that everyone can know and understand where people currently are in that particular unit of work.

[0:09:18.1] BD: Yes, that sounds a lot like transparency that we just talked about.

[0:09:21.2] MN: Right. But I mean, I guess your ‘team physical’.

[0:09:25.8] BD: I am. Maybe that’s just my upbringing.

[0:09:30.0] MN: Okay., it makes sense. I could see the benefits of having a physical wall.

[0:09:34.7] BD: Yeah, and again, this ties back to one of the Agile values. Actually, misstated one, the Agile values. I said, people over process and tools is actually individuals and interactions, over process and tools. Slight twist on that.

But the physical wall helps encourage that. When you are at a standup and you’re huddled around a physical wall together, there is more interaction and it also - I’m a fan of it from a visibility standpoint. If you have literally like this thing posted on to a wall, it’s very visible, way more visible than logging onto a screen which is another big benefit.

Drawback being it’s harder, it’s not – it’s a little more cumbersome to calculate your velocity or do a burn down chart or something like that. There are tradeoffs, the other big tradeoff is if you have remote members on your team, getting in an accurate live up to date status of what the Scum board looks like is harder.

I’ve seen some teams do a hybrid which is actually works pretty well where you have your stories in some software project management tool but the individual tasks for those are on a board.

[0:10:50.0] MN: Interesting.

[0:10:51.4] BD: Your stories have the points and you can calculate all your burn down charts and if you’re remote like you can see like the general overall progress, you just don’t get like the small task level view.

[0:11:01.5] MN: I see.

[0:11:02.5] BD: There’s tradeoffs, there’s a debate for a reason because there’s not like an obvious solution.

[0:11:06.9] MN: Yeah, I mean, in a lot of the clients that I’ve worked on, there’s always some form of digital board, there’s always somebody’s got a load the Jira, right? Or Trello. But in the places that I worked that have had physical walls, it’s like really engaging to stand in front of the wall and know, everything that’s happening.

[0:11:29.7] BD: Yeah, one other thing I’ll say that I’ve enjoyed with Cisco walls is you can do whatever you want. There’s a need to say like well, “Trello doesn’t let you put this in that column,” you can literally put things where everyone make it as big or small with as much details, it’s really fast. How much effort does it literally pick up a sticky note and like move it one foot?

[0:11:54.8] MN: Yeah, do that on Jira, that probably – something’s going to happen, you got to refresh the page, shout out to Jira, it’s everywhere but it’s tough.

[0:12:04.3] BD: Yeah, no, I mean, but yes, there are tradeoffs, it does provide value, it’s easy for like looking back over historic data on things like there are some nice benefits to it. What I’ve seen work well is team start off with a physical board, learn like the best practices and then move into a digital tool.

[0:12:27.4] MN: We have an idea what Scrum is and all the tools necessary and the pillars that keeps Scrum up and stable. We want to implement in the real life. I know that you know, once you have the process an d the team buy in to do it, you got to adapt and you have to like start using certain processes. Is there one that comes to mind that you want to like discuss right now?

[0:12:50.9] BD: There’s a lot of small processes that you take to do Scrum well. Just like glossing over, that you have your definition of done, what does it mean for a story to be completely done, you have acceptance criteria which are particular to that story. You even have user stories, user stories is actually not something that’s like in the Scrum guide per se but typically get associated with Scrum.

There is a lot of your main ceremonies are standup, retro, sprint planning and also product backlog refinement and standup is more slang term. Scrum, it specifically calls it the daily Scrum.

[0:13:32.3] MN: Okay so wait, standup is the slang for the daily Scrum?

[0:13:35.7] BD: I am calling it slang. I don’t know I love it.

[0:13:37.9] MN: I mean it is just a different term, yeah I mean that’s what it is.

[0:13:39.6] BD: Yeah but that’s right, people usually know it as but if you go to the Scrum guide, it would say daily Scrum, is what it is.

But those are all things but there is a lot of work putting that into place with a new team and these processes can be read a lot about you know, I think we need to go into all of the detail of what those are in great lengths but one thing that we’ve seen being at two teams that adopted Scrum, where everyone has different reactions to this.

It is not a natural process, people naturally like to plan way, way in advance and people aren’t used to like they don’t just naturally fall into writing user stories and having retros and all of this stuff. So you are putting a lot of process in place that feels like a lot of overhead at first.

You need to understand where people are and where the team is at and have time to get feedback on that. I have seen teams that have Scrum just thrown at them and little room for let’s have some feedback of that.

[0:14:52.6] MN: Oh wow, okay so people are almost forced to do, “Hey we have to do this thing now.”

[0:14:56.7] BD: Yeah or at least it feels that way. They don’t - and I have also seen processes where it’s like this is the direction we’re going but let’s talk about it a lot.

[0:15:07.5] MN: Which I think is the more Scrum way to approach it right? Some open conversation about how you want to do things?

[0:15:15.3] BD: Yes and that’s really important. You have to understand where people are right now and meet them there and see the current process and respect that and not just say, “Oh the old way was total garbage,” like let’s see what wasn’t working. One thing that I’ve seen work really well is like, “Okay, on that note before we talk about all the Scrum setup and all this stuff, let’s talk about the problems that the team is having and waste.”

And I’ve seen great exercises done about identifying waste. And saying, “Okay, now that we’ve identified all these areas, how can we look at this Scrum process that we are looking at implementing and how can this actually improve it?” So probably an example would be helpful.

[0:16:12.4] MN: Yeah, I mean even as a team gets introduced into Scrum you have to start implementing some Scrum, right? Like there has to be some transparency as to why you’re doing this. Why are we about to step into this new process? You can bring all the benefits, the benefits that we mentioned before then the adaptation part comes in where people may be uncomfortable to adapt then that’s why you have retros, right?

Because to talk about the pain points of the process and the good points of the process and get all of that fixed up. I think one thing that we might have like just was in the essence of what you are describing earlier is the team itself has to have a trust in one another. It’s when sure that like Scrum is going to work, right? You have to trust that your team members are doing the best that they can with the tools that they have and the times they needed to get the work done.

That was a very off the cuff retrospective, prime directive but you need to have that trust with one another to ensure that everyone in a team is building the best thing they can possibly do at the moment.

[0:17:25.0] BD: Yeah, agreed and that trust is vital to Scrum working well because think about what you’re doing. You are putting a lot of transparency into this process. Now if people aren’t used to that and they’re going to say, “Whoa okay! Now you can see on this physical wall right here like how much time I’m spending on this task. I don’t know, I mean I thought that Mr. XYZ over there really didn’t think that I was doing a good job. I don’t think I really want this on the wall now and then we’re going to inspect it?”

So that actually gets into something that Jeff Sutherland talks about in his book, Scrum - The Art of – I think it’s got a long subtitle, it’s like The Art of Doing Twice the Work in Half The Time.

[0:18:10.6] MN: There you go, everybody wants to do that.

[0:18:13.0] BD: Yeah.

[0:18:13.6] MN: If that’s not it, it should be that just letting you know.

[0:18:16.0] BD: Yeah, it’s a hook. It will get you, yeah but he talks about the importance of looking at a process over people and how important that is and it goes right hand in hand with trust.

So when you’re retrospecting on how the sprint went and things are going well like sure, give a shout out to so and so doing a great job with this sprint. If things aren’t going well and maybe someone missed something. Someone slipped through the cracks, look at the process not the person because that’s really important.

Sutherland, we won’t get into it but Sutherland cites several really interesting psychology studies about under the right conditions, people can do really stupid things.

[0:18:58.2] MN: Yeah, oh yeah.

[0:18:59.6] BD: Even with the right process you can be like, “Why did that person do that?” Well, look at their incentives or look at why they’re set up for that.

[0:19:07.3] MN: It could be a poorly QAed or tested feature because they are getting pressure from some other team to make sure that this work gets done and Bobby has been up since 12 AM, midnight, working 18 hours trying to get this feature done and yeah, people will do crazy things. I, for one, have done a lot of crazy things in my time.

[0:19:26.6] BD: Yeah, so that trust is really important when you are trying to put your process under a microscope, you need to be comfortable with saying like, “Okay we are going to do this, we’re going to do that.” and no one is going to be sitting there looking at this individual person is messing up or something like that and I’ll just add it real quick about trust. It also happens at the stake holder level and the product owner level.

I mean the more that you can like incrementally every say goes sprint two weeks, every two weeks deliver working software, you are going to build trust with your stakeholders and they will - and the more you can say it at the end of the sprint review like, “Okay we delivered features A and B and next sprint we are going to do C and D.”

And then when you deliver on that, oh man you start building that kind of relationship like they really start trusting you and then you are not – there might be sometimes in teams pressure, say, “Oh we really need to perform and so all of this.” But if you can just break that down and say, “Okay we are not about committing to six months from now, or committing from two weeks from now and let me just build that thing for two weeks and show you that,” right? “Like in another two weeks I am going to show this next thing,” and that’s the way that you can build trust.

[0:20:43.4] MN: Yeah, I mean I think demos is definitely a good way to do that. Just like, “Oh that thing was pretty hard but look at how much they have accomplished and the things that they worked on.”

[0:20:53.8] BD: Yeah, absolutely.

[0:20:55.3] MN: For it to work, for Scrum to work I think as you mentioned before Blake, the team should be ready and be able to get buy in on this new process that they have to do that has to be trust across the board. There is an episode, drop in, there is an episode on The Rabbit Hole, Episode 67, Building Trust. I think we have a very extensive conversation on what that means and how to do that effectively so go check it out if you haven’t.

But when you do have Scrum I guess the question is there has to be balance from what is working for the team in Scrum and then what isn’t. Do you in the past couple of times that you implemented Scrum, did you follow it to the tee or is there some things that you would change that are little different?

[0:21:42.2] BD: That’s a really good question. You need to be able to be flexible I think is really important. You stick to it to the tee as much as possible and I will get into the why in a second. To the extent that you are not losing, again trust or buy in with the team. If you say, “We are doing this no matter what,” and people are not onboard, what’s the point?

[0:22:08.5] MN: Right, yeah this is not going to work.

[0:22:10.1] BD: Yeah, it’s just not. You need the team to do the thing. If they are not onboard, they are not going to do the thing. So you could say all that you want but I will say that I am a fan of trying to get there as much as possibly because I have seen teams slip up and slide away and say, “Well we don’t really need to do this, we don’t really need to do that,” and you realize, “Oh this is there for a reason and each Scrum ceremony, each artifact of Scrum is there for a reason and build on each other.

And if you use it all together it is a multiplier effect. For example, I’ve been on teams going back to retrospectives like where a team is not visualizing action items out of retro and they’re just like, “Yeah, we’ll get to them and we used to do it but we don’t really do that anymore. You know it’s been a little while,” I’m like, “Oh I mean why do our retros feels stale. Why does it feel like we’re just talking and not doing anything? Oh, it’s because we’re not.”

So if you start to actually like one of the big things that I am a fan of with action items is you slap them on the top of your board as the highest priority thing and they’re there and prominent and also I am a big fan of SMART goals. You know that I have a specific measurable, achievable, relevant, time bound, something like that, yeah.

[0:23:31.1] MN: There you go, there is an episode on that too, yeah we got one of those for sure.

[0:23:34.0] BD: So I am a big fan of that as well. Let us actually make this action item actually actionable and not some vague thing that we don’t know. So that is just one example of when you let your process go a little bit, you will see a drop off most likely but I am also a big fan of not doing things just for the sake of doing it. If you are continuing to do something and this is like, “There is no point to doing this,” stop, don’t do it.

[0:24:02.5] MN: So like being as strict as possible and then finding things to shave off whenever but I think that way just work because if you are already cutting things as you are starting, then you’ll not going to see the benefit as to why they’re there, right? This process has been happening for many years now and people have perfected it, written books and literature and all sorts of stuff about Scrum.

Blake DeBoer, ladies and gentleman. Do you have any text you want to refer to people so they could learn more about Scrum?

[0:24:29.7] BD: Yeah, two resources that I learned a lot from. Well there’s one I already mentioned it, Jeff Sutherland’s book on Scrum. It is called Scrum: The Art of Doing Twice the Work in Half the Time and the other one is a pretty obvious one. It’s just The Scrum Guide, you can find it online. I think it’s thescrumguide.com or dot org or something like that. Just look it up, it’s top result.

It’s The Scrum Guide, it gets into the nuts and bolts I touched on some of like what is a Sprint product backlog. All of those phrases and words that you hear in Scrum, it goes to a very detail about that but it is not long. It’s 17 pages but the Scrum book is really interesting because it gets into more of the theory and the why and the history of Scrum and where it comes from. It is a pretty interesting stuff.

[0:25:22.6] MN: Awesome. Follow us now on Twitter @radiofreerabbit so we can keep the conversation going.

Like what you hear? Give us a five star review and help developers like you find their way into The Rabbit Hole and never miss an episode, subscribe now however you listen to your favorite podcast.

On behalf of our producer extraordinaire, William Jeffries and my amazing co-host, Dave Anderson and me, your host, Michael Nunez, thanks for listening to The Rabbit Hole.

Links and Resources:

The Rabbit Hole on Twitter

Blake DeBoer on Linkedin

Stride

Episode 23

Jira

Trello

Cisco

Jeff Sutherland

Scrum: The Art of Doing Twice the Work in Half the Time

Episode 67