Podcast Ep. 65: Understanding the Scrum@Scale Framework with Michael McGreevy

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 Neumann is joined by his collaborator Sam Falco and special guest, Michael McGreevy. Michael is an enterprise agile coach at Grow Financial and is a Certified Scrum Professional, agile leader and Scrum@Scale practitioner.

A couple of episodes back, Christy Erbeck shared some of her beliefs and understanding around the scaled agile framework (SAFe). That fascinating conversation led hosts Dan and Sam along a journey to discovering other scaling frameworks. So, in today’s episode, they’re continuing their conversation around scaling and taking a look at Scrum@Scale. Michael explains some of the basics of Scrum@Scale and shares his own experiences with the framework, agility and scaling in general within his professional work at Grow Financial.

Listen on Google Play Music


Key Takeaways:

  • Challenges around scaling:
    • It is unique to every organization
    • Too prescriptive of a framework can become its own impediment
  • How these challenges can be addressed:
    • You don’t have to use all of a framework; just what is necessary
  • Benefits to Scrum@Scale/why Grow Financial is using elements of the Scrum@Scale framework:
    • It brings their teams together to get things done more effectively
    • Helps to create transparency throughout the organization
    • It is more simple than other frameworks
    • It introduces concepts for people who might not know how to start scaling
    • Creates complete alignment between all teams
    • Supports information flowing both ways (from the “lowest” teams under the development scale all the way up to the enterprise team)
    • It also supports information flow laterally (i.e. between the software teams and marketing teams)
    • There’s ambiguity with the framework so success can be determined by the teams and enterprise
    • More visibility into what all teams are doing and how it impacts other teams
    • Created more transparency (which is key in transformation as it helps to not let any teams lag behind)
  • Possible challenges with Scrum@Scale:
    • Because the framework is so simple it is somewhat vague and difficult to get right; there isn’t a clear path to success
    • You need to make sure that everyone in the organization is on board and understands it
  • Michael’s advice on scaling:
    • Don’t get too prescriptive with any one framework—give it a try but be willing to adjust aspects of it or be okay with moving on to trying something else



NEW SEGMENT! Listener Q&A:

Q: Janis, a Scrum Master at Fidel (a growing fintech startup from the UK), describes how their company is currently in a fast-growth and global expansion phase where they’re expanding from a single agile team to multiple teams. They ask Dan and Sam to talk about the dilemma of letting developers do code reviews for other teams vs. keeping code reviews inside the team.

A: It’s good that Janis is interested in making sure that the knowledge of the codebase remains strong across the team and that the knowledge does not get fragmented and siloed. However, there are more than two options to explore. Here are some other ways for Janis to have a richer conversation with their team about how they might foster shared knowledge amongst team members as their teams grow: pairing, promiscuous pairing, mob programming, team reviews/inspection/walkthroughs, and unit test automation.


Mentioned in this Episode


Michael McGreevy’s Book Pick:

Transcript [This transcript is auto-generated and not completely accurate in its depiction of the English language or rules of grammar]

Intro [00:02]: 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.

Dan Neumann [00:11]: Welcome to this episode of the Agile Coaches’ Corner. I’m Dan Neumann and today I’m joined by colleague Sam Falco as well as an enterprise agile coach from Grow Financial, Michael McGreevy. So thanks for joining both of you.

Michael McGreevy [00:25]: Oh, you’re welcome. It’s a pleasure to be here.

Sam Falco [00:26]: Always a pleasure always.

Dan Neumann [00:28]: And for folks that have been listening for a bit, Sam and I have been trading off some of the host roles a little bit, so hopefully that’s not too disjointed. Neither of us is planning to go anywhere. But uh, since the theme of this episode is scaling, I guess we’re scaling the podcast a little bit now. We’ve got three people in here. We went from a two person, uh, point to point to now three people. It should be fun or weird. Or both. There’s an intersection of those two. So a couple episodes ago, Christy Erbeck shared some of her understandings or beliefs about the SAFe framework that were dispelled when she went to training. And that led us along a little bit of a journey of other scaling frameworks. And this one will be about Scrum at scale. We’re not going to give people a Scrum at scale tutorial, if you will. So it’s not meant to explain all the parts of Scrum at scale, but to introduce it and maybe talk about some of the reasons it was applied and some of the parts, Michael, you specifically have been exploring, uh, within your professional work.

Michael McGreevy [01:32]: Okay.

Dan Neumann [01:34]: All right. So let’s start, when I went to training for Scrum Master class back in the day, Scrum of Scrums was about the only kind of scaling thing that was introduced. And in my understanding right or wrong, it was about scaling the daily Scrum. And I’m curious, what types of challenges did you run into with scaling? And maybe we can start there and then how you’ve addressed some of those.

Michael McGreevy [01:59]: Okay. Yeah. So when we talked about scaling here at grow, um, part of the reason why it became such a pressing conversation for us is cause it was happening. Um, regardless of what we wanted necessarily to be happening at the time. Uh, agile became very popular around here very quickly and it was faster than we had anticipated. So there were teams that were standing up their own Kanban boards or using their own Scrum. And those of us who were quote unquote responsible for it had no idea what was happening. Um, so it became a matter of how do we bring this all together, uh, so that we have a better overview of what’s going on. Um, we had looked at elements of safe and I am one of those people who admittedly looks at the SAFe framework map and my head explodes. Uh, and I still do. I’m, I’m certified in leading SAFe. And I think that there is, there are elements of SAFe that are, are very good and worthwhile. And I think that there is some genuine interest in being, uh, an agile framework and being flexible within SAFe. But I think it’s very process oriented and it appeals to people who are process oriented people. And, and here at Grow we had that kind of dichotomy going on where we had people that were very process-oriented and looking at safe and saying yes, this is what we need. And then you had me going no. And so I looked at Scrum at scale and said, I think this is what we need. I like simplicity. I like putting it to people and just keeping the framework as simple as possible and letting the individuals figure it out. So I went to get Scrum at scale certified and I had the pleasure of taking the class with Jeff Sutherland. Um, which is one of the reasons why I chose the one I went to cause I wanted to just work with Jeff and it was a great experience and I came back here and we have kind of cobbled together our own sort of thing here at Grow that we’re small relatively speaking in our back office. So for those of you who are listening for a frame of reference, our back office here at headquarters is about 150 to 165 people. From a software development standpoint, we have two teams, uh, basically one large team and one smaller team that’s a support and they’re more of an implementation team. So we are not developing new software and on a regular basis, uh, and we have teams outside of IT that are using it. So we have our marketing team and other departmental teams are using agile framework. So it really became a matter of how do we take all of these teams that are shared services working together on these initiatives and how do we bring them together to get things done more effectively. And that’s where we ended up kind of picking and choosing elements that worked for us out of SAFe, out of Scrum, at scale, uh, to form whatever this odd thing is that we currently have grow at scale, whatever.

Sam Falco [05:24]: I think that’s one of the challenges of any scaling is that too prescriptive of framework, um, becomes its own impediment. Uh, scaling challenges are in large part unique to every organization. And so one of the reasons I have the same, I had the same response that you had Michael. Well, the first time I saw the SAFe diagram and that’s what’s back in SAFe 3.0 was, Oh my God, that’s a lot. Uh, and, and how would you use all of it? And obviously you don’t use all of it, you use what is necessary. But I, I like the way Scrum at scale introduces some concepts for people who might not know how to start scaling. So we talked about the Scrum of Scrums and like Dan, when I was introduced to the concept, it was just a two or three times a week or as many times a week as you needed meeting of Scrum Masters to discuss impediments that everybody was having. And in Scrum at scale it says, no, this Scrum of Scrums actually operates as a Scrum team of its own so that you can do more than just raise impediments but actually make progress on them as its own sort of complex knowledge domain problem.

Michael McGreevy [06:41]: Yes. And I, and I think that here what, where I really kind of keyed in to Scrum at scale and why I liked it. Uh, and I like that the idea behind it is I stood up in front of our executive team, uh, two and a half, almost three years ago I think. And I said, my ultimate goal is to get this team of individuals doing a 15 minute daily standup and getting value out of it. Like that was my key. Like I would love for all of the C suite people to do a 15 minute daily standup and really get value out of having that standup, which meant that at the time there was no way I could say just start having a daily standup because there was nothing supporting that. There was no up and down of information where that would be worthwhile. And I think that for me that seems to be kind of the ultimate goal of Scrum at scale is what was, um, first time I was introduced to it, I think it was Sutherland, it was a keynote at one of the conferences where he said, imagine a world where your work environment every day within 45 minutes to an hour from the lowest lowest team under the development scale, all the way up to your enterprise team. You’re in complete alignment every day. That you’re having these meetings and all these development teams get together and then somebody from that team goes up to the next level and they have a meeting and then if it necessary, if you’ve got another level, they go up that next level and it’s going up. And then you have the ability to take things back down as necessary within the course of a day instead of having to wait for all of this bureaucracy to get in, in, in between it. And that’s where I was like, I love that concept. I love that idea of let’s just talk every day and see what can we do together to help on the most important stuff we’re doing as an organization.

Dan Neumann [08:32]: I wanted to follow that thread. You were talking about the information up and down. A lot of times alignment is thought of as the people at the top set, the, the vision, the goals, et cetera and then that cascades down. But what that misses is the people. Um, yeah and again I need to come up with a better term than bottom, but the people who are more directly engaged delivering the increment the work, we need a way for that information to flow up cause they have this ground truth, reality that’s often very different than the perspective of the C suite. And so needing the information to support that conversation flowing both ways I think is valuable. And I was curious Michael, with the description of the Scrums and then the information going up, how do we make sure that information is flowing both ways? Cause I feel like the daily Scrum of a team and then a Scrum of Scrums may be above that, if you will, or a consolidated one, I feel like that could easily turn into just a report that it’s going up and up and up as opposed to a coordination and alignment creating activity. How have you, how have you helped make sure that it’s not just reporting up, up, up?

Michael McGreevy [09:47]: Well, I think that’s one of those situations where you, you really kind of have to constantly be coaching those individuals to say, okay, well once it gets up here, it doesn’t stop. Like we have the rituals, but you have the ability to go through and you know, talk outside of them if necessary. You know, I think we sometimes get caught into that just like, well, if it doesn’t happen in the standup, I can’t talk to my team again for another 24 hours because the standup is tomorrow. Well, no. You know, you have to have that follow up and you have to have, I think that in most situations, especially as it’s going up, ideally it should kind of be, well here’s just the updates on things that are going on and we don’t necessarily need help. You know, we don’t necessarily need anything that’s going on, but here’s, here’s the current status of the situation. Are we still, this is what we’re intending to do and are we still on the right path? Let’s take the Marquet, uh, Marquette, Marquet, um, you know, team of teams. Like this is our intention. Here’s what’s going on and here’s how you can help us do what’s going on. And if there’s something where you have to intervene, cool. But if not, you’re just kind of getting that flow. So I, I see it more as a flow of information up and just kind of head nodding and yep, you’re, we, we got your intention that you’re good. But on the other side where I see the power of the Scrum of Scrums is that impediment removal. Like if you’ve got a team that’s really good at impediment removal and that starts on the delivery team and you mentioned earlier, bottom, I don’t like that either, but we put the, the the folks that are closest to the work, so if they’re really good at identifying actual impediments and voicing them and talking about them in their, their daily Scrums, then that goes up, okay, we can’t solve this. We’ve tried to solve this in our daily Scrum. Now I’m going to take this out of there and I’m going to go to my Scrum of Scrums and say, Hey everybody, here’s an impediment that we’ve run into that we can’t fix on our team. Can we do it in this group? No, we can’t. Okay, now we’ve got another level to go up. So you have that escalation standpoint where within the course of the day, if you’ve got an impediment that however many levels of teams that you have in your organization can’t fix, you’ve got the C suite at the end of it going, okay, you are the most powerful people in this organization. How can you help us remove these impediments? What can you do? Can you write a check? Can you do whatever it is that you need to do all the way up at the top level or just say, you know what, it’s okay that you have that impediment. Deal with it.

Sam Falco [12:15]: All right. So that is interesting with the up and down flow of information, again for lack of a better term, uh, from top to bottom and back again. But what about sort of lateral communication? So you said earlier that in addition to software teams you’ve got marketing teams working with you. How does that information flow and what does an increment look like when you have non technical teams or non software teams working alongside the software teams?

Michael McGreevy [12:46]: Sure, we have. So not only do we have marketing, we have just about every quote unquote delivery team/department within our organization is using some form of agile, uh, be, it just Kanbans be it just part of our, what in the safe world would be released forecasting or your meta Scrum kind of get together where all the Product Owners get together and they plan out the work. Um, everyone’s kind of using it to some level. We deal with that in release forecasting, we call it here where we have all of the Product Owners get together with the enterprise level initiatives where, so we have a top level portfolio board where we have the most important initiatives in the organization that, and we kind of have a loose definition on what qualifies something to get on this board, but it’s generally, it’s either impact from our member impact or cost or impact from a, this will impact a number of delivery teams and needs to be prioritized accordingly because we also let our Product Owners, like not everything has to go through this board and there’s things that you do and then you just do them and we don’t need to micromanage everything, but if we’ve got stuff that we need to get done and that’s an enterprise priority, we’re going to put it on this board, prioritize it, and then give it to the Product Owners or the people who were filling that sort of role within their teams to figure out. So they get together on release forecasting and they go, okay everyone, let’s take a look at this thing that the VPs ABPs and executives have asked us to do what’s actually involved in this, who’s involved, what groups are going to do work, what groups just need to be informed in case something goes wrong or their resources need to be available. And they kind of plan out, okay, we can start working on this during this time frame and Hey, if we’ve got a dependency on you, okay, we’re going to work on it here and then we’ll be able to have what you need at this point. And so generally speaking, all of our teams that are doing that are working within a two week Sprint cycle, um, simply because it’s easier to coordinate, uh, to say, okay, over the course of the next two weeks, here’s what our teams are going to be working on. Uh, and here’s what you’re going to be working on. And so we’ve all got that same common language where we all say Sprints. So at Grow a Sprint means two weeks. Like that’s one of the things that we have kind of just solidified to say if you’re using the term Sprint, you’re using a two week. Even if in say our marketing team, one of the ways that they have kind of adapted Scrum and made it their own over the several years that they’ve been doing it, they do a review every two Sprints, so technically they’re kind of on a four week Sprint but they still use a two week planning cycle even though they wrap it all up and they do a review in four weeks and that’s, that was a very conscious choice on our part just so we had that common language so that you didn’t have that lag in being able to say, okay, that’s in two Sprints. Okay. What does that mean? Again, is that four weeks or is that six weeks because this other team is involved? Is it just if we say two Sprints, we mean four weeks. So yeah they get together in that, that release forecasting meeting and we kind of have a Product Owner who runs that and coordinates with all the Product Owners and then they leave it to each individual team to go through and size it, break it up as much as they need to or don’t. But they come back to that release forecast and say, okay, here’s how things are going and here’s how we’re working out this map, this roadmap of the work that we need to deliver to the team, to the enterprise.

Dan Neumann [16:36]: Okay. And we’ll post a link to the Scrum at scale PDF. Much like the Scrum guide is pretty thin. The Scrum at scale framework document is also quite thin, so we’ll, we’ll put a link to that so people can see what I’m about to describe. But the Scrum at scale has a Product Owner cycle kind of iterating clockwise on one side of the diagram and then a Scrum Master cycle iterating counterclockwise on the other and they kind of mesh in the middle like gears might mesh. And it sounded like what you were describing was the Product Owner cycle from vision to backlog prioritization, refinement to release planning, kind of those activities being important to aligning all your different teams there at Grow Financial. Could you give an example of what an increment might look like for somebody, let’s say in a marketing team or another service type of team? Uh, when they do their Sprint review? Like what, what would an increment look like?

Michael McGreevy [17:34]: So because of the fact that we, uh, have so many of our teams, our shared services teams, it’s kind of a hodgepodge. We do have one team, they’re currently on a pause, uh, but we have one team that is a dedicated functional cross departmental team that works on essentially a single product and delivering on a single product product in our environment. Being a very nebulous term product could mean an OKR or product could mean a specific year delivering this product or product could you know, it, it just depends on whatever that thing is at the time. They’d been repurposed a couple of times, but they are focused on that. So when they show their increments, it’s very much like a Sprint review because like what you would imagine we’re talking about this one product, here’s the things that we’ve delivered on this product and how we’re moving it forward and what you can use now. So that’s that team. Everybody else is just kind of, okay, here’s what we worked on for this particular initiative and here’s what we worked on for this initiative and here’s where we coordinate up. Um, it’s one of the places where a, unfortunately a lot of our reviews are still very dog and pony show because of that, you know? Uh, but we work on it and there’s, that’s one of those things whereas a Scrum Master, as the coach for the enterprise, I might challenge on occasion I might say, how do you get more interactive? How do you put something into people’s hands? How do you make it less of a dog and pony show? But I have to step back and say, at the end of the day, if the team is getting value out of it and the people who are going to the review are getting value out of it and they think it’s a good meeting and they have good questions and they walk away from it. Okay. And then it’s not, you know, then I step back from that at that point and say, you, you do what is working for you as a team and what your stakeholders are getting value out of. Um, so yeah, I mean it can be, uh, showing video like, because one of our teams that uses this is our property administration department. So I mean, you’re a very traditional waterfall construction essentially is what these do. I mean, they coordinate with a lot of contracts and it’s really working with a whole bunch of third party. But they’ll get up in their Sprint review and say, okay, here’s this thing we’re trying to fix. Here’s a picture of the before, here’s a picture of the after, you know, here’s what we did throughout, here’s our progress with the contract and where things are going, where we’ve run into road bumps with the contract and why maybe we’ve decided to switch to another vendor or something like that. Here’s video we shot of the external of our headquarters with a drone so you can see the, what we did a, we had a major project where we did the whole external got pressured cleaned and sealed. So they took drone video to show before and after and they showed that in their Sprint review. So yeah, I mean it’s, it’s just kind of, um, I say it’s, it’s a little bit more report card than, than I would say really like, but people get value out of them and they like them.

Dan Neumann [20:32]: Well and I like what you’re describing from a experimenting into what the review would look like. So yeah, not everybody’s going to go to all your branches. Some of them are under construction, some of them are far away, et cetera, et cetera. And so you’re bringing the visual, not just a PowerPoint says, you know, we built this, you know, building at X, Y, Z. You’re, you’re going beyond the the PowerPoint review.

Dan Neumann [20:53]: During our weekly podcast episode, we invite listeners to emails us at podcast@agilethought.com or tweet to us using the hashtag #AgileThoughtPodcast and we ask them to send us any questions or comments they might have so our viewers might communicate back to us in forms of upcoming episodes and at times we’ve weaved responses into existing planned content. We have an inventory of episodes queued up for production and release and making a new episode based on a question would mean waiting a couple months for that one to come out and be released. And we wanted to make sure to keep a short feedback loop and be more responsive to folks who have questions in that. To that end where weaving a segment into this episode. Here’s a question we received: Yannis who is a Scrum Master at Fidel sent us an email and explained that Fidel is a fast growing FinTech startup from the U.K. And they provide card linking for loyalty programs. They’re in it, this fast growth global expansion phase and moving from a single team to multiple agile teams. Their concern is who does code reviews within the teams. Currently they’ve had one team, they’re done within the team and now they’re going to grow and split into multiple product teams. And Yannis was hoping to keep the team stable and build velocity measures. Yet code reviews have been a really important and ideal mechanism for spreading knowledge about all the technical details of the different products that the developers are working on. And so this team now has the dilemma where do they continue to have the developers do code reviews for other teams or do you keep the code reviews inside the team? And I really appreciate Yannis that you’re interested in making sure that the knowledge of the code base remains strong across and within the teams and that it doesn’t become fragmented or siloed. This either/or scenario that you mentioned reminds me of something I learned when I was reading the book, Crucial Conversations by Kerry Patterson and their coauthors. What the authors referred to this type of situation where you’ve only got the two options as a fool’s choice. And I’m not implying that you’re a fool, it’s just that the term for ending up in this trap where it’s this one option or the other option is what they call a fool’s choice. One person’s idea has to win and the other person’s idea has to lose. There’s almost always additional options to explore and here are some ways that crossed my mind for trying to make sure that you and your teams can have a rich conversation about how to foster shared knowledge amongst the team members and make sure that you don’t end up with silos. So I’ve got a handful of ideas here and I’ll go them fairly quickly. Pair programming is the first idea that came to mind. So a scenario where you have a navigator and a driver and much like a road rally in the car where one person’s working the steering wheel and the gas pedal and the other person is looking at a map and the terrain and doing a wider view of where everybody’s going. Both the roles are critical and in software pairing one person is sharing information about what to program and the other person is interacting with the computer and coding what the navigator is sharing. Now this role rotates so each person should be taking turns as a navigator and then the driver and back again but both end up with a shared experience in the code. So that’s a very kind of focused way of sharing. So those people then have common understanding. The next notion is promiscuous pairing. So encouraging an environment where people are rotating their pairs and it’s not a longterm commitment to pair with one person. You want to pair with different people perhaps on different product backlog items or rotating on some other type of cadence, but really encouraging the team to self organize and find different ways of rotating who they collaborate with to share that knowledge. Now back in episode 45, I had Chris Lucian on as a guest and that’s the third approach that comes to mind, which is mob programming. So Chris is a cofounder of the mob programming approach. He was there, um, at the same location where Woody Zuill was. And, and those folks have done a lot of sharing about mobbing. And mobbing is where the whole team works on a product backlog item together. So if you’re in an organization that felt like pairing is radical, then this will definitely feel like a very radical or foreign notion. But it might be something to experiment. Take a backlog item or a time slice of the week and have the team work together to develop an increment of value. One of your product backlog items. So now we’re kind of building up from pairing to promiscuous pairing, maybe mob programming. And another option then that comes to mind would be not creating a gate for code to have to go through, which could slow down the team’s ability to turn out awesome new features. But find a way to do code reviews or inspections or walkthroughs as a group. And by doing that, you’re building familiarity with the code base and you’re not becoming another gate before things can get checked in and delivered. So make sure that these don’t become stale. And if you’re doing them at lunchtime, I’d highly encourage you to feed the teams and try and find a way to make the review inspection, walk through, whatever you want to call it, try and make it fun for the team. And the last idea that came across my mind was to really look at the degree to which you have unit tests and test automation supporting your ability to change the code. So some people will do test driven development where you write a failing test, you make it pass and then as necessary you do a refactor. And what I love about test automation and specifically TDD is it gives the development team really instant feedback when they’ve made a code change and it’s not doing what they wanted it to or they’ve broken something else unintentionally. And this automated failing test creates a huge safety net and lowers the risk of changing code that you might not be familiar with. So I hope those ideas are helpful. Thanks for listening, Yannis, and thank you for contacting us with the question for other listeners, if you have a question, please send it to us via email podcast@agilethought.com or tweet it to us with the #AgileThoughtPodcast. Thanks for listening.

Intermission [27:45]: Have topics you want us to tackle, send an email to podcast@agilethought.com or tweet it with the hashtag agile thought podcast.

Sam Falco [27:56]: I also love, you said it twice now that you want to make sure people are getting value out of it and so that the focus of your practice of agility is about making sure that we get value out of the activities we’re doing. Um, earlier you said that one of the reasons that you had to start looking at scaling frameworks was because it was already happening regardless of whether you wanted that to happen and it was happening faster. And I think that resonated with me because I’ve seen that at other organizations and I’m wondering how your scaling choices have affected that. Are things still happening? Are you that that you weren’t expecting or happening faster than you expected or has this given you an ability to get out ahead of things a little more?

Michael McGreevy [28:48]: I think it absolutely has. And I think that one of the common threats from business leaders all throughout where when they look at a,nd some folks here still aren’t entirely on board with all that fancy agile stuff that we’re doing and you know, but one thing that is consistent through almost every leader and department that we talk to is I know what’s going on now. I have visibility into what other teams are doing, how it impacts my team. Um, and they love that. And some of that is very process. Plan view Lean Kit is our product. And so we have electronic boards and just about every team has their board for their team and they all tie up and we can show those connections electronically and say, okay, here’s what’s going on on my board. So for the more process and technical oriented folks, they love that. They love being able to get their visualization and here’s what’s going on. And, and honestly, that’s something that really was a big selling point for our new CEO who was our executive vice president when we started our transformation. He absolutely loved the fact that he could walk into IT and CR at the time, physical boards and just look at it and see like, okay, that’s what’s going on and not have to bother anybody and not have to ask what, what they were working on. Or if he did, he would come from a more informed place to be like, well, I saw this thing but I don’t know anything about it. What’s, what’s happening with that. So that’s, that’s been a big win for us as an organization. Just having that, that visibility. And that’s, that’s been a big catch for us in our transformation. They wanted to be part of that. Like that’s where with our property administration department, the vice president over at that team said to me a couple of years ago, this is happening and I see this happening throughout the organization and I don’t want my team to lag behind it. I want us to be part of it. I want us to be involved and not trying to play catch up. Uh, so he’s got two folks down in his group. Um, who, you know, acting Product Owner and acting Scrum Master. We’re, we’re struggling with that question a lot. You know, the are you a dedicated Scrum Master and Product Owner? Are you a manager who fulfills those duties? That’s, that’s, that’s an issue that we’re tackling constantly around here. So, but I mean it’s, people are at least doing it. We have so many people certified here in some level of Product Owner or Scrum Master or they’ve gone to a Kanban class or whatnot. Lots of business units have, have spent their own budgeted dollars to send their people to trainings.

Dan Neumann [31:33]: You mentioned the use the words visualization and that for me went back to the pure pillars of the Scrum framework, transparency, inspection, adaptation. And without that transparency or the visualization, you can’t do the other things effectively. And so that really stood out and people see that in the Scrum at scale document as well.

Michael McGreevy [31:55]: Yeah, there’s very little these days that goes on that isn’t visible somewhere. I mean we even have a section of our, our enterprise level board that is called visibility. Like we’re not prioritizing this. This isn’t an enterprise level initiative, but Hey, if you’ve got something going on to the other departments know about, just throw a card up here just, just so we’re aware of it. We put like major upgrades to our core product, uh, go there. You know, nobody outside of IT is really involved in that, but it’s kind of a big deal every time we have an upgrade to our core. So that’s up there. We’re doing a disaster recovery plan that’s up there. You know, it’s, it’s a big deal. It just doesn’t necessarily impact out of, uh, one group. But now we’ve got a place where we can share that information throughout the enterprise.

Dan Neumann [32:39]: So you’re talking about the LeanKit and the, the electronic boards. Do you still have physical boards?

Michael McGreevy [32:45]: A few of our teams do. Uh, we have one of our support teams in our deposit services group uses, uh, they have a physical board where they follow a Kanban for tasks. The 90% of the work, pretty much that they do is a daily, weekly, monthly. Here’s just things that have to be done. So they use a common bond to monitor that flow and to work with each other to get those things done. For the most part, all of our delivery teams are using electronic boards because we’re trying to be more distributed. Uh, we’re trying to be more remote friendly. And one of the things that we learned early on was that maintaining a physical board and an electronic board at the same time is a giant pain, uh, and more work than it is usually worth. So the one board that is 100%, both physical and electronic that we still have is our enterprise level board, uh, because we have a very large physical board in one of our meeting rooms. Uh, and that’s just one of those people can walk in and I can see what’s going on and I don’t have to log in to anything. And, and just having a board up on a screen is just not pretty. We had having this, you know, we can, we can have fun with the physical board, but we maintain that one physically and electronically. So I think as far as I’m aware, there is one board here, uh, at grow that is 100% physical and everything else is either electronic or a hybrid of the both.

Sam Falco [34:12]: Okay. Now I know grow, does agile tours, um, for the community, uh, or, or a privately scheduled? Uh, so what do you show them?

Michael McGreevy [34:25]: I show what they want to see. Uh, I really try to, we generally, we will start up at our enterprise board and I’ll give a, you know, the 500 foot overview of us as a credit union. Uh, the fact that we’re not for profit, our history, uh, why we decided to join in to the agile revolution, if you were, uh, why it was important to us to be, have more business agility, uh, and kind of go through our journey. But then I turn it over to the group and I’m like, where, where’s your focus? Uh, do you want to talk about portfolio level questions? And we could just stay here in this room for the next hour and I can answer your questions about our scaling and what we do on portfolio or do you want to see our, um, um, you know, teams that are using it outside of IT. Do you want to see our traditional quote unquote IT folks, um, together? Uh, so I really try and gear it towards the folks that are in the room at the time. Again, Sam, you caught on caught on it earlier. I’m very big on getting value out of what it is that I bring to people. I don’t want to waste anybody’s time. That, that has been a huge part of my motivation for becoming the agile leader that I have is that as a developer and as a manager coming up in the software development world, I felt that a lot of traditional project management activities were just a monumental waste of my time. I had better things to do than to sit in a room and wait for my turn to say that I was 75% done with my task. Um, so once I got into that world, and that’s kind of the irony behind it, like I was the worst meeting person just ever, I was terrible. And I, now that I’m in the role where I’m hosting a lot of meetings and facilitating them and part of it, like I look back on the way that I was and I’m like, I was a terrible jerk and I owe a whole bunch of people apologies. But you know, it is what it is. Uh, now that I’m kinda in that world, I constantly tell people, if I’m not doing something that’s bringing you value, please tell me, please, please let me know. Give me an opportunity to try and make it worthwhile. And if ultimately it just doesn’t work out, we’ll get rid of it. Um, when I went in and I spent a little over a year with the marketing department fully embedded with them as a Scrum Master full time. And for one period when they didn’t have a Product Owner, I was Scrum Master and Product Owner. And like early on they were like, daily stand ups are a joke. Why are we doing this? We have an open space. We all sit together, we talk all day long. We don’t need to have these standups. This is dumb. We shouldn’t do this. And I said, okay, give me two months. Like this is part of the framework. I’m trying to teach you the framework and if after two months you still come to me and say, we shouldn’t be doing this, we’ll change it or we’ll get rid of it. They still do daily stand ups today. So, you know, but I really had to give them that. They had to trust that I was serious about that and that I would, if it ultimately said standups aren’t going to happen, then I would go to their boss and say they’re not doing standups anymore. And here’s why. Um, so yeah, that’s, that’s a big thing for me. I really want to make sure that I’m bringing value to the, the organization and the teams and the individuals that I’m working with.

Dan Neumann [37:48]: That’s outstanding. Yeah. Show, show them what they want to see and don’t waste their time can go a long way. Michael, we’ve explored a lot of different facets of Scrum at scale and we’ve kind of wandered into some other areas of agility. And I was curious, what else do you think people may ought to know about Scrum at scale and why you folks are using some elements of that?

Michael McGreevy [38:11]: Well, I think that you mentioned it earlier, Dan, that if you look at the Scrum guide, uh, and, and if you look at the Scrum at scale guide, they’re very thin. They’re, they’re quick reads. You can read them half hour, hour maybe at most if you’re really spending time and taking notes. Um, and one of the things that you hear all the time about Scrum is that it’s very simple, but it’s difficult to get right. Uh, and, and I think that that’s, that’s accurate and they even say with Scrum at scale, before you scale up, you need to scale down. You need to make sure that you’re doing Scrum really well and that your teams all understand it. Um, but that’s a nebulous thing. Like what does it mean to be doing it right? What does success look like? And I think that that’s what makes Scrum at scale a little bit more challenging and maybe harder for people or for enterprises to look at because there really isn’t this clear path to success. But if you look at a SAFe, they literally give you a clear path to success. They give you a roadmap that says if you follow all of these steps, you’re going to be doing SAFe and you need to get all these certifications and here’s all the things and here’s all the stuff that you need to do. We’re Scrum at scale basically says, Hey, get good at Scrum and then make more teams use Scrum. And that can be a challenge. It’s been a challenge here. You know when you have your process-oriented people, you have your, your folks who are maybe not so good with ambiguity or, or, or not so good with having kind of open goals or you don’t know what success is gonna look like. SAFe gives you what success is going to look like. I mean there’s 100%. You can look at that SAFe model and whatever level you go to, they have the four different levels. So we say, okay, this level fits with our enterprise. Here’s all the things that we need to do. Here’s the roles that we need to have, here’s the ceremonies and then we, yay, we win. Like if we’re doing this, where Scrum at scale is just kind of like, eh, do Scrum good. Okay. Do more Scrum. Good. Um, all right. You know, so, and, and so for me, I like that. I love that ambiguity. I love the fact that success can be determined by the team and by the enterprise and that it’s really open ended like that, but that’s going to be a hard pill for some people to swallow.

Sam Falco [40:29]: Yeah. And I think we’re going to find, uh, some similar sentiments expressed when we do, uh, cover nexus in our next podcast. Um, so Michael, you have said repeatedly how much you like to provide value and make sure people are getting value and you have certainly provided value on this podcast today. So thank you for that. What we like to do at the end of our episodes is talk about continuous learning. What are you reading or listening to or otherwise doing to further your personal education?

Michael McGreevy [41:02]: Well, right now, uh, I just kind of agreed. Again, it’s when I look at my life and I’m like, what? Um, there’s a group of local members of PMI who are working together to study for the PNP. Uh, so I’ve kind of decided to join up in that group and see, uh, what I can do about getting my PMP. Uh, not that I want it, but I just want to have it, you know, it’s a weird thing like I am, I’m not you know, but it’s just one of the things that like, I feel, it’s imperative for me to constantly be looking at things that don’t necessarily quote unquote agree with my understanding of stuff so that I can, uh, so I understand where other people are coming from. Uh, my former boss, uh, Brad Sears, who just retired, he emphasized that to me a lot. He, he said, you know, if you have something, you’re, you’re big on agile and you love this agile stuff, but do you ever go out and look at criticisms of agile? Do you go and, and find the problems? Do you look at the other side? Do you understand the value of waterfall and why maybe some people would want a waterfall environment versus agile. So for me, that’s kind of one of the things about the PNP is to say, okay, I want people to know that I’m just not the agile guy that I get where the other folks are coming from and that I’m trying to bridge the gap in that understanding. Of course, the other part of that is that, uh, my understanding is the test is changing in July and it’s going to be more agile related. So maybe I should wait until July and get it then. I don’t know. Um, so yeah, so I mean that, and then, uh, the best agile related book that I’ve read recently, and I’m sure it’s not anything new, it’s, it’s Age of Agile, Dennings uh, I love that book. Uh, I, I, I’ve got my CEO to read it. Um, and I think his criticism was, was very much one of the things I’ve heard that it’s very slow to start. Like he, he had a hard time getting into it, but then it got to the meat and he, he got much more value out of it. Um, but I, I love that book. And what I love about it and where it kind of ties into the conversation that we’re having is that like Danning points out that all of the big organizations that are agile and they’re famous for being agile aren’t necessarily following a framework or they’re following one that they made up on their own. Uh, and that’s what we’re doing. And I think that’s important in all this is to just, it’s that prescriptive side, Dan, we’re, we’re, you know, you just can’t take it and say, if we do this, we’re going to succeed. There’s going to be stuff that isn’t working for your group. Give it a try, but be willing to just say, okay, we’ve given this an honest shot and it doesn’t fit our environment. What else can we do?

Sam Falco [43:54]: So SAFe actually does talk about that apply systems thinking.

Dan Neumann [43:58]: And then it’s up to the people using it to actually apply the systems thinking so. Well Michael, thank you very much for your time and Sam as well. Yeah, I think it was nice to have kind of the three, three different voices and perspectives and um, Age of Agile is certainly, uh, one of those books that has come up and duplicates are allowed on our list. It kind of helps people here where here, where folks are going. So, um, thanks again Michael and I’ll look forward to taking tour of Grow at some point. It’s been awhile since I went through there.

Michael McGreevy [44:34]: I look forward to it.

Dan Neumann [44:35]: All right, thanks folks.

Outro [44:38]: 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 from this episode and other episodes at agilethought.com/podcast.

Stay Up-To-Date