Practical Agile in a Complex Enterprise Environment

Find this Podcast “Practical Agile in a Complex Enterprise Environment” on the ThreeWill Soundcloud, Stitcher, and iTunes.

In this Podcast, Practical Agile in a Complex Enterprise Environment, we discuss…


2:55Practical Agile Overview
6:18Enterprise Release Calendar
13:30The Business Side of Agile
22:20Agile for Every Project?

LinkedIn Profile – Kimberly Eubank
LinkedIn Profile – Bob Morris

Tommy Ryan:It’s Wednesday, July 24th, and today we’re talking with Kimberly Eubank and Bob Morris about practical Agile. Kimberly comes from a large bank as a Senior VP in charge of digital transformation and projects that use Scrum for that and Bob Morris is a ThreeWill principal Scrum master that works on some of the more complex projects we have here at ThreeWill. We have a great conversation today, talking about practical Agile, how do you take Agile and fit that within the context of the enterprise where it’s not always Agile throughout the organization. There’s Waterfall and other methodologies that you have to play nicely with to fit within the organization. It’s a great topic. Looking forward to sharing what we have talked about today.


Hi and welcome to the Work Together Better podcast. This is your host, Tommy Ryan. This is ThreeWill’s official podcast about enterprise collaboration, how people process and technology combined to help organizations, departments, and teams work together better.


All right. We’re here with Kimberly Eubank and Bob Morris, and the topic we’re going to cover is practical Agile. And we were talking just before this, preparing for the podcast, and really almost had a podcast in itself before we started this, talking about the experience of how Agile works in the real world at the enterprise level, that there’s so many things that you have to be aware of in your context of how you use Agile to make sure it’s the right tool in the first place and that it has the right kind of adjustment to communicate with others and connect into an overall ecosystem of how things get done in the enterprise. The software is one component, it’s not the whole thing.


So wanted to have that as the topic and for us to start talking about what are some of those challenges that we have in the enterprise when we use Agile. So, Kimberly, what are your thoughts in terms of your biggest challenges that you see when Agile is used for the work that you get done? I know right now you have Agile Scrum teams and the work you’re doing at your company today, what are your top challenges that you feel that it’s not textbook, it’s not written in the Agile rule book, but it’s what you have to do to adjust to make Agile work in your company?


Kimberly Eubank:Yeah, and I’m very much a proponent of the practical Agile approach because every company situation’s different, every company’s evolution to Agile is different. So in my current environment, and in most companies I’ve worked at, 75% of the companies still Waterfall, and you’ve got a couple of pockets within the company who are trying to be Agile. And so at the end of the day, my job is to not just get the code out but also to deliver a cross-functional product, and so that means delivering the code but that also means delivering the training to your front line, making sure that your marketing is in place, the holistic product development process.


And so one of the challenges I think that … I come into the process really looking at, okay, what is the most efficient way in this business, with this business’s processes, for me and my team to get work done? And that likely isn’t going to be textbook Agile. So one of the challenges I have is when companies are trying to evolve to Agile, they’ll bring in Agile coaches to try to teach you the right way to do it. The challenge is is that that Agile coach doesn’t really have the skin in the game to make sure that it actually gets delivered and delivered successfully, and they really are quoting from the Agile Bible.


Tommy Ryan:Right, so they’re not asking about your organization and the ethos, the DNA of how people work in the organization when they try to apply Agile, they’re just coming in and saying, this is how you use Agile the correct way.


Kimberly Eubank:Typically. And if they do ask those questions, it tends to be with the bent of how can I get everybody to do it the Agile way as opposed to looking at it as, oh okay, I see that 75% of the company does it this way, so how can we adjust how you’re going to use Agile to better fit into the whole versus trying to get the whole the fit into you? And the reality is when you’re one department doing Agile in a sea of Waterfall, you’re the one that’s going to bend, not the sea. I mean that’s just the reality, the practical reality of large enterprise.


Bob Morris:And, Kimberly, I was going to say, I think another way to put what you’re talking about with the external consultants is you see it a lot now where people are entirely too focused on the practices of Agile instead of the principles. And I know there’s a lot of conversation happening now about sort of Agile fatigue in the terminology, but I think the principles are still fresh and I think that’s where the value is.


Kimberly Eubank:Yeah. I love the fact that you have sprints, that you can see the code before the unveiling of Waterfall, you can make sure that you’re on the right track with the development team the whole way through, all of those things are valuable. But when you get into, it must be this way, I’ve found in my career that nothing is ever that way and if you don’t bend then you’re, you’re going to be the one that breaks.


Released calendars tend to be, I think the biggest, actually day to day working challenge because Waterfall locks requirements much earlier and they release on a common calendar. And we’ve had a lot of challenges in our business with testing environments, which is just making sure that the right code branch is ready at the right time and that the Agile development teams are lined up with the Waterfall teams and that we aren’t conflicting. And so just keeping all of that aligned and in a rhythm is hard because you very rarely are fortunate enough to have an Agile department that doesn’t need any other systems from any other department. I mean my core systems that I have to go back to are Waterfall systems, and so that means I got to work it out, like when are you releasing that code versus when I am releasing that code, that type of thing.


Tommy Ryan:How do you address that when Agile … Traditionally people are going into a sprint, they plan what they’re going to do and they have an outcome of working software. I see the challenge that you’re saying is this is Waterfall, if you want this integration that’s part of your software solution to be put in place, you might have to get in a line that is six months down the road before you get into their release cycle to give you the dependency that you have. So, are you doing spikes earlier on to set some requirements to say, as a part of this Agile sprint we have to do some work that we’re going to realize maybe six months down the road? Is that how you kind of fit in that world where you do have dependencies that are more Waterfall like?


Kimberly Eubank:We actually try to time it at the same time, so we adhere … The way we’ve gotten around it is we adhere to the enterprise release calendar, and there are tons of releases in our calendar. We have four major releases a year and three what we call Alt releases, which are medium sized, and then we have monthly releases. So there are 17 opportunities a year on the enterprise calendar to drop code. So, for us, we don’t really need more than that and so we try to align to their calendars.


But to your point of upstream, our centralized customer information database is involved in just about every single project we do, and I have to get that on their roadmap, my IT partners have to get that on their roadmap easily six months in advance, and so we won’t then start necessarily working on that. We don’t work and hold it. We will try to time it for the same release so that we’re working on it at the same time. That’s how we’ve kind of overcome it because we have so much work that there’s always something that we can be doing while we’re waiting to get to their timeframe.


Tommy Ryan:So the things that you have in queue that need to be worked on is a much greater queue than you have time and so you’re just pulling the prioritize thing that doesn’t have a dependency into that Agile cycle and running your Agile Scrum team to go develop that and produce the best value towards the goal that you have for those items that are coming in to the sprint?


Kimberly Eubank:Yes. The other thing that I still do that people may feel like is a little bit more Waterfally is I roadmap at the Epic level. So everything is in Epic, for me that is a project. And so everything starts as an Epic for me. And then I place those Epics based on business need prioritization, the fact that another team needs something and they’re planning on delivering it in July so therefore I’m an ancillary system then so I put it in July so that I don’t hold them back. So I actually still do a release by release roadmap. Things change, things move around, but it gives you an idea of what’s coming up so that we can have those conversations with other systems. But yes, I absolutely always have more stuff that I need to do.


Tommy Ryan:So you’re slotting out all those Epics and then as you approach it, you start breaking it down into stories and accomplishing that?


Kimberly Eubank:Yes.


Tommy Ryan:And that’s very common. We see that quite a bit.


Bob Morris:Yeah. Kimberly, I’m curious, I know you integrate at the Epic level with the releases with these other groups, do you ever involve those other groups at any sort of interim point where they get an idea of what’s going on at the detail level in your group? Or is it totally, completely cordoned off just at the Epic release … Like attending sprint reviews or-


Tommy Ryan:Scrums.


Bob Morris:Yeah, or anything like that.


Kimberly Eubank:We tried to have them attend PIs, that did not work because they have their day job to do and it was too much and they really didn’t care about the whole thing. They just cared about that one conversation. So there, our intake processes within our IT department where if you want to engage that centralized customer information database for instance, they have an intake process. So our IT project manager will make sure that we get into their process, and then when we get to the feature in story grooming or the solution architecting, that’s when we’d actually engage with them on what is the solution and how are we going to write the requirements to make sure that we’re building the same thing and that the pieces are going to fit together at the end. But we tried to involve more folks at the PI level and it didn’t work. They didn’t really want to invest that quantity of time so we just stopped inviting them because they weren’t attending anyway. So that’s very much a traditional Waterfall kind of engagement model. Yeah.


Tommy Ryan:What would be any other big challenges that you see that makes you recognize that I have to adjust my Agile methodology, that I can’t just do it the traditional way? You were talking about releases, I think that’s a key thing that we see that you’ve got to communicate to folks that have dependencies that there’s massive training going on that they have to develop that, organize around it, and so they can’t just in an Agile way, only have a day’s notice to do an activity like that. What are other challenges you see beyond coordinating to a release cycle?


Kimberly Eubank:So I think the one that you talked about is key. All the Agile training that you’ll hear is really about how do you write the requirements and deliver the software to production. But there is a whole other business side that has to happen before whatever you’re realizing in production is real, and it’s customer care training. It’s if you have a retail front, your retail representative training, getting legal and compliance reviews depending on the business that you’re in, that may be harder than others, and so there’s this constant, we should be able to do things fast and we should be able to release code anytime we want, and that’s on my IT side, right? And I’m like, great, I know why you want to get there, but I don’t actually ever want … I’m never going to want to get to the point where I’m releasing code just whenever I feel like it because I can’t communicate to my front line and get them trained on things every other week. It needs to be packaged into something.


Now, if that means that your company has four releases a year in Waterfall and you can get down to having one release a month, great, but then they know to expect that one release a month. So I think that is one of the challenges, is making sure that the development and the business side of it marry so that you’re putting out a holistic product development effort and not just dropping code that nobody knows about and if it has problems, the hoo ha is going to hit the fan.


I think the other one is just talk track. I mentioned to you guys that I had a boss who hadn’t really gotten really deep into product development process and the software delivery life cycle, and so he had embraced Agile, which was good, but he was going around saying, well we should be able to do things from concept to production in eight weeks. And we’re tied to an enterprise release calendar and so I had to say, you know what, it’s not going to be eight weeks and let me explain to you why, because in a major release we have six sprints, which are two weeks long, that right there is 12 weeks that doesn’t talk about what happens before you get to the sprint, that doesn’t talk about what needs to happen after the sprint is done, Gold Code and all of that. And so really the time from start to finish is X. It’s not y. And when you go around saying to everybody why you’re setting your team up to fail.


And so I think that the marketing of Agile has set some expectations that may be absolutely realized in a smaller company, or a company that’s 100% Agile, or doesn’t have as many legal compliance, hurdles that it has to go through, but that same expectation is probably not going to translate to large scale enterprise as far as speed because the decision making in large scale enterprise is never going to be that fast. There’s too many people that you have to get involved in, and I don’t see that changing.


I’ve been through the Safe, we tried to do Safe, Safe to me, they just took all the jobs that existed and renamed them and stuck them on one slide. But the decision making in your company didn’t really change because you said we’re doing Safe and so I still have to jump through all those hurdles. So I think just the educating about the practical reality versus the marketing that’s been put behind Agile is another challenge to get people on the same page about expectations.


Tommy Ryan:You were talking about earlier about the release cycles and only releasing it, say every, sixth sprint to be consumed. We actually learned that from you and your project a while back in major telecom that we would do these sprints that were two-weeks sprints, I think, and we’d go to a three-week sprint that would be that major release, and I think the benefit of not just saying, well why don’t you just go to one release and why these interim releases that are part of these sprints … I think the benefit is you get to see what you’re going to get and you have a level of accountability and predictability of we are on track. I’m not going to get this big bang and then all of a sudden realize that, oh, that’s not what I really expected to get. I think you’re mitigating that risk of I’m not getting what I thought I was going to get based on having those iterative, or sprints, that lead up to that final release sprint.


And we suggest that with other organizations of consider this release sprint and make that a little bit different because … I mean we always experience this as you can barely get your testing done within an Agile’s friend, usually people are dropping code the day before the sprint’s being done. So we would lock it down and say we’re all done with code now we’re in this stabilization and ensuring that we’ve got a good solid release, we’re ready to release.


Kimberly Eubank:Yeah. And I think if I remembered that situation correctly, you did it in two weeks, you dropped the code, we tested it. If we saw anything then you had the rest of the week to fix it before we released it to the end users and-


Tommy Ryan:Versus pushing it off to the next sprint.


Kimberly Eubank:Right.


Tommy Ryan:Yeah, and that was great. I will say that, again, back to the right tool and the right situation, that was a self contained product that wasn’t customer facing. It was an internal tool. And we actually had the ability to have two versions, we could keep the production version completely functioning during that week where we were testing it out, and so you just raised another challenge, which is I have yet to be in a company that has perfect testing versus production. And so that is a challenge that we have is that what we test in lower environments is not really the equivalent of prime time and so therefore we have to … In a perfect world, you’d test it and you’d drop the code and you don’t need to retest it again because you tested the exact same thing, we actually have get up on release morning and test it in production because the lower environments are not one to one and so stuff can and does happen-


It can’t integrated with every system that you have.


Kimberly Eubank:Yes.


Tommy Ryan:Yeah, the costs or the practicality is not-


Kimberly Eubank:And data. You may not have all the data sets for every single corner case, they didn’t go grab that data just for expediency, so there may be a case that you’re not testing until first thing production morning. So I think that’s another challenge.


I worked for a fortune, I don’t even know, 5, 10 company, and that was a concern there and every single company I’ve worked at since. None of them have had that one to one environment that would be so helpful in so many ways. I mean, training, I mean just … But yeah, it’s because the companies have … They’re an amalgamation of systems over time and acquisitions and so it’s not pretty underneath the covers.


Tommy Ryan:Yeah. Yeah.


Bob Morris:And I think that that’s part of what’s really driving the Dev ops movement right now, which that’s really getting a lot of air time in Agile circles. But again, the challenge is if it’s not … If you don’t have one group owning that process from beginning to end, you still got that challenge that you can only go so far. And then when you go to the final step, you have to coordinate the group. There’s no way around that.


Kimberly Eubank:Yeah, yeah.


Tommy Ryan:Yeah. So yeah, I think the things at your disposal for using Agile are definitely going to depend on the organization you’re in, the industry you’re in, which might not lend itself to Agile at all, you might have some things you have to do from a software development standpoint that Agile is not the answer. It’s not the hammer for everything. And we’ve also learned that sometimes you have to have a hybrid approach and I think the way you describe it, you have to make it hybrid every time, you have to integrate it within your organization based on that, how that organization works. And we’ve looked at things like migrations, for us that’s been a big part of a hybrid Agile approach where we go from Agile that discovers what do you need to customize in terms of the experience of what you get after you move the content, do we need to do updating to the tooling that maybe is a gap of what needs to be done, and then we take it into those strict waves of migrations that is really a Waterfall step for us when we go through that.


Bob Morris:Yeah, and I think that the market has matured enough and knowledge of Agile that you can’t just say that word and think you’re going to get a good reception every time. I mean, we recently had a workshop with a customer for a migration and we were talking about the fact that, yeah, we’re an Agile shop, and they actually got very concerned and excited about that because they were saying that’s not a good fit us for a migration, we need reliable gates that we go through, you have to be able to get in there-


Tommy Ryan:I think I know who you’re probably talking about.


Bob Morris:Yeah. Unnamed. And we had to explain to them, no, we use Agile when it’s appropriate for the portions of projects where we’re doing things like we’re doing code and feature development, but once we get into certain kinds of projects and work streams, like doing the migration, we’ll use something different. It’ll be a Waterfall or an incremental, but it won’t necessarily be an Agile. We’ll use Agile principles, we’ll do things like we’ll still have daily stand ups. Everybody feels better that they’re connected if we do that. We’ll still be transparent about our progress, we’ll have information radiators about what percentage of the migration is done at a certain point, what’s been moved over, what hasn’t. But you can’t just cling, like you said, dogmatically to these Agile practices all the time. It just doesn’t work.


Tommy Ryan:Fall back to the principals, I think.


Kimberly Eubank:Yes.


Bob Morris:Yeah.


Tommy Ryan:If you can think about what is the principle and apply it to the context that you’re in is key to making it successful.


Kimberly Eubank:Yeah, absolutely. And I would say that that hybrid, every time I would go into a new company, how I hybridize would be different at every company. Just because I figured it out a company A doesn’t mean I can pick that up and take it to company B because company B’s got completely different processes, completely different teams, completely different company. And so I completely agree with you, it’s taking the best parts of everything and putting it together to form the most efficient, expedient, holistic end result. Because at the end of the day you’re there to complete a task.


Bob Morris:Right, and the process should serve you. You shouldn’t serve the process.


Kimberly Eubank:Yes.


Tommy Ryan:This has been a great conversation. I really appreciate the knowledge you guys have shared with our audience here, Kimberly and Bob. You guys have great experience around Agile, making it real, making it practical, making it work within the enterprise and making it purpose fit. So I think folks that are interested in the topic should learn quite a bit and we appreciate the time you’ve invested in this conversation.


Bob Morris:I have a blog post to mention, the topic we were talking about with the migration, the hybrid approach, we actually have a blog post on that.


Tommy Ryan:Okay. It’s awesome. We’ll link that up in the show notes. All right, thanks for your time.


Kimberly Eubank:Thank you. I really enjoyed it.


Tommy Ryan:All right, adios.


Thank you for listening to the Work Together Better podcast. We’re available on SoundCloud, iTunes, Stitcher, and Tunein. If you’re looking for a partner to help you craft a modern digital workplace on the Microsoft cloud, please come by and see us at That’s the number three spelled out, Thank you and have a great day.


Tommy RyanPractical Agile in a Complex Enterprise Environment

Join the conversation

This site uses Akismet to reduce spam. Learn how your comment data is processed.