All Things Agile - Episode 008 - Nupura Kolwalkar Interview
Agile Instructor - Coaching for Agile Methodologies such as Scrum and Kanban
English - September 28, 2014 00:46 - ★★★★ - 10 ratingsBusiness agile software scrum kanban lean Homepage Download Apple Podcasts Google Podcasts Overcast Castro Pocket Casts RSS feed
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!