Agile and Scrum Videos

Watch Mountain Goat Software videos on agile, Scrum, product ownership, estimation, planning, and teamwork.

All Videos

Why Most Product Owners Fail (And How to Succeed) with Barnaby Golden

Transcript

Welcome in Agile Mentors.
We're back.
This is another episode of the Agiles Mentor's Podcast.
I'm here with you as always, Brian Milner, and we have a very special guest with us today.
Very excited to have Barnaby here.
Barnabee is an agile coach, also a scrum master.
He is known to us because he is part of our agile mentors community and he's an active member there and has weighed in on several issues and helped people
and mentored people through things there.
So we wanted to share some of the wisdom of, the crowd that we have there at agile mentors, just a few select people that have really contributed and given
us some really good advice there with the podcast audience as well.
So you guys can kind of hear what kind, of stuff is there on the agile mentor's discussion forums.
But we were talking about topics here with Barnaby and about what we're going to talk about, and he proposed one that I really found intriguing.
It was focusing around the underpowered product owner, the Underpowered PO.
And I think that's probably a good place for us to start then.
Barnabee, why don't you kind of just explain to everyone what that idea is, what you mean by the underworld PO?
Sure, of course.
So in fact, what I'll do is I will explain it by giving you the opposite, which is what does a good, effective, powerful product owner look like?
And I was working for an organization a few years back and it was a publishing organization and we had the head of the editorial team was the product's
owner for a particular scrum team.
And this head of editorial had a lot of power and influence in the organization.
They were pretty much a decision maker in terms of the products that the team was building.
And I remember a particular conversation where the theme was talking to this product owner and the teams said, look, we know you want to get this release
out this week, but we've got some technical debt.
We really need to fix it.
I'm going to let me think about this for a second.
OK, I can make the decision on this, which is, yep, you can have your time.
Communicate with others within the organization that the release will be delayed.
And that was such a powerful moment, because in that second, the product owner trusted the team.
The team completely trusted, and it felt slick and efficient and worked really well.
Conversely, I've worked in organizations where in some way, surprisingly enough, product owner is seen as quite a junior role.
So I, I have seen the situation where you have a whole hierarchy of product people and the most junior roll in the product organization is the products owner.
And what happens in that scenario is that the product owner is powerless to make a lot of decisions.
So they have to, they, have, to push them up the tree.
And in, that situation, the conversation between the team and the products owner, is the teams says, yeah, we need to do this thing.
The product says.
Okay, give me some time.
Might be a day and I'll get back to you.
Hopefully I can get in contact with other people within my hierarchy and flows broken.
What's the, team going to now?
They're going, maybe you find something alternative to work on.
It's very frustrating.
And you sometimes get the situation as well, where the, the underpowered product owner will sympathize with something the team is saying,
but will not be able to make a change because they haven't got the authority to do the change.
So they'll say, yeah, I agree with you.
I know what you're saying.
This is a really bad idea, what's being suggested, But I have no choice.
We have a roadmap.
we've got to meet the roadmap Yeah, that's a clear picture.
I agree with you that those are two stark contrasts.
And what I like about the explanation is you kind of highlight the effectiveness of one versus the ineffectiveness of the other,
right?
It's such a dramatic difference when that person is able to make the decisions on the spot, go forward, and the team is just free to move as quickly as possible.
Whereas the other one, it's just holdups.
It's delays and obstacles, roadblocks in the team's way.
So yeah, a really clear picture there.
Just as you were talking about this, I was thinking to myself, well, maybe one of the worthy paths for us to go down here and talking this is trying to
understand a little bit about the why behind it.
Because I think there's just in thinking about it, I, think maybe there are several causes for this or several things that might lead to having an underpowered PO.
What's been your experience?
What kind of things have you seen that may contribute to an Underpowered Po?
I Think the main reason, the biggest driving factor behind it is the feeling that the people with the authority to make decisions do not have time to spend
with a team.
So you've got your head of product or the real decision makers in the organization.
They are saying, I can't spend two, three hours a week with a team.
I Can't go to a planning meeting.
You know, i'm a busy person.
i've Got things on my schedule.
So they see the product owner role as a stand-in for themselves with the team.
And the stand in has lots of time to spend with a team, which is good, and that's a powerful thing.
But at the same time, if they've not got the authority to make decisions, then maybe that time is not effectively spent.
Yeah, it's almost as if they just want a warm body there, you know, like it sits, It's a placeholder.
You're you're here as a, place holder for me.
Cause I can't be two places at once.
I've heard, uh, kind of a couple of things that people will, will frequently point to that a product owner needs to be successful.
And there's sort of this dichotomy of these two things, that are part of that.
That's, the, You know kind, of empowered product, owner that is, is empowered to make decisions.
versus having the availability, uh, to actually be present with the team.
And it's always, it seems like that's a fracture point that sometimes causes this because you have the leaders who, Hey,
I need to make all the decisions, but I don't have availability.
and the people that they know have, the, availability they don' want to empower to, make the decision.
So they're kind of setting up their product owners to fail.
I think it's a classic example as well with when you want to be an agile organization, you can't just have pockets of agility.
You can just to have a scrum team and say, well, that's where we'll be agile in this scrumm team.
The entire organization as a whole has to think in the agile mindset.
And if you wanna be able to adapt to change, then one of the ways you're gonna have to do that is you have the decision makers close to the teams that
are implementing the decisions.
And so you can't have your cake and not eat it, if you see what I mean, in terms of, you, can pick and choose the aspects of agile that you want.
You need to, as an organization, adopt the whole thing.
Yeah, that's always one thing I try to tell people as well is when you're selecting a product owner, when trying to decide who's the right person to be
the product for this team, those are two of the things you have to really consider strongly is does this person have the availability to is this person
empowered to make decisions?
I've run up against leaders before that don't want to empower someone.
And kind of the counterpoint I give them a lot of times is, I don' know, maybe in their head they're thinking this is giving someone free reign to really
long-term decisions on their own, when that's not really the case.
The product owner can be fully empowered, but the decisions that they are making on the spot are just a couple of weak decisions.
You know, it's not a six month decision.
There's going to be sprint reviews.
We're gonna, we're going display stuff and get feedback and we can course correct and all those things.
So once, once you can kind of put it in that frame that, you know it really just a couple of weeks that you're empowering them to make decisions.
I've had more success framing it that way.
What about you?
Yeah, I think that makes a huge amount of sense.
The fear is loss of control.
So the fear that by empowering the product owner, they might do something which they would regard as a mistake.
And they will often see themselves, because they're in a senior position, as being responsible.
If they are responsible and the products owner makes the decision they don't like, perhaps that will reflect poorly on them.
There's a trust issue here.
A good product owner is going to be consulting their stakeholders anyway, and I would think the senior product leadership team is part of their stake holders.
So you would hope that they were keeping them very, very up to date on their thinking, that there would be no great surprises,
they wouldn't do something, you know, suddenly switch from one product to a completely different product.
They would always be keeping their Stakeholders in the loop.
And in which case they would be building up the trust of the people around them.
And then you would hope that over time that they will become more empowered.
Yeah.
I kind of wonder if that's maybe part of it, that the they have a misunderstanding.
of, uh, kind of how the role works, you know, because maybe they, maybe, they see it as completely independent.
This person is just making decisions on their own without consulting anyone.
Maybe that's because that how they do their job.
So they may, may look at that as, this is, how I would do it.
Why wouldn't this person do at the same way?
Well, that not how it's designed.
Yeah, it was designed to be done in concert.
Yeah, it's a misunderstanding of the product owner role and it is also a misunderstanding of why the Product Owner role came about.
which is the reason it was there was to solve the problem of too many chefs, of two many people trying to make decisions.
So there's huge value in the role, but the value and the roll only comes about if that person can actually take ownership of the product.
I mean, the clues in name, isn't it?
They are the owner of products, therefore they can make the critical on the ground decisions, all the time talking to their stakeholders.
So, I mean, as with many things in Scrum, it's about a misunderstanding, a general misunderstanding of what the roles are within the Scum team.
Yeah.
I think they also have the fear of the wrong decision that somehow that's going to lock them in, or this person's not equipped to make the right decisions.
They are the knowledge expert for the product, and so they should be the one making all the decisions, they have authority.
And I have had a couple of cases where I've had to have difficult conversations with leaders to say, Well, let's examine the decision because you're looking
at them as making the wrong decision, but is it the right decision?
You know, you, your, kind of disconnected from the day-to-day of the team.
This person is fully connected to the data day and they're more likely to have more current knowledge.
And it's, it, not always the case that just because it is the, wrong, decision that it actually is, they may actually be right.
You could be wrong.
And funny enough, this brings on to another topic I'm greatly interested in, which is the definition of value.
And that is, if there is no clear understanding within the organization of a value, then decisions become arbitrary.
We decide to do x rather than y in the product.
Well, why did you decide do that?
Well because it was my decision to that.
Yeah, but is there a rationale behind it?
Do you have a definition to the value of x and the of y and why you chose one over the other?
And I think that's part of the problem as well.
The kinds of organizations that don't have empowered product owners also typically don' have a definition of value.
Yeah, I completely agree.
I know I've had conversations in classes where I talk to people about how when you're prioritizing, when your looking at things in your backlog and we
always say you prioritize according to value, Well, what's the value of doing that thing?
And so many times I think there are organizations that can't really identify what it is.
Why are we doing this thing, because it sounded cool, cause it seemed like the right thing to do.
It just felt right.
No, we're doing it so that it does something, it creates some outcome for us.
And if you can even really define what that outcome is that you're hoping it achieves, Well, isn't that the start of the problem?
And I think part of, the root cause of that as well is the tendency for these types of organizations to do long-term planning.
So what they'll often do is they will have a roadmap for the year and they say, in this roadmap, for a year, we will achieve all these things.
And then it becomes less about delivering value and more about, delivering the roadmap.
And I've had conversations with product owners where I said to them, you do realize what we're doing doesn't make sense.
And they say, yeah, of course they do.
But I'm not being measured on sense or the delivery of value.
I am being measuring on whether or not I meet the roadmap.
Right.
That's what's important to me.
You can see how all these elements are tied together within the organization.
Yeah.
No, that's an excellent point.
And you're absolutely right.
So much of our metrics and some of the things that we judge teams on or performance by is basically just a volume kind of metric.
It's how much stuff is being produced.
That's not value.
Volume does not equal value, value can be achieved with much less a lot of times.
If we're This is why sometimes I'll advise product owners in classes to say, look, start of your sprint review, maybe go back and look at some things that
you've done recently and show the metric that's you're using for that thing to see if it's successful.
Because if I've.
If the team's done something in the past three or four sprints and it actually moved the value needle some way.
is increased customer satisfaction, added new members to our site, whatever the thing is, right?
If you can show that kind of business value to it, my experience is that people stop focusing as much on volume, because that's volumes of means to the end,
which is the value.
Yeah, absolutely.
And the other thing I've noticed as well in these types of organizations is that the value they're focused on is not the incremental delivery.
It's usually a new feature or something like that competing.
What you often find is the teams are not end value creators.
They're often parts of the creation of value.
Rather than the whole creation value, there may be a component of it.
And because of that, people will say, well, there's no direct link between you and value creation in the organization.
I find that is very problematic and it really flies against the rationale of Scrum, which is that you want within each sprint,
you wanna deliver some incremental value.
And if you can't measure it, if can clearly define what that value is.
And as you were saying, If the product owner can stand in the sprint review and say, well, this is, the value we've delivered.
How does the team keep motivated?
How do they, how do, they keep passionate about what they're doing?
Yeah.
Yeah, I think part of that is just trying to put yourselves in the shoes of your customers and try to look about what they would find as being really valuable.
I don't know about you.
Well, sure, this applies to you as well.
But we all are consumers of different software products, whether that's a business software product or even games or other things that we would use.
And when they come out with new releases of those things, they came out With release notes.
Now, when They come up with the release Notes, are you looking at the Release notes and going?
Wow, I'm satisfied.
There's a ton of things that's in this release.
Or are You looking through the individual items and Going?
Well, care about that.
I don't care About that on care.
About this, that thing.
Oh, yeah, That's important to me.
Right.
That's what we do.
And, and that's a clear picture of value over volume.
Yeah.
I mean, I think the thing that gets in the way here is a lot of it is the pride of the management team.
So they often have strong self-belief.
They believe they make, they believe by definition the decisions they're making are powerful decisions.
So it's also, I think, one of the reasons why a lot of organizations aren't data driven.
You would hope they would produce a feature and then measure whether or not that feature was a success, but that's not as common as it should be.
There's very rarely business metrics tracked against deliveries.
I mean, I'm generalizing here.
There are many organizations do this very well, but I found there's quite a few organizations that don't really do that.
And it leads to a disconnect with the customers.
I can think of an example, an organization I was working at where they worked on a feature delivery for six months that was on the roadmap and they got
it done and I think The expected users were tens of thousands and they got 16 users for this feature.
And at that point, there wasn't even a post-mortem.
They didn't look back and say, well, what are the lessons learned here?
It was like, oh, that's a shame.
Let's move on to the next item on the roadmap and hope that works instead.
It's very frustrating, especially because the feel of a good Scrum team is the connection with the customers and the feeling that you can see the passion
in the engineers and in that the team size because they're delivering things that people want and they feel connected to it.
And it means they work better and then work more effectively.
Yeah, there's no worse feeling than building something no one uses.
I used to joke with the team.
It's kind of like that old joke about if a tree falls in the woods, no, one's around as a mix.
If we build software that nobody uses, did we built it?
Yeah.
You know, it just, i-it's, not going to be used for anything.
So it didn't serve any purpose.
Yeah, the way I like to think of it is that an organization should not view people's time spent in the job as important.
What they should view is the value that that person has delivered is important, so sometimes people will say, well, you know,
yeah, okay, we delivered a feature that nobody really used, but you did your job.
You came in for eight hours a day during that time.
And that's hard for people, I think, because they feel like this is my life.
I'm investing time and energy into this.
Yeah, the money is important, of course.
So I am doing it as a career.
But at the same time, i also want to feel reward.
i want feel I can achieving something.
And i think with that element, you get so much better performance from the team if they fill that.
I agree.
There's another thing I was thinking of here too, when we were talking about underpowered POs, another cause I think that,
that maybe you've encountered or seen as well, but screwy things that people do with, with kind of personnel, like for example,
having multiple product owners for a team that leads to under power product owner or, or the opposite, even putting a product on her on too many teams,
and that's going to lead to power PO's as.
Well, what's been your experience with that?
Have you seen that I have one extreme example.
where there was an engineering team and the organisation was international organisation.
politically within the organisation, it was unacceptable to have one backlog.
They had to a backlog for the UK, a back log for US, backlog Australia, backlog for other areas of the world.
And the team then had too prioritise them kind of in this wild order.
So they would say, right, we'll take number one from UK and number from US.
There was no coherence to what they were building at all.
It was really just about satisfying people within the organization.
And it kind of brings you back to that key point about why do we have product owners?
Because product tenders, they narrow down all the ambiguity.
They narrow about down, all of the possibilities to the thing that's most effective for the team to do next.
Yeah, I like it.
I liked your example because it highlights kind of what I think about that.
Those scenarios a lot of times is that they're theater, you know, they are an act.
They're not really serving the purpose, but they, are making someone or helping someone to feel a sense of security about something that really they shouldn't feel.
It's not there, But it has the appearance of it and has, the stage set of something, that looks secure, Yeah.
I mean, whenever somebody mentioned that to me, the first thing I always think about is the length of the backlog.
Yeah, but we're adding 10 new items a week and we are only completing eight.
So in fact, you're moving further down the backlog.
You're not actually getting closer to being done.
And it's, it is a disconnect to gain.
This is what it all about.
Good agility, good scrum is when there's a strong connection.
If you start having that, that just doing things for appearances sake, then you lose that connection Yeah.
And it really is kind of that fundamental flaw that we try to address throughout Scrum of transparency.
When you do those kind theater-ish things to give the appearance of something, it's the opposite of being transparent.
You're trying to make it more difficult to see the reality.
Yeah, It's on the backlog.
So you have this false sense of security.
It is on backlog, but it is never going to get done.
But that's not transparent that it will never get it done because it was on a backlog Part of that I put on the product owner a little bit,
but that could also be that the organization demands it.
Like your example with it having different backlogs across different geographies, does it serve a purpose?
Well, maybe the purpose is to make someone feel better.
Hey, my thing's number one on our list, that doesn't mean it's the next thing that's going to get done.
It was done exactly for that reason.
I mean, it was because they didn't want to alienate the heads of the individual countries.
So they wanted to make them feel like they were going to get something even though they weren't going get it.
Which is really frustrating.
Because there's a, I don't know if there is a fear that someone's going to feel undervalued if they're not called the product owner,
but it just seems like, uh, yeah, we want all these voices to be involved with it, which again, maybe it's the misunderstanding of the Product Owner role.
That's okay.
You can have multiple voices involved.
But you got to define who's the decision maker.
And if a team doesn't know that, that's going to cause a whole host of problems.
Absolutely.
I mean, I've been in scenarios where you would have multiple product owners.
The team has been instructed by a product owner to go in a direction.
Then midway through a sprint, the other product will come along and say, yeah, That's not really what I had in mind for this sprint.
Can you please switch on to this other thing?
And I was a scrum master at the time.
And what I ended up doing in my sprint report was I would say, and the team lost 20 to 30% of their capacity in switching between what one product owner
wanted and what the other product owners wanted.
That at least got a reaction because people said, well, okay, maybe that's not a good thing if we're losing output from the tea.
But it's a failure of the organization to make value judgments and make genuine decisions.
Instead, it becomes political decisions, Well, I'll give you my trick for when I when i've encountered it as a consultant a couple times.
I usually just ask one question and it'll clear it up.
i'll just go to them and whoever the leader is that's insisting that there's multiple product owners on the team.
And usually the immediate thing I hear back is, oh, no, they get along.
They usually understand.
And I always just counteract it really quickly and say, yeah, but what happens when they don't?
What happens?
When the day comes when one of the product owners wants something that's number one, and the other one wants an entirely different thing as the number-one priority,
who makes the call?
And, usually they'll point to one them and push comes to shove that one.
Got a little bit more authority, so they make the decision.
I mean, at that point, I just say, well, you just told me that's your product owner, right?
That's the product on the other person's stakeholder, which is fine.
But there's nothing devaluing about someone who's a stakeholder.
They can work all day, every day with that product.
Yeah, absolutely.
I think that people feel if they're not in the product owner role, then they will just be another stakeholder and maybe they won't have as loud a voice.
But what's so frustrating about the situation is when you see it done well, when we see done effectively with a really good,
empowered product, a very motivated team, it's such a powerful thing.
And I mean, that's why I stayed in Agile for so long is because I know how good it can be.
And it's very frustrating and I guess I have sympathy for organizations because maybe if they've never seen it done well,
it is difficult for them to understand just how effective it it.
Yeah, I agree.
Well, this has been a great discussion.
I really like this topic.
It's great to focus on product owners a little bit and hopefully maybe there's a leader out there or somebody listening who heard some of these things
and thought, you know what, maybe it is time to give our product owner a lot more power.
You know, we talk about testing things all the time, inspecting and adapting as we go.
Leaders, try that.
Yeah.
Maybe just try it as an experiment.
If you're concerned, give it a go, Yeah, give it a shot and see what happens.
You may like it and you may decide this is the best way to go.
So yeah, I think that's a great suggestion.
Well, Barnaby, this has been great.
I really appreciate you making time for this and thanks for not only being on the show, but for the contributions you made in the Agile Mentors community
as well.
Thanks a lot, Brian.

Why Most Teams Struggle: The Hidden Group Dynamics Leaders Miss: Colin Fisher

Transcript

Welcome in Agile Mentors.
We're back for another episode of the Agilementors podcast.
I'm here as always Brian Milner and today I've got the one, the only Colin Fisher with us.
Welcome and Colin.
Thanks so much for having me, Brian.
Uh, very delighted to have Colin with this.
If you haven't crossed paths with Colin before you're in for a treat.
There's just a lot of stuff here that I think you'll find really interesting.
Primarily here that what I want to point you to is he's the author of a book called the collective edge which is really an amazing book about group dynamics
and how groups and teams work together.
It distills down just a ton of research that's happened over the years and makes it really accessible and readable.
He has a PhD from Harvard.
And he's also on the faculty of the UCL School of Management.
In kind of looking him up previously, kind doing some further research, I found out that he is also a jazz trumpet player.
So that is really interesting.
I love that.
Do you still get to play very often?
Yeah.
I mean, it's amazing.
So I moved to London about 10 years ago and my kids are getting older now.
It doesn't feel as important to be at home every single moment now, you know, a 17 year old doesn' want to hang out with you quite as much.
So I've gone back out and playing in one band, a shout out to Swade Jazz Collective, where they just sort of think I'm another musician,
another professional musician who's out there.
And I try, you know, I talk in the book about going to this jam session at a club called Grow, and I, try and go there on Thursday night.
So if you're, if your in London on the Thursday, night looking for something to do, or last Friday of the month, look me up.
I may have some good things for you to come here.
I can promise you that the next time that I find myself in London on that timeframe, I am definitely going to be there.
That's going be awesome.
Yeah.
So I want to get us into our topic area because I know that there's a lot for us to dive into here, but I think Colin, what I wanna start with is just,
We have a lot of people that are trying to guide teams and maybe from a management level or leadership level, but maybe also from kind of a scrum master level.
Or project manager kind level of team.
And what I'm really want to start with is what do you feel like is the biggest misunderstanding that leaders have about how teams actually work?
I mean, there are so many, I had to write a whole book about it.
Right.
But I mean, I think the most common problem.
So if we're starting kind of at the biggest level is just people, um, get very focused on either the technical aspects of their jobs.
And especially when you're doing this kind project based work, you know, there's a lot of focus on the project itself.
and then people when there are problems, people get focused.
On individuals.
And that there's a serve attribution of, you know, things, especially going poorly to, oh, there is some kind of problem with an individual or there some
kinda problem between, uh, two people.
That the reality though is that a lot of this stuff is at the group level.
It's stuff about the structure of the, and it's about, the norms of it.
So if I've got you paying attention to the.
And that, you know, if you're listening to this podcast, that you probably somebody who's looking to think kind of at that group level,
You're already ahead of the game.
Cause so many people are just, sort of unaware that.
Group dynamics might be something they need to be paying attention to.
Yeah.
I mean, I think you're right.
When I, think about the leaders I've interacted with, uh, you know, and they, they talk about, the problems they're having with their teams.
It's, it's very much, i've got this thing I need to get done and there's a problem that's taking too long.
This person doesn't understand what they need.
And so what you are saying and what, what are you trying to focus here on is that there is a larger kind of structural problem here that is the group dynamic
that really is kind more core.
Is that kind what your, your saying?
Yeah.
I mean, the group, groups are sort of the hidden driver of almost everything that's, that going on in organizations, but especially if you're,
you know, if in agile, or if your in scrum, your own software development, You know you guys are at the forefront of, doing this kind of team-based project
organizing that, everybody else has been trying to copy another lines of work for a while.
But I, so I think, you know, there's some things that that gets really right, but there are also some very common problems that just emerge over time because
we're actually our, our although we are social creatures and where our brains are designed for us to live in groups.
We're not designed to work in bureaucratic organizations that have the kinds of pressures and that they do.
And so a common thing like, you know, when we want to have a group, we wanna include a lot of people.
We want us sort of get everybody who we possibly could involved in things.
But that one of the main findings from research on groups is that there's an ideal number for real collaboration, a number of that you would want a collaborate with.
And that this comes out of research where my mentor, Richard Hackman, had did a study where he was asking groups of different sizes out in the world.
Do you think your group's too big or too small?
So you know, you would rate, yo, what, What size is your.
No, to what extent do you, I think it's two big, two other extent.
You think.
And the important thing there is where those lines cross.
Where do we think?
It's just right.
and that that number, which I'm trying to get people to call Hackman's number after, after my mentor is 4.5 people.
So that we want that that's where the kind of sweet spot for collaboration is.
And I think most, for most people, this would be intuitive if I'm saying like, Hey, I want you to have organized a dinner.
Where there's one rule at that dinner, you have to, have only one conversation.
You can't splinter into subgroups.
Can't have little sub conversations.
Everybody's got to bet that diner has to just have focus on that single conversation And so if we say that it's like four or five people,
you know, we're all going to get to talk.
We're going get the contribute.
Were all gonna be heard and understood.
But now if I say, that dinner's got 10 people.
Like maybe, right?
Like we, You can pull that off.
That's not impossible, but it can be a lot harder.
Yeah.
All of a sudden, if you've got 15, 20, 25 people There's no way, right?
We can't do that.
And yet when we have these meetings, even in, you know, agile and, and scrum methodologies where it's like, usually at the forefront of these things,
we've, We do all the time.
We've got so many people that there's way everybody can contribute.
There is no, way.
Everybody can feel heard and there is way that everybody's going to get on the same page.
If you have, an hour long meeting, much less a much shorter meeting.
So.
You know, we set ourselves up for failure really right from the start with the number of people that we're thinking about collaborating with.
Yeah.
That's a great point.
I love that.
And it's, it, you know there's there has been lots of different numbers thrown out there over the years.
Right now scrum is, is saying it is usually 10 or less that are on a team, including Scrum Master and Product Owner.
But I think, when you're focused on the actual work being done, then you are talking about the developers in that group.
That's kind of closer to the number that you're talking about here.
Amazon used to have the two pizza team kind rule of, you should be able to feed a team with two pizzas.
So yeah, there is something I agree that's magical about a smaller size.
And I love your analogy because that so true.
When you go out to dinner with friends or anything else, when the group starts to get too big, it splinters.
And that splintering happens naturally in a work environment as well, because these three or four people work together all the time,
but they don't talk to the other three of four.
People cause they're doing their own thing.
So you have the natural split in teams anyway.
Um, is there, I know I get this, asked this question a lot of times in class.
Well, if it's 4.5 is kind of the ideal, Is there a lower threshold that, you know, are two people, a team.
Two people can't, I mean this, this is hotly debated amongst scholars.
Generally like two people, can have a lot of the attributes of, of a team.
And I think, you know, we, a of times when we're teaching about these things, well, will teach like there's this really hard dividing line between a group
and the team, but in reality, This is a continuum.
Right?
Like we're on a continuum of more or less groupiness and like these real teams of 4.5 people who are like, you know, a basketball team or a jazz ensemble
or these kinds of teams, those are the groupiest groups where they have all the attributes of groupness that we would want.
And that when you get into dyads, they, have some of them, but not as many.
Most people would say like we really get in to most of the groups dynamics once we have three people.
And it's harder to have some of the things we talk about as important in group dynamics when it is only two.
Some of those things just won't happen as much.
Agreed.
Yeah, I absolutely agree.
All right, so let's kind of carry it forward then.
If we've got our 4.5 people that we want and we got a project that want to have them focus on, how do we set that group up for success?
What's the keys?
If I'm that leader, what can I do to enable them to get off on the right foot and really have a strong foundation?
Yeah.
I mean, that's so important.
So that getting off to a good start, when you compare like how much of the variance in, in group performance, can we explain from stuff that happens before
the group exists, stuff happens right in that first meeting and then everything else that happened after that.
The results are really striking.
So I'm going to, again, hearken back to Richard Hackman here, which is coming up a little more than it usually does.
He had the way of talking about this, what you called the 60-30-10 rule.
And the, 60 30- 10 rule says that 60% of how a group is going do is determined before it ever meets.
That, and those are by things of who's going be on the team.
What tasks is that team going, to be charged with?
Are those goals communicated well and do people understand what they are and what the, what its importance is.
And so that stuff usually happens before a group ever meets, but those are the most powerful drivers of group performance.
But then 30 is actually what happens in that very first meeting at the launch.
and that's because we do form our impressions of.
What are groups going to be like very, very quickly, but that the kind of norms of behavior and our personal orientation towards that group also tend to
form in that first meeting.
And it's really sticky.
It's not that you can't change it at all.
it gets progressively harder to change.
and so it, it it easy to imagine when it like, you know, where am I going sit?
You know, are we going to make small talk before the meeting or are, we all gonna stare at our phones and pretend we were not in the same room together?
You, you know those kinds of norms we see, but there's also more important stuff like who's talking a lot and who is not talking at all.
You do, is this a group that's going be important to me is, or is one where I feel like I'm kind of peripheral and I don't understand why I am here.
And so those things are also forming in that first meeting.
So to get your group off to a good start, the most common thing, and I'm sure you've heard this from 10,000 different perspectives.
The problem is that people have different perceptions of what they're trying to achieve.
What is the goal?
And that.
Communicating that goal really clearly so that we know the end point.
We know what mountain we're supposed to climb.
we are not trying to go to different places.
That's really important.
But it's also really critical that people understand why it is important, you know, for the organization, the team, and for them personally.
And often that's why they specifically are there.
Now if you're in, if your in a domain that has really strong roles, like, you know, find the trumpet player up on stage with a jazz band.
I know I am there because of the instrument I'm holding.
There's a lot of it's determined by the context, but when we get into new kinds of tasks, stuff we haven't done before and stuff,
that's all more uncertain.
That's where you really have to tell people because it is not determined just by their job descriptions, why they're there,
what they are supposed to bring to that team.
And the best, the leaders are the ones who are communicating their vision for that, checking that with everybody else who's on the team to see if anybody
has questions, if anyone has different understandings of it, and that ideally giving people a chance to respond to that.
So that's one of the most important things.
But then there's another really basic thing that often doesn't happen and gets lost in the shuffle, which is Who is actually on this team and who am I
supposed to be collaborating with?
And I mean, you'd be shocked how often that teams don't get that simple thing, right?
Right?
Like when you have, yo, 10, 11 people showing up, but maybe somebody is not there that day.
Maybe some of those people are there for some reason.
That's not going to.
They need to continue to, be communicated with on the team.
And that it's so often it just like people don't know who they're supposed to be working with all that well.
And both of these things I think are things that leaders can do a lot about.
In that one military leader who I was talking to as part of going around talking about this book, said he was taught that the best leaders think of their
job as being the repeater in chief.
That they, they come in every day and they're like, this is why we're here.
This is what we trying to do.
Everybody's role is in achieving this.
And there's a lot of truth to that because just there is natural kind of coming apart that happens when you don't keep coming back to these issues.
And so, you know, the best teams are repeating these things.
They're putting it big in their shared workspace that, yeah, there are really clear indications of who's supposed to be paying attention to what.
And that those things often are the source of, you know, it's like you see somebody who's checked out, they may not know what they're supposed to be doing.
You see, yo, two people who seem like they are arguing about what the best way forward is.
They may have really different views of what goal we're trying to achieve it.
And a lot of these kind of surface level problems come back to these real basic things about the team.
Yeah.
This is really good stuff.
I agree.
And it's, you know, it gets to kind of that, that whole Dan ping think about the purpose motivating the team and that sort of stuff as well.
A I don't want to, um, I want make sure that to dive into a little bit as Because we're dealing with individual human beings that are trying to work together
to produce something.
And when you have individual humans, you differences in personality, differences and culture and just personality traits and preferences and all that kind
of thing.
How can a leader take that into account and how do we help a team really blend When you've got a team of, I don't know, some extroverts,
introverts some verbal processors, and some that need quiet time to think, how do we blend that kind of really core differences in personality to get things done?
Yeah.
I mean, it's a great question.
This comes up all the time and it is something that researchers have been really curious about too.
And I think the answer really is surprising.
And that is even all these different kinds of people, these, different personalities, especially personality doesn't actually matter that much.
It doesn' matter nearly as much as you think because that we were really good as social creatures at trying to fit into a particular social culture that's there.
And that when it's really important to us and we know why we're there and what we were supposed to be doing, a lot of this stuff takes care of itself.
But the flip side of that is, and the reason I think this, this comes up a.
Is that another critical ingredient of teams is that they are valuing and actively seeking to understand the different knowledge skills and perspectives
of their members.
Now, perspectives might come into this idea of having really different personalities, but there's the research that, you know,
people have looked so hard to say like, Oh, this combination of introverts and extroverts is going to do better than, than some other way.
Or this is how we kind of get these, these who are different to work together.
But the answer to that always comes back to shared goals.
And norms that value speaking up, listening to one another and valuing these kinds of disagreements as valuable ways to say,
like, we're trying to solve a problem here.
We're, trying, to achieve a task.
And that the best way to make sure we doing that optimally is to consider different points of view and to, consider consider differences.
and so the teams that have these norms, that, have the strong goals.
tend not to have the kind of conflict between that are due to work styles and personality types.
And the ones that end up having that conflict, it's often because there's something else missing.
There's, something wrong with the structure of the team.
and so the remedy is not, to then say, let's develop special skills in navigating the conflict.
Between these people.
It's really, because that's sort of in that 10% of, the variance that you might be able to control as managing a team in real time.
And it's really to say like, all right, those problems are emerging.
Let me first check the 90% of the variance that, that I should have been attending to and get that part right.
So that's not to, say this never happens.
Like there's of course people who, for a variety of reasons, don't like each other, will struggle to work together.
But you know, first, if you have a ton of people, those people on your team or in your organization, you may have other problems with your recruiting and
hiring processes that you're getting a whole bunch of.
People that can't work together over and over, but it's much more likely.
I can almost, I struggled to come up with an example where it doesn't come back to.
These people didn't understand what they were supposed to do.
They didn' understand their role on the team, or they just weren't actually given very important work.
Or they weren' given signals from their leadership in the context that their perspectives were not valued and were important.
And that almost everything comes back to those issues.
Yeah.
Great, great point.
And you know, it's, you bring up the whole area of conflict there and the friction that will naturally occur when you have these kinds of differences and
people working close together.
Um, and I, I just curious to get you to talk a little bit about that, that that whole realm, because I think there, there is sort of a misunderstanding
a bit.
Up from folks that that is something to try to avoid that.
You know, you, want to kind of ignore or dismiss.
So you're going to to get past any differences that you have so that You can get back on target with whatever it is that your,
your there to talk about.
And, I've heard some people make some analogies in the past, like you wouldn't do that in a relationship with your spouse.
Like you would just say, but we can't ever fight.
Fights are important so that you establish that humanity kind of bond between each other and trust and you know, you go through things.
So when you see conflict kind as a part of that team dynamic, how do you, see that playing a role in the formation and what should teams do when they encounter
kind that friction where, Hey, I want to do this.
No, this is the right way to go.
So if it's, if, it that kind of disagreement, disagreement about the task and saying, I think this is the best way to do it.
I, think it a different way.
That's good.
that's a sign of a healthy team where people are sharing their, their honest views about what the way forward is.
And as long as the team maintains this orientation of it, us against the problem.
We're okay.
But once it turns into it's me against you, and this is me trying to get my way and you arguing to.
Or even worse when it turned personal and I'm saying, you know, Brian, he always say things like that.
Like those are real.
Those are warning signs and that that is uniformly bad for, for team performance.
So we, researchers divide the world into task conflict and relationship conflict.
And sometimes also consider status conflict separately from that.
So arguing about the social hierarchy, but the task conflict can be good.
The problem is that, you know, when emotions run hot and we really care about, the project, we care, about to work.
Sometimes that starts to spill over into these other forms of conflict.
And that's what you've got to be on the lookout for is where whenever it turns personal, whenever, it's about a contest of wills or one person being right
and the other person, being wrong.
That's the beginnings of dysfunction.
And that is something that I, at least as a team leader, when I'm leading a, I have zero tolerance for conflict going off in that direction.
and often when there's a contentious issue that we're bringing up, you know, whether it's hiring, anything where I suspect we are going to have some disagreements.
You know, again, I become the reminder in chief and say, Hey, you know we're all just trying to do what's best for, for the team here.
Let's all try to solve this problem.
We're going to disagree.
let's make, let us have some ground rules for how we are going do that disagreement.
But I really do want to know what, what you all think.
And, and for us to really hash that out, we not all going get our way at the end of this.
There's, there's going have to be some give and take.
But that that's, that how we come to the best decisions.
And so you, you know, whatever the reminders you need to give your team are that you're setting those ground rules, your setting,
those expectations and that are doing this consistently because it only, it takes once of something devolving into, uh, a fight that sometimes people,
people don't, uh, forget easily that there's a lot of psychological research that suggests bad, stronger than good.
So whenever, whenever something bad happens in your team, you're going to have to do at least four or five times as much positive stuff to offset that
negative event.
Yeah.
I want to ask you about one last little area here too, before I let you go in our last minutes, because I feel like I'd be negligent if I didn't because
in today's work environment, just about every team has some kind of a hybrid or remote component to what they do.
And I'm curious what your research kind have showed on that and how, if we are in one of those situations, which a lot of us are,
How do you go about trying or what can we do to try to strengthen our team or make our.
A stronger, you know, higher performing team when we're never together, when were always seeing each other like this.
Yeah.
I mean, hybrid, I think we have to be clear about two different things.
Right.
One, one kind of hybrid.
Is sometimes we're in the office.
Sometimes we were remote.
And that means, you know, sometimes were meeting, meeting in, across the computer screen from each other.
When we are all meeting across a computer stream, the problem that we facing is what, what psychologists call psychological distance.
that we just seem a little less human to one another because we're programmed to perceive other humans when they're nearby us,
when we can see all their nonverbal cues, and we see their bodies and just physically being able to hear, see, smell all these things,
other human.
That makes people more real, but then that has this other effect of We view people more individualistically.
So we, I can say like, Oh, understand Brian.
And I come really like zero in on your idiosyncrasies in a way that when we're virtual, our brains tend to view other people,
more abstractly.
And that the problem with that is that sometimes when we view people more as abstract generalizations, we tend to treat them worse.
That we treat the more like their tool that we're comfortable sort of ignoring or disregarding them in ways that would not do if we were in person.
So if you're a leader and you are having a lot of virtual only meetings, that's what you fighting.
You're trying to reduce that psychological distance.
And that sometimes that is things like, you know, most of us, don't blur our backgrounds as much as we used to, as, we've kind of gotten used this world
because that makes us feel more psychologically close.
It looks more like we're in the room together.
Sometimes that means we do little catch-ups at the beginning and we were all finding the boundaries of how much time do teams want to spend on that?
Because we also don't like being on our computers, staring at video screens all the time either.
So I think different teams can find different ways of doing that.
I've seen teams that do show and tells.
Have seen in teams where they just, you know, do really quick check-ins at beginning.
They have optional times for people to kind of do meet and greets before.
And those are all ways of reducing that psychological list.
So, you know, that's one, kind of one set of things.
And I also think like, we have a lot of opportunities with meeting virtually because we can get Different expertise in the room that we could if we're
reliant on who could physically be there in The Office.
We can communicate through different media that like, especially when you're doing digital work, you can actually do work together in a way that's sometimes
actually harder in A room when You're all sitting there In a room together.
So there's a lot of opportunities with it too.
But the, the other kind of hybrid and that people kind use the word interchangeably is hybrid meetings and hybrid.
Meetings means some people are there face to face and some.
You know, on, you know online and then these, uh, digital environments like zoom and though the research on those is much less optimistic.
Yeah.
So to say, yo, teams tend to figure out how to operate when they operate in a consistent communication and information environment.
So if we do the same thing over and over, you know, we're always meeting in person.
We're going to develop kind of norms and ways that we, solve problems.
If we always meet online, We are going develop ways of solving problems, but if.
Keep switching it up all the time.
And especially if, switch who's online and who is in-person, it's much harder for us to, develop those norms of operating.
And that the research shows actually that like, there's not as much of a disadvantage to meeting online as, as a lot of people had feared,
especially for teams that do it consistently over time, that they tend to kind of start to figure stuff out if they're well-structured in the ways that
we talked about in first place.
But that the teams that struggle the most are the ones that keep switching.
They keep.
How they meet, they keep, what the medium is.
And those teams are, you know, hybridity, the hybrid of that meeting is a real cost.
Yeah.
So the consistency matters, right?
It's just that, that consistency can, can as you said, it's about team norms.
If you're switching all the time, then there's nothing that feels normal.
It just feels like.
a chaos.
So yeah, I mean, this is really fascinating stuff.
And I cannot recommend the book high enough to people who are listening.
The Collective Edge is the name of the books again, and we'll put links in our show notes for this.
But Colin, anything else, any, that people want to get in touch with you further or find out more, is there anywhere you would send them to kind of stay
in contact with?
Yeah, that's great.
Please check out my website, colin m fisher.com.
I write a free sub stack newsletter and, uh, I'm on all over LinkedIn more, probably more than I should be.
So find out what I am up to in, in any of those places.
Perfect.
Thanks Colin so much.
Really appreciate you taking the time to share your wisdom with us.
Oh, thanks so Brian.
It was a lot of fun.

Why Smart Professionals Struggle in Job Interviews (And How to Fix It) with Tali Shlafer

Transcript

Welcome in, everyone.
We're back for another episode of the Agile Mentors Podcast.
I'm with you as always, Brian Milner.
And today I have Miss Tali Schlaufer with us.
Welcome, Tally.
Thanks, Bryan.
Very excited to have Tali with us.
She is a job interview coach.
So you can kind of see the direction we're going in here.
One of her tagline is that she, she helps, you know, professionals get offers they're really excited about.
And, um, She's got some really interesting insights here because I know in today's world, in Today's environments, there is lot of shifting going on there.
There's a lot.
Transitioning.
between different places of work.
And that interview is always kind of the forgotten portion of it, right?
You get past all the other stuff, you get to the point where you're in the interview.
So Tali, from your perspective, I know you see and help a lot of people with that portion.
What are some of some the biggest mistakes that people make that you routinely as you help people prepare for their interviews?
Yeah, absolutely.
I think one of the things that you just mentioned where, you know, people really struggling with the interview piece, so you do all this work in your job
search to update your resume, update, your LinkedIn network, all the stuff.
And then you get to the interviewing.
It's like, okay, we're close.
The interview is actually a completely different stage.
than anything else.
And one mistake that I often see people making is just the mindset around interviews.
A lot of people think, if I'm great at my job, I'll just interview really well.
Like, i'm a top performer.
I am good to go.
But interviewing is actually a skill that's completely separate from anything we do in the workplace.
It requires you to be able to articulate what you've done in workplace and the results and impact that you brought.
in a way that most of us don't have to do in our day-to-day jobs, and you have do it better than everybody else.
So just because you are a top performer doesn't necessarily mean that that translates into your ability to talk about yourself and talk your career,
especially in way resonates with the specific job culture and the job that you're applying for.
I think that's kind of the top Top mistake that I would just from a mindset level is seeing interviews as something that you're naturally good at rather
than as a skill that can really develop and build in order to set yourself up for success.
That's a great point because, as you said, just because I'm a top performer in something that I do, I have a huge skill set or knowledge area that i'm
really good at, doesn't mean that, iI'm necessarily good in an interview process because it is a whole set of other communication skills that you have
to have in that kind of environment.
I know when I've talked to people about it, sometimes they feel sort of this I don't know, dichotomy a little bit back and forth about,
I know I'm supposed to plug myself here.
I now I am supposed kind of brag a bit, but I also don' want to sound cocky.
Don't want sound, you know just brash or anything.
How do you help people or what do advise people about in that area?
Yeah, and I think this is really common for people who are top performers and people are very team oriented and collaboration oriented.
It's really difficult for those folks to go, hey, I did all this stuff by myself, and to kind of put themselves in that spotlight.
So it's a very common challenge.
It is also very commonly for folks who are really good at their job and have been doing this for a long time to actually be able to articulate what that
secret sauce is, like why they're actually good in their jobs.
which is part of the challenge.
Remind me the question that you just asked.
No, I'm just in talking about kind of like how people prepare for these kinds of things.
The way they communicate this stuff, you know, sometimes it's kind more this worry about, am I being a little too overbearing or brash in how I am bragging
about myself?
Will I come off feeling cocky or overconfident?
How do they walk that fine line?
Yeah, I think this is a really big mindset piece where a lot of people who are those top performers and are very collaborative in nature are afraid to
talk about themselves and be in the spotlight and kind of take credit where, especially in something like in The Agile World or project management,
product management.
It's a very, collaborative space.
So people are.
Afraid to like, people.
Are afraid.
To say, here's what I did.
And.
Part of the mindset shift that I really encourage clients and job seekers to have is rather than to see it as, hey, the interview is all about you and
the spotlight's on you.
And, you know, your used car salesman trying to promo yourself and it feels really icky.
So we don't want to do it.
We end up not doing it at all.
Think of it rather as you're trying.
To help this employer solve a problem.
you're on the same side of the table with them.
You're essentially a consultant for them, their problem is, hey, I've got this role.
I have this challenge in my company.
And I need to find who's gonna be able to help me do that.
So you are essentially being an advisor for that and sharing here's how my previous experiences and what I done in the past might be to be help you with
your challenges.
a partnership type of conversation where you're exploring, well, what are you struggling with and how, let me share ways that I think I might be able to help.
I Think having that mindset is a lot more helpful for people who are more collaborative in nature.
There's also a part of it that is getting really clear on how your work has actually delivered results.
Being really confident.
A lot of folks who were more cooperative in Nature, which is lot a people that i work with, tend to really get stuck in the we.
So they say, we deliver this, We manage this.
We strategized in this way.
And then the interviewer ends up losing the thread of, well, what did this person sitting across from me do?
What did they lead?
what do they manage versus what they do collaboratively?
So getting really clear and even getting some language around how to talk about your contributions with respect to the team.
So saying, I led the strategy session, or I facilitated the collaboration of this, Or I made the suggestion to people who then made a decision.
Those kind of nuanced pieces of communication can help us feel more comfortable with actually owning our story in a way that doesn't feel gross.
Yeah.
I think you make a great point there about the partnership aspect of it because having been on both sides of the table there,
I know when I was hiring people as a software manager of some kind, the thought is always when the person comes in, you want to hire them.
When they've reached that stage, when you finally bring them in, you're excited about the people that you decided to bring in and you are pulling for them.
You want them to actually be successful.
So it's an, I think it is important to keep that in mind too, that they want you to be.
Successful.
They want that role filled or they wouldn't have, put out the job wreck and all the other things.
If you, so let, let's just kind of talk through on a practical level.
You've done the work, you've put out the resume, You got the call, maybe you even gone through.
Well, I guess we should talk about that as well.
Kind of the difference between a virtual or phone interview and an in-person interview.
Is there a difference in level of prep or in how you tricks to being more successful if it's virtual versus in person?
I think the preparation itself should be the same.
At the end of the day, your preparation should be about what are the challenges that this company that, this organization is facing and how does this role
help solve those challenges?
What are those skills?
what Are the top five skills that I need to demonstrate hard and soft skills and in order to show them that.
I can be the talk performer for this roll and what our stories that can share for each one of those.
To prove that yeah, I have what it takes.
So I, can actually walk the walk as well.
And I've gotten results in this area before.
The prep work itself in the days leading up to the interview should be more or less the same.
I would say the difference between a virtual interview versus an in-person interview is just people's comfort level.
A lot of people are really comfortable in in person interviews because it feels like you're actually talking to a human.
You have a full-size person sitting across from the table from you.
So it's a lot more comfortable.
And I think even though through COVID, we had a lot more virtual conversations.
There's still a very performative feeling element to it when it comes to virtual interviews.
So one of my top tips for virtual interview is please turn off your self view.
If you're in the Zoom call and if you are in a meeting, because it makes people so nervous and self-conscious.
When you get on that Zoom Call, on the Teams call, whatever platform you using, make sure you in frame.
Right, make sure that your lighting is good, all that stuff, and then turn off that camera so that you're not just watching yourself and being super self-conscious
the entire time.
Because think about it, in what other context in your life, when you are having a conversation with someone, do you have a mirror that looking at?
Right.
Right, I mean, if you're in their interview room, unless there's a mirror all the way around, you are not really getting that view.
And even if did, probably wouldn't watch yourself in the mirror the entire time.
So yeah, that's great tip.
I think you absolutely right.
Kid and Alita being very, very self-conscious then.
I want to go back a little bit to the prep because I think your tip there is a really important thing to try to understand the challenges,
understand what it is they're looking for.
And it just struck me as you were saying that it seems very similar to in my kind of line of work.
I do a lot of consulting work with people.
And when I have a client that's a prospective client, it's almost the same thing where you have to research a little bit about the company ahead of time.
You know, if you're doing kind a sales call prior to the engagement, It's very similar.
And I just thought about that.
There is an overlap there between that and job interviews because you are selling yourself.
You know, you're selling your services to that company.
And a lot of people, here's another mistake that a of well-meaning people make is as part of their prep work, going online and finding a bunch of questions
that they can then prepare for.
So it's a very, I kind of call it whack-a-mole where, hey, let me try to figure out all the possible questions I might get asked.
write out answers for those.
That might get some people results.
And if it's getting you results, that's great.
But what I really encourage people to do is really reverse engineer your talking points from the job description, from what you know.
Even once you've had the conversation with the recruiter, you a little bit more about the position than maybe is even listed on the drop description.
So compile everything that you about this opportunity and figure out, OK, what are the most important things for me to be able to articulate rather than
just guessing at random questions that the internet says you might get asked.
Yeah, that's a great point.
I know we all want to get past that and get to the job, but I think there's also an element there of, let's say you do memorize these questions and they
just happen to ask you the exact questions you had prepared for.
If you don't really have that knowledge, then you're not going to really do well in that job even if you get it.
So it's almost a blessing to not get that a job if if didn't know that information because they're gonna be counting on you to do that and you're not gonna
do your job well then.
Yeah.
And the memorizing piece that you just mentioned is really, really easy for people to fall into the trap of trying to memorize their answers,
especially with chat GPT and AI.
Everybody's thinking, well, let's use these AI tools to help us come up with interview answers.
Job seekers will plug in, here's a bunch of questions that I might get.
Look at my resume, tell me how can I answer these questions?
And it feels safe.
It feels like this very smart robot or technology is going to say this in a better way than I can.
But it really sets people up for failure most of the time, because number one, most people aren't good at memorizing things,
right?
Most of us don't have to do that as our job.
So most us are really bad at memorize.
Number two, it makes you sound like a robot.
it doesn't sound human.
You lose the attention of that person who you're talking with.
And number three, it doesn't, when you just memorize answers, rather than thinking about it as what are talking points that I can riff off,
riff on, and kind of reuse and recycle and tell stories with.
When you memorize, It puts you in the position of, oh, yeah, that's great if they ask you that exact question.
And some questions you will get asked, like, tell me about yourself.
You're going to get 99% of the time.
But for the most part, if you memorized a set of 10 questions, And one of those questions gets a slight variation or they ask a question that's not on there.
you end up panicking, you don't know how to think on your feet because you're reliant on you tool.
You've used AI or you've use your script as a strategy rather than a tool." Yeah, that's a great point.
I'm kind of wanting to get your take on this because this is a big thing that I know often comes up in these kinds of interviews is those questions that
we all hate to, no one ever knows how answer these things.
So I am just curious how you advise people You know, the awful question like, you know give me some of your weaknesses or give some things that you're
not good at.
How do you advise people to handle those kind of questions when they get asked in interviews?
Yeah, so there are definitely some questions that we tend to hear more often than others, especially when it comes to those recruiter interviews that tell
me about yourself.
What are your strengths?
What?
Are your weaknesses?
Tell me.
About a time you had to deal with a conflict.
Tell about a 10 you have to do with the mistake.
Those are pretty common.
I would say in that.
initial recruiter conversation.
It's always an interview in my book.
The weakness question I know is one of the that and the tell me about yourself is what really stresses people out.
My general advice for the weakness is actually something that I heard Adam Grant, who's an organizational psychology at Wharton share,
which is pick something.
That is real, but not disqualifying.
So if you're an Agilist, your weakness should probably not be scrum.
or not be, you know, understanding business requirements.
But it could be something like public speaking, or it can be like something delegating where, it's something real and it is something authentic.
Authenticity is really, really important, especially nowadays in interviews.
but it doesn't stop you from being able to perform well.
So what I typically advise is, pick a weakness, like Adam Grant says, that's real but not disqualifying.
This is important.
We're in where a lot of people miss out.
Cher, what are you doing to actually address it?
Because what we want to do, the point of that question isn't tell us what's wrong with you so we can judge you and disqualify you from the job.
It's the subcontext of it is, do you have self-awareness?
Are you somebody who is aware enough and humble enough to know your shortcomings and Are you someone who's proactive about fixing them and about becoming
a better person?
So the second part of that answer should be, well, what have you done to try to improve?
What are specific steps that you've taken in order to Yeah, that's a great response.
I know I've heard the traditional, you try to say, one of your strengths as if, I guess my weakness is I work too hard.
Like that kind of thing, which I agree.
It's not sincere.
If I'm hearing that and I am interviewing someone that could disqualify him in my book, because I could think, oh, this person is not going to be honest
with me.
Or the, I'm a perfectionist.
Oh, right.
I remember perfectionists, the most common answer to that question.
Yeah, exactly.
Well, you hit on the other big one too.
Tell me about yourself.
How do you advise people to handle that?
You have a script in mind.
Do you, do kind of detail out a couple of things?
What are, what's important to hit when someone asks you to just tell you tell me.
About you.
yeah, i'm.
A big fan of formulas over scripts.
So I'll share my formula, but let me share a couple things that derail people.
Let's kind of establish what's not helpful.
And then we can kind talk about this formula.
Which by the way, lots of different career coaches have different formulas.
There's no necessarily one that works.
It's just pick something and learn to do it really well.
A lot of people will go in and start, well, I graduated from the University of Washington in 1995, and they give kind their entire history.
We lose the interviewer right away when we do that.
So rather than giving them a chronological history of everything that's happened in your career and asking them when you do,
that we are essentially asking.
Hey, here's all this information and data.
You make sense of it.
you figure out how it's relevant to you.
I think it is actually really kind to use a formula.
to help them understand, here's everything you need to know about me as it pertains to this role.
So taking everything, taking your history and your career through the filter of what is important to demonstrate for this rule.
The formula that I teach is sharing a super quick background.
Hey, I'm Tali.
I've been a project manager for the last 10 years.
That's not true.
Let me reset that.
Starting with a very brief sentence about yourself, your relevant role, how long you've had experience.
Hey, I'm John.
I've been project manager for the last 10 years, sharing the three key skills that you need to have in order to succeed at this job.
And for each of those three skills, can you list an accomplishment or a metric or success story?
And we're not telling a whole story.
We're just giving them here's the highlight reel, here is the headline, and then you'll click into all of those stories later.
So quick little background about yourself, three main skills that you've developed that are relevant for this role and super high level accomplishment
to demonstrate those skills.
So that's a little bit, that kind of is the first half, and that talks more about your previous experiences.
And then in the second half of this answer, we want to pivot it to the future.
So the 1st half is really about the past, it's about yourself.
In the 2nd half we wanna pivot to future, so what are you looking for in your next role?
And hopefully that thing is also in that whatever you're looking in next roll should dovetail really nicely into what they're offering as a company and
as an organization.
What are you looking for specifically in your next role and why are so excited about interviewing with this company?
And we want to share something really specific that we wanna share, something specific.
That feels personal where a lot of people go wrong is they'll share.
I really want growth in my next roll.
And I'm excited about this team because I know you guys has really value innovation.
That doesn't really tell us anything.
So we want one level of detail lower.
What I really want in my next role is more leadership opportunities, so opportunities to mentor.
And i'm really excited.
About this particular opportunities because i looked on your website.
I looked at your blog posts.
You know, CEO's posts that they share on LinkedIn.
And I can tell that this is a really important part of your culture is being able to mentor people up into higher positions,
right?
Getting that specific and there's not a right answer.
I remember when I was interviewing for out of college, I, was interviewed for T-Mobile for an internship and my answer was.
I've talked to a lot of people, I have networked with a of a people at T-Mobile and one thing that really strikes me is the fact that a lo of the people
will leave for local companies like Microsoft, Amazon, and then they come back.
There's a a And the culture, like I shared things that are specific to the.
And there's not a right answer here.
It just needs to be specific and it needs.
When you talk about it, you kind of start getting butterflies because that's contagious.
That's awesome.
Well, I want to ask about kind.
Of the other half of the interview or the portion of the interview as well.
I often hear people say, you should walk into the, understanding that it's a two-way interview.
They're interviewing you, but you're, interviewing them as, because you want to know, is this the right place for me?
So I can make the decision about where I'm going to end up.
What kind of things do you advise people to ask about or to focus on?
What are some things that might expose some hidden things about the organization, warning signs or anything like that, that you might pop up in an interview
to asked about?
That's a really good question.
I think one thing, it really depends on the opportunity and what you're looking for.
So I don't think that there's one magic question that if you ask it, oh, the person is going to be super impressed.
Let me back up.
What I really like about what you just said is the framing of the questions that you ask at the end as a two-way conversation and as way for you to understand
more about the company so you can see if it's a good fit.
I think a lot of people, especially in tough job markets, tend to kind of close their eyes and hope they get something and they almost blind themselves
to the fact that they need to also do the work to make sure that it is a fit or I see a of a people who go, well, What can I ask that's impressive?
What questions can i ask?
That's going to really wow them at the end, rather than seeing it as an opportunity to understand what they offer more.
So I would sit down and prioritize what is really important for you in a culture.
If getting feedback, if growth is important to you.
Making sure to ask about, well, can you tell me about recently on your team, somebody who was promoted or how you helped somebody grow in the company?
The best way that we can learn about something is through examples, the best proof that some somebody values something, is to the examples that they share.
So we want to.
Kind of like you hear behavioral questions, you get asked, like, tell about a time when you can also use that figure out what's important for you and then
create ask questions specifically about those things.
One question that I think can be really helpful to get you to, get a sense of what kind of person succeeds on this team and what the team really values
is kind, of the inverse of that.
So can you tell me about, can, you, tell, me, about what type of, person, doesn't do well here?
Because then if they say, the type, or person who doesn,t do, well, here, Isn't committed to working 60 hours a week.
They expect to take their vacations and not be able to unplug that kind of being able.
Who isn't successful gives you some context around some of their values as well.
Yeah, that's an excellent question because I agree, presumably this is someone you're gonna be working with if you get the job.
That immediate kind of relationship I think is going to really be impactful on the expectations, you know, and that sort of thing.
So yeah, if I'm interviewing and I ask that kind question and they do come back and say, yeah the person who doesn't work 60 hours or anything,
Yeah, that's a good sign that maybe this is, I don't know, unless I enjoy working 60 hours a week, or that, maybe, this isn't the right cultural fit for me.
So that is an excellent question because I think that would expose some of that behind the scenes stuff, cultural things.
And you really want to ask about questions about your dynamic with the manager.
So what kind of people succeed under them?
Because that's the number one people.
I believe I'd have to fact check this, but you always hear that the Number One people reason people don't like their jobs or people leave their job is
because of their boss.
You're essentially going on a date with them and you want to understand what is it like to hang out with you for 40 hours a week?
So asking specific questions to really understand, what's their working style?
What are their expectations?
What does feedback look like?
Is it a once a year thing?
Every time we touch base during our one-on-ones, you get feedback.
That is really important.
The other thing that's important to think about is, do you understand the role itself?
What questions do have, what gaps in your understanding do, have about the roll?
Really clarifying to make sure that you know what you're signing up for.
Yeah, that that's a great response as well.
I know I've, I remember from back in the day getting told that, you know, it's, a good kind of question to ask.
What would success look like?
You know?
If you really got someone to nail this and you were really happy with the hire and it was perfect, what would, would be the biggest thing that would contribute
to that?
And I always liked that approach as, well, because it kind gives you the, the the expectation from the start to know, here's what's most important in that
manager's mind of what they're looking for.
Yeah, just in my memory of interviewing people, I would say I don't think I've ever not hired someone because of a question that they asked at the end,
but I have felt sometimes like when they don' ask questions that their a little unprepared.
I think part of the not asking questions, one is being not prepared, not thinking thoroughly about the job.
But it's also a little bit of a sense of desperation.
Like, oh, I've been applying for four months.
I'm willing to take anything.
So I don't have questions because let me just take any first job that comes available.
There's kind of that mindset.
And I thinks it manifests as I do not have any questions.
People can kind feel that when you're not critical when you're not trying to figure out, hey, am I really going to be able to succeed here?
People kind of pick up on that and it either looks like desperation or it looks disengagement and disinterest.
We want people not, we don't want to hire the first person off the street who can do the job.
we want hire somebody who's excited to there and who we know isn't going leave six months later when they find something better.
Yeah, that's really good.
Well, this has been really enlightening.
I think there's a lot of gems in here that I thing people can apply.
We all find ourselves in that position from time to time of, you know, having to interview for things.
Even as I said, even as a consultant, it's an interview when you talk to a potential new client.
So I that these are all really great tips for that.
We're gonna make sure that there's contact information for Tali and the show notes of this so you can get a hold of her.
Anything you want to shout out about, any places you wanna point people to to get in contact with you.
So for the last few years, I've been posting usually about two short form videos a day to LinkedIn, all the social medias.
Over the past couple of years I have posted over 700 short-form videos on social media.
I actually had over 100 million views on LinkedIn which is really crazy.
Somebody recognized me at the dog park the other day which was wild.
I created an interview tip vault that took the best, the most helpful videos.
The ones that have gone viral, received the.
Best feedback gotten people the biggest results in their interviews.
And I compiled them all in one interview, tip bolt.
So that's my little thing that I like to share with people.
You'll see everything in there from how to tell me about yourself to answering.
Why do people ramble and what other mistakes are people making?
And also special tips for senior leaders and executives.
So that's my little freebie that I like to share out for folks who are interested in the stuff that i'm talking about.
Awesome, awesome.
Well, we will definitely make that available to people in the show notes and links to your socials as well so people can follow you and stay on top of
your tips as they come out.
So thank you so much for coming on Tali and I appreciate you spending some time with us and sharing your knowledge with this.
Thanks so Brian, it was a pleasure.

Why So Many Agile Transformations Fail — 3 Ways to Make Agile Stick

Transcript

Is your Agile transformation like joining a gym in January?
Full of good intentions, but you know the changes won't last?
Fortunately, there are things you can do to make your transition effort stick.
Hi, I'm Mike Cohn.
I am the author of three best-selling books on Agiles and Scrum.
iHelp Teams Succeed with Agil.
In this video, i'll share three things that you could do that will help you and your organization stick with it through an Agila transition.
First, focus on showing progress with just one team that is moving to Agile.
A lot of organizations transition a bunch of teams, 5, 10, or 100, and hope that each succeeds, getting a little better at Agil each iteration.
I'd rather have one team kicking butt than 20 teams, each 5% better.
You can have multiple teams moving to Agile at the same time, but focus on helping one get really good at Agil.
Getting one very successful shows others what is possible.
Other teams can then be motivated to pursue the results.
There are two areas you can leverage to help that first team become great.
The people on the team and the attention that is shown to that team.
You can really help a first-team get great by focusing on a team that has the right people.
They may already be on that Team or you may need to transfer them onto that You aren't doing some double-blind clinical trial of Agile.
By this time, more than 20 years after the Agil manifesto, we know Agiles works.
What we don't know is what successful Agils looks like in your organization.
This first team to get great will tell us what we need to know.
Find a team that wants to try Agile and is willing to change to make it happen.
Stack the deck, if necessary, by putting open-minded people and Agil advocates on that team.
The attention given to that is your other leverage point.
Agile coaches, especially if from outside your organization, often have limited time that must be spread across multiple teams,
helping each improve.
Make sure the team you're trying to get successful with Agil first gets all the coaching they need.
Unfortunately, at first that will come at the expense of attention to other teams.
But the long-term benefits of getting this first team successful will be worth it.
A second thing you can do to help your organization stick with it through an Agile transformation is to get support from above.
There is almost always someone who resists an agile transformation.
Most commonly, this is some level of middle management.
You want to circumvent this stumbling block by gaining support above that layer as early as possible, like right after you finish watching this video.
With support from above, anyone resistant will be caught between teams and leaders, both pushing for Agile.
You shouldn't necessarily go to your boss's boss and say your Boss is resistant to Agil, but look for ways to spread the word about the success teams are having,
especially that first team you're helping to get great.
Let's look at a third thing you can do to help your organization stick with an agile transformation longer than someone who quickly abandons their January
resolution to go to the gym daily.
To remain motivated, it's important to measure progress along the way.
There's an infinite number of metrics related to agility you could use.
The metrics you use can change over time.
Let's suppose quality is something the organization hopes to improve through its agile transformation.
Begin by measuring the number of tests that pass each night or that are added each sprint.
These don't truly tell you about the quality of the shipped product, but they are leading indicators.
Increase these and it is likely the product quality will improve down the line.
If you see quality is improving, perhaps you switch to tracking team member satisfaction or track both metrics if you have time and see the need.
As you begin an agile transformation, or as soon as possible if you've already started your transformation work to get baseline measures of anything you
may later want to use as a metric.
Some metrics will be hard to baseline after the fact.
For example, you can't ask team members today how much they enjoyed their work six months ago.
If you don't track and report some metrics that show improvement, the effort of an agile transformation will begin to feel a burden,
and the motivation to continue may drop.
Too many agile transformations fail after the initial enthusiasm fades.
You can keep yours moving along by getting a first team grade as soon as possible, getting support for the effort from higher up in the organization,
and measuring progress along the way.
I'd love to hear how your agile transformation is going.
If it's going well, tell me in comments what you've done that's helped.
If it's struggling, let me know where, and I'll try to use your comment when I make a video on how to get a stalled Agile transformation moving again.
I post a new video each week.
Check out the related videos on the screen right now.
And if this video has been useful, click the Like button.
If you're new to this channel, Click Subscribe so you don't miss out on future tips to help you succeed with Agil.
Thanks for watching and i'll see you next time.

Why Soft Skills Matter More Than Technical Skills in Agile Teams

Transcript

Think about the technical skills you were hired for.
Now ask yourself, how many of those skills are still relevant today?
Most technical skill don't age well.
Languages change, frameworks disappear.
The tools you mastered a few years ago may already be on their way out.
What has changed is the speed.
In the 1980s, it took about 10 years for half of what you knew to become obsolete.
Today it's closer than four, and soon less than two years.
So here's the real question leaders should be asking.
Where does investing in people actually pay off over the long term?
Technical skills are necessary, but they're temporary.
Soft skills last.
And in product development, they matter more than most leaders realize.
Anyone who's been in product development for a while has seen this pattern.
A skill becomes essential.
Teams invest heavily in it.
And then, quietly or suddenly, it's no longer the thing that matters.
That doesn't mean technical skills are unimportant.
They're important, but they have a shelf life.
Soft skills behave very differently.
When someone learns how to collaborate effectively, how facilitate conversations, make decisions with incomplete information,
or lead without authority, those skills don't expire.
Those skills become part of how that person works, regardless of tools, frameworks, and roles.
Learning how to learn is a good example.
Once someone develops that capability, it stays with them for their entire career.
The same is true for leadership, decision making, and collaboration.
Those skills may deepen over time, but they never become irrelevant.
Let me give you an example.
I once observed a demo where a programmer was showing new functionality to a group of user nurses.
During the demonstration, he displayed text on the screen suggesting that a fussy newborn should be given saltine crackers.
Clinically, that's inappropriate.
The programmer tried to explain that it was just placeholder text.
The real point, he said, was that the system would eventually provide useful guidance to nurses.
the exact wording in this demo didn't matter.
But to the nurses, it mattered a great deal.
Their professional identity is grounded in do no harm.
What they saw violated that principle.
They could not get past it.
And they were prepared to escalate the issue and potentially cancel the project.
What saved that project wasn't a technical fix.
It was soft skills.
The project manager calmed the situation, acknowledged their concerns, explained what had happened, and convinced the nurses to come back a week later
for a revised demonstration.
If the failure wasn t technical, it was a failure of empathy.
Had the programmer validated the example with a nurse or simply considered how it would land with them, the situations likely never would have occurred.
Product development is inherently uncertain.
Requirements evolve, feedback is incomplete, stakeholders don't always agree, and teams are expected to make good decisions under pressure.
Soft skills reduce risk in exactly these conditions.
Empathy helps teams understand users and stakeholders.
Clear communication builds trust.
Strong collaboration prevents small misunderstandings from becoming expensive problems.
When these skills are weak, teams often pay later and rework strained relationships and lost opportunities.
When the skills were strong, team adapt more easily and move forward with far less friction.
Many organizations under-invest in soft skills because the return is harder to measure.
It's easy to send someone to a technical course and confirm they learned a new tool.
it's much harder measure whether someone has become a better facilitator, collaborator or decision maker until the team is under stress.
There's also a widespread assumption that people should have already acquired these skills by the time they enter the workforce,
so gaps are ignored.
until they surface at exactly the wrong moment.
Ironically, that's when soft skills matter most.
Another reason soft skills matter is that they don't just improve individuals, they improve teams.
When someone learns a new technical skill, the benefit usually stays with that person.
But when someone learned how to collaborate better, facilitate discussions or lead more effectively, everyone benefits.
Communication improves, decisions improve, trust improves.
This multiplying effect is one of the most overlooked returns on investment and product development.
you Some leaders believe soft skills can be improved later, once things slow down.
But you can't wait for a crisis to develop these skills.
A team under pressure is when the absence of soft skill is most damaging.
Teams with strong soft-skills can have difficult conversations when it matters.
They can disagree productively.
they can make thoughtful decisions, even under stress, because trust was built earlier.
Teams without those skills often shut down, avoid conflict, or default to the fastest solution instead of the best one.
Everyone on a product team benefits from strong, soft skills.
But some roles depend on them more heavily.
Scrum masters rely on facilitation skills to help teams think clearly and work well together.
Product owners rely leadership skills, to align stakeholders, create shared understanding, and guide decisions.
Agile coaches and leaders shape the environment where these skills are practiced every day.
When these roles lack strong soft skills, the entire team feels it.
This is why effective product organizations don't leave soft skill to chance.
They treat them as capabilities that must be intentionally developed.
Technical skills will always matter, but they're temporary.
Soft skills persist.
They compound over time.
The strengthen entire teams.
And they show their value most clearly when the pressure is on.
Leaders who want teams that can adapt, collaborate, and make good decisions over the long term need to invest deliberately in these skills.
That means treating collaboration, facilitation, and leadership as capabilities to be developed, not traits to assumed.
At Mountain Goat Software, we work with product owners, scrummasters, the leaders to build exactly these capabilities through training,
coaching, hands-on learning.
Because the soft skills that don't fade are the ones that keep paying off long after the latest tools and frameworks have changed.

Why Sprints are Essential in Scrum: Avoiding Student Syndrome and Maintaining Focus

Transcript

Can you do scrum without sprints? No. Sprints are fundamental to scrumb. These short one to four week time boxes force team members to focus on achieving a meaningful goal in that period. If you go without sprint, team member will be prone to something called the student syndrome. This is a tendency to start something at the last possible moment in which we can still finish it. Remember starting the final paper the week or last night when you were at university? Without sprints, the goals seem safely distant and teams work without the focus or urgency they need. to achieve great things. If you don't want to use sprints, which are more generally called iterations, you may want look at an alternative agile process. Kanban, in particular, may better fit your needs. But don' call it Scrum if you're not using sprint.

Why the Best Teams Run Their Daily Meetings

Transcript

Imagine you've invited friends over for tacos and drinks.
No one is going to run this little party.
Sure, you'll be the one to decide when to eat and you prepare the menu, but you're not controlling each conversation or where people stand or how much
guacamole someone eats.
The party runs itself.
An Agile team's daily meetings should be the same.
Teams will have in place either some rules or norms that are established over time.
These might be that the meeting never takes longer than 15 minutes, that lengthy problem solving is done after the meetings,
and that meeting happens at 10am online.
Similarly, most teams establish a pattern of discussing progress, plans, problems, the three P's.
The best agile teams do this without someone running the meeting, much like having friends over for tacos.
This means no one calls on team members to provide an update.
The meeting does not run by a scrum master, coach, product owner, manager, or anyone else.
If a team is new to Agile, it's fine for someone, usually the scrum master or coach, to run the meeting.
That person can call on me and instruct me to provide an update on my progress since the last meeting, my plan through the next meeting and any problems
I'm facing.
Team members won't know what to discuss in a daily meeting until they have this explained and have experienced a few meetings.
But team members quickly figure it out, and when they do, whoever has been running the meetings can stop.
To get a team to the point where they are fully running a meeting themselves, I like to successively stop doing things.
First, I will stop asking questions like, what progress did you make yesterday and what is your plan for today?
If a team member forgets to answer one of the team's agreed-upon questions, i'll ask just that question of that person.
I want to reinforce the correct behavior in the meeting.
After perhaps a week of this, I'll stop calling on people.
I leave it up to them to figure out who goes next.I'll typically call the meeting to order, okay, it's 10 o'clock, let's get started,
and I wait for someone to get things rolling.
If someone asks who should go first,I tell them it is up them.
They can go alphabetically, east to west, geographically or random, however they choose.
Next, I'll stop starting the meeting.
Instead of saying, it's 10 o'clock, let's get started, i'll wait for someone else to do that.
Normally that doesn't happen by itself.
If people are used to you calling the media to order, they'll just stare at you until you do.
So you'll probably need to tell them that it is their meeting and they can decide when to get it started.
Here's a challenge.
Imagine someone is observing your daily meeting.
From just that meeting would they know who is the scrum master coach or team lead?
They shouldn't.
Leaders need to avoid running the daily meetings.
It's the team's meeting, it should be theirs to run.

Why Your Team Keeps Missing Deadlines (It's Not What You Think)

Transcript

Many leaders think teams overcommit because teams are careless.
I don't think that's true.
Most teams do not need a leader to pressure them into overcommitting.
Teams will usually do it on their own.
That may sound surprising, but in my experience, software teams often are deeply optimistic.
They believe they can solve hard problems.
The believe that they figure things out.
Believe they make things work.
That optimism is part of what makes them good.
It also shows up in their estimates.
Overcommitment usually starts before a leader says a word.
A team looks at the work, they imagine a path through the works.
They make assumptions about what will go well.
And because they're optimistic, they often lean toward the best case or near best-case without realizing it.
That does not make them irresponsible.
It makes them human.
I learned this early in my career.
When I was first promoted into leading a team, my management philosophy was basically this.
Ask people for estimates, assume the estimates are optimistic, then hold people to those optimistic estimates.
It didn't work.
I treated optimism like a contract.
Think about driving across town for an appointment.
You look at the distance, you think about the time of day, consider normal traffic, and you conclude that 30 minutes is enough.
Most of the times you're right.
But one day a train blocks the tracks for 10 minutes and suddenly you are late.
That doesn't mean your estimate was bad.
Like any estimate, it had a certain probability of coming true.
And on this day, you ended up on the wrong side of that probability.
That happens to teams all the time.
So if teams are already a little optimistic, what happens when a leader adds pressure?
Usually, the problem gets worse because pressure does not remove uncertainty.
It changes how teams behave around uncertainty, When teams feel pressure, they choose the optimistic estimate instead of the realistic one.
They become less willing to expose risks.
The stop looking very hard for what could go wrong because discovering bad news becomes uncomfortable.
And once that happens, the risks go unnoticed.
A lot of leaders apply pressure without meaning to.
I once worked with a leader named Erin, who was upbeat, positive, and well-intentioned.
As she walked through the office, she would greet people with, getting a lot done today?
She didn't mean to imply schedule pressure.
It was just her way of saying hello.
In fact, her bigger concern was quality.
But what the team heard was daily pressure about productivity.
When I pointed this out, Erin changed her greeting to something deliberately silly.
Staying bug free today?
That small shift mattered.
It signaled what she actually cared about.
And because it was a little funny, it broke the pattern.
That example has always stuck with me because it shows how easy it is for leaders to communicate one thing and be heard another way.
Even a simple, how are things going, can sound like pressure if the team hears it as, tell me you're on track.
Pressure does something else, too.
It creates rushing.
Urgency is fine.
Rushing is not.
I like this admonition from basketball coach John Wooden to his players.
Be quick, but don't hurry.
That is exactly what leaders should want from teams.
Move with energy, not with panic.
There's another way leaders accidentally create overcommitment.
They anchor the answer before the team has done its own thinking.
A leader asks, can you deliver these features in three months?
That sounds harmless, but it's not neutral.
Now the Team knows the leader's expectation.
This much work in that timeframe.
So instead of independently deciding what's realistic, they start looking for a path to yes.
I saw this very clearly when I was a VP of development at a public company.
My boss asked whether a product could be delivered by the end of the year.
We needed the revenue that year, and the product can help.
He told me that if we couldn't deliver by end the of year he'd have us work on something else.
My team and I worked on a plan and came up with mid-February for the release.
We cut some things, revised the plan, and got the planned to show mid December.
Great, we thought.
But we'd missed one important fact.
Our customers were not going to make beta testers available in November and December, they were too busy.
So the released slipped into January.
Now, on an 11-month effort, missing by a couple of weeks is actually pretty good planning.
But because the whole point was revenue in that fiscal year, the outcome was a failure.
The failure was my fault.
But it started with the way the question was framed.
If instead of telling me he needed it by the end of the year my boss had asked when we could deliver, I probably would have said February.
That would have led to the right business decision.
Don't do the project.
But can you do it by the end of the year?
Anchored us to a desired answer.
And we found a way to almost get there.
Almost was not good enough.
So what should leaders do instead?
First, make it clear what kind of answer do you want.
Do you wanna forecast a plan, a commitment?
Second, Make it safe to tell the truth.
Ask questions like, what assumptions are you making?
What could derail this plan?
what dependencies are there?
Is this your optimistic case, your most likely case or your pessimistic case?What should I know about the thinking behind this Those questions are very
different from asking for reassurance.
And that difference matters.
When a leader hears bad news, one of the most important first responses may simply be, thanks for telling me.
Because that tells the team that truth is valued.
So if your team keeps missing deadlines, don't assume they need more pressure.
Start by assuming they may already have enough pressure, and then ask yourself, what am I doing that makes realistic planning easier or harder?
The best leaders do not squeeze harder.
They create the conditions for truth.
That is how you get better plans and, over time, better outcomes.

Why Your User Stories Keep Carrying over Sprint After Sprint

Transcript

Look at your sprint board for a moment.
If three or four items are almost done, one story is waiting on testing, another is on the back end, and the most important story moving into the next
sprint again, the problem probably isn't that the team didn't work hard enough.
The deeper problem is this, your team is finishing tasks but not finishing value.
In this video, I'll show you why that happens, how teams accidentally hide unfinished work inside their stories, and a simple test you can use to tell
whether something is really a story or just a task.
I'm Mike Cohn.
I've spent decades helping agile teams write better user stories.
And this is one of the most common patterns I see.
A team works hard, all sprint.
Everyone's busy.
Real progress is made.
But at the sprint review, the more important story still isn't done.
The backend works, but the interface isn' connected.
the happy path works.
but edge cases aren't tested.
The feature is close, but no one is comfortable calling it complete.
So the story moves into the next sprint.
When that happens occasionally, it may just be bad luck.
when it happens regularly, look first at how the Story was split.
Teams often think they have a capacity problem or commitment problem when the real issue is a splitting problem.
Big stories are hard to finish, but the bigger issue is that teams often break stories down in ways that still prevent anything usable from being completed.
Work moves, tasks get checked off, the board looks active, But the value is still trapped inside something larger that isn't done yet.
And in Agile, unfinished value is the same as no value.
That's where story splitting helps, when it's done correctly.
Story splitting means more than just making stories smaller.
It means creating smaller stories that each deliver something meaningful on their own.
The goal of story splitting is to release value sooner.
Let me show you what usually goes wrong.
A team has a story like this.
As a home buyer, I can search for a Home based on size, rooms, status, type, age, and amenities.
That's a big story.
So the team splits it by technical layer.
One backlog item for the user interface, one for back end, One for database and one testing.
That may look like progress, but nothing usable exists yet.
No one wants a search screen that doesn't search, and no one can use a database query without an interface.
The team has divided the work, But the value is still locked inside the larger story.
the team's finishing pieces of work but not finishing anything a user can actually use.
A better approach is to split vertically.
Do a little of the user interface, a lot of back end, little database work, and enough testing to make something work end to end.
For the home search example, the first story might be, as a prospective home buyer, I can search for a home based on size and number of rooms.
That's smaller.
It's incomplete compared with the full capability, but for what it includes, it works.
Now the team has finished something real.
A later story can add status and type of home.
Another story could add age and amenity searching.
Each story unlocks more value.
That's the shift from completing tasks to delivering value!
This is where teams confuse story splitting with task splitting.
Tasks describe activities.
Stories describe outcomes.
A task says, build database tables.
A story says a customer can complete a payment.
Here's the test I like.
After this is done, can someone do something they couldn't do before?
If yes, you probably have a story.
If no, You probably a task, even if you called it a Story.
If this sounds familiar on your team, this is exactly the kind of thing we help companies improve in our private agile training.
We work with teams to write better stories, split work more effectively, and make finishing meaningful work inside a sprint more realistic.
I'll include a link below if your company wants help with that.
One reason this matters is that big work hides uncertainty.
You've probably seen this, a story is 90% done.
A week later, it's still 90%. The developer was being sincere when they said they were 90%, but additional complexity showed up and finishing the story
got bigger.
Small outcome-based stories avoid this.
They move cleanly from not started to done and they expose risk earlier.
As a rough guide, be cautious of any story that can take half of a sprint.
That's usually a sign that value is bundled together instead of being delivered incrementally.
Good teams work with much smaller stories, not because small is automatically better, but because finishing is better.
So what makes a good split?
Someone can do something new when it's done.
The team can finish it comfortably within a sprint.
It cuts vertically through their product instead of separating the interface backend database and testing into separate backlog items.
Its clear enough that the team understands what must be true for this item to be considered complete.
And it creates value, even if it is only one small part of a larger capability.
Sometimes the team will say, this story cannot be split.
My first response, try harder.
Not harshly, but realistically.
Most teams give up too soon.
They try one or two obvious splits, usually technical layers.
And when those don't work, they give-up on splitting the story.
That's why I use Spider.
It gives teams multiple ways to find splits.
Spike, paths, interfaces, data, and rules.
If one type of split doesn't work, try another.
So when a story feels too large, don't ask, how can we divide the work?
Ask instead, what's the smallest piece of value we could deliver?
Can we support one path first?
can We defer an edge case?
We limit the scope to one persona, one data source, or one rule?
Are we creating smaller stories?
You're just disguising tasks as stories.
And most importantly, what must be true for this to be done?
If your stories keep carrying over, your team may not be failing to finish.
They may be finishing the wrong things.
The fix is to make the unit of work small enough that finishing something meaningful is realistic.
If you want a practical way to find those smaller value-based splits, watch my spider video next.
It gives you five ways to split a story when the obvious split doesn't work.
Thanks for watching.

Working in Agile Teams (9 Lessons from the Princess Bride)

Transcript

Have you seen the movie The Princess Bride?
If not, that's inconceivable.
While ostensibly a swashbuckling tale of high adventure, pirates, torture, and true love, the film is actually full of advice for agile teams.
And the book is even better.
Here are nine takeaways for Agile Teams from The princess Brides.
Number one, cutting quality never helps.
In the movie, the hero Wesley dies but turns out to be only mostly dead.
This is good news because a miracle can bring him back to life.
When pushed to rush making that miracle happen, Miracle Max brushes aside the urgency by saying, you rush a Miracl man, get rotten miracles.
Max's words remind us not to rush.
When a team hurries, it creates problems they'll need to solve later.
No rushing for Miracle Men or Agile teams.
Number two, iterating gets easier over time.
Another of Wesley's trials involves him drinking wine that has been poisoned with Iocaine powder.
Normally, this would be fatal, but Wesley has spent years building up a tolerance to Iacaine.
He drinks it and survives.
Very few Agile teams need to become accustomed to drinking Iocaine powder.
However, all Agiles teams do need become accustom to new practices, such as iterating, automated testing, frequent collaboration,
and so on.
Like Irocaine Powder, these practices do get easier to take over time.
Number three, the Scrum Master is a role.
In The Princess Bride, The Dread Pirate Roberts is revealed not to be a single pirate, but a progression of pirates, all using the same name.
Upon the retirement of the first Dred Pirates Roberts, his second-in-command carries on under the name, deciding that this would be easier than building
his own reputation as TheDreadPirateCluny.
When he retires, a third Dread Pirate Roberts takes over, and so on.
In other words, the Dred Pirates Roberts was a role that was being filled by one pirate at a time.
It's the same for Scrum Masters.
Number four.
Tools have their role.
The Agile manifesto is well known for favoring individuals and interactions over process and tools.
This doesn't mean agile teams are opposed to tools, we just want tools that support individuals in interactions.
A good tool such as a Holocaust cloak used by Fezik in the movie can really be a lifesaver for a team.
Number five, things are rarely as scary as they seem.
Going through a change can seem frightening.
Adopting Agile, for example, can be scary for team members wondering how design fits into Agil or how testing can accomplished in the same iteration as coding.
In the movie, Wesley and Buttercup are forced to navigate the fire swamps and battle the rodents of unusual size who live in swams.
Buttercup in particular is fearful because, as Wesley acknowledges, no one has ever survived.
But once through the fire swamps, Wesley concludes, it's not that bad.
Well, I'm not saying I'd like to build a summer home here, but the trees are actually quite lovely.
Agile teams need the courage to try new ways of working.
They rarely find anything as intimidating as fire swamp or rodents of unusual size.
Number six, work at a sustainable pace.
In The Princess Bride, Count Rugen offers the advice.
Get some rest.
If you haven't got your health, you have got anything.
Agile teams practice this through the principle of sustainable pace.
Working at a steady, consistent pace beats frantic overtime followed by periods of recovery.
Number seven, action settles arguments.
In a classic scene, Vizzini, a genius who makes Plato, Aristotle, and Socrates look like morons, argues with the man in black.
Not Johnny Cash, but a different man.
This was before Johnny Cash, but after arguing, everything came after argument.
No matter how well Vazzini reasons through his predicament, he and the man in black only resolve it through action.
It's the same with agile teams.
Team members can debate process changes or technical decisions endlessly, But the only way to resolve the dispute is to try something and see how it works.
Number eight, flexibility is essential.
It's beneficial to have team members with more than one skill.
The tester who can write some JavaScript or the programmer who could make database changes, for example.
Inigo Montoya demonstrates the ultimate in flexibility by sword fighting with both his left and right hands as needed.
Number nine, rely on reason, not guesses.
In the Princess Bride book, Vizzini, with his staggering intellect says, I don't guess.
I think, ponder, deduce, then I decide.
But I never guess!
When identifying changes to make, agile teams should do the same.
Think about the sprint that is ending, Ponder possible improvements to making, Then deduces and decides on the most promising changes.
I hope The Princess Bride can help reinforce these agile lessons for you.
I know it's cliché to say so, but the book is much better than the movie.
Check it out if you haven't yet.
Remember, agile is difficult.
Anyone who says different is trying to sell you something.
Now, anybody want a peanut?

Working with Non Functional Requirements & Product Backlogs

Transcript

When we talk about non-functional requirements, we're not talking about features in the menu or user-facing functionality.
We're talking attributes and characteristics, how the system exists in-the-world.
Things like it runs on Android and iOS.
It loads within half a second.
Works in Chrome, Edge, Safari, and maybe Firefox.
It handles 100,000 concurrent users.
And it follows brand standards.
These aren't functionality.
They're constraints.
There are qualities.
The often make or break a user's experience, but they're not always obvious.
Here's the problem.
Non-functional requirements apply across multiple stories or even an entire system.
That makes them harder to define, harder prioritize, and harder test, especially if they are vague.
Be fast means nothing.
Respond within half a second with 100,000 concurrent users, that's actionable.
And because NFRs are not attached to any one story, they often get ignored until they blow up, slow performance, cause security issues,
fail to support a browser, you name it.
Here's a better way to handle them.
Start by creating a user story to come into compliance.
then once you've got it working, add that requirement to your definition of done so you stay in compliance.
Let's say you support Chrome Edge and Safari.
Eventually, you want to add Firefox.
To ensure you don't forget to do that, write a story.
When I visit the site in Firefox, it works.
when that story bubbles up in priority, do the work to implement it.
Then update your Definition of Done.
Supports Chrome, Edge, Safari, and Firefox Another example, maybe you support English, German, and Spanish.
You want to add French.
you begin with a story, as a French speaking user, I want it to interact with the site in my preferred language.
Again, As it becomes a priority, it's worked on and finished.
Then you update your definition of done again, supports English German Spanish and French This approach works because it enables adding support for new
non-functional requirements to a product, but also helps a team remember ones they need to continue supporting.
So remember, nonfunction requirements are about how your system exists in the world.
Start by writing them as user stories.
Then as each becomes a priority, do the work to come into compliance with that story.
Finally, add each to your definition of done.
If this was helpful, hit like, subscribe, or drop a comment with how your team handles non-functional requirements.
See you next time.
So remember, nonfunction requirements are about how you system exists in the world.
Start by writing them as user stories.
Then as each becomes a priority, do the work to come into compliance with that story.
Finally, add each to your definition of done.
If you'd like more help working with user stories, download my 200 User Story Examples PDF.
It showcases the good, bad, and ugly user story from one of my early Agile projects with comments from me now on how I'd improve some of those user's stories
if I were writing them today.
You'll find the link in the description.
See you next time.