Agile transformation and delivering “first value” with Jeff Despain of CHG Healthcare
One of the most difficult transitions an organization can make is moving from “how much will that cost?” and “how long with that take?” to “how quickly can we deliver first value?”
That’s the essence of Agile transformation, so Ledge sat down with Jeff Despain, Sr. Director Engineering at CHG Healthcare to discuss the company’s relatively rapid and intensive transformation to Agile product teams — a full 80-person org in just over 9 months.
Jeff shares lessons about change management, leadership, and customer-focused value.
Transcript
Ledge: Jeff, great to have you. Thanks for joining us today.
Jeff: Hey, I’m very excited to be here.
Ledge: It’s really good to have you. Could you give two or three minute intro of yourself and your work, just so the listeners can get to know you a little bit?
Jeff: So, myself right now today, currently Director in IT for CHG Healthcare. We have a team of about 30 engineers. We’ve got a team that’s recently gone through kind of an Agile-Scrum transition over the last year, which has been pretty exciting.
We’ve also adopted some new technologies. We’ve had a lot of technologies develop themselves for us. We’ve incorporated more capabilities where we’re now building in AWS and doing a lot of cloud development. It’s been a great transition for us.
All of that over the last year and the team had done just a great job. We’ve come from a lot different place a year ago to where now we’re kind of already through some of these transitions and we’re really starting to start hitting on more and more cylinders.
Ledge: So you’ve got a platform-to-platform, technology-to-technology, a legacy upgrade kind of disposition there. I wonder, outside of the technology, what’s that been like? The change management from your perspective. Trying to move attitudes, talk a little bit differently. I mean it’s just a lot different going on there. That’s a lot of transition for one year.
Jeff: It is a lot of transition for one year and we were really concerned about it, to be honest, going into it with a team that has pretty high tenure. So this kind of change was one of the considerations and concerns we had going into it, especially around Agile Scrum.
However, we on-boarded, we brought on a team to help us go through that and consult with us as we went through that, and I think that kind of helped. Also, just the culture. We’re lucky to work in a place that has a really good culture, and that culture along with a lot of the Agile principles, really helped us move a pretty good size team. The size I gave you was just the developers, if you consider the whole team, we’re probably 70, 80 people that went through that transition.
I think really – I’ve been through this kind of transition before with other companies. It took a little longer. Here I’d say it’s taken us about nine months to get through that to where we were not looking back and saying, “We want to go back,” we’ve already passed that. And so, I think the culture had a lot to do that and being considerate of the change management.
Also, there’s a pretty high-touch approach to leadership here, where we do weekly one-on-ones and stay really close to the people as leaders. So, I think that helped through that transition.
Ledge: Yeah, how do you arrange 30 engineers you must have now with a Scrum team approach? What was the difference in the team and organization arrangement, as you went, I’m guessing, from more like a waterfall format to now a Scrum team?
So, how big are they? How did you arrange leadership and management around that transition? How do you break up the work?
Jeff: That’s a great question. Functionally we didn’t change too much. The functional reporting kind of stayed the same.
However, the first thing we did that lasted just a few months was we broke up into product teams, and we organized the product teams around our business value stream. So with those product teams, that provided some focus, first for each of the teams, and started helping us build out the teams and separate them into not just focus but the right size teams.
That lasted for a few months. Then we came in with Agile and started building specific Scrum teams. Right now we have eight Scrum teams under that number of engineers. I guess I should add all of our engineers are involved in that, so we’re probably up around 42. We’ve got an average of five engineers on each Scrum team.
Ledge: So you broke them up along product lines then. So there’s a customer alignment there?
Jeff: Yeah, with our value stream and our customer alignment. We’re a bit of a sales organization. We do staffing for medical companies, for hospitals. Our clients are hospitals, and physicians would be our providers, and we match them up.
Where there might be a position opening with a client, with a hospital, we help do all of the logistics of finding and credentialing involved with onboarding a physician or a provider.
Ledge: We know that business – just not in healthcare. Right? I’m interested, just from a technology perspective how do you facilitate maybe some of that matching kind of thing? There are a lot of business that use essentially like a two-sided marketplace. Basically, you’ve got your customer and you’ve got your provider and you’re putting that together. In the middle, you’re the technology and human middle-ware there.
What’s that look like and how do you address that? A lot of people try to build businesses like that.
Jeff: Well, it’s not all technology. I think, for CHG healthcare especially, a lot of it is fairly high-touch.
We have a great sales department and they’re pretty high-touch reaching out to the clients and the providers. Where we are wanting to grow more is in the tech. So we’re focused right now on not just being high-touch but also high-tech. And for our clientele, clients and providers, providing a little bit more user-friendly technical experience for them where that comes into play.
So, it’s truly going to be, going forward, both of those obviously, getting a lot attention from us as a company. From an IT standpoint we’re pretty excited that we have an opportunity to bring that high-tech. The company is investing in that and we’re going forward with that focus.
Ledge: You talked about Salesforce, obviously a big SaaS product. You talked about AWS, which means you’re going from on-prem to cloud. How does that play in? Did you find that that transition had to happen at the same time as Agile?
Jeff: Well, no, we actually did it at the same time but it didn’t have to happen at the same time. It was an opportunity for us…
Salesforce is a large part of our infrastructure and a lot of our toolset. What we saw was an opportunity in some of the new solutions we want to provide, to look at some other technology stacks – and costs is one of those things we’re always looking at. So, we were looking at some of our external-facing solutions and we felt like AWS was a good platform. Some of the technologies we wanted to work with would work better in that space.
Really, what we’ve done is just increase our toolset and out digital platform so that we, now when we look at what we need to provide for our internal company or for our external-facing company, we have a toolbox where we aren’t constrained by just one set of tools but we can leverage whatever and come up with the best solution for us and for our clientele.
Ledge: As a new Agile organization, I’m interested to know, how has your estimating and budgeting evolved?
Jeff: Well, that’s a great question. We were very, very project-centric before, which I think is probably typical for a lot of companies that look at Agile and move to that, they’re probably coming from a very project centric mindset. Becoming product centric, especially in IT, is a little different, right? Especially when you’ve got a lot of internal IT projects that appear to have start and end dates, project kind of fits that.
Whereas product you’re looking at building and maintaining something longer term, adding in different versions and revisions and really keeping the focus on that as a product. It’s a little bit of mindset there so the estimating becomes a little different too.
I think you’re aware of Agile Scrum. You’re in a different mindset where you’re starting to put more of that ownership closer to the team but that’s actually gone pretty good. We’re able to differentiate our focuses. We have product managers running different parts of even our internal development, and the teams have over time started to refine and develop that backlog more and more.
Initially that was kind of rough but now they’re starting to get a pretty good step on that, and our estimation is now a little bit better. Then it gets harder… We’re still going through a little bit of the challenge of, we’re not just sticking the data out there and trying to hit it, we’re focusing more on delivering value.
But I think what we’re seeing is, with the frequency of the times we’re presenting that value – at the end of every sprint, for example – that the collaboration with our customers just keeps getting better. They don’t feel like they have to wait six months or a year longer before they get an update. They’re getting that more frequent.
So the discussions around that date all the time seems to start moving away to, “When can we get this value?” and that type of discussion. So it’s actually a great change from dates to value.
Ledge: I love that. That’s a really great way to summarize it.
Now, you obviously had to have high-level business buy-in as well. This is all the way up to, I’m guessing, your operations and finance level and probably highly executive. Because you can’t shift from that disposition unless you have the buy-in to say, “We can no longer cost and budget per project,” which means so it goes all the way up. It has major budget implications even at the P&L level.
Jeff: You’re exactly right. It does go all the way up and we’re fortunate to have that. In fact, there’s a lot of credit given to the team and those involved kind of pushing and driving this transformation. We call it evolution because it never stops. But without the support from higher up, without the funding, without the continual backing then it probably wouldn’t have been successful as quick, right?
I’ve heard of situations where a company is trying to bring on Agile Scrum from grassroots and trying to develop, and that can work but that’s a longer term thing. But at some point you’re hitting into business and getting them to engage.
I think with the approach we took, the support was there right from the beginning and the business was encouraged and also didn’t have to be encouraged very much. They were just right on board to get in and understand what we’re doing, and how they can be involved and how this can be wins for everybody. That was very helpful in that process.
Ledge: Yeah, I’m sure that send you home with more of a smile than trying to drag the change management train behind you.
Jeff: Yeah, absolutely. Change management-wise, getting the business buy-in initially and having that buy-in continually really helped make the process smoother for us.
Ledge: My last and favorite question. We are in the business of finding and vetting, evaluating and then placing the very best software engineer. We take that very seriously. We have a multi-tier process, all kinds of interviews, testing, et cetera.
That’s said, we know we can always learn from other experts in the field. You’ve been doing this for a long time so I’m curious to hear from you, how do you evaluate and find and understand that you’re talking to the very best engineers for your team? What are your hiring heuristics to bring the best software engineers on board?
Jeff: Well, that answer may surprise you a little bit. We have a breadth in skillset levels with our engineers. And with each of our Scrum teams right now we’ve actually taken a close look at all the teams and the skill levels that we have across engineers. We’re looking at that right now and we’re realizing we have a lot of engineers, what we’d call Engineer II. We have engineer I, II and the senior engineer.
A lot of our engineers are Engineer II. We’re really strong medium/senior engineer type feel. As we build these teams, we’re right now looking at how we want to grow more at the heavy skillset – lead some of those senior engineers and the principal engineers – at the same time bringing on junior engineers and getting more of a bench on each of these teams.
When we hire, however, we don’t jump right into the skills. For us, a lot of it is culture. A lot of it is just discussion with members on the teams with a candidate. Understanding where they’re coming from – where they’ve been working and that but really where they’re coming from for a culture fit. We actually feel pretty comfortable where maybe we hire someone on their strong culture fit that we can blend in and help with any technical growth that may benefit them or the team.
But again, back to what I said, now we’re kind of looking for very high-end engineers, like we were talking about. How we rate that, we do have some sessions now where if we’re looking for someone that’s a senior principal engineer where they’re meeting with our solution architects and enterprise architects, that’s where more of our in-depth technical discussions are coming from now, not just from peer engineers or development managers.
That’s where, when we’re looking for more of the high-end, we’re having some of those discussions with architecture.
Ledge: Well, fantastic. Jeff, thank you so much for the insights. Thanks for joining us today and best of luck as you continue the transition.
Jeff: Hey, I appreciate the time. Have a good one.