All Things Agile - Episode 008 - Nupura Kolwalkar Interview

I am thrilled to bring you a true business leader to the show. This episode features an interview with HealthPort CTO, Nupura Kolwalkar. Learn how she championed the transition to Agile in her organization. We will discuss challenges, tips, and most importantly, results.

I hope you are enjoying the great targeted content on this podcast. Please take a moment to subscribe in iTunes using this link: iTunes. Also, please send me your thoughts and questions using [email protected].


All Things Agile - Episode 008 - Nupura Kolwalkar Interview

Transcript:

Welcome to the All Things Agile Podcast - your destination for tips and interviews with the leaders in the world of Agile. Don’t forget to subscribe to this podcast on iTunes and please check out our sponsor: TeamXcelerator.com. And now, here’s your host – Ronnie Andrews Jr.

Ronnie: Hello everyone and thank you for joining me for another exciting episode of All Things Agile. Today I’m joined by a special guest: Nupura Kolwalkar. She’s a long-time friend and former colleague of mine. Nupura is a business leader who is utilizing Agile to accelerate her organization. So first off, thank you Nupura for joining us today – it is definitely an honor.

Nupura: Thank you for having me on the show.

Ronnie: Can you please take a moment to tell our audience more about your background, maybe both personally and professionally?

Nupura: Sure! So I have been in the healthcare IT space for about 9 years now. I have been exposed to all aspects or most aspects to approach IT from a revenue cycle, clinical, HR and analytics perspective. So a good, broad understanding of this day’s American healthcare industry. It’s been an interesting journey – as much as everybody focuses on the actual industry and the domain expertise, through 9 years, more of my learning has been on the talent management and process simplification side, although the domain expertise is always a great plus.

What I enjoy most about my role, where I’m at now, is that I get to see folks learn something from simple processes and direct conversation that helps them to be better professionals at their workplace and find joy in working with their teammates.

Currently, I am working at HealthPort Technologies as the Chief Technology Officer. I have worked in the past with companies like McKesson, Pfizer, NextGen – so I have a wide variety or background, but I’ve definitely found my groove where I am.

That’s professionally. Personally, I have two young kids, a husband, a house, a typical family with a dog as well. So, standard young family, mom role at home. So my goal always is, if I take on a new challenge, how do I rely on the talent that I hire and work with to achieve my personal work-life balance; which is usually measured by how many times in a week do I have to take my laptop back home. And currently I take my laptop home only in the weekends, which I think speaks to my theories and my co-workers and the folks that work in our organization.

So that’s probably more on the personal side. I love to travel, love to interact and learn these things; I love change, so change is probably the most constant thing in my life.

Ronnie: That’s a great introduction – thank you so much! First off, I really wanted to thank you for coming on the show because you’re really our first guest that’s coming on as a business leader. We’ve had some other guests before that were sort of with the Agile gurus and more like instructors and so forth; but I’m really excited to have an actual person who is putting this in place in the field as a business leader and implementing Agile in their organization and being able to testify to the impact. So with that, I’d probably like to dive into our first question which is: As a business leader, how has the use of Agile impacted your teams?

Nupura: When I think about the question, there are so many little impacts that make a big impact; but at the end of the day, to really pinpoint a couple, I would say my biggest satisfaction from bringing Agile to our organization is it’s allowed the organization to scale fast and work correctly really early on.

We do two weeks test, so in a couple of weeks we usually know if something’s going to work through the organization, because we’re able to demo to the business. And if it doesn’t, then we’re able to course correct early on in the process. My next key point is showing business value. This is probable where I feel that Agile has come true in the most significant way and close to the idea Agile principles. But showing business value: when I walked in we had internal tenth day quarters because we had a good evaluation aspect to work with, as well as products and we had to wait 6-7-9 months to see what came out, but as we moved to Scrum and we installed the demo process, the stakeholders got absolutely addicted to it. They wait for every Tuesday to get the demo for their operation goal and objective.

The business value, it helps us, it helps them, it helps the organization and save a lot of money. As a business leader, between the two of them, what is ultimately impacted is the cost and efficiency that we’re able to achieve and through our organization because of fail fast, course correct early principle in Agile. So those are the two biggest ones. There are quite a few little ones like the morale of the team. Once we settled down with Scrum – it was definitely difficult to get there – but once we settled down the morale, the motivation, the commitment and ownership are definitely very high on the radar. Sounds like little things, but ultimately the team puts the show together so they are highly motivated, and you get better results. So those are probably my key 3 points that I would point out.

Ronnie: Sure. I love that answer and I really like the phrase you used that the stakeholders were addicted to the demos – that’s awesome. And I would definitely agree with your experience that when you are able to provide those demos and be able to course correct early, it keeps you from making costly mistakes later. You don’t want to be 6 months later at the end of the release and realize that what you’ve developed wasn’t what the stakeholders really wanted.

Nupura: Right, absolutely. And one the things that I would like to point out is that it takes time for the teams and the stakeholders to get to where we are. In the process, many times the stakeholders won’t show up for a demo. And they’ll show up for the next and skip one and they would start complaining ‘Well, that’s not what I really asked for’ – but the demo is our way to hold our stakeholders and customers accountable for what they asked us to do. So our response would be: If you don’t show up to validate what you need, then you get what you signed up for because we’re not going to go back and invest in correcting the mistakes. So it’s a bi-directional accountability as well. The demo holds the team accountable to the stakeholders, but what I have found very interesting is that’s my only forum to hold the stakeholders accountable to the team.

Ronnie: Excellent point, excellent point. I totally agree. That’s a really key factor there; being able to hold each other accountable. Well, I think that probably really dove-tails well into our second question, which is: What are some steps that you are currently using or in the past have used to help adopt Agile practices?

Nupura: Good question, Ronnie. And I think we did really good at McKesson. I changed the direction of how I wanted to go about doing this at our business. The theme of this implementation has always been: let’s have a grass-roots level movement, not a top-down level movement, but have a  grass-roots level movement with top support to it. People ask me what I have learned; I’ve done this in a couple of top organizations – if I had too many external folks involved who did not understand the impact of a good or a bad process, or the lack of a process, it added a lot of noise to the organization. Why go through this change?

And one of the things I have definitely seen as we implement Scrum is that we do see attrition. I have seen close to 25-30% attrition in all the last three cases that I’ve implemented this process. So a couple of things we did. My functional management team and I sat down and planned for what happens if we have attrition? What is it that we need in our organization to ensure that we can take on the attrition? Which is mainly knowledge redundancy – do we have knowledge redundancy in the organization? If there are people who are going to leave because of change, will the organization, the stakeholders and ultimately the customers suffer?

So that was one question. The second was: what will it do to our morale organizationally, and what would it be as a reflection of the management team? That was relatively new to HealthPort. So those were the three answers that we wanted to answer so that we can deliver to the business; we wouldn’t have a revenue impact to the business, but we’d be able to take this organization through the change at our own pace instead of someone else’s pace.

Once we set goals for those, the rest of the time was getting the knowledge documented because when I walked in there was nothing documented. And when I say documented, it’s not pages and pages of requirements. It’s really about change. For example, this particular area is a little bit difficult to understand. Let’s put it into our knowledge pack that we give to our new hires. So the first thing we do in getting ready for Agile was a new hire packet because we knew we were going to go through attrition and we wanted a good, stable base to hand over to our new hires as they came in. So we implemented a new hire packet. We planned for attrition by getting the knowledge into visual workflows and these workflows were located on the walls, they were in the team environment. They weren't living in a tool; they were out there in everyone’s face so people could just walk over and look at them. So that was the trick to even think about Scrum.

But once we started to actually think about Scrum, one of the ideas that I’ve used back in my McKesson days was to put together a team of the teams to build it in a way that the teams hold themselves accountable to this change and they wanted to go through this chance. So we called our team Matrix, because it truly was a matrix of different roles. Now, one of the things we did do differently here than what I have seen done – there’s a big focus on no functional management or leadership should be in any of these meetings. Now, we haven’t released functional managers but there is no stress between the contributors and the management teams. We work well, so they asked us to help out so that we could use some of our time and save them some project time in order to take this through change.

So our Matrix team consisted of some functional leaders, but not all of them, and contributors from each function area and a couple of stakeholders outside of my direct organization to help them see how they’re going through this change, and how is it going to impact them. And the team pretty much put their agenda together; they worked through our town-hall meetings, and monthly staff meetings to get buy-in from directors in the organization, next steps, morale boosters, coaching – which is the biggest thing in my opinion. We trained a team so that a team can start to train at the peer level to other teams. We had, of course, formal coaching which can never be replaced in my opinion.

It was a 6 month effort to transition the whole organization to Scrum. We did it based on the revenue impacts that we could forecast. Cause, you know, when you plan for attrition, you have to make sure that key knowledge is not lost; and if it’s going to get lost, what’s the impact that it would make. So all in all, it was a gradual movement reported completely by the management teams and implemented by the individual contributors through the individual contributors. I believe it took us to stabilize, maybe about 6 to 9 months, just to stabilize. We saw a very high level of attrition, but we were able to plan to bring new people in and have them absorbed into the organization without an impact. It did, in fact, impact morale, and I want business leaders to recognize that when they sign up for these things, we have to do morale boosters for the organizations because it’s hard to see your colleagues leave because they don’t agree with the culture that’s coming into play.

So that was my biggest struggle – to keep the motivation and morale level high through this change. And we also discovered that there were a couple of things in Scrum that don't even apply to those teams because of the turnaround times that we required on those teams. So all in all, in 6 months the team did it – all I had to really do as a business leader was to have their back and be supportive. We did all of this internally with none of the businesses stakeholders really knowing what we were doing because they were still getting their projects delivered and introduced the concepts very slowly to them,  the demo being the first thing that we introduced. So there was the transition period, we allowed people to transition at their pace, not our pace. And I believe we came out really good out of the transition and I do believe having the individual contributors drive it really helped that process significantly.

Ronnie: I would agree, and I like your insight. Again, as a business leader regarding, for example attrition because that’s really something that most of us wouldn’t have even considered, right? And it is true that in any organization, doesn’t matter what it is, you’re going to have some individuals that are going to embrace change and you’re going to have some individuals that are just very resistant and they just don’t want to change and when you’re trying to implement any type of process change, there’s also going to be a degree of friction and it’s important to be cognizant of that. So I’m glad you…

Nupura: And plan for it. As a business leader responsible for $400 million – in my case, if I haven’t planned for it behind the scenes that would’ve been a huge impact that the organization couldn’t absorb because of their size. Another thing I would like to point out on that is that it’s not just that people don’t want to change. What I saw was – sometimes the pace is too fast for some people. We have lost some really extremely talented people who had great business knowledge because they couldn’t deal with the pace of this sprint. So trying to find that balance and letting the teams come there was definitely another big challenge that we had to face.

Ronnie: That’s a good point. Well, Nupura, why don’t we transition into our next question; it’s a little bit more of a tougher one, it’s definitely more of a challenge and definitely someone looking for an answer from a business leader, which is: how are you currently, or perhaps in the future, look into tie in the HR component to the use of Agile? For example, what do you recommend to other business leaders to provide performance reviews, rewards, to encourage successful Agile adoption and use?

Nupura: I have been asked this question a couple of times before. From my personal perspective, given our context and culture, it’s a little bit different to perform mixed measurement and management. And myself have gone through a lot of performance metrics, being a leader, I’m doing it a little outside the box. So what we do, and I can only speak about what I do and it is working pretty well in our organizations: two things. There’s a team level performance which is directly tied to the outcome of the Agile aspects of the process. I don’t really say it has to be tied to a date, although dates are important, don’t get me wrong – but I don’t really tie directly to their run-rate – it’s about what outcome did you achieve at the end of two weeks, at the end of four sprints is how we measure it. And we have data that we use to measure it internally. We do surveys with our stakeholders, we do after-demo surveys for the big projects. But it’s very outcome-based, not necessarily estimates vs. actuals based. Which is a little bit of a different way to look at Agile. And I’m sure not all business leaders would agree with me, but it worked well for the team, it helps with the morale and motivation.

Now, with personal performance management, we focus on in the individual and team, and on the individual side, where I say that Scrum helps the most, is in more than the management itself. It was the individual found it easy to break down some of the barriers that they need to find like communication. Like let me cover my basis constantly via email. Those things, I think, Scrum really challenges you to open up, break the barriers and get into an uncomfortable zone of direct communication.

So through this, while we were transitioning a few things we did was measure our folks. Not necessarily whether they’re performing well or not, but measuring our folks to see if they’re able to get over that barrier and help them with a lot of personal coaching, outside coaching, to get over the barrier of direct communication and conflict management. So those are the two things where I have found value in implementing Scrum and the fact that implemented Scrum has brought out our talented folks to be direct, respectful and ready to deal with conflict. I haven’t really thought of tying any direct Agile results to individual performance and I don’t know if I will get there, because from all different perspectives – I do feel like artificial data like dates and boundaries ultimately don’t measure a talented person. It’s the creativity and it’s the outcome that they provided to the organization, along with their commitment, that measures the individual. It’s maybe a little bit of a different answer, maybe not expected.

Ronnie: Sure – it’s great! I definitely appreciate you opening up and explaining what you have seen and I hope that that benefits other members of our audience, so thank you so much. With that, I’d like to transition into our final question which is: What advice would you like to give to other organizations that are considering adopting Agile?

Nupura: Agile and Scrum works for any organization. Several times when I’ve been on forums, where I’ve engaged some of my peer conversation, the first thing people say that even though you had all the right stars aligned to put Scrum in – that’s why you were successful. Scrum’s not for me, Agile’s not for me – anything that bases off from my organization. I really, truly, passionately believe that Agile is for anybody and it is up for the business leader to find ways to bring such a wonderful bi-directional accountable process to the organization for the better of your talent. At the end of the day, your talent is going to be at a better place once you have this process.

And I hate to call Agile a process as well, because it’s a principle, it’s a mindset, it’s a culture. It’s not so much just a demo or the retrospective; it’s how people think when they start to practice Agile. That’s what I love about what this methodology brought to our organization. So given that, I would say be open-minded and be ready for a change. If the business leader is not ready for change, then there’s no way you can transition into something that’s so intrusive to the organization, creates a lot of noise in the interim, but knowing where you want to get to, you should be prepared mentally, organizationally, knowledge-wise to cross that barrier as a leader.

Now, one of the lessons learned from my past is, in the first round, we all read books, we all were trying to implement Agile in a very waterfall organization. We all read books and we said we are going to follow Agile to the end nth principles. So we started with the expectation to have an ideal implementation. What I’ve learned through taking two or three organizations through this is the core would be to get to an ideal implementation, not to start at ideal implementation. And it allows for people to absorb change, leave, come back and embrace the growth of this methodology, instead of the brute force of the methodology. So we, having been in product management and strategy for a long time, I always tell the product managements: the thing about minimal value products instead of the perfect product – I have applied that principle to the implementation of Agile. Minimal viable that shows the value of the change itself. If you’re able to provide the value to the business and to our own organizations, then take the next step. So don’t use the Agile principles to implement Agile. That would probably be my biggest take-away.

Ronnie: That’s a great point. Love that answer! Well, thank you so much Nupura for that great advice and insight and thank you once again for joining us here on All Things Agile. It’s been a real pleasure.

Nupura: Thank you for having me on the show again and I’m glad to be here with you, Ronnie. Great job on what you’ve started here!

Ronnie: Well, thank you very much to our special guest Nupura Kolwalkar and thank you everyone for listening to another great podcast. Look forward to seeing you again! Thank you!

Thank you for listening to All Things Agile. We look forward to you subscribing to the podcast on iTunes and leaving a kind review. Thanks and God Bless!