In this enlightening presentation from Prodacity, Felicia Schwartz shares her insights on transforming organizations into truly Agile entities. Emphasizing the distinction between being Agile and merely doing Agile, Felicia navigates through the challenges and opportunities presented by Agile transformation, especially within large organizations and the public sector. From initial steps of embracing the Agile mindset to scaling Agile practices across multiple teams, this talk provides practical advice, real-world examples, and strategic approaches to foster an environment where continuous improvement, collaboration, and customer-centricity are at the core.

‍

Felicia Schwartz (0:14)

A lot of what I'm going to talk about today is really a follow on for many of the things you heard over the course of the past few days. It's about being Agile, not necessarily doing Agile. There's a lot of frameworks out there. I agree with Mike, there's a lot of frameworks. Pick what works but do what works. So what I'm going to really talk to you about is how to be an Agile organization, and large organizations - I'll skip through slides 'cause it's not that big deal - a lot of companies have adopted Agile. The buzzword has been out there for over a decade about doing it. And a lot of 'em started out with small teams and often started out in small companies that were like, we need to get some product out to market. We need to check and we need to get something fast. We need feedback. So just similar to what you hear, it's about the customer. So how do we get out there? 

(1:01)

So we put together small teams and they went and they worked together and they figured things out. They went out to speak to their customers to get feedback and they could iterate. Goal getting something in there and out to their customers to start driving revenue or solving problems. But what happened is things get really hard. Like in a small company or one group, things are easy, right? You've got a team of five to 10 people in there, you work together. Pre-COVID days, people were co-located. So you could talk a lot, you could communicate a lot, figure things out a lot and solve problems a lot. But when you get into the government, it's a little bigger than a small startup. You have a lot of people, a lot of things are very complicated. If I build something and I'm going to use something, an example that we all probably could relate to, does anybody like to work and not get paid? No? Really? So that's probably a good thing. Success in an organization like that is if you're doing a job, you want to get paid. To get paid, you as the customers of the paychecks, all you care about is getting your money right? But what do you have to do to get that money? What is the company that's doing the payroll have to do? They need your information. They need to give you the option of like, there's an I9 in the US you have to fill out, they need to know what your benefits are. They need to get the deductions, your taxes. There's a lot that goes on. You care about getting that paycheck, right? They have to deal with your bank. So when you start caring about everything that goes on behind the scene, it's not so simple as putting five to 10 people together to build out what the UI is to say add what you want as your deductions. There's a lot of different pieces into play that go into that. And that's where organizations start struggling and getting stuck. And that's where Agile has often failed, 'cause you get there, everybody's fed up, and throw their hands up in the air and they're like, that's it, this doesn't work, this Agile thing doesn't work. And they come up with different frameworks. And this is why I don't propose any one framework, because then they go Agile, Scrum, Fall, like Waterfall. 

‍

(2:56)

The world we started in worked really well, right? We knew everything we had to do, but we want to be Agile and all different types of strategies come into play and oftentimes they don't work. You will have a few little things on the side that can be done quick. But when you have something at this enterprise with this large organization scale, it just starts to fail. So what I want to talk about with you today is how do you get past that? And one of the things you have to understand is one, it's never done. It's never complete, you will never get to the point to say, check, we're now an Agile organization, we can deliver faster. It's a continuous process because Agile isn't something you do, it's something you become, right? It's a combination. And I don't care about AI out there. There's always people involved and the technology is really, really cool and it's really growing fast. That's solvable. Getting your people on board to not sabotage what you're doing, and to be aligned is going to be, it's usually what I found is the key to failure but also the key to success. So understand at every level in your organization, this is as leaders, you need to own this, is you need to be and create the environment to be an Agile organization. So where do you get started? How do you do this? We're still not there, so I hope my words would make sense to you without any visuals. So I'm going to walk you through like a couple steps and you'll see in the slides, this is documented, but I'll walk you through it verbally. So one, get started, right? Think big. You need to think of that payroll system to say, I've got to figure all of this out. I can't just say I'm going to take money and move it from my bank account to my employee's bank account, because I'll be in trouble with the law, right? And we all work for the government. Who wants to have the IRS raining down on us to say you're not compliant? So you do have to think big. You still have to think of everything you really want to achieve. And one of the things in the private sector is there's a lot of competition out there and if you don't do it right, somebody else will. And you won't be around in a year from now if you don't. So think big, but start small. So what I've seen success in is start someplace, find a place you want to start. But as you're getting started, to find the outcomes, why are we doing this thing overall? Why do we want to be an Agile organization? If everybody is not allowed? Ah, we're getting there. We're almost there. And now I forget how to use this. Now we're gone. So why do you want to be there? Let's align with that team to say, hey everybody, now I'm in a totally different person's deck. That's okay. That's okay.

‍

[Audience Member] You're doing great.

(5:42)

Thank you. Thank you. Always got to be thinking on your feet. I wish I had a joke with me though, 'cause they would've been better than the ones we heard. Shh. what you need to do is, why are we doing this? Like what's the outcome we want to do? I am a fan of out-OKRs, right? It resonates with me. There's a million and one different ways to do it. Do what works with you, but really identify, we're doing this in a…we want to be Agile because we want to deliver value to whoever our customer is. And it could be people internal, right? A customer doesn't always have to be an external customer. In this case it's you who get paid, you're the customer, right? We want to be Agile 'cause we want you to be happy. As employees, we want you to feel like you are seamlessly getting paid. It's not something you worry about. So you do your job. Who's going to be really happy doing their job if after a month, two months, they haven't gotten a paycheck? Are you going to go to work and be enthusiastic and energetic? I am. Oh, nobody's raising a hand, I don't understand that. So get everybody aligned. Let's define, if we do this thing that we're going to start working on, what's going to be different, right? We're going to keep our employees happy, we are going to get things to production. Get that vision out there, get that mission, but also get some quantifiable results. If you can baseline things today, that's great. I don't know if everybody was in the presentation earlier in the week when they talked about the DORA metrics, but time to market, that's the good one. Like if it takes you, and I've worked with organizations where it would take nine months to test something, right? That's just a test. So this is, I've done all my development, now I have to test it, that was nine months. So if I was able to go in there and say I'm going to reduce the time it takes to go from an idea to production, 'cause if it's not in production, it has zero value to anybody, right? You can have the coolest thing in a non-production environment, it adds no value. 

(7:33)

So put those quantitative measures. So I'm going to reduce it, less than nine months. I don't know how long it's going to be, too soon to say, but I'm going to make it less. Let's start out identifying, here's why we're doing this thing, and it's got to be meaningful. It's got to have something that everybody around you at every level in the organization is going to want to rally behind. Next thing you need to do is then pick your team. Who do you want to work on this? When you're starting with your first team, you want to be very strategic in who you pick. You want to get people who are motivated. You do not need to pick the people that are like, yeah, this is the best thing ever. You want people who are motivated to at least try something. I've seen the best success with the person who is the biggest naysayer, like this will never work, I know it's not, but they're willing to try. And the reason why that person is really good to have on your team is it'll push the team to try to sway anything that they're going to say, but they're influential in your organization. They may not have any title or stars or authority, but everybody listens to them. So if you've taken the biggest naysayer and you converted them to say, hey, you know what, this worked, everybody around who may not have seen it, they know that person usually is very negative and finds the things that go wrong. They're going to listen to that person 'cause they're going to see it. So get together a team that can be influential, are motivated, willing to try something, will accept the principles of we're not going to follow a script, we're going to do what's right and we're going to try. A team should be everybody, and you've probably heard this before, everybody in that team, all the people and the skill sets needed to get something done, right? 

(9:18)

In a new product development, it's usually product management, user experience and engineering. If you're doing modernization, which is what I've spent the past 10 years doing, like large scale COBAL modernization efforts, it may be more than that. Architecture, it may be a little bit more. But define what you need to get something done. Put that team together. Leaders need to give that team the autonomy, implement servant leadership. Make sure that your leaders are there to support them. They're not going to get everything they need to get it done, but at least the leaders will listen. They're not going to dictate, shift it around to say, what do you need and how do we solve it? Get that in place. Then when that team gets started, what they're working on now, just like the mission of why we're doing this, of Agile needs to be clearly defined. What that team is doing also. Put together those OKRs. What's the objective of this team? We are going to make sure that paychecks, the payments of your paychecks get done on the day they're due. By midnight or 12:01 AM on the 30th of the month, everybody gets paid. That's our mission. How are we going to do that? Well that's what the team is going to decide. But get those quantitative results, right? What are you going to do? We are going to have, again, with the DORA metrics, we could go in and say, we're not going to have to resubmit something that went live. When we put it in, we're going to really reduce the amounts of things we have to back out, or if something should go down, 'cause mistakes will always happen, we're going to get that up fast, right? So put some key metrics into something. Paychecks, I think we all, nobody gave me a like, I'm willing to do my work as a volunteer. So I'm going to say like getting something like this that's important to people, if you're successful there, people will like it and people will listen. 

(11:07)

The team in itself, they should continue to focus on those outcomes. If you define it upfront, and I'm a big fan of getting everybody on a kickoff, everybody in the room define it, align, talk through where your differences are. And I think Mike said this in the last talk as well, get it out there. You may not agree a hundred percent, but at least everybody's walking out with the same, like hey, here's what we're doing, here's why we're doing it and here's the outcomes we're driving for. The team then, as they start working, will continue to work towards those outcomes. You should monitor that so that it's really easy, especially engineering. Like you see a cool, shiny object, I want to work on it. That's okay, if you say one, we're experimenting, fine to experiment, but it should always tie in to the outcomes, and the team, if they learn something and those outcomes are wrong, raise it up the flag. So that constant communication with the team and alignment to that outcomes is always in play, continuously. And then communicate. There's various ways of communicate. Don't solve on one. Know your organization. I use Slack, I don't know if that's government allowed. Teams, eh, no. Teams, Slack, emails, whatever works. Know what works and use it. Don't try to force too many changes because then none of the changes we'll go through. Use the communications. 

(12:29)

What I found really successful, we've done things in one week intervals, which seems really, really short term. And everybody initially is like, oh my god, what do you get done in a week? Thing is, you get done a lot because you're doing it in small increments. When you do those demos at the end of every single week, invite the right people to it. It doesn't necessarily mean just the team and your stakeholder. If you're doing something that's really cool from an engineering perspective, there's a lot of engineering teams around you. Invite them. They don't have to come, it's up to them. But I've seen, we mentioned Kubernetes, like when you're early on, Kubernetes is hard, right? Putting things in containers and working through that, that's hard. Bring the other teams, they're going to want to see what you've done. They're not under the spotlight to say, make sure you do it, but they're going to learn from you. So it's a great way to communicate. If you're doing something really cool from a business and you've gotten something done, invite your business and ask them to invite other stakeholders. Don't be afraid to open the doors and then the team will listen to that feedback. And then internally, after you do that demo, hey, what did we hear? What did we learn? It could be, we're going in the wrong direction. Or maybe we learn something that we didn't know from an outsider that we should think about as we're building this out. And once you show that first success, and you will show that first success, like you will, I will almost guarantee it, with my kids 'cause they're annoying me right now. But celebrate it, share that out. Everybody wants to be a part of a success story. So share that success story. Again, whatever communication channels you have, if you do town halls, if you do blast newsletters, share that success, let everybody know, take pride in the fact that this is a success. 

(14:17)

Now that comes the hard part, right? Great, I've had one team that did something really successful. How do I scale this out? I deal with hundreds of teams in a division of a bank, right? And that's one division out of many divisions in a bank. How do I scale it out across that? So there's a couple of things, and you'll see some of this in the deck when you get it. But one, create a learning hub. Teams need to learn how to do this. Whatever practice, be it scrum, Kanban, whatever you want to do. Get your teams through the training first. People shouldn't go in there blind not knowing what to do. Get them through some formal training, but understand formal training of itself doesn't get you ready for the reality. So bring in, teams start out, get experienced people to work side by side. Pairing is a model that I know Rise8 uses, I use it at Pivotal days. Use that, get coaches in, do both. Really set those new teams up for success so that when they hit a gotcha, and they will, there's somebody there who can help them, not solve the problem for them, but show them how to walk through these problems so they're really being enabled by doing with somebody with experience. In addition, set up a transformation hub, and what that transformation hub is, I've got a hundred teams doing things separately. They're going to hit thing. Oh am I on? Yay! Now I got to figure out how to go to the next.

‍

[Audience Member] You were doing a great job with the slides.

(15:43)

I'm going to keep without the slides, 'cause then somebody, okay, I'm going to keep going. Create that transformation hub, and really what a transformation hub, it's a central place of people with experience. I found the best success is when I've done the work and now I go to this transformation hub for three months and I'm going to work there. And really what we're doing is we're taking the problems from the different teams and we're gathering it together, 'cause I will guarantee you, you're going to have a lot of similar problems. A lot of the problems that come in is I need to integrate. I don't know if we have a lot of engineering, I need to integrate with other systems, I need to integrate with a central data repository and the DBA won't make changes fast enough for me. Those are common problems. Get that transformation hub in, you start to solve it and then you spread that out to other people. Create the cookbook of recipes of here's how we did it. And that transformation hub is the one that allows you to do that. They will gather information, they will create a central repository to help, rotate those people in, and that team also then starts dealing with your upper level. So there are certain things that the teams at that level cannot change. They just don't have the authority, they don't have the control. But that's where you have your senior people in your organization. Everything that's being done should be based upon what they need to do. When you started out the initial OKRs, it should be aligned with what their missions for the year, for the decade or whatever it is, that should be aligned. They also need to be the ones to get rid of the blockers that you have. What's sticking you? So that transformation hub would work with the Agile, I call it the Agile leadership. There should be representation at the leadership, the most senior leadership level to represent your customers, represent engineering, represent security, whatever else you have in your organization that's specific at the most senior level, that team should be Agile. Just like your delivery team, they have their daily standups, so should this team. What they discuss is what that transformation hub is gathering from all the different teams when they meet with them, of, hey, here's a blocker. 

(17:47)

I mentioned earlier that I'd been working a lot of old school legacy COBOL-DB2 modernization. This approach has helped to say, hey, we need to implement DDD because we really need to change the way our teams are structured, right? That's a major change in our organization. How you structure your teams, the roles and responsibilities. That is something top level executives really need to align on 'cause there's a lot goes behind that. But when you start hearing like, we can't deliver this thing that's so mission crit- I can't get people to get paid on the 30th, they're not going to get paid 'til the fifth of the next month, they start hearing those problems, they're going to start getting rid of the blockers that's stopping you in there. So I'm trying to give examples but I know I don't want to run out of time and I want to make sure you have your break. But I'm happy to talk about specific use cases outside of this. This leadership team starts showing success. Any of these little blockers. Some of the common blockers I have is I've got a laptop that's about 20 years old. It's really slow. Well you know what, if you're giving your people the wrong tools to do their job, you're not going to do that. So those are some of the easier things. I mean they cost money, but those are some of the easier things. Give your people the right tools they need to do. If it's communication strategy, make sure, if somebody's not, start tackling those little problems early for your teams. And again, that transformation hub has been very successful of collecting all the feedback from the groups and sharing it out. And automate complexity. You're going to hear this too. I think Mike talked about the automated, like I call it the path to prod, from the time you're in your dev environment to you're in production, 'cause nothing matters if it's not in production. Automate that. Your security team is going to be so happy when they know every time you push code, every push of that code has gone through your security checks and your scans so that it's not vulnerable. So that if you have an emergency thing you need to get in there, that's not going to stop you. 

(19:47)

A lot of meetings, they used to have cab meetings and all these meetings for everybody to look at it. The automation of this gets rid of the need for that. The first time they're going to be a little leery. But once you prove that, I'm catching everything, I'm catching everything before it gets to production, so if there's a problem when I go to a pre-prod environment, maybe it's QA or whatever, I'm catching it. So I'll never get to the point where production, never say never, so 99% of the time I'm going to catch something in another environment. So it's really safe and secure. Your CISO will be very, very happy with that. Automate whatever you can and then your teams can focus on new capabilities, better improvements, making sure that you don't have to wait until the fifth of the month they get paid so that you can feed your family. And then create that culture. So it's all going to be about the culture. If there is blockers in there, people are going to be your blockers. Make sure people know the value they bring to the organization, right? Every job, when I worked in an office, I'd make sure the people that cleaned up at the end of the day, gosh, I don't want to go to an office where there's garbage on the floor. I would thank them for when they would clean up. They have to understand that you bring value to me 'cause you're bringing a physical environment that makes me happier to work there. I don't want to work when I have to worry about, okay, and this happened a few months ago in an office in, I'm from New York, If you couldn't tell by the accent, walking in the office and all of a sudden, you see like a family of roaches walk across. There was no way I was getting anything done the rest of that day, 'cause I'm sitting here paranoid. So everybody should have a role and a value. People should understand the value they bring to the organization. If roles need to be shifted, shift the roles around so that everybody is bringing value for what they are passionate about and what they're good at. Combine the two and it's not, again, there's no quick you must do this. I think you really need to know your people and provide that culture that people are comfortable saying, hey, there's something else I think I'd be better at, I'd like to give it a try. 

(21:43)

I have 12 steps in here that you could read, but I'll just, very simple things to just focus on is command control. You've heard that a lot. No, that's not good. There are things that executives need to make decision, but you really need to, this the world of technology is way too complex today that any one person is going to know everything. But your teams will. Are we up there? Oh, there you go. Yay, my last slide. And treat your stars, right? Historically, there's going to be those superstars, and then they're the ones that are burdened with the long days, the emergency. My nirvana was I got called to make sure, I worked on Wall Street, we did tradings, and I worked for one of the Morgans. I'm not going to tell you which one. So I've narrowed it down to two. And middle of the night we had like, oh, a couple billion dollars worth of trades and something went wrong. So you are up all night. Do you know what it's like to lose a million dollars of change? The interest on that would bankrupt most people. So that pressure, but they took a few of us that just knew it really well. It's too much pressure on your people, they quit. So you don't want to create stars, like you want to treat them fairly. You will have the superstars. There's always going to be people who like it and will go out of their way, but treat them fairly. Share knowledge across the thing. Get people who are, hire for enthusiasm. People that really want to do something. Train them up on the skills they need to do that. Measure people on the outcomes they deliver and their ability to work as part of a team. Feedback, I'm not a fan of the annual review. People should know, if you have to do a formal annual review, that's one of the things executives should change. But nobody should ever be surprised at the end of the year to say, oh, you're not doing a good job. Managers, continuous conversation, feedback. Let people know, help them, offer that. You want your people to be inspired 'cause they're going to drive your success. That's the cultural shift. Make sure that happens. Celebrate successes. Full transparency, good or bad. Let people know what's going on. If you hide when things fail, people will never trust you and all they're going to know is like, oh, you only talk about the good times. Tell 'em about failures. Let them know we experimented on something, yeah, but it wasn't great. Let them know you tried it, it failed, you moved on. Here's how I recovered. What a great success story. I would love to have known when people failed in parenting so that when I failed in parenting, I would know how they became good parents. So just overall, share this information. And you could read the rest, but I'm just going to end this 'cause I think I'm at time. 

(24:20)

Do what works. I'm giving you kind of a general playbook about how I've seen success. Every organization is slightly different, very similar but slightly different, being the private or the public sector. Listen to your people and then do what works. If it's working, keep going. It doesn't have to be anything we talked about today. If it's working for your organization and you're getting those outcomes that you defined upfront, keep it up. Why not? Keep doing it. If it doesn't work, stop and go into another direction. And I'm going to end on that note.

‍