May 7, 2025 • 38 mins
What if everything you thought about improving team delivery was focused on the wrong problem? Sonya Siderova, founder and CEO of Nave, challenges the traditional approach of pushing people to work harder by revealing a game-changing insight: between 60-90% of delivery time is actually waiting time, not effort time.
Through her work analyzing over 100,000 workflows, Sonya demonstrates how making the invisible visible transforms team performance. She shares a powerful example where simply adding a second approver to a bottleneck process reduced delivery time by 40% without requiring overtime or additional resources. This shift in focus—from workers to the work itself—creates transparency without micromanagement and builds trust across all levels of the organization.
Sonya walks us through practical approaches for mapping workflows, structuring work around customer value, and establishing team decision frameworks that enable autonomy. She explains how aging charts can quickly identify bottlenecks during daily standups, saving teams from wasting time on status reports and focusing them on what truly matters: getting stuck work moving again.
For leaders struggling with the eternal question "when will it be done?", Sonya introduces probabilistic forecasting using Monte Carlo simulations. This approach replaces arbitrary deadlines with data-driven projections that acknowledge the inherent uncertainty in knowledge work while providing meaningful ranges for decision-making.
Whether you're a team lead trying to improve predictability, a product manager seeking to deliver customer value faster, or an executive looking to create a more transparent delivery system, this episode offers actionable insights to transform how you think about and measure work. By focusing on flow rather than force, you'll discover how to dramatically improve delivery performance while creating a healthier, more trustworthy work environment.
Listen in and learn how to stop pushing people and start pulling work through your system for remarkable results.
Connect with Sonya on LinkedIn:
https://www.linkedin.com/in/siderova/
Check out Flow Metrics Including Probabilistic Forecasting using Nave:
https://getnave.com/
Follow us on LinkedIn:
https://www.linkedin.com/company/the-agile-within
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:06):
Welcome to the Agile Within.
I am your host, mark Metz.
My mission for this podcast isto provide Agile insights into
human values and behaviorsthrough genuine connections.
My guests and I will sharereal-life stories from our Agile
journeys, triumphs, blundersand everything in between, as
(00:29):
well as the lessons that we havelearned.
So get pumped, get rocking.
The Agile Within starts now.
Attention, scrum Masters andAgile enthusiasts, are you ready
to level up your skills andconnect with the best in the
industry?
Well, the Online Scrum MasterSummit is your chance to hear
(00:51):
from world-class Agile experts,gain real-world insights and
explore the latest trendsshaping the future of Agile.
Best of all, it's 100% free andcompletely online.
Happening from June 17ththrough the 19th, this event
brings together thousands oflike-minded professionals for
(01:13):
engaging talks, interactivesessions and hands-on workshops.
Don't miss this opportunity tosharpen your skills and expand
your network.
Sign up now atonlinescrummastersummitcom.
And now on to the show.
Welcome back to the AgileWithin everybody.
This is your host, mark Metz.
(01:34):
My guest for today's episode isSonja Sidrova.
Sonja, welcome to the show.
Hi, it's a pleasure to be here.
Thank you so much.
I follow you on LinkedIn.
I see all your wonderful poststhat are out there.
You're from Antwerp, belgium.
Is that right?
That's right, yes, okay.
So, sonia, if I were coming toAntwerp for a day and had never
(01:56):
been there before, what's onething that you would say that I
couldn't miss doing?
Speaker 2 (02:07):
Mark.
So when I say that I live inAntwerp, I don't really live in
the city itself.
I'm living in 30 kilometersaway from it, in a little place
called Zursel.
It's a little village with agorgeous nature, and the one
thing that I would do if I knewyou were coming around is I
would invite you to be my guestin my home.
I would invite you to come tomy place because we're living in
(02:32):
the middle of the forest, in ahouse in the middle of the
forest with a huge garden, and Ihave two lovely dogs.
I have two Labradors One isstill puppy, super crazy to be
around and I would love.
I would love it if you can comeand stay with us for a couple
of days, because the biggestthing for Belgium apart from the
(02:56):
chocolate and the beer, ofcourse is the gorgeous nature
and the quietness, the beauty ofwhere you are.
It's a farm country.
There are a lot of people inthe villages, in the farms, and
it is a lovely place to reallystay and just enjoy the silence,
(03:17):
enjoy the nature.
You're more than welcome to bemy guest next time if you decide
to come around.
Speaker 1 (03:25):
That sounds fantastic .
So is it even quiet, even withthe puppy in the house.
Speaker 2 (03:30):
He's the loudest thing in the house, for sure.
Speaker 1 (03:34):
All right, well, thanks for sharing that, sonia.
I want to introduce you.
So.
Sonia is the founder and theCEO of Knave, a company that
helps teams use flow metrics toimprove delivery performance and
make better decisions.
Her background is in agilecoaching and lean product
delivery, and she's especiallyfocused on making delivery more
(03:54):
predictable and efficient, andthe title for today is how
Transparency in Delivery HelpsBuild Trust Without
Micromanagement in deliveryhelps build trust without
micromanagement.
Tell us a little bit more abouttransparency and delivery and
how that builds trust, sonia.
Speaker 2 (04:13):
So I probably should take a step back first, because
I do want to talk about deliveryand I do want to talk about,
when it comes to delivery, whatdoes this really mean?
Usually, when agile teams gothrough their work, they measure
different kinds of things, theyreport different kinds of
(04:34):
things, and the goal, obviously,is to make data-driven
decisions, to be aware of what'sgoing on and to be more
transparent, to be moreproductive, to be more
predictable, if you will.
The biggest mistake that I'vebeen seeing lately is that the
focus really is on theperformance of the teams in
(04:57):
terms of individuals.
If, let's say, someone says,hey, I need this done by that
specific date and things startgoing south, the first thing
that people do is to keeppushing people work harder.
They keep pushing in thisdirection and say, hey, you have
to stay long hours or you haveto stay over the weekend, or the
(05:23):
focus really goes intoindividuals and how hard they're
working.
Now, the problem with thisapproach is that effort time and
delivery time is not the samething.
In fact, there is a study thatwe performed internally at NAVE,
where we've analyzed more than100,000 workflows, and it turned
(05:49):
out that anything between 60%and 90-90% of the total delivery
time is waiting time.
Pay attention to these numbersbecause they were like really a
game changer for us.
Anything between 60% and 90% ofyour delivery time is waiting
(06:12):
time, it's not effort time.
So when I talk about delivery,I'm talking about both those
efforts time and waiting timetogether.
I don't usually talk abouteffort time because, if you
think about it, anything between1% to 30% is effort time.
(06:33):
If you keep pushing inoptimizing that effort time, you
can literally improve those, goto up to this 30%, but no one
actually talks about the rest,like the 60 to 70%, that can
actually be improved in orderfor us to become faster, to
become more predictable.
So when I'm talking aboutdelivery, I'm talking about both
(06:57):
waiting time and effort time.
To be even more honest, I'mtalking more about the waiting
time than the effort timebecause there are just little
tweaks that may happen in orderto reduce that waiting time
tremendously without changinganything else.
Speaker 1 (07:18):
So why do you think it is that the waiting time is
not one of the first places thatwe go or that management goes
to look at the workflow of workto try to reduce?
Why is it?
Is it just easier to push onthe people to work harder or
work longer?
Speaker 2 (07:38):
Because waiting time is invisible, because you don't
see it, because no one knowsabout it.
That's why and it's not thatpeople, like, don't have the
expertise or they don't have thewillingness to get there, they
just don't know about it.
Honestly, this is one of themain reasons why I started my
own business back in um 2014.
(08:00):
I wasn't in a situation where Ididn't see what's going on.
I was in a team.
Everything like everything wasdelayed, people were frustrated,
the development cost wentthrough the roof.
We didn't know what's going on,so we started unhiding what's
going on with the work.
(08:20):
So this was like a big shift inthe actual way we thought about
it.
We started to think about thework itself and not what the
people did right.
So we didn't want to focus onthe workers, we wanted to focus
on the work itself.
We started mapping the stepsthat work goes through, from the
(08:44):
idea to the refinement, then tothe moment that the team put it
into the workflow the code,reviews, the approvals, the
deployments, all of it.
So we started mapping it.
Then we actually visualizedthat flow of how the work moves
through that flow, and then westarted measuring how much time
(09:07):
the work spends in each state.
We didn't care who is doingwhat, we didn't care what people
are busy with.
We were solely focusing on okay, let's see what happens with
the work.
So we started measuring thetimes that it's spent in each
state and it turns out 40% ofour total time, of our total
(09:30):
delivery time, was spent in someweird approval state, and we
only figured that out when westarted measuring that time.
We didn't know about it, wedidn't see it.
It was the waiting time spentin that approval column that
increased our delivery timestremendously.
As soon as we revealed thatinformation, what we did is to
(09:53):
ask for a second person to joinon that step, so that there are
at least two people availablefor that approval.
So once that person who wereresponsible for that step were,
they were on a leave or theywere engaged with something else
, that second person jumped into help.
Just by making that tweak, wemanaged to reduce our delivery
(10:15):
times by 40%.
We didn't change 40?
.
Speaker 1 (10:20):
Yes.
Speaker 2 (10:21):
By just making this tweak.
We didn't do anything.
We didn't add more people, wedidn't have to work overtime, we
didn't even have to change howwe managed the work.
The only thing we had to do isto make sure that the work
doesn't age artificially in theprocess.
It doesn't just stay and waituntil someone is available to
(10:42):
approve it.
And the only way for us to knowthat was to unhide that waiting
time.
It was to reveal what's goingon with the process and really
focus on the work and not theworkers.
The reason people just don'tsee it.
It's just invisible and we haveto unhide it.
(11:02):
That's one of the things ouranalytical suite does.
It actually measures cycle timeof each step in the workflow
and then it tells you themajority of the time is spent
here.
Is this what you expect to see?
And if not, this is thebottleneck in your process.
This is the main priority foryou to handle right now.
Speaker 1 (11:26):
So what does that mapping look like?
How do you go into a sessionwith a team to figure out what
that workflow looks like?
I'm envisioning some sort of avalue stream mapping for the
work itself.
Speaker 2 (11:38):
It's actually very easy.
It doesn't matter what yourworkflow looks like.
It really doesn't matter.
The most important thing whenyou talk about flow and we talk
about mapping that flow is tomake sure that you represent
what you're currently doing.
You don't want to design somefancy processes or any some sort
(11:59):
of a future state of the work.
You do want to visualizeexactly the steps that your team
are going through in order torelease a piece of work that has
been requested from them.
You have a board.
It could be Jira board or AzureDevOps board, even Trello board
, doesn't matter.
(12:19):
You take a board, then youcreate the columns which
represent the steps and then, assoon as you have a work item,
you create a card for it andthen move the work item through
these columns or statuses and assoon as it goes out of the
process, then this means thatthe work has been delivered.
Now, during our retrospectives,we just go and evaluate our
(12:43):
cycle times and the breakdown ofthese cycle times.
At NAIF, we have the so-calledcycle time breakdown chart,
which essentially is a pie chartwhich shows you, from all of
your delivered work items andthe time spent in all of the
statuses, which is the statusthat we spend the most time in,
(13:03):
and again, for our case back inthe day, that was disapproval
status.
40% of that delivery time wasdisapproval status and it's as
easy as just looking into thebreakdown to understand that.
But then I think one of themajor things for us was to
really have this shift inmindset in our mindset of
switching the focus from tryingto understand what everyone is
(13:28):
doing up to trying to understandwhat happens with the work and
where the work spends the mostof our time.
Speaker 1 (13:36):
So one of the traps that I have seen and I'd like to
get your perspective on howcycle time can help with
measuring that to look is thatmany times I've seen developers
when I say developers, I'mtalking the development team of
their eyes being bigger thantheir stomachs, and what I mean
by that is this looks like asmall amount of work.
(13:59):
It won't take me long to do so.
We're going to do this piece ofwork, and before you know it,
the cycle time starts going upand up and up, and it stays in
development for days beforemoving, and then, when it moves
on to the later stages, it takesa long time to get that, and so
one of the things I have seenis trying to break the work down
(14:21):
into smaller increments so thatwe can get that value realized
sooner, as opposed to waitingfor a larger chunk of work to
get done to realize all thatvalue.
Is that something that you'veseen as well, sonia?
Speaker 2 (14:36):
Yes, I've been into this conversation pretty much on
a daily basis.
Now, when we talk about how weshape the work and how we
organize the work, I have a verysimple rule.
So, when we're creating ourstories, we do want the story to
represent customer value.
(14:58):
And what I mean by this is thatwhen I'm shaping the story, I
do want, as soon as I'm done, assoon as we as a team are done
with that piece of work, theperson who requested it can
check it, can play with it, cangive us feedback on it, because
(15:19):
the main goal for us as a teamis to solve problems, is to
deliver something that'sreasonable, that's meaningful,
and we can only know ifsomething is meaningful and
reasonable as soon as the personwho asked for it confirms that.
That's the only time when weknow for sure that what we've
(15:43):
been doing is worth it and whatwe're delivering is actually
customer value.
So for us, in order to get tothat place to understand whether
we're moving in the rightdirection, we need to try to
shorten that cycle time as muchas we can without compromising
the concept of value.
(16:03):
Right, I'm seeing teams who aretrying to split the work to
back-end development, front-enddevelopment, database
development.
I'm not a fan of this approachbecause if I have a piece that
says database development, howwould the person who asked for
it can give us feedback on it?
How would the person who asksfor it can give us feedback on
it?
Isn't it better to split it in,let's say, maybe some UI
(16:25):
interaction, so maybe we canhave just the frames and then
give it to the customer and theycan say, okay, this is in the
right direction, or I don't likethis, or even that has nothing
to do with what I asked for.
So when we're splitting thework, we want this to be in
terms of customer value and wewant to split it in a way that
(16:46):
we get to that solution in thefastest and easiest way.
Now, if we've done this and thepiece of work is still too big,
it's just there is no way tosplit it.
There is just no way to deliverjust part of it.
If it's too big, in order tomake sure that we still stick to
(17:06):
those short cycle times, weallocate more capacity on that
work.
What this means is that,instead of one person, we
allocate two, maybe three people, if there is any bottleneck
that appears around it.
Any question, this is thehighest priority for the team.
This means that if, for somereason, something more urgent
(17:27):
comes in, we understand that bysuspending this big piece of
work, we are delaying itintentionally.
But all of these decisions,they are intentional.
When we're saying yes tosomething, we're saying no to
something else and we're awareof the fact that we're saying no
(17:48):
to something else.
Speaker 1 (17:50):
I love that.
Speaker 2 (17:51):
There is a lot of perspectives around that.
I believe if the main goal ofthe team is to make sure that
value, that piece of value, goesout of the workflow as soon as
possible, then they will startpaying attention to anything
that gets delayed, anything thatstays in the workflow for
(18:14):
longer than it should, and thisis something that we're doing on
our dailies.
We have a chart that we callthe aging chart, and that aging
chart it has all of our workitems as dots scattered on a
plot, and then we know if acertain dot goes up, this means
(18:36):
that it accumulates waiting time.
It accumulates cycle time.
It's not necessarily awaitingulates waiting time.
It accumulates cycle time.
It's not necessarily a waitingtime every time.
It's just the higher the dot,the longer it stays in the
process.
Now, for us as a team, theconversation during our dailies
is to go through the top dots,everything that's on top, and
(18:58):
talk about it.
We don't talk about it,anything that just has been
started.
We don't talk about our to-dolists.
We don't talk about things thatare still moving the way we
expect them to do.
We talk about things that areaging artificially, things that
are taking longer than, let'ssay, 85% of everything else that
(19:19):
has been finished so far, let'ssay, 85% of everything else
that has been finished so far.
We talk about any blocked work,any expedite work, any
questions the team has in orderto move forward.
Our meetings are not statusreport meetings.
We don't go through the entireboard to see what's the status
of each task.
The board gives us thatinformation.
We don't need to talk about it.
The only priority really iseverything that's staying longer
(19:44):
for a specific state.
Why is that?
Is it blocked?
Is there anything else that youneed?
Is there like additionalinformation that we need to
provide?
Do you need feedback?
What is it that's making thework stink and aging, and then
we brainstorm solutions in orderto have this work moving
further.
Speaker 1 (20:03):
I'm sure you've experienced this.
How do you help teams getunstuck when you're looking at
your cycle time chart and you'vegot this one circle that's like
way above the others.
So the cycle time is going up,but the team is convinced oh,
this is a special situation,this is different, this doesn't
(20:24):
always happen.
This just is what it is.
We just need to get focused ongetting it done.
Whenever it gets done, it getsdone and we won't experience
this again.
How do you help teams getunstuck with being more open to
looking in and not justconsidering this to be a one-off
and something that theyshouldn't look into?
Speaker 2 (20:45):
The way our teams make decisions are following
specific decision-makingframeworks.
We call these process policies,and a process policy is just a
decision, an answer to aquestion Like what do we do with
blocked work?
(21:05):
What do we do with aging work?
What do we do if something likea defect arrives?
What do we do if we have itemswith different priorities?
How do we manage work that hasthe same priority?
Which one goes first, which onegoes second?
When is the right time toescalate something?
Who is the right person toescalate it to?
(21:26):
Those are our process policies,our decision-making frameworks
that first enable autonomousteams, meaning they know what to
do in every situation,especially in urgency situations
, and second, it sets a base forus to keep improving our
(21:47):
workflows.
If something goes outside ofour thresholds, and we have like
big red zones that show us thatsomething goes outside of the
thresholds, as soon as this isthe case, we start talking about
this and then we try tounderstand what was it that
(22:07):
actually led to that result?
And usually it's something inthe policies or the fact that we
didn't have a policy about thatuse case.
Those cases are feedback for us.
We use that, we use thosesituations, these outliers, as a
feedback loop which fits therules and the changes we want to
(22:28):
apply.
On the rules, because thosedecision-making frameworks are
owned by our teams.
They create them, we don'tcreate them.
The teams create thosedecisions.
They make those decisionsbecause they're in the best
position to do so.
They're in the trenches all day, in and out, and they know
(22:49):
what's best for it.
And when they create it andwhen they own it, there is no
reason for them not to follow it.
When they see those outliers,what they do is they start
brainstorming.
Okay, what is it that led tothis situation?
Can we change something on ourpolicies in order to make sure
we don't end up in thatsituation again?
(23:10):
And simple things like wedidn't have enough information
in order to resolve that problem.
Well then, let's change thepolicy that a task can only
enter the workflow if you havethis and this and this available
.
You just don't start the workuntil you have those three
points there.
(23:30):
That's how the team is actuallyembracing these cases, and it
is because it helps them dotheir job better.
It helps them to be better atsomething that they're not
individually influencing, butthey influence as a team.
(23:51):
That's one of the reasons whyI'm so focused?
I'm not focused at all onindividuals' performance.
That's something that we don'tcare.
That's something we don'tmeasure in our tool.
There is no place where you canactually track individuals's
performance.
That's something that we don'tcare.
That's something we don'tmeasure in our tool.
There is no place where you canactually track individual's
performance.
You can only track team'sperformance, because it's a
collaboration that is needed inorder to go out with something,
(24:16):
because it doesn't matter howefficient your developers are.
If everything gets stuck in thetesting phase, you're not
delivering, you're not bringingthat piece of value to your
clients, and when you don't,what's the point right?
Speaker 1 (24:32):
I'm glad you brought that up about the policies,
because that is very, veryhelpful to the teams, very, very
helpful to the teams, and Iwould say yes.
And the part that I would liketo add is I've seen some teams
be so obsessive over making surethey get those policies right
up front.
Those evolve over time.
You cannot foresee everypossible combination that's
(24:56):
going to happen.
So take your best shot up front, set your policies on how
you're going to handle work andif something arises, hey, you've
got a retrospective.
That's a great topic to talkabout.
How might we update ourpolicies to prevent this from
happening again in the future?
So too, they're so anxious andso worried to make sure they get
(25:16):
all the policies right up front.
You know, even within our ownsociety we have to amend laws
right, so it takes some time forthose to come up and to get
those just right.
Speaker 2 (25:29):
This is good.
I actually love this because,indeed, those policies, they're
not set in stone, they're aliving thing, and it's not just
with policies, it's everythingsteady in stone they're a living
thing, and it's not just withpolicies, it's everything.
If you start thinking onsomething big and then in the
middle of the process, it turnsout that it's way more
complicated than you initiallythought, of course you're going
(25:51):
to split it.
Of course you're going tochange the scope or cut some of
the scope or even add more tothe scope.
It's a living thing.
The policies are a living thingand you should change them.
They have to change.
If you don't change them,something is going wrong.
You have to change them becausethings change around you.
(26:13):
Your clients change, the marketchanges, the environment around
you changes.
Your policies have to adjustbased on all of these changes.
So, absolutely, those areliving things.
And back to your initialquestion mark how does that lead
(26:35):
to transparency withoutmicromanagement?
Well, first of all, you don'tcare anymore about individuals'
performance.
There is no place for that.
Second of all, with all thatbeing said, all the policies,
all the rules in place, you haveyour autonomous teams.
You have teams who understandhow to do the work in the best
possible way for the businessand for their customers.
(26:58):
And third, the C-level and themanagement level.
They have that understanding ofwhat delivery means.
They have understanding aboutwhat's their time to market.
They have understanding of howmuch work they can handle at any
one time.
They have understanding of thecapability of the team, which is
(27:18):
the most important thing inorder to know when to say yes
and when to say no to.
In the end of the day, it's avery beautiful picture, because
everyone is happy, your teamsare happy, your management is
happy, your clients are happy,Because the biggest advantage of
(27:39):
focusing on flow and flowmetrics is that the focus is on
the end customer.
It is on how much time you makethem wait in order for them to
get what they asked for, andthat's all what matters in the
end of the day.
Speaker 1 (27:57):
So, sonia, what about that CEO, that COO, that
customer that is waiting for,let's just say, the delivery of
a system and, right or wrong,the system can't go out
partially, it has to go out as awhole.
(28:17):
You're delivering value everyweek, every two weeks.
What have you?
It's not going to be releaseduntil the whole system is there
and you've got this CEO that'sasking you okay, I hear all that
you're saying about this cycletime, about this value, about
wait time, but when's it goingto be done?
That's all I want to know is,when is it going to be done?
(28:40):
And they're so high up in thecorporate structure that they
really don't want to know in theweeds.
They just want to have that oneanswer.
How do you answer that and howdo you approach that type of
stance?
Speaker 2 (28:53):
I have a very special opinion when it comes to making
delivery predictions.
I'm a strong believer of theconcept of probabilistic
forecasting.
What is probabilisticforecasting?
It is the understanding thatthere is no one single certain
(29:13):
answer to that question.
When will this be done?
Probabilistic forecasting givesyou a range of delivery times
and a probability of achievingeach of them, and the question
when will this be done is nolonger that interesting, because
we have the tools In ouranalytics suite.
(29:36):
We have the tools.
They're called Monte Carlosimulations.
They take your past performancedata.
They run millions ofsimulations based on what you've
done so far in order to giveyou those dates.
So you can simply use your pastperformance data in order to
come up to the answer when youwill be done right.
(29:58):
And then the Monte Carlosimulations, the probabilistic
forecasting tools, are going togive you that answer.
They're going to give you fivedays and the probability of
hitting each of them, and nowit's up to you to decide.
How much risk are you willing totake?
Your job now is to make thatdecision.
Is the work easy?
(30:18):
Have you done this this before?
Do you expect any challengesalong the way?
Are there a lot of unknowns?
If that's the case.
If it is like very important tohit that end goal, you go with
a higher percentile.
The higher the risk, the higherpercentile.
Then you choose the date that'slike at the end of that range.
(30:39):
If the work easy, you haveconfidence that you can deliver,
you know that even if you don'tget to that place, it's
negotiable.
You go with the 70th percentileand then you go and choose a
date that's earlier.
That's how you make yourcommitments.
You use probabilisticforecasting that's based on
(31:02):
facts and not judgment or gutfeeling.
You use your past performancedata in order to come up with
that date and from then on youstart running that forecast
every two weeks.
That initial commitment is justthat, your initial commitment.
(31:23):
Your work hasn't been done justyet.
Your work is just has started.
So you have to keep runningthat forecast every two weeks,
taking into account what you'vedone in the past two weeks, and
you make adjustments based onthe feedback that you receive.
So if it turns out that theprobability of hitting your
(31:44):
initial goal is getting lowerit's not 98% anymore, it's 90%
or even 80%, even 70% what is itthat you can do?
Can you cut the scope?
Can you add more people?
Can you reduce thework-in-progress limit so the
team can really focus on whatthey're doing and not doing
another 100 things a part of it.
(32:05):
What is it that you have tochange in order to get back on
track?
You keep changing the process.
You keep running every twoweeks, even if at some point it
turns out that you won't make iton time, and at least you can
communicate this early.
You can go ahead and say, hey,here is the situation, we won't
(32:26):
make it, let's make a decisionnow so we don't impact the
business goals that you havebecause of that commitment.
That's how you buildcredibility.
That's what builds yourreputation as a professional
Making those decisions andhaving those conversations,
(32:49):
because you cannot predict whenyou will be done.
There is just no such thing as100% certainty that something
will happen in the future.
The best thing you can do is tostay flexible and put your hand
on the work and keep runningthose simulations in order to
make sure that you'll make it ontime.
Speaker 1 (33:09):
That's really good.
I've often found that givingpeople options to be very
powerful, because when you justsay, like, when someone says are
you going to have it done bythis date, to just say no,
there's some level of rigidityto that and you typically don't
get a good response.
But if you give them options,like you say, hey, well, if you
(33:30):
would like to take on the riskof we've got a 50-50 shot at
making it as of this date, whatwould you like to do?
Can we cut scope?
Are there some pieces of thisthat we could deliver later?
And one of the things that Ilike to do when I prioritize
features to be included in adelivery is I like to go by them
(33:50):
one by one, because typicallyyour response is going to be, as
you go through this list,stakeholders will say, yes, I
need that.
Yes, I need that.
No, I can't live without that.
Say, okay, let's look at this adifferent way.
If I were going to tell youthat I was going to deliver
everything on this list exceptthis one feature, would you
(34:11):
release?
Would you go live with it?
If the answer is no, we need tohold everything, all the work
that we've done.
We're going to hold it offuntil we get this done.
And okay, that sounds likesomething that you have to have.
But if you turn the perspectivejust a little bit, sometimes
you can get a different answerof well, so you're telling me, I
(34:31):
can get all of this in, but Ihave to wait on just this one.
No, we can live without thatfor another month.
Yeah, let's do that.
And so you can kind of startde-scoping some of those things
that once felt like a must-havenow turns into well, maybe we
don't have to have it, maybe wecan bring that in later.
(34:52):
But I love the idea of givingoptions because that makes
someone else feel like they havesome power in the say right.
They have some power in the sayright.
They have some choice in thedecision, not just be told no.
Speaker 2 (35:07):
And it's their decision.
In the end of the day, it'stheir decision.
You can even go ahead and letthem choose the end days.
You can just tell them okay,these are the risks that are
coming with these delivery days.
Just pick how much risk youwant to live with.
And just for the record, 50%certainty is like very low.
(35:30):
For me, 50% certainty reallymeans we either make it or not.
I would never commit to the 50%chance of hitting a target
because, like you, you're betteroff just buying a pair of dice
and trolling them Right.
Um so never do that.
Always go with at least 70%chance that you can hit your
(35:53):
targets.
The most important thing for meis that when you take action
and when you have theseconversations Because if you
have these conversations as soonas the due date arrives- you
lost that game.
You have to be upfront with this, you have to be aware of it way
(36:16):
before you hit that deadline.
So take advantage, takeadvantage of all the tools that
would give you that informationreal time, and make sure you put
your finger on the pulse of thework, because, again, this is
the difference betweenprofessionals and amateurs Even
if things don't go the way youexpect them to go, if you're
(36:40):
upfront about it and you'retransparent about it, that's
going to make the wholedifference.
Speaker 1 (36:47):
Sonia, this has been absolutely fantastic.
I really appreciate you comingon the show.
If our listeners out there wantto get in touch with you,
what's the best way for them todo that?
Speaker 2 (36:57):
I'm on LinkedIn, sonia from NAVE.
I would love to hear from eachand every one of you.
I do want to know what's thebiggest takeaway from today.
I do want to know what is itthat actually sparked that
thought?
Because, mark, I want to behonest.
I love I can talk about thisall day long, but the most
(37:17):
important thing for me is whenpeople take action.
So, from each and every one ofyou, go ahead on LinkedIn, send
me a note.
I want to know what's the nextthing that you're going to do as
early as tomorrow morning.
What is it that you've learnedtoday that you're going to go
ahead and apply as early astomorrow morning in order to
(37:38):
move the needle?
Let me know.
Speaker 1 (37:40):
Okay, listeners, that's a call to action.
All right, Sonia, it's been apleasure.
Thank you for coming on theshow.
Really appreciate it.
Speaker 2 (37:48):
Thank you.
Speaker 1 (37:49):
And that ends another episode of the Agile Within.
We'll see everybody next time.
Thanks for joining us foranother episode of the Agile
Within.
If you haven't already, pleasejoin our LinkedIn page to stay
in touch.
Thanks for joining us foranother episode of the agile
within.
If you haven't already, pleasejoin our LinkedIn page to stay
in touch.
Just search for the agilewithin and please spread the
(38:12):
word with your friends andcolleagues Until next time.
This has been your host, markMetz.
Welcome to the Agile Within.
I am your host, mark Metz.
My mission for this podcast isto provide Agile insights into
human values and behaviorsthrough genuine connections.
My guests and I will sharereal-life stories from our Agile
journeys, triumphs, blundersand everything in between, as
(00:29):
well as the lessons that we havelearned.
So get pumped, get rocking.
The Agile Within starts now.
Attention, scrum Masters andAgile enthusiasts, are you ready
to level up your skills andconnect with the best in the
industry?
Well, the Online Scrum MasterSummit is your chance to hear
(00:51):
from world-class Agile experts,gain real-world insights and
explore the latest trendsshaping the future of Agile.
Best of all, it's 100% free andcompletely online.
Happening from June 17ththrough the 19th, this event
brings together thousands oflike-minded professionals for
(01:13):
engaging talks, interactivesessions and hands-on workshops.
Don't miss this opportunity tosharpen your skills and expand
your network.
Sign up now atonlinescrummastersummitcom.
And now on to the show.
Welcome back to the AgileWithin everybody.
This is your host, mark Metz.
(01:34):
My guest for today's episode isSonja Sidrova.
Sonja, welcome to the show.
Hi, it's a pleasure to be here.
Thank you so much.
I follow you on LinkedIn.
I see all your wonderful poststhat are out there.
You're from Antwerp, belgium.
Is that right?
That's right, yes, okay.
So, sonia, if I were coming toAntwerp for a day and had never
(01:56):
been there before, what's onething that you would say that I
couldn't miss doing?
Speaker 2 (02:07):
Mark.
So when I say that I live inAntwerp, I don't really live in
the city itself.
I'm living in 30 kilometersaway from it, in a little place
called Zursel.
It's a little village with agorgeous nature, and the one
thing that I would do if I knewyou were coming around is I
would invite you to be my guestin my home.
I would invite you to come tomy place because we're living in
(02:32):
the middle of the forest, in ahouse in the middle of the
forest with a huge garden, and Ihave two lovely dogs.
I have two Labradors One isstill puppy, super crazy to be
around and I would love.
I would love it if you can comeand stay with us for a couple
of days, because the biggestthing for Belgium apart from the
(02:56):
chocolate and the beer, ofcourse is the gorgeous nature
and the quietness, the beauty ofwhere you are.
It's a farm country.
There are a lot of people inthe villages, in the farms, and
it is a lovely place to reallystay and just enjoy the silence,
(03:17):
enjoy the nature.
You're more than welcome to bemy guest next time if you decide
to come around.
Speaker 1 (03:25):
That sounds fantastic .
So is it even quiet, even withthe puppy in the house.
Speaker 2 (03:30):
He's the loudest thing in the house, for sure.
Speaker 1 (03:34):
All right, well, thanks for sharing that, sonia.
I want to introduce you.
So.
Sonia is the founder and theCEO of Knave, a company that
helps teams use flow metrics toimprove delivery performance and
make better decisions.
Her background is in agilecoaching and lean product
delivery, and she's especiallyfocused on making delivery more
(03:54):
predictable and efficient, andthe title for today is how
Transparency in Delivery HelpsBuild Trust Without
Micromanagement in deliveryhelps build trust without
micromanagement.
Tell us a little bit more abouttransparency and delivery and
how that builds trust, sonia.
Speaker 2 (04:13):
So I probably should take a step back first, because
I do want to talk about deliveryand I do want to talk about,
when it comes to delivery, whatdoes this really mean?
Usually, when agile teams gothrough their work, they measure
different kinds of things, theyreport different kinds of
(04:34):
things, and the goal, obviously,is to make data-driven
decisions, to be aware of what'sgoing on and to be more
transparent, to be moreproductive, to be more
predictable, if you will.
The biggest mistake that I'vebeen seeing lately is that the
focus really is on theperformance of the teams in
(04:57):
terms of individuals.
If, let's say, someone says,hey, I need this done by that
specific date and things startgoing south, the first thing
that people do is to keeppushing people work harder.
They keep pushing in thisdirection and say, hey, you have
to stay long hours or you haveto stay over the weekend, or the
(05:23):
focus really goes intoindividuals and how hard they're
working.
Now, the problem with thisapproach is that effort time and
delivery time is not the samething.
In fact, there is a study thatwe performed internally at NAVE,
where we've analyzed more than100,000 workflows, and it turned
(05:49):
out that anything between 60%and 90-90% of the total delivery
time is waiting time.
Pay attention to these numbersbecause they were like really a
game changer for us.
Anything between 60% and 90% ofyour delivery time is waiting
(06:12):
time, it's not effort time.
So when I talk about delivery,I'm talking about both those
efforts time and waiting timetogether.
I don't usually talk abouteffort time because, if you
think about it, anything between1% to 30% is effort time.
(06:33):
If you keep pushing inoptimizing that effort time, you
can literally improve those, goto up to this 30%, but no one
actually talks about the rest,like the 60 to 70%, that can
actually be improved in orderfor us to become faster, to
become more predictable.
So when I'm talking aboutdelivery, I'm talking about both
(06:57):
waiting time and effort time.
To be even more honest, I'mtalking more about the waiting
time than the effort timebecause there are just little
tweaks that may happen in orderto reduce that waiting time
tremendously without changinganything else.
Speaker 1 (07:18):
So why do you think it is that the waiting time is
not one of the first places thatwe go or that management goes
to look at the workflow of workto try to reduce?
Why is it?
Is it just easier to push onthe people to work harder or
work longer?
Speaker 2 (07:38):
Because waiting time is invisible, because you don't
see it, because no one knowsabout it.
That's why and it's not thatpeople, like, don't have the
expertise or they don't have thewillingness to get there, they
just don't know about it.
Honestly, this is one of themain reasons why I started my
own business back in um 2014.
(08:00):
I wasn't in a situation where Ididn't see what's going on.
I was in a team.
Everything like everything wasdelayed, people were frustrated,
the development cost wentthrough the roof.
We didn't know what's going on,so we started unhiding what's
going on with the work.
(08:20):
So this was like a big shift inthe actual way we thought about
it.
We started to think about thework itself and not what the
people did right.
So we didn't want to focus onthe workers, we wanted to focus
on the work itself.
We started mapping the stepsthat work goes through, from the
(08:44):
idea to the refinement, then tothe moment that the team put it
into the workflow the code,reviews, the approvals, the
deployments, all of it.
So we started mapping it.
Then we actually visualizedthat flow of how the work moves
through that flow, and then westarted measuring how much time
(09:07):
the work spends in each state.
We didn't care who is doingwhat, we didn't care what people
are busy with.
We were solely focusing on okay, let's see what happens with
the work.
So we started measuring thetimes that it's spent in each
state and it turns out 40% ofour total time, of our total
(09:30):
delivery time, was spent in someweird approval state, and we
only figured that out when westarted measuring that time.
We didn't know about it, wedidn't see it.
It was the waiting time spentin that approval column that
increased our delivery timestremendously.
As soon as we revealed thatinformation, what we did is to
(09:53):
ask for a second person to joinon that step, so that there are
at least two people availablefor that approval.
So once that person who wereresponsible for that step were,
they were on a leave or theywere engaged with something else
, that second person jumped into help.
Just by making that tweak, wemanaged to reduce our delivery
(10:15):
times by 40%.
We didn't change 40?
.
Speaker 1 (10:20):
Yes.
Speaker 2 (10:21):
By just making this tweak.
We didn't do anything.
We didn't add more people, wedidn't have to work overtime, we
didn't even have to change howwe managed the work.
The only thing we had to do isto make sure that the work
doesn't age artificially in theprocess.
It doesn't just stay and waituntil someone is available to
(10:42):
approve it.
And the only way for us to knowthat was to unhide that waiting
time.
It was to reveal what's goingon with the process and really
focus on the work and not theworkers.
The reason people just don'tsee it.
It's just invisible and we haveto unhide it.
(11:02):
That's one of the things ouranalytical suite does.
It actually measures cycle timeof each step in the workflow
and then it tells you themajority of the time is spent
here.
Is this what you expect to see?
And if not, this is thebottleneck in your process.
This is the main priority foryou to handle right now.
Speaker 1 (11:26):
So what does that mapping look like?
How do you go into a sessionwith a team to figure out what
that workflow looks like?
I'm envisioning some sort of avalue stream mapping for the
work itself.
Speaker 2 (11:38):
It's actually very easy.
It doesn't matter what yourworkflow looks like.
It really doesn't matter.
The most important thing whenyou talk about flow and we talk
about mapping that flow is tomake sure that you represent
what you're currently doing.
You don't want to design somefancy processes or any some sort
(11:59):
of a future state of the work.
You do want to visualizeexactly the steps that your team
are going through in order torelease a piece of work that has
been requested from them.
You have a board.
It could be Jira board or AzureDevOps board, even Trello board
, doesn't matter.
(12:19):
You take a board, then youcreate the columns which
represent the steps and then, assoon as you have a work item,
you create a card for it andthen move the work item through
these columns or statuses and assoon as it goes out of the
process, then this means thatthe work has been delivered.
Now, during our retrospectives,we just go and evaluate our
(12:43):
cycle times and the breakdown ofthese cycle times.
At NAIF, we have the so-calledcycle time breakdown chart,
which essentially is a pie chartwhich shows you, from all of
your delivered work items andthe time spent in all of the
statuses, which is the statusthat we spend the most time in,
(13:03):
and again, for our case back inthe day, that was disapproval
status.
40% of that delivery time wasdisapproval status and it's as
easy as just looking into thebreakdown to understand that.
But then I think one of themajor things for us was to
really have this shift inmindset in our mindset of
switching the focus from tryingto understand what everyone is
(13:28):
doing up to trying to understandwhat happens with the work and
where the work spends the mostof our time.
Speaker 1 (13:36):
So one of the traps that I have seen and I'd like to
get your perspective on howcycle time can help with
measuring that to look is thatmany times I've seen developers
when I say developers, I'mtalking the development team of
their eyes being bigger thantheir stomachs, and what I mean
by that is this looks like asmall amount of work.
(13:59):
It won't take me long to do so.
We're going to do this piece ofwork, and before you know it,
the cycle time starts going upand up and up, and it stays in
development for days beforemoving, and then, when it moves
on to the later stages, it takesa long time to get that, and so
one of the things I have seenis trying to break the work down
(14:21):
into smaller increments so thatwe can get that value realized
sooner, as opposed to waitingfor a larger chunk of work to
get done to realize all thatvalue.
Is that something that you'veseen as well, sonia?
Speaker 2 (14:36):
Yes, I've been into this conversation pretty much on
a daily basis.
Now, when we talk about how weshape the work and how we
organize the work, I have a verysimple rule.
So, when we're creating ourstories, we do want the story to
represent customer value.
(14:58):
And what I mean by this is thatwhen I'm shaping the story, I
do want, as soon as I'm done, assoon as we as a team are done
with that piece of work, theperson who requested it can
check it, can play with it, cangive us feedback on it, because
(15:19):
the main goal for us as a teamis to solve problems, is to
deliver something that'sreasonable, that's meaningful,
and we can only know ifsomething is meaningful and
reasonable as soon as the personwho asked for it confirms that.
That's the only time when weknow for sure that what we've
(15:43):
been doing is worth it and whatwe're delivering is actually
customer value.
So for us, in order to get tothat place to understand whether
we're moving in the rightdirection, we need to try to
shorten that cycle time as muchas we can without compromising
the concept of value.
(16:03):
Right, I'm seeing teams who aretrying to split the work to
back-end development, front-enddevelopment, database
development.
I'm not a fan of this approachbecause if I have a piece that
says database development, howwould the person who asked for
it can give us feedback on it?
How would the person who asksfor it can give us feedback on
it?
Isn't it better to split it in,let's say, maybe some UI
(16:25):
interaction, so maybe we canhave just the frames and then
give it to the customer and theycan say, okay, this is in the
right direction, or I don't likethis, or even that has nothing
to do with what I asked for.
So when we're splitting thework, we want this to be in
terms of customer value and wewant to split it in a way that
(16:46):
we get to that solution in thefastest and easiest way.
Now, if we've done this and thepiece of work is still too big,
it's just there is no way tosplit it.
There is just no way to deliverjust part of it.
If it's too big, in order tomake sure that we still stick to
(17:06):
those short cycle times, weallocate more capacity on that
work.
What this means is that,instead of one person, we
allocate two, maybe three people, if there is any bottleneck
that appears around it.
Any question, this is thehighest priority for the team.
This means that if, for somereason, something more urgent
(17:27):
comes in, we understand that bysuspending this big piece of
work, we are delaying itintentionally.
But all of these decisions,they are intentional.
When we're saying yes tosomething, we're saying no to
something else and we're awareof the fact that we're saying no
(17:48):
to something else.
Speaker 1 (17:50):
I love that.
Speaker 2 (17:51):
There is a lot of perspectives around that.
I believe if the main goal ofthe team is to make sure that
value, that piece of value, goesout of the workflow as soon as
possible, then they will startpaying attention to anything
that gets delayed, anything thatstays in the workflow for
(18:14):
longer than it should, and thisis something that we're doing on
our dailies.
We have a chart that we callthe aging chart, and that aging
chart it has all of our workitems as dots scattered on a
plot, and then we know if acertain dot goes up, this means
(18:36):
that it accumulates waiting time.
It accumulates cycle time.
It's not necessarily awaitingulates waiting time.
It accumulates cycle time.
It's not necessarily a waitingtime every time.
It's just the higher the dot,the longer it stays in the
process.
Now, for us as a team, theconversation during our dailies
is to go through the top dots,everything that's on top, and
(18:58):
talk about it.
We don't talk about it,anything that just has been
started.
We don't talk about our to-dolists.
We don't talk about things thatare still moving the way we
expect them to do.
We talk about things that areaging artificially, things that
are taking longer than, let'ssay, 85% of everything else that
(19:19):
has been finished so far, let'ssay, 85% of everything else
that has been finished so far.
We talk about any blocked work,any expedite work, any
questions the team has in orderto move forward.
Our meetings are not statusreport meetings.
We don't go through the entireboard to see what's the status
of each task.
The board gives us thatinformation.
We don't need to talk about it.
The only priority really iseverything that's staying longer
(19:44):
for a specific state.
Why is that?
Is it blocked?
Is there anything else that youneed?
Is there like additionalinformation that we need to
provide?
Do you need feedback?
What is it that's making thework stink and aging, and then
we brainstorm solutions in orderto have this work moving
further.
Speaker 1 (20:03):
I'm sure you've experienced this.
How do you help teams getunstuck when you're looking at
your cycle time chart and you'vegot this one circle that's like
way above the others.
So the cycle time is going up,but the team is convinced oh,
this is a special situation,this is different, this doesn't
(20:24):
always happen.
This just is what it is.
We just need to get focused ongetting it done.
Whenever it gets done, it getsdone and we won't experience
this again.
How do you help teams getunstuck with being more open to
looking in and not justconsidering this to be a one-off
and something that theyshouldn't look into?
Speaker 2 (20:45):
The way our teams make decisions are following
specific decision-makingframeworks.
We call these process policies,and a process policy is just a
decision, an answer to aquestion Like what do we do with
blocked work?
(21:05):
What do we do with aging work?
What do we do if something likea defect arrives?
What do we do if we have itemswith different priorities?
How do we manage work that hasthe same priority?
Which one goes first, which onegoes second?
When is the right time toescalate something?
Who is the right person toescalate it to?
(21:26):
Those are our process policies,our decision-making frameworks
that first enable autonomousteams, meaning they know what to
do in every situation,especially in urgency situations
, and second, it sets a base forus to keep improving our
(21:47):
workflows.
If something goes outside ofour thresholds, and we have like
big red zones that show us thatsomething goes outside of the
thresholds, as soon as this isthe case, we start talking about
this and then we try tounderstand what was it that
(22:07):
actually led to that result?
And usually it's something inthe policies or the fact that we
didn't have a policy about thatuse case.
Those cases are feedback for us.
We use that, we use thosesituations, these outliers, as a
feedback loop which fits therules and the changes we want to
(22:28):
apply.
On the rules, because thosedecision-making frameworks are
owned by our teams.
They create them, we don'tcreate them.
The teams create thosedecisions.
They make those decisionsbecause they're in the best
position to do so.
They're in the trenches all day, in and out, and they know
(22:49):
what's best for it.
And when they create it andwhen they own it, there is no
reason for them not to follow it.
When they see those outliers,what they do is they start
brainstorming.
Okay, what is it that led tothis situation?
Can we change something on ourpolicies in order to make sure
we don't end up in thatsituation again?
(23:10):
And simple things like wedidn't have enough information
in order to resolve that problem.
Well then, let's change thepolicy that a task can only
enter the workflow if you havethis and this and this available
.
You just don't start the workuntil you have those three
points there.
(23:30):
That's how the team is actuallyembracing these cases, and it
is because it helps them dotheir job better.
It helps them to be better atsomething that they're not
individually influencing, butthey influence as a team.
(23:51):
That's one of the reasons whyI'm so focused?
I'm not focused at all onindividuals' performance.
That's something that we don'tcare.
That's something we don'tmeasure in our tool.
There is no place where you canactually track individuals's
performance.
That's something that we don'tcare.
That's something we don'tmeasure in our tool.
There is no place where you canactually track individual's
performance.
You can only track team'sperformance, because it's a
collaboration that is needed inorder to go out with something,
(24:16):
because it doesn't matter howefficient your developers are.
If everything gets stuck in thetesting phase, you're not
delivering, you're not bringingthat piece of value to your
clients, and when you don't,what's the point right?
Speaker 1 (24:32):
I'm glad you brought that up about the policies,
because that is very, veryhelpful to the teams, very, very
helpful to the teams, and Iwould say yes.
And the part that I would liketo add is I've seen some teams
be so obsessive over making surethey get those policies right
up front.
Those evolve over time.
You cannot foresee everypossible combination that's
(24:56):
going to happen.
So take your best shot up front, set your policies on how
you're going to handle work andif something arises, hey, you've
got a retrospective.
That's a great topic to talkabout.
How might we update ourpolicies to prevent this from
happening again in the future?
So too, they're so anxious andso worried to make sure they get
(25:16):
all the policies right up front.
You know, even within our ownsociety we have to amend laws
right, so it takes some time forthose to come up and to get
those just right.
Speaker 2 (25:29):
This is good.
I actually love this because,indeed, those policies, they're
not set in stone, they're aliving thing, and it's not just
with policies, it's everythingsteady in stone they're a living
thing, and it's not just withpolicies, it's everything.
If you start thinking onsomething big and then in the
middle of the process, it turnsout that it's way more
complicated than you initiallythought, of course you're going
(25:51):
to split it.
Of course you're going tochange the scope or cut some of
the scope or even add more tothe scope.
It's a living thing.
The policies are a living thingand you should change them.
They have to change.
If you don't change them,something is going wrong.
You have to change them becausethings change around you.
(26:13):
Your clients change, the marketchanges, the environment around
you changes.
Your policies have to adjustbased on all of these changes.
So, absolutely, those areliving things.
And back to your initialquestion mark how does that lead
(26:35):
to transparency withoutmicromanagement?
Well, first of all, you don'tcare anymore about individuals'
performance.
There is no place for that.
Second of all, with all thatbeing said, all the policies,
all the rules in place, you haveyour autonomous teams.
You have teams who understandhow to do the work in the best
possible way for the businessand for their customers.
(26:58):
And third, the C-level and themanagement level.
They have that understanding ofwhat delivery means.
They have understanding aboutwhat's their time to market.
They have understanding of howmuch work they can handle at any
one time.
They have understanding of thecapability of the team, which is
(27:18):
the most important thing inorder to know when to say yes
and when to say no to.
In the end of the day, it's avery beautiful picture, because
everyone is happy, your teamsare happy, your management is
happy, your clients are happy,Because the biggest advantage of
(27:39):
focusing on flow and flowmetrics is that the focus is on
the end customer.
It is on how much time you makethem wait in order for them to
get what they asked for, andthat's all what matters in the
end of the day.
Speaker 1 (27:57):
So, sonia, what about that CEO, that COO, that
customer that is waiting for,let's just say, the delivery of
a system and, right or wrong,the system can't go out
partially, it has to go out as awhole.
(28:17):
You're delivering value everyweek, every two weeks.
What have you?
It's not going to be releaseduntil the whole system is there
and you've got this CEO that'sasking you okay, I hear all that
you're saying about this cycletime, about this value, about
wait time, but when's it goingto be done?
That's all I want to know is,when is it going to be done?
(28:40):
And they're so high up in thecorporate structure that they
really don't want to know in theweeds.
They just want to have that oneanswer.
How do you answer that and howdo you approach that type of
stance?
Speaker 2 (28:53):
I have a very special opinion when it comes to making
delivery predictions.
I'm a strong believer of theconcept of probabilistic
forecasting.
What is probabilisticforecasting?
It is the understanding thatthere is no one single certain
(29:13):
answer to that question.
When will this be done?
Probabilistic forecasting givesyou a range of delivery times
and a probability of achievingeach of them, and the question
when will this be done is nolonger that interesting, because
we have the tools In ouranalytics suite.
(29:36):
We have the tools.
They're called Monte Carlosimulations.
They take your past performancedata.
They run millions ofsimulations based on what you've
done so far in order to giveyou those dates.
So you can simply use your pastperformance data in order to
come up to the answer when youwill be done right.
(29:58):
And then the Monte Carlosimulations, the probabilistic
forecasting tools, are going togive you that answer.
They're going to give you fivedays and the probability of
hitting each of them, and nowit's up to you to decide.
How much risk are you willing totake?
Your job now is to make thatdecision.
Is the work easy?
(30:18):
Have you done this this before?
Do you expect any challengesalong the way?
Are there a lot of unknowns?
If that's the case.
If it is like very important tohit that end goal, you go with
a higher percentile.
The higher the risk, the higherpercentile.
Then you choose the date that'slike at the end of that range.
(30:39):
If the work easy, you haveconfidence that you can deliver,
you know that even if you don'tget to that place, it's
negotiable.
You go with the 70th percentileand then you go and choose a
date that's earlier.
That's how you make yourcommitments.
You use probabilisticforecasting that's based on
(31:02):
facts and not judgment or gutfeeling.
You use your past performancedata in order to come up with
that date and from then on youstart running that forecast
every two weeks.
That initial commitment is justthat, your initial commitment.
(31:23):
Your work hasn't been done justyet.
Your work is just has started.
So you have to keep runningthat forecast every two weeks,
taking into account what you'vedone in the past two weeks, and
you make adjustments based onthe feedback that you receive.
So if it turns out that theprobability of hitting your
(31:44):
initial goal is getting lowerit's not 98% anymore, it's 90%
or even 80%, even 70% what is itthat you can do?
Can you cut the scope?
Can you add more people?
Can you reduce thework-in-progress limit so the
team can really focus on whatthey're doing and not doing
another 100 things a part of it.
(32:05):
What is it that you have tochange in order to get back on
track?
You keep changing the process.
You keep running every twoweeks, even if at some point it
turns out that you won't make iton time, and at least you can
communicate this early.
You can go ahead and say, hey,here is the situation, we won't
(32:26):
make it, let's make a decisionnow so we don't impact the
business goals that you havebecause of that commitment.
That's how you buildcredibility.
That's what builds yourreputation as a professional
Making those decisions andhaving those conversations,
(32:49):
because you cannot predict whenyou will be done.
There is just no such thing as100% certainty that something
will happen in the future.
The best thing you can do is tostay flexible and put your hand
on the work and keep runningthose simulations in order to
make sure that you'll make it ontime.
Speaker 1 (33:09):
That's really good.
I've often found that givingpeople options to be very
powerful, because when you justsay, like, when someone says are
you going to have it done bythis date, to just say no,
there's some level of rigidityto that and you typically don't
get a good response.
But if you give them options,like you say, hey, well, if you
(33:30):
would like to take on the riskof we've got a 50-50 shot at
making it as of this date, whatwould you like to do?
Can we cut scope?
Are there some pieces of thisthat we could deliver later?
And one of the things that Ilike to do when I prioritize
features to be included in adelivery is I like to go by them
(33:50):
one by one, because typicallyyour response is going to be, as
you go through this list,stakeholders will say, yes, I
need that.
Yes, I need that.
No, I can't live without that.
Say, okay, let's look at this adifferent way.
If I were going to tell youthat I was going to deliver
everything on this list exceptthis one feature, would you
(34:11):
release?
Would you go live with it?
If the answer is no, we need tohold everything, all the work
that we've done.
We're going to hold it offuntil we get this done.
And okay, that sounds likesomething that you have to have.
But if you turn the perspectivejust a little bit, sometimes
you can get a different answerof well, so you're telling me, I
(34:31):
can get all of this in, but Ihave to wait on just this one.
No, we can live without thatfor another month.
Yeah, let's do that.
And so you can kind of startde-scoping some of those things
that once felt like a must-havenow turns into well, maybe we
don't have to have it, maybe wecan bring that in later.
(34:52):
But I love the idea of givingoptions because that makes
someone else feel like they havesome power in the say right.
They have some power in the sayright.
They have some choice in thedecision, not just be told no.
Speaker 2 (35:07):
And it's their decision.
In the end of the day, it'stheir decision.
You can even go ahead and letthem choose the end days.
You can just tell them okay,these are the risks that are
coming with these delivery days.
Just pick how much risk youwant to live with.
And just for the record, 50%certainty is like very low.
(35:30):
For me, 50% certainty reallymeans we either make it or not.
I would never commit to the 50%chance of hitting a target
because, like you, you're betteroff just buying a pair of dice
and trolling them Right.
Um so never do that.
Always go with at least 70%chance that you can hit your
(35:53):
targets.
The most important thing for meis that when you take action
and when you have theseconversations Because if you
have these conversations as soonas the due date arrives- you
lost that game.
You have to be upfront with this, you have to be aware of it way
(36:16):
before you hit that deadline.
So take advantage, takeadvantage of all the tools that
would give you that informationreal time, and make sure you put
your finger on the pulse of thework, because, again, this is
the difference betweenprofessionals and amateurs Even
if things don't go the way youexpect them to go, if you're
(36:40):
upfront about it and you'retransparent about it, that's
going to make the wholedifference.
Speaker 1 (36:47):
Sonia, this has been absolutely fantastic.
I really appreciate you comingon the show.
If our listeners out there wantto get in touch with you,
what's the best way for them todo that?
Speaker 2 (36:57):
I'm on LinkedIn, sonia from NAVE.
I would love to hear from eachand every one of you.
I do want to know what's thebiggest takeaway from today.
I do want to know what is itthat actually sparked that
thought?
Because, mark, I want to behonest.
I love I can talk about thisall day long, but the most
(37:17):
important thing for me is whenpeople take action.
So, from each and every one ofyou, go ahead on LinkedIn, send
me a note.
I want to know what's the nextthing that you're going to do as
early as tomorrow morning.
What is it that you've learnedtoday that you're going to go
ahead and apply as early astomorrow morning in order to
(37:38):
move the needle?
Let me know.
Speaker 1 (37:40):
Okay, listeners, that's a call to action.
All right, Sonia, it's been apleasure.
Thank you for coming on theshow.
Really appreciate it.
Speaker 2 (37:48):
Thank you.
Speaker 1 (37:49):
And that ends another episode of the Agile Within.
We'll see everybody next time.
Thanks for joining us foranother episode of the Agile
Within.
If you haven't already, pleasejoin our LinkedIn page to stay
in touch.
Thanks for joining us foranother episode of the agile
within.
If you haven't already, pleasejoin our LinkedIn page to stay
in touch.
Just search for the agilewithin and please spread the
(38:12):
word with your friends andcolleagues Until next time.
This has been your host, markMetz.
Popular Podcasts
On Purpose with Jay Shetty
I’m Jay Shetty host of On Purpose the worlds #1 Mental Health podcast and I’m so grateful you found us. I started this podcast 5 years ago to invite you into conversations and workshops that are designed to help make you happier, healthier and more healed. I believe that when you (yes you) feel seen, heard and understood you’re able to deal with relationship struggles, work challenges and life’s ups and downs with more ease and grace. I interview experts, celebrities, thought leaders and athletes so that we can grow our mindset, build better habits and uncover a side of them we’ve never seen before. New episodes every Monday and Friday. Your support means the world to me and I don’t take it for granted — click the follow button and leave a review to help us spread the love with On Purpose. I can’t wait for you to listen to your first or 500th episode!
The Breakfast Club
The World's Most Dangerous Morning Show, The Breakfast Club, With DJ Envy And Charlamagne Tha God!
The Joe Rogan Experience
The official podcast of comedian Joe Rogan.