How can you rapidly deliver value to your clients/community? In this episode, Aarron Szalacinski, Director of Engineering, describes how Foundant Technologies uses the Agile framework - and how this methodology could be valuable for the philanthropic sector.

Aarron Szalacinski, Director of Engineering | Foundant Technologies

Aarron is proficient in Domain Driven Design principles, Software Documentation, Web Applications, Micro Service Architecture and Agile Methodologies. An extroverted people person who is always looking for the opportunity to coach and manage team members to maximize their potential and bring value to an organization.

He is a detail-oriented software engineer and leader who is an expert in collaborating with companies to architect full-stack applications and the teams that build them. Aarron's job is to help maximize revenue potential and deliver business value.

Topics:

1. Agile work methodologies
2. Value mindset
3. Daily standups
4. Monotasking

Links:

• Compass: Connect with other members of the philanthropic community at Community.foundant.com
• Webinars: register here
• Social: Follow Foundant Technologies on Facebook, Linkedin, Twitter, and Instagram
• Website: Foundant.com

We practice what's called the scaled Agile framework from the Board of Directors down to our executive leadership team, down to the middle management, all the way down to individuals were all aligned to a strategy to accomplish what we think is going to be best for our customers.

Hello everyone, and welcome to the Connected Philanthropy Podcast. My name's Rachel Myers. I'm guest hosting a few episodes while we dig into how we can all work smarter, not harder as we move into 2023. So we've covered a few different topics so far. We've talked about time management, we've talked about prioritization. Today we are taking a look at how to actually get the work done.

So it's great to create space for working. It's great to prioritize the work, but then at some point we actually have to get the work done. And so we have a special guest with us. We're very fortunate to have Aarron Szalacinski who works at Foundant. And Aaron is also not just the director of engineering, but also an expert in the Agile approach to getting work done.

And he's going to tell us so much more about that, which I'm excited about, because it's something I'd love to learn more about. And it's a it's a very common approach for a lot of tech companies, but also other companies who are adapting the strategy. So that's kind of where we're going to do our deep dive today. Before I have Aaron introduce himself more fully, I want to just quickly introduce myself.

If we haven't crossed paths before, I have been working in the nonprofit and philanthropic sector for the past 24 years. I was an executive director for 12 years. I worked at my local community foundation for nine years I've been a board member, am a donor, and for the past little over a year, I have been consulting with nonprofits and other organizations.

So I know how tricky it can be to move those key projects forward when you're sitting in the in an organization surrounded by competing priorities. So that's really the that was the inspiration for this whole work Smarter, not harder Content series is to help us all because we're all learners, sort out how we can create this space and using the tools and tips and approaches that make the most sense for us to get our important work done because we know how important the work is that all of you listening are doing.

So thank you for that. Erin, Will you please tell us a little bit about yourself and how you ended up in the role you have at Foundant.

Hey, Rachel, thanks for having me. How I wound up here, went to school for Fine Arts. I got a background in graphic design, and that led to working for Adebisi, who needed someone to build websites. This is 1999. And so that was like, All right, that sounds like a cool job, know? And I kind of just fell back into into the software development industry, but learned enough skill sets and this is back before Google, Yahoo!

And some message boards about all you had to search.

I remember in 1999.

When you had to actually use books to research and learn, right? I couldn't just go. Everything I had done enough skill sets, learned how to be really dangerous at my job in software development at the time. And within 30 minutes of Monster.com got a call from a recruiter. You have a great skill we’re gonna pay you, you know ,of market.

And by the way, it's with Disney. Are you are you interested? Absolutely. Heck yeah. So guy who doesn't have any background and you're going to go out for Disney. So and I'll only bring that up because when I was at Disney, I wore many hats there too. I want to be developer. You got to be a project manager, got to, you know, product management didn't exist at the time, but get to be a team.

Lead eventually wound up up getting to the operations management position. But when I was a team lead, I started reading this book on on what was called Agile delivery practices in about 2005, 2006, 2007 is when Agile started coming about. And so I delivered. I delivered at this time like this, no big deal and you hear about it but like Disney's online check in was a big deal by being able to check into your resorts online without having to go to the front desk was a big deal.

So I helped land that first iteration of that feature for the Disney, the Walt Disney World Parks and Resorts. And it was behind schedule. It was like six months like it had been passed around, like it was the project going on for eight months had been handed off to six different project managers and they find Aaron, Hey, we're missing a lead again, fix this.

I'm like, okay. so, I just read the book. You had moved from project manager back into engineering, and so the team was like four or five engineers. Like we're going to use Agile to fix this. And one of the team of senior team members were like, Oh yeah, I've heard about that. Let's do it. So broke it, you know, following the best practices which we'll get into and we're able to actually we and we only had like three months get this wrapped up a project on eight months.

We had three months way behind schedule and pressure. But using those practices, we were able to manage the scope and deliver on time and deliver on budget. So I was like, All right, there's something legitimately here.

Yes, that's amazing. Agile. So I was pronouncing I knew so little about it. I was even pronouncing it wrong. So it's agile. Okay, Now I like.

My southerness so.

Is that your southerness? okay.

Agile.

Agile as All right, we'll get to the bottom of this is the burning question for the podcast. Just kidding. So yeah, I'm super excited to learn more about and I know you are going to share lots of insight about, about Agile/Agile and I know that a lot of the folks listening are thinking that like I noticed that.

So many times it would just the momentum piece of keeping. So like you were saying, like you only had three months when you were given this project and in some ways maybe that I mean, I'm sure it was very stressful, but it's almost a blessing to be like, okay, this is the time we have. We have to deliver by this date.

And when I felt a lot of times and I still sometimes struggle with this for sure is like all these different things are happening, making progress in a timely way, like keeping that momentum going. So I'm super excited to hear about that piece along with and I'm sure lots of other folks would love to hear sort of like the I guess what I'm the question for you is like when you think about the challenges that many teams face, how do you feel?

Agile sort of addresses those challenges and helps helps to mitigate some of those?

Yeah. I mean, it's it's about getting work done. There's multiple methodologies. But the easiest way to sum up you've got what your your traditional waterfall methodology and you've got your know and then you've got these, these agile methodologies that come about in the last they've been around for 40 years, right? The car industry has been doing it for a long time.

Toyota's they pioneered it and that's a whole historical discussion we get into. It comes down to two factors How critical is a final deliverable and how much change you're expecting to affect that final deliverable. So you're in the middle of developing whatever that final deliverable is. If you know for a fact that there's been no no changes coming in, what there's inputs and outputs, you don't have inputs coming in to to alter the specification of what you're trying to do.

Waterfall, work, Waterfall. Very handy in that regard. However, if you're very much in a dynamic environment like software development, where we do watch market trends, we do see customers what they want. If you plan your work out one a year ahead of schedule, well that target is not going to maybe make customers happy because what we're really trying to do is with that with Agile, really does, is really try to enable to let your customer be happy.

And we all have a customer, every business customer. So that's what we're going to.

That makes sense. And I think the flexibility and the responsiveness is something that many folks in the nonprofit sector could relate to directly, right? So sometimes, yeah, you're on a path and this seems like what needs to happen and then there's a disaster in your community or there's a new need that that, that your organization needs to address and suddenly you're pivoting away from what you thought was the path into a new path.

And so, yeah, I'm curious about what are some of the sort of steps or tools that that Agile brings to that kind of responsive work.

So I can reference you. Every company delivers that. It's about delivering value. All right. So what is your strategy to deliver value? Where are you trying to do nonprofit? You're trying to whatever their mission is, What we're trying to achieve. Right? That becomes that becomes an overall thing. That is that is the what is the just cause? Why are you working this?

Why why is this Why are you in existence? You take that and then you have to struggle. It really gets deep. We really have to step back here a bit. Right. In order to like, it’s everything. It feeds all that all the way down to the tactics that we'll call it look like the ceremonies that used to execute in the framework.

But basically the strategy, your business strategy, your product strategy, we'll call it that will you've got a vision and then that feeds a strategy. Okay, Here's our strategy to land the vision for that strategy. You can start breaking that up into, All right, we're different pieces of that. - achieve that strategy like we want to you know, we want to do.

You know, we have an objective. We want to achieve that. That, let's say, nonprofit is battling childhood obesity, Right? Grit. All right. So this is what we're trying to mimic in our software development to the products we bring for customers. How do I structure that as a campaign and how do I the opportunities to fulfill that campaign. So again, it's just breaking that down to smaller bits.

That's from those smaller bits. You get what we call our product backlog, you get your backlog of work I have to do. So. All right. So looking at this, okay, here's the opportunity to fulfill that that opportunity. I break that down into smaller pieces when I can prioritize that. And I know that what I'm working on is actually feeding into the higher know, the higher structure of what we're looking for.

It's feeding into the delivery of a value that achieves that opportunity, which feeds the ultimate strategy for our company, the scales all the way from one team up to tens of thousands of team members working off the same backlog, depending on the scope and scale of what's being done right.

Two things that really stood out to me about what you just said that definitely are reinforced in the research and training I've had around getting work done, and one was connecting the work itself to the vision or strategy of the organization that is so crucial And think about for any of us. We all of us want to understand why is this important?

Why is this the most important thing? So just making those connections crystal clear, I love that piece and the other piece about it, about what you're describing that really stands out to me as exciting is the visibility piece here are the different product backlogs is what you call them. A Here are the chunks, and we've decided that this piece is most important, but you're still seeing like here, the other pieces that we will either reprioritize or we'll get to that.

You know, we'll get to those next.

And there's a point to be said about that. You're not when you first think about those items, you're not planning how you're going to do it. Right. You're not planning, you're not we call it gold plating. You're not gold plating the plan because the plans change. And then would all sudden you spent three days planning this one piece of work.

Well, guess what an item. Four items down the back of those and get higher priority. Like, Oh, we just burned four days. So there's a lot of just in time as to this and that's that the challenger for individuals now it's like the planning aspect is like you've got to really take a step back because people, you know, individuals, human beings, we like structure, we like organization, we like to know we have some sense of control.

I do practices. It's a it's an art. It's a discipline to be learned to like, all right, let's not go too down the rabbit hole. Just we call it rabbit hole. Like we don't want a rabbit hole just yet, so. Right.

So how do you how do you actually like what does it look like? I'm curious for your team to not to prevent yourself from rabbit hole-ing Oh, gosh. If I could present my prevent myself from going down rabbit holes, I would be delicious and so productive, So like, how does it look? What does it look like in your actual daily practice within the team?

Great question. So it's so the keyword, there's team. So that's like use an individual. You make your own choices by yourself. Like you rule the day. Like, here's what we're here's what I'm going to do today. But when you when you start expanding your work beyond the individual, it becomes a team effort. And so having that group, the group of peers to like, hey, here's what we're doing, let's talk about it.

So having that collaborative environment is like, here's what we're going to do and we're not. Again, we're not collaborating on the minutia, like the exact detail like that. If you get into that, that becomes like, well, maybe it's a process we need to close out of where we talk in process here, we actually talk and delivered value. But part of that team, it not only composes of of the individuals who actually execute the work, you know, but it also the individuals who decide how they do decide how the work would get done.

That's our team leads. We do have subject matter experts. In our case, that's our product management team. They're the ones who know what we're trying to build for the product. But the key team member for all of that is the Scrum Master, the scrum master's job on an Agile team is to be that impartial third party and to end to basically pull you back out of that whole like, wait a second, are you going too far?

Right? And so it's like time out and we need to you know, it's a fine line because there are certain details you need to be a good scrum Master knows what the team go just far enough to where they get what they need. Like, All right, stop. Because otherwise you can start rabbit holing on details that actually don't provide any value and it actually spawns a piece of work that derails the whole effort.

And that's that's and it's better like you get gold plating, you're planning for scenarios that may never happen, so you're supposed to stop. And that's the other key point to to working Agile is the iterative improvement.

So it feels like the Scrum Master position is it's like an art in science a little bit, sort of like part part big picture thinker, part facilitator, and then maybe part project manager as well. So how does one how does one balance that? I think am I correct in saying that you are a Scrum master? Is that true?

I've been a Scrum master in the past, yes. Yeah. So previous job before Foundant. You know, after I left Disney I was, I was Scrum master for several companies and that's but it's but it's not understanding what the big like what's our strategy does this align with the strategy and being able to and trusting the scrum master to be that impartial third party and so but it's not - let's be clear - the team members are all equal.

There's no everyone's got their specialty there's not someone to say stop it doing your job. The scrum master's job is to make sure the value is being delivered on a consistent basis. Right. So and removing roadblocks. The second piece of that is like, what are the roadblocks for me delivering value? So that's where the project management piece comes in.

You know what's different from a project manager is typically project manager. There's nothing like what's a hold up? Well, this is taking me four weeks and they'll update the Gantt chart to show, All right, it's like everything four weeks where it's like, all right, why is it taking you four weeks? All right, let's. Oh, it's a process gap.

It's an unknown. It's a it's a third party dependency. All right. How do we how do we eliminate that? So we can continue moving forward? So the Scrum master very much herds the cats. I like to say it's about herding cats because ultimately you want to use the script. The Scrum master takes the cognitive load off the product team.

You know, you're your subject matter expert and your team members are actually getting the work done. You want to take that load off them as much as possible. Not that they're automatons, but so they can focus on like where they find gratification because like they're working for you, because they find gratification and do what they want to do.

The project management stuff, they just want to knuckle down and deliver value. That's what you're paying for or why they're volunteering. You know, so

Yeah, and like continuing, like we were, we said earlier to connect their work to the big picture, to the big vision, to the big mission. Yeah, that's, I think that's super, super helpful. So I hear what you're saying about it's an iterative process and so how iterative are we talking? Like how do you is this something where you're meeting a few times a week?

Are you meeting daily with this kind of a an approach or how does that look?

Sure. So there's no there's no prescribed. Again, the framework is very loose. You read up anything on you'll hear you'll hear typical right in, you'll hear best practices. There's no there's no prescription like, alright, you must do this. That's not that's not actually being agile And every team is going to adapt how they want. Every company's going to do it the way they want to do it, how we do it, how software companies typically do it unless they're very optimized and they have a very senior team who are very trusting.

So that's another aspect of it. You don't want to put this process in just for process sake. Part of and I was like, You know what? I've got a team of 30 engineer to be doing this for 30 years. They know what they're doing. I'm going to just like that was go create, go get stuff done. However, if it's a very like, you know, if you've got timelines and deadlines to go, you want to know you want to have the fidelity you want have a high fidelity of input, you know what's going on.

Like you want to make sure that that that you're getting the feedback needed so you can act, not so you could use a stick to beat the team over with like you're not working fast enough, but you can identify those roadblocks. So we meet daily our teams, all our engineering teams. We meet daily for 15 minutes and in that 15 minutes, essentially they ask three questions.

There's a fourth question now, but three questions like Would you do yesterday? What are you doing today? And do you have any roadblocks? And the fourth question is like, how much more and how much more time do you need? Right. Just get checked. So and that basically that that gives the scrum master and our team the whole of the whole team an idea of like, okay this individual is making progress.

We're seeing iterative progress towards where this can land yet so once a day and that happens in two week blocks, we call those sprints or iterations and plan work for basically two weeks. So there's a planning cycle to where we so we don't rabbit hole. We, we practice what's called the scaled Agile framework at knowledge and that's basically most software companies.

Agile is performed by engineering in product and that's it. Sales is part of it, marketing is not part of it. The executive team is a part of it. And the challenge with that is the direction and strategies that those teams want to do. Don't align with what engineering and products are doing sometimes. And then we have collisions what Scaled

Agile allows is from the Board of directors down to our executive leadership team, down to the middle management, all the way down to individuals. We're all aligned to what we talked about before. We're all aligned to a strategy to accomplish what we think is going to be best for our customers. So we plan it in quarterly increments. We look, we look at the next three months beginning every calendar quarter, like, all right, we're going get this work done right?

We call it plan. Here's how we plan. But enough by saying broad brushstrokes. We think we're going to pencil this in. Then every two weeks, that's when we go in and start kind of filling in some of the details, enough to like what the team's like. Okay. Yeah, we can get that. Yeah.

Yeah. Okay. I see how that works. Oh, that's so useful. I yeah, okay. For like a in a, a podcast is not visual, but now I'm sort of envisioning like a piece of paper that has the quarter with the big goal at the top written across the top. And then your sprints are the little chunks. If you have a timeline.

Oops. Going underneath the headline there, the little chunks that then connect back up to that big, you know, goal.

And the goal for each of those chunks. And this is the goal for our teams. The goal of each of those chunks should demonstrate value that was delivered to meet the overall arching goal. So it's not it's not is it total customer value? is my team get to build something that I found that customers like. Oh, we get to use that not every time sometimes to enable, you know, further down the line for something to launch.

And that's just a software development that's very much you're building a house with the walls framed up the customer. You know, there's the wood framing customers not really going to benefit from that, but it enables the finishing of the house, right? So I really like that analogy of building a house is equivalent to how agile methodologies work, how software development works actually.

So yeah, I do. I like that for, for lots of organizations actually, because so many times you have to build a structure or a system of some kind before or there's a benefit to, you know, it's allowing, it's this sort of launching pad for something to allow something else to happen. So that is a that is a really helpful analogy.

If someone is thinking about this sort of learning more about this and potentially a adopting this strategy to their to the way they work, what are your suggestions or recommendations as far as next steps are?

The best place to start is is a good ole YouTube go to you to look for it and then just and go on LinkedIn and just there's so many scrum master groups out there. You can just find a Scrum master group and just start posting questions that the scrum masters all about optimization as much as possible and helping each other out.

So it's that they're really the heart of like they're the engine that helps keep it moving forward. That's what the Scrum Master job is along. About ten years ago, that was just a role. It wasn't really defined position, so someone assumed the role of Scrum Master. So it usually was like a software development lead. I was the software developer, but I would also assume the role of Scrum Master.

Now in the last five or six years, it it's evolved into its own standalone position because there's so much to do, like optimizing the business up and down. The total business that's I can't do software development and that piece.

Right, it's like that connective tissue between all the different pieces. And when I think about, you know, obviously that makes a ton of sense for software. But when again, when I think about a nonprofit organization and the different work they're doing and how, you know, with some of the clients I work with, how easy it is even within one department, if it's a larger organization for folks to get siloed right.

They're working, of course, on their particular role and focus area. And, you know, we all get into our little silos or deep into our rows. I think of it like a field, right? And then you're in your row in the corn, and it's sometimes so tricky to look up and be like, Oh, wait, they're doing some I should I should have known about that.

I wish I'd known about that a month ago. And, you know, so then having a actual, you know, defined role that is Scrum master connective tissue kind of person that keeps everybody not so much about their deliverables, but it really is more about like making sure alignment is happening.

The solid point of the one thing caveat want to give to you about being Scrum Master and this happens every place I've been. We like to joke about this, but like there were, they are responsible for everything but in charge of nothing. So it's very much a it's very much a you're responsible for delivery, but you're not in charge of any of the team members who are doing it.

So you can't have that HR aspect of it. You're not responsible for making sure the product properly designed to find you have a say in it. So there's a bit of letting go and that's where the planning piece, like I’m not sticking to the plan. Like it's it's okay, it's all right. Trust your team members, but have those conversations.

So that team member needs to be willing to have those conversations and be like, okay, what do we need to do to make this better? Right? And they usually become a very much a KPI. You'll focus like, All right, tell me how much work I've done this week. Why didn't we get more done? Can we get more done?

So that's very much that type of role. So they're not in charge of anything in particular, but they're responsible for everything versus being responsible and in charge.

So fascinating. I love this. I'm definitely going to read more about Scrum Master and Agile personally. And I think I guess the maybe that sort of as a last sort of if you wanted people to leave with with, you know, something to take away from this conversation, I one question I'm dying to ask you is what do you feel like like personally as a leader you have gained or benifitted?

How have you benefited as a leader from from implementing this approach?

As a leader, you have to be connected to your team members who are actually getting the work done. Like so you really connect on that level. It's not about ivory tower leadership at this part or like it's not my job to figure out, tell me what exactly to do. My job then becomes like, okay, the framework is lined up.

Here's the work that gets done. So now I can focus on what I'm supposed to do as a leader, which is I'm a big believer that my job is not to elevate the team members themselves. My job is to give them a framework, my team members, a way to elevate themselves within the company. And then the gaps I've got.

I work on that. That's my job as a leader. So by getting in close, you're building those relationships, building that trust, giving them a spot to where they feel like they understand what we're doing. They're finding gratification in the job that's what I'm supposed to do. That's what that's what this allows me to do. Versus top down leadership.

You need to do this. This I need to know everything that's going on when I know I don't need to know that that's not what that kind of organization I work for those organizations And there it's yeah, that's that's not good It's not healthy.

You know I, I can appreciate everything you're saying and I think you're spot on because like we have already mentioned a couple of times, you're connecting folks to why they're doing the work they're doing. But you, as their leader, are also staying connected to what they're accomplishing and what their and what roadblocks, as you mentioned before, need to be addressed or navigated.

But I like how that fits in on sort of both sides of the of the leadership spectrum.

Once again, I'm paying them to deliver value. They're working for me because they can deliver value. They're working for the organization because they believe in the value, the mission of the organization. Thus, if there are focused on if they're all there, if I optimize your time as much as possible to, you know, to build to deliver value as fast as they can, that's elevating the organization, that's elevating them.

So I think it's it all connects together.

And I love that. I love how it all connects together. So a couple of things I wanted to share out while we're talking about getting things done, just I think it's very complementary to what you've already shared with us, Aaron. So feel free to jump in. But a few sort of time tested tips that I wanted to share with folks who are listening about productivity and getting getting the work done.

One is making your goals specific. And and Aarron has gotten has sort of described a really fascinating way to do that. That's time specific. And I would that was going to be my second tip like make things time specific because I know for me when I was leading an organization, man, if we didn't have a deadline on something, it was so easy for that, something to move down the list.

And in lieu of something that did have a deadline, an event or a training or something like that. So make things time, you know, put a deadline on it, put a date on it, and then write it down. So there is all this research out there about the power of simply writing down an actionable goal versus just saying it.

So some folks believe that you have a 42% greater chance of achieving your goal just by writing them down so or typing them. So I offer that up as a couple of tips that have served me well. Oh, one more thing before we wrap up this topic, and that is I just read an article a few days ago and they used the word I'd never heard this phrase before, mono task instead of multitask.

So in other words, don't, don't multitask, multitask does not work. It's a waste of your time when you're context switching between different things too much. So mono task. In other words, focus on one thing at a time and really try and stack your work as much as you can. Not every day will allow this, but stack similar work together.

So even your, your brain doesn't have to context switch, you're already editing, you're already writing. Keep writing, you know you're already researching, keep researching, even if it's not for the exact same project. So those are a couple of takeaways that I wanted to share with the team. Is there anything else that we need to share with our listeners?

Aaron, before we sign off.

Now, you hit a lot of what you touched on at Agile addresses that work in process limits, key links, you know, what have you. So there's a lot of like, which would you prescribe? There is a there is, there is a framework for that to make that easy and it just plugs in.

Awesome, okay well, I really, really appreciate your time today and all your expertise. Aaron, thank you so much for taking the time to share this with me and with everyone who's listening. And I'd love to hear. For all of you listening, we'd love to hear the systems and approaches that you're using to tackle your work and get stuff done.

So if you want to share some of that over on compass that would be delightful. Otherwise, thanks for listening and thanks for all the good work that you're doing. We appreciate you, take good care.