The Agile Coach Podcast - Ep. 37 | Life And Work As A Scrum Master And Agile Coach with Laxmi Khanal

Ep. 37 | Life And Work As A Scrum Master And Agile Coach with Laxmi Khanal

02/24/22 • 55 min

The Agile Coach Podcast

HIGHLIGHTS

Working as a scrum master in Mayo Clinic and acquiring an Agile mindset
Empower your team by not making them excessively reliant on you
Learn how to ask the right questions, then ask some more
How to create transparency in your team
Working with leader to develop an agile mindset
Handling a difficult member in the team
What is the biggest hurdle to success?
Good leadership is largely about building good rapport with co-workers
How to be an effective facilitator
Don't be afraid to change things up if you're not achieving the desired outcome
How to make retrospectives fun, engaging, and productive

QUOTES

Laxmi: "I don't find myself needing to jump in to fix things for my team. In the past, when I work with teams, I used to find myself in a situation that I'm sure a lot of scrum masters out there have felt this way at some point in their careers, where in the process of being helpful, you kinda create this need for your team to become excessively reliant on you."

Laxmi: "Allow the team to learn by doing something poorly. Let them have a bad daily scrum. We humans, I think, learn when we make mistakes. That's how I learn."

Laxmi: "First, it's really helping the team understand what we're tying to get out of by visualizing our work. What is the reason behind transparency."

Pabitra: "So it's not, you're not shoving and pushing, you're not a dictator. You're not saying, hey, like do this or do that. But you're really helping them come up with your own like ways in a way and saying, Hey, you know, I see like what you're doing here and that provides value, but here is like also by not having this in place, there's this here's what's causing us or here's the problem that's causing."

Laxmi: You really want to build out a one-to-one relationship and coach them a little to find out what is getting in the way of them being a better team member, right. What is that internal dialogue? And the biggest thing is you have to be open to the experiences of that person, without any judgment."

Laxmi: "I firmly believe our style and personality obviously plays an important role in our ability to effectively facilitate. However, as a scrum master, you shouldn't just subscribe to one way of facilitating team events. Yeah. So just like, you know, you're advocating to the team that, Hey, there is more than one way to achieve the same outcome. You also have to believe that there is more than one way to hold, for example, a daily scrum. If your team is still asking the same three questions, what did I work on yesterday, What am I working on today? What is progressing in my work? Then I believe you're just going through the motions and most likely, so is your team."

Laxmi: "As a facilitator, you have to create an environment for the team to perform at their best. And if you're not experimenting with your technique and, you know, doing what's necessary to provide, the setting that's needed, where the team can reflect, they can discuss and have fun, I don't think you're growing as a scrum master or caring enough to bring them, bring the group together."

Learn more about Laxmi in the link below:

Linkedin: https://www.linkedin.com/in/laxmi-khanal-921687100/

HIGHLIGHTS

Working as a scrum master in Mayo Clinic and acquiring an Agile mindset
Empower your team by not making them excessively reliant on you
Learn how to ask the right questions, then ask some more
How to create transparency in your team
Working with leader to develop an agile mindset
Handling a difficult member in the team
What is the biggest hurdle to success?
Good leadership is largely about building good rapport with co-workers
How to be an effective facilitator
Don't be afraid to change things up if you're not achieving the desired outcome
How to make retrospectives fun, engaging, and productive

QUOTES

Laxmi: "Allow the team to learn by doing something poorly. Let them have a bad daily scrum. We humans, I think, learn when we make mistakes. That's how I learn."

Laxmi: "First, it's really helping the team understand what we're tying to get out of by visualizing our work. What is the reason behind transparency."

Learn more about Laxmi in the link below:

Linkedin: https://www.linkedin.com/in/laxmi-khanal-921687100/

Previous Episode

Ep. 36 | On The Kanban Method And Other Agile Practices with Matt Philip

HIGHLIGHTS

A lifetime of learning
What is Kanban?
The Kanban Iceberg: it's not just about sign cards
Explaining Flow
What does a flow manager do?
Measuring Cumulative Flow Diagram (CFD)
The Agile Manifesto
How to coach a team on XP (Extreme Programming)
On Service Delivery Review
Measuring outcome vs output

QUOTES

Matt: "It's been really nice to see how different people are doing things and learning from other people and different places and pick up bits and pieces. For me, an agile mindset is one of learning and so picking up bits and pieces where people are doing some interesting things, trying interesting things, and that's what I've just done. Very little of what I've done is my own novel idea. It's really just incorporating other people's ideas and making it work."

Matt: "Kanban helps us to see how our work works. It's really making visible the work systems that we work in."

Matt: In knowledge work, where we are in, intangible goods, it's harder to see the work. It's stuff that lives in our computers and in the cloud, and so it's not quite as transparent and visible as in a physical goods environment.

Matt: "It's a way of, I talk about humanizing work. For me, seeing how actual people were doing work can be overburdened and stressed out by having too much work to work on, or not having a visibility into how things are working. And so it's about the work's sake, but also the worker's sake that I really find Kanban to be a helpful way of thinking really about our work."

Matt: "The Kanban Iceberg metaphor that I've used in the past is, that which is seen at the top of the iceberg, which is the sign cards or the cork boards. But there's so much of the Kanban method that's below the surface. Not quite as easily seen. I think about the other practices, the principles, and the values."

Matt: "In my experience, I've experienced lots of different places that say Agile and do Agile. My very first experience was doing XP extreme programming orientation. My main experience is initially doing Agile stuff from an XP standpoint. For me that's really valuable because I understood the importance of engineering excellence and technical excellence as opposed to just the organizing principles of some methods that are useful but don't necessarily speak to what code looks like and what deliverable work should look like."

Matt: "Make it okay to fail. We talk a lot about psychological safety. Making it clear that it’s okay that you're not gonna get it right the first time. And being resilient in that experience and to learn from those things."

Matt: "If doing something fast is important, there's tradeoffs obviously, maybe the quality suffers but sometimes the customer's okay with that. It takes a very important conversation to make them aware of the implications of taking some shortcuts with code. But one of the things that I find useful, for example, is predictability. Being able to be predictable in delivery, to the extent that we have control over some of these sources of variation and impact."

Learn more about Matt in the link below:

Linkedin: https://www.linkedin.com/in/matthewphilip/
Website: http://mattphilip.wordpress.com/
Twitter: https://twitter.com/mattphilip

Next Episode

Ep. 38 | What It Takes To Be A Product Owner with Richard Seroter

HIGHLIGHTS

The role of a Product Owner
Leadership factor in Product Ownership
Difference of Product Ownership and Product Management
The setup in Pivotal and Centurylink
The importance of updating versions and models
The leadership style needed in Product Ownership
Building a relationship with the team
How to build relationships with the engineering team
Managing and sourcing backlog items
Best practices for decomposing and refining backlogs
Best practices for continuous improvement
Best approach for prioritization
Best practices for product life cycle
Richard’s advice to new product owners

QUOTES

Richard: "Because look, if it wasn't for agile, I don't think you need the idea of a product owner, if we were shipping every three years. Those were the old days, I was in those projects, those big waterfall projects where you did requirements for nine months, it coded for a few months, and you did a bunch of integration testing for twice as long.”

Vivek: “It's a very demanding job. It's a really rewarding job in a minute, you know, you have to be technical. There's a lot of elements of leadership, prioritization, which is so important.”

Richard: "A product owner needs to still be sitting there, readily talking to customers, readily talking to your internal teams, they care about your product, and regularly talking to engineers.”

Richard: "There's gonna be different paradigms. I think the important thing is who's going to make sure that you don't add a lot of friction between; what are we trying to accomplish? And how does that get broken into work that engineers can work on? As long as you don't add friction to that and mess up that process I don't care what you call people.”

Richard: "And so as a product owner, product manager, I have to be really good at identifying good data sources, adding telemetry to code, and knowing how to find some signal in the noise, because I can just get drowned in data points.”

Richard: “A good product owner leads through influence. They don't have direct authority. They don't have a management staff of people, the engineers don't report to them. No, but you are leading, often by showing that you have their back.”

Richard: “I learned quickly, especially with a few folks who were a little more grouchy, that I have to prove I've done the work first.”

Richard: “If you want a good relationship with engineers, show you care about their thing, and genuinely.”

Richard: “Yeah, I mean, arguably, some of the best parts of DevOps of Agile have these ideas that you should first of all be hiring people who are never satisfied and not in the sort of like, they're psycho. So we're just always mad about stuff. But like you people who don't just settle in go and like, good enough and good enough.”

Richard: “Sometimes your priority is stabilizing it, sometimes your priority is growing something else. Sometimes your priority is maybe just finding a new market. So I think that's the awesome, fun part of this job is that there's no single sort of Product Strategy for each person. But you have to stop, observe your landscape, talk to stakeholders, understand your corporate priorities, and then reflect that in your backlog.”

Richard: “But you know, hey, look, a good product owner says no, a lot. A good product owner does not say yes, all the time. That is a bad product owner, right? Because you should be saying no, you should be retiring features, retiring products when necessary. So first half, you have to think of the end sometimes.”

Richard: “ Are you a learner? Are you someone who's going to come in here and invest in the relationship, you're not gonna, you're gonna have some courage, and you're gonna have an opinion. And I want to hear your point of view. And you're not just a yes person who comes in and says yes to everybody, or, you know, you're going to come in with an opinion, you're going to be observant, you're going to listen.”

Learn more about Laxmi in the link below: