Ken Medley:   0:00
Hi, everyone. Welcome to this episode of Two Scrums Up, a podcast by Alley, where we discuss Agile and all things Scrum. My name is Ken Medley, I'm an Agile Process Leader here at Alley, and I'm joined by our Director of Agile Process, Mr. John Ragozzine.

John Ragozzine:   0:18
Hi! That's right, my name is John Ragozzine, Director of Agile Process here at Alley.co. Alley is a fully distributed web agency and we've been running Scrum for several years remotely, fully distributed. We have things we've learned both the easy way and the hard way. We want to share them with you and that's why we have this show. When I first joined Alley years ago, I had gone through Scrum certification, some other folks have gone through Scrum certification with myriad agencies organizations and whoever was offering it. We started laying a foundation of Scrum tactics and Scrum frameworks across the company. But there was a lot that was suboptimal or not ideal and we knew as an agency that we had to really start from scratch, reset the numbers back to zero and move forward with everyone running Scrum and everyone running Scrum from the same vantage point. What we did at the time, we sent everyone to either CSM training or CSPO training with an organization called Scrum Inc. that comes from Jeff Sutherland, who is the inventor of Scrum, the originator of Scrum. It's his company, and so we went that direction and the training compared to some other organizations that we used was great. I mean, there are plenty of places that do good Scrum training, but there are some places that do less than good Scrum training and Scrum Inc. we think does great Scrum training. So we stuck our claim, to make sure everyone gets trained doing that, no matter what your background was and it went forward to making sure that every new person who joined Alley went through training as well. Ken you came on after this transformation first started and you went through Scrum training pretty close to after your hire date, right?

Ken Medley:   4:49
Yeah, that's right, like you mentioned I had gone through Scrum training previously before I joined Alley as a Product Owner as well as a Scrum Master. Part of the appeal of joining Alley was the entire company was using Scrum, specifically the Scrum@Scale model, which I really appreciate. We can get into that a little bit later, but I I loved being able to just kind of reset and go to Scrum Inc., take their Scrum Master certification course, and I learned so much while I was there. This is coming from someone who has been doing Scrum and Agile, different forms of Agile processes for almost the last decade. I really appreciate Scrum Inc., I think they add a lot of value, and I was glad to be able to attend that. Like I said, here at Alley using Scrum@Scale, I think it has been super helpful to me to come into an organization and look at Scrum when it's done right. There are a lot of Scrum butts out there, we say: "you know, we're using Scrum but" and then they give some reason why it doesn't work for them or how they're twisting it around. To hitch our wagons to an Agile process like Scrum and then move forward with it I think has really benefited us in a lot of ways.

John Ragozzine:   4:49
Yeah, definitely. And it's interesting, too, because both of us had Scrum training  prior to this and to see the organization go kind of whole-hog into it is really interesting. Having run Scrum previously, I self-taught myself as much as I could and then I went through training. and then was going to apply this within the organization that was not running Scrum from top to bottom with team members that may or may not be familiar with some of the Scrum rituals or frameworks, or even like what it is. I feel like, and I was definitely guilty of this many years ago being, not a Scrum skeptic, but stressed out about certain things when thinking about the Scrum framework and I think a lot of that came from the lack of information and a lack of context. Making sure the entire agency here has that context at some level has been really beneficial and has definitely paid itself forward.

Ken Medley:   4:56
When I think about Scrum, though, when I stop and press pause and say, "Why are we doing this as an organization? Why are we all in?" It really came down to one word for me and that was clarity. When I break down every ritual in Scrum, all the artifacts and the outcomes, it comes down to just clarity. Why do we do sprint planning? Well, it's to have clarity to make sure that the entire team knows what's coming into the sprint and what's being asked of us and rallying around sprint goals so that we have clarity there. Why do we do a daily stand up? It's to make sure that we have clarity around how everything is going. Do we need to adjust? Do we have clarity of what's happening? Why do we do backlog refinement? We do backlog refinement so we have clarity around the work that's coming up. Are the tickets well-refined? Do we need more information? Would they be ready to be brought into a sprint? Why do we do a retrospective? We do a retrospective to make sure that we have clarity around how the team is doing. Are there any optimal things that we could do to help us run more, better, faster, smoother, increase velocity. Everything in my mind came back to the simple word of clarity and when everyone has clarity, of course you're going to run faster. Employee satisfaction is going to go up. Hopefully, clients will be more happy with the outcome as well because they want clarity on "how is my project doing?"

John Ragozzine:   6:26
Yeah, I've always related it to, instead of clarity, just data collection points, which is kind of boring and a little impersonal. If you think about it, in your daily stand up you are collecting data on how things are going, are people blocked and making decisions based on those data. But the use of clarity really opens it up a lot more because you're all speaking the same language, which could be tricky sometimes. When you get into things like: "What do you mean by this term that we all know and we all are familiar with?" It could mean different things to different people. What I see, at least through Agile coaching, and some other stuff is the approach to a daily stand up. The daily standup is a meeting so people approach it like a meeting. the meeting goes like: "We're gonna fill in these three blanks. What did I do? What will I do? How are things going? Am I blocked? If you say, we're gonna have a meeting every day with your team, people are gonna riot about it. But when the meeting is structured in a certain way, that word can change its meaning a little bit, and operate a little bit better because they know what that is. We're not having a meeting, we're having a stand up. In fact, we've gone so far on my team to shorten it to "standy." So if I say "standy," they know I'm talking about stand up. Not that the daily stand up meeting that we have. Yeah, exactly. "Refiny" hasn't caught on as much, but "standy" is rolling with it, which is cool, but what I really liked was how you likened this idea of clarity and being on the same page to music, right?

Ken Medley:   8:02
Right? Yes. So I have a musical background, grew up playing drums, guitar, and middle school band all through high school. And then, of course, still jam with my buddies in the garage from time to time.

John Ragozzine:   8:17
But also, your last name is Medley. Yeah, kind of stuck.

Ken Medley:   8:20
Yeah, it's true, I guess I kind of have to be musical. If you think about it, if you ever watch an orchestra perform, there's a conductor. There are multiple different instruments playing. There are violins and cellos and the horn section and percussion. It's really interesting if you sit back and you watch because every one of them is looking at a different piece of music. It's the same song, but they're looking at the music that was written for their particular instrument and Scrum, in my mind, a lot of it is the same. The Scrum Master does something totally different than what the developers do, like the PO does something totally different than the Scrum Master does. However, if we're all going to be on the same sheet of music, if we're all going to play the same song, we've got to be on the same piece of music, right? We have to understand how each instrument or each role fits into this Scrum team. So that was the analogy I was making there. If you could imagine watching an orchestra play where a violinist has no idea how to read music, or no idea what the conductor is telling them; why is this person just waving their hands, what am I supposed to do? Obviously there's chaos but when everybody works together, everybody understands it is on the same sheet of music reading the same piece, that song is gonna be beautiful, right? It's gonna be an amazing thing and I think it's the same with Scrum teams. If we are all in the same piece of music. If we all understand the role that we play then of course, our teams are going to be moving at an awesome pace: velocity will increase, satisfaction will increase. So to take it back to why we do Scrum at Alley, it's one for clarity but also everybody goes through some Scrum Inc. training. Scrum Masters are getting their Scrum Master certifications, regardless, if they had it or not prior to coming to the organization like you said. POs go through certification and even our developers will go through Scrum Team Member training.

John Ragozzine:   10:30
Some of it might seem at face value a little reductive: oh, okay there are different roles, people doing certain things, and I'm aware of it that's cool, but you don't want the string section suddenly picking up the brass, like I'm gonna play this trombone part, you know? But that being said, I think about this a lot. It's akin to, if you ever dig into a football player, for example, and the positions they played in high school and in college, and if they go to the NFL positions they played there. Some athletes will be quarterbacks in college and very good at being quarterbacks, but when it comes to the NFL they'll transition into a wide receiver role or something. Or even like certain plays, like the flea flicker. Is that the one where you hand off somebody, then they pass it back to you, or they will pass the ball? I can't remember. I'm not exactly a sports person. I am from a video game perspective, but not a real life perspective. It may come to the point of "it's a fake!" and now the field goal kicker has to throw a touchdown pass. So knowing nothing of the limits of your role or what is expected of certain aspects of it can allow for dev team members to very much act like a PO when trying to organize a project, or if the Scrum Master's out someone can run stand up and not be totally clueless of what's going on. So it's beyond the what, it's really like the why and what you're trying to achieve at that role. And that's what I think is really interesting to me is you start thinking about other ways folks work together and what that could really mean in the real world.

Ken Medley:   12:06
Yeah. So coming back to Scrum, I think Scrum is set up to do that right. We all go to training, we understand the role of Product Owner and if need be, I could sit in on that role if there was an emergency and the Product Owner had to be out. Or is it okay for a developer to run a stand up? Sure, why not? I think Scrum is set up to do that. In the past I've done several different models: Extreme Programming, SAFe (Scaled Agile Framework), I've done everything down to just cork-board and pieces of paper, just trying to manage projects that way. In my experience, I think Scrum has had the most success across all the organizations that I've worked with and here at Alley. Like you're saying, everybody is versatile in that model.

John Ragozzine:   13:03
Yeah, definitely. I remember a couple years ago, a client stakeholder during a kickoff asked for a RACI document (Responsible, Accountable, Consulting, and Informed), if that's not correct, it's fine. I do have my PMP certification, but clearly RACI is not something that I've internalized too much, but it was important to them. Rather than railing against it being like, "Oh, that's such an old school project management tool that folks want and what does that even mean?" I just mapped Scrum's rolls to a RACI document. What that was helpful on is that when you talk about it being accountable, it wasn't Ken or Liz or Betty or whatever. It was the team, the team, the team and you see where folks are at which removes that "not my job" mentality, which always concerns me when that's the fact. There are things that I cannot do on the team, and I'm perfectly comfortable not knowing how to do certain things. I should be able to understand what people are doing and help them or facilitate a fix if they're out, so getting over that idea of "the SM does that, I don't, so we can't possibly do these things." It's identifying a point person for these things, but not the only person who can do this. But, if folks hadn't gone through the Scrum Team Member training they may not know that they're like "oh the Scrum Master's out, I guess we won't do stand up today." No, that's not the point. The point of stand up is not for this Scrum Master to facilitate a meeting, take notes, then email everyone notes at the end of it. It's to be like: "Okay who has issues that they think they cannot overcome and how can the team help them?" And that does not require any one person to be there.

Ken Medley:   15:02
Yeah, I know. You're right. Exactly. Are we on track to hit our sprint goals? Is there anything you know? Any impediments that we need to remove? That doesn't have to be the Scrum Master's job. Much like someone on our team recently went through their Scrum Team Member training and came back with this ah-ha moment. They said, "Hey, did you know that I could spend up to maybe 10% of my time if I wanted or more on backlog refinement and I'm not even the Product Owner?" I was like, well yeah, get out there. Look at what work is coming up, you get a say in that. They're like, "this is great!" Obviously, there's still work they need to do in the sprint, because they're a developer, but they were pumped to know they're not just stuck just writing lines of code all day. They get a say in the product and they can think about what's coming up and what order might we want to tackle these in? So it's really cool to see how a framework provides clarity and empowers people.

John Ragozzine:   16:01
Yeah, empowerment was where I was going to go next, because it's true. So often there's a little bit of tension when creating tickets, bodies of work, stories, or however you're framing it. The PO is responsible for the product vision, so they have to write really detailed spec-based tickets that are going to explain what we're doing and why and how and all this stuff. Going through Scrum training can help a Scrum Team Member realize that while the PO is supposed to identify the business value or the client value, in our case, it's really up to the entire team to figure out how that translates into something that's working. And it's not like someone grand vision architecting a solution. It's really like they want to be able to do this, like, how do we accomplish this? And there's tension there. You know there's ambiguity there because it does take a lot of time to approach something that way rather than just support that ticket taker or whatever. When it works well it's just really uplifting for the entire team. 

Ken Medley:   17:11
Yeah, one of the things that I really enjoy about the Scrum@Scale model, is this idea of an Executive Action Team. For those who aren't familiar with the Scrum@Scale model: do a quick Google search. You'll find it. And I think it's really awesome because obviously we want to raise impediments up, like if there's a blocker. Hey, I'm stuck. I need help. Those kinds of things. Those aren't failures necessary on the individual, it's just: Hey, I'm learning, I'm growing, or I have a dependency here. You want to raise those things up. And usually I'd say about 90% of the time, the Product Owner or the Scrum Master or someone else on the team can help get them unstuck. But what I really appreciate about the Scrum@Scale model is you have an executive action team. So if there is something above the team: Hey, this thing is not working, or there's a client dependency here. Whatever it is that needs to be raised up, there's a team sort of on standby ready to solve the big problems that you can't. And raising them doesn't mean the team is failing. That is a huge psychological safety net for teams instead of "I can't believe I have to raise this up." And "what am I going to lose my job?" And "I'm nervous. Now I have to go talk to one of the bigwigs here, right?" It's like, "No, the whole purpose is to help get you unstuck."

John Ragozzine:   18:45
Yeah, and it's passing on that clearly that you were talking about. It's making clear what's going on at the team level at a more like organizationally-wide level because, these Executive Action Team (EAT), it's made up of all the partners at Alley, they have complete information from a 30,000 foot view of what's going on with the company, and what's going on with financials, and what's going on with business deals, and things like that. They don't have the day to day minutia of things, which is fine, but with Scrum@Scale we have a Scrum of Scrum of Scrum, which is the meeting of the Scrum Masters and a representative of EAT twice a week and we can escalate things whenever, but we can escalate things there. It's a quick, usually 10 minute call that we'll have. We're able to get the entire company on the same page twice weekly, which has been super valuable. Without that shared foundation of what it's for and what we're trying to achieve and what a blocker really is people would not feel comfortable raising stuff because you're right, there's a fear. If something's not going perfectly smoothly, whose fault is it? Who do we have to change to make this work? Not what do we have to change?

Ken Medley:   19:59
Right. Yeah, very rarely I found is that the Who. Very rarely. If we think about that, it's often easy to blame a who versus address a what because what identifies there's a problem with our process or there's a problem somewhere, and that takes a little bit more time to uncover. But once you do, you've freed up everybody on the team, we've all learned something, and we can share that with one another so other teams don't have that problem in the future. Having an Executive Action Team, folks  at the executive level who are ready to have your back and jump in and help remove roadblocks that you can't, is super empowering and just provides clarity.

John Ragozzine:   20:48
Yeah, and the only were able to kind of get that agency wide, we're somewhere around 75 or 80 people working at Alley, is because all those members of EAT also went to Scrum training. The same Scrum training that I went through and that Ken went through and that everyone who works here, because in the first week that someone's here we have them go through at least Scrum Team Member training, if not something more intense and person. Everyone from the newest person at Alley to one of the founders who are on EAT. Everyone's gone through the same experience and has the same vocabulary of language and the same ideas and visuals and things about what Scrum is supposed to achieve. It doesn't always work like a flawless machine or anything, but we always have stuff to reset with and come back to. Agency wide we have a lot of clarity over what needs to be worried about, what's going well, and how do we make things better? In the twice weekly meeting that we have with EAT, the solutions are not "Okay, I'll go see what I can do." It's like, "all right, I understand that, maybe this would help" and usually a possible solution or next step divines itself. I see outcomes pretty speedily happen as a result of that, rather than "I reported it. Now they're gonna have to wait for their monthly board meeting and then come back and then say this person's fired, because that's really the problem."

Ken Medley:   22:24
Yeah, exactly. A lot of times when you have an impediment to raise, you don't have to wait. You know this model that we're using here at Alley allows us to address problems immediately and remove roadblocks and I don't have to wait for, like you said, a board meeting or let's get the stakeholders together and we'll talk about that. No, we're just going to solve a problem right now. So again, it provides us clarity. It gives us the ability to be Agile. We can make decisions quickly. We can pivot when we need to. It's also a lot of fun to help our clients understand the value of being Agile, specifically in the model with Scrum. So many times I've seen clients come in and say "Wow, this is great. This is happening way faster than we thought it would. This is a way smoother than..." Or "So I got all the information out of this meeting and it's only been a 10 minute stand up? Wow, This is great!" It's cool to see the light bulb go off sometimes.  

Ken Medley:   23:27
Thinking back to the orchestra thing, everybody has sheet music and everyone's watching a conductor, and sometimes in an orchestra there are lots of people there, right? There are tons of people. The thing about Agile is to think about it like a three or five-piece jazz band. Everybody knows the court progression. Everybody knows how many beats per minute they're playing. As long as we know that, now we have the ability to be Agile. I see folks in the crowd nodding their head and getting up and dancing around, so I think "let's freestyle a little bit, people are enjoying this." It gives them the opportunity, that flexibility, to go off the cuff a little bit, and then bring it back down. Maybe people are yawning, they're not engaged. Let's go ahead and wrap this one up. It's not as prescriptive as maybe an orchestra is, but they have the ability to be Agile. They can ad lib a little bit. Scrum is the same way, you know? Yes, we have some guard rails that we use. Yes, we're going to have a stand up. Yes, we're going to have sprint planning. Yes, we're going to have a retrospective. Yes, we're going to do a demo. For the most part, we can be Agile and we can bounce around.

John Ragozzine:   0:00
Yeah, definitely. As long as you're remembering the foundation and that you're going to improv one musician at a time in the jazz example, it's sort of like, "All right, you're going to go, go!" And then it's the beat, it's wild. And folks can do whatever. And folks who are exceptionally good at improvisational music, it's just incredible to me how they can keep the count in their head and still do all this amazing stuff, I could never do it. You know the counterpoint to that? Not the counterpoint, but a side note is way back when I was doing a lot of live theater, I came from the mind set of improvisation and unscripted work. I would sometimes make other actors really mad because I would change slight wordings in lines that were written by someone else, and I wasn't trying do anything, I just felt like this felt more natural--it just felt better. But I was probably being a bad cast member because ideally I should be adhering to what we all agreed upon, which is: these with lines, I know when you say that I'm gonna do this, or whatever it is. I was totally messing people up. The counterpoint to that is in Scrum we're supposed to react and engage in a way that feels most beneficial, the most true or whatever. Once you know what the flexibility is contained within, it's not like: "Hey, we're doing this work. No we're not, we're going to do all this other work instead," it's like: "Oh, this has to change a little bit. Let's have the communication often to make it clear to everybody what's going on and why, and we'll pick it up next sprint."

John Ragozzine:   0:00
With the pandemic that's been going on that we know about it has definitely affected the working priorities of a lot of the clients I work with. Some of the folks are in the healthcare news space or in a scholarly space and all of the sudden, it's like those things that we thought were really important last week are not important anymore, and that's what we need to do and we need to do it quickly and timely. And it could be a real challenge and a real like head spin for the team, but we had processes in place. Everyone knew what the deal was, everyone knew the rules of things. So again, it's not like throwing the entire sprint out the door. It's like "Okay, let's make some swaps" and the better that I can have my clients understand why we're doing what we're doing, you can't just keep shoving tickets into the sprint and expect it's going to be done. There's this work that we already know that we're doing so can we reprioritize things? Can we swap things around? What's the timeline on these things? Giving everybody a shared idea about the rules of stuff. It's not a hard wall like once the sprint starts, you can't do anything. It's more like we know what we have to do, but let's approach it from a place of shared understanding.

Ken Medley:   27:44
At the time of this recording, we're experiencing this pandemic, right? And like you said, a couple weeks ago no one thought "Oh, man, you know, the world's going to change, and we're going to have to have shift priorities." If you were using the waterfall method, you're like "Yep, that's on the books. And maybe we'll get to that feature in a year and half." Well, a year and a half may not be relevant anymore, but we're able to be Agile and say "Okay, let's re-prioritize a backlog based on the needs of the world today." As long as everybody has a shared framework, a shared understanding, and clarity around what we're supposed to do and what needs to happen it gives us the ability to just move forward, be flexible.

John Ragozzine:   28:28
Yeah, nothing in a vacuum. Nothing in black hole. It just brings the stuff out in the open for everybody.

Ken Medley:   28:34
Yeah, I like to say too: "Yes, it brings clarity, but it provides value faster." Which is really what we're after, right?

John Ragozzine:   28:48
That's our show! Thank you so much for listening. Ken, thanks so much for joining me today.

Ken Medley:   28:53
Absolutely! And thank you to our listeners. If you want to learn more about Alley and the cool stuff that we do here, head over Alley.co we'd love to hear from you. What's today's Fibonacci number of the day?

John Ragozzine:   29:05
I'll spin the big wheel. Today's Fibonacci number of the day is: zero.  

John Ragozzine:   29:26
Thank you so much for listening. Take a moment to head over to Alley.co to learn about the work we do and the people we work with. We have a blog. We have other things that are going on, a newsletter. So we would love for you to sign up and say "Hello."