In the book, I use this concept of the five thieves of time that
I think resonates with everybody, whether they're in
technology or not. And these five thieves of time
are related to too much work in progress, conflicting
priorities, unplanned work, unknown dependencies, and
neglected work or neglected WIP. And so most everybody has
experienced all of those and are looking for ways to deal with
that kind of time theft. Hey everyone, my name is Henry
Surya Virawan and you're listening to the Technically
Journal podcast, the show where I'll be bringing you the
greatest technical leaders, practitioners and thought
leaders in the industry to discuss about their journey,
ideas and practices that we all can learn and apply.
To build a highly performing technical team and to make an
impact in your personal work. So let's dive into our journal.
Hello to all of you, my friends, and my listeners.
You are listening to the Technically Journal Podcast, the
podcast where you can learn about technical leadership and
excellence from my conversations with great thought leaders in
the tech industry. If you haven't, please subscribe
on your favorite podcast app to get notified for new episodes.
Also, subscribe to Techlegional's various other
contents on LinkedIn X, Instagram, YouTube, and Tiktok.
And consider supporting this podcast by either buying me a
coffee at techlegional dot dev tip or becoming a patron at
techlegional dot dev patron. My guest for today's episode is
Dominica de Grandis. Dominica is the author of one of
my favorite books making work visible.
In this episode we. We discussed how we can optimize
our workflow and reclaim control of our work and time.
Dominica unveiled the concept of the Five Thieves of time that
rob us of our productivity, which includes too much work in
progress, conflicting priorities, unplanned work,
unknown dependencies, and neglected work.
She also shared actionable practices and tips on dealing
with each of those five thieves. Towards the end, Dominica
emphasized the importance of making work feasible within an
organization and how to measure our flow of work.
I hope you enjoy listening to this episode and getting to
understand the different time thefts that I'm sure frustrate
many of us in our daily work. If you enjoy listening to this
episode, please do share it with your colleagues, your friends
and communities and leave a five star rating and review on Apple
Podcasts and Spotify. Your small help will help me a
lot in getting more people to discover and listen to this
podcast, and I really appreciate it.
So let's now go to my conversation with Dominica after
quick words. From our sponsor.
Hey, a quick message for those of you who are listening to this
episode on Spotify. I have a small favor to ask.
Spotify now allows mobile users to rate podcasts.
I would really appreciate it if you can take a quick pause to go
to the Techni Journal podcast page and leave your favorite
show your best rating on Spotify.
It will help me a lot to get this podcast to reach more
people on the platform. Thanks a lot.
Hey everyone, welcome back to the new episode of the Techni
Journal Podcast. I'm very excited.
Today I have a guest that I have been admiring for a long time
After reading her book, Make Work Visible.
Her name is Dominica de Grandes. So, Dominica, thank you so much
for your time. Looking forward to our
discussion today. Delighted to be here Henry.
Thank you. Yeah, Dominica, if I may ask you
in the beginning to share maybe your career journey, any
highlights or turning points that we all can learn from?
All right. Well, my first job out of
university was at Boeing Airlines.
It's a very large company and I felt I was very ill prepared.
I didn't know what to expect based on the courses that I'd
taken at school, so I had a lot of learning to do really
quickly, mostly about configuration management.
That was what I did for many years, software configuration
management, just building decoder rings so people could
understand what version of what file was in what environment and
on and on. And that was quite a big problem
for many years. So there was a opportunity to
provide value in that space. And then I went on to work for a
variety of different companies from big telecom to startups and
doing software configuration management, build management,
release management, deployment automation.
And then probably a real turning point in my career was in around
2005, 2006, 2007, I was working at Corbis, which was Bill Gates
other company in Seattle outside of Microsoft and we started
implementing Kanban and it was supposedly the first
implementation of Kanban in the US for engineering and software
development. I was so excited about this way
of working. I never really did Scrum.
We went sort of straight from waterfall to this pull system
that was Kanban and where I had to learn how to start capturing
meaningful metrics and present those metrics to my peers and
and leadership. And it was a really pivotal time
in my career where I had to learn how to speak in front of
people and present data. And it really did blow me away
because I got budget and headcount and empathy from other
teams. It was a great learning lesson,
even though I was terrified to get up and speak in front of
many other people. But very good learning lesson
that really laid the foundation for the work that I was going to
do later on, which was going more into helping other
organizations understand Kanban and flow and pull systems.
And why too much work in progress is a problem.
And how to collect and measure flow metrics, interpret them and
help other companies do that too.
And that's really carried me on to where I am today, you know,
from there, I was independent for a number of years.
I used to travel a lot and do workshops primarily for IT OPS
and then later dev OPS and I got very involved in the dev OPS
community. I was just happened to be in the
right place at the right time. So I was just kind of lucky to
meet all these great luminaries of the dev OPS community and
teach them Kanban and be able to help out the practitioners
working in the trenches who were really suffering from being
overloaded and too much cognitive load, too many
conflicting priorities, too many dependencies that were invisible
and became blockers. And then through the whole
continuous improvement and delivery and deployment
automation. So my role, which I had done
most of my career, was shifted rather rapidly after that
because the pipeline was mostly automated, so we didn't spend as
much time having to worry about doing database restores from
production and making sure that every environment was set up
with identical software. That became less of an issue,
and I kind of worked my way out of that job and moved more into
help setting people up for success in that journey and that
sort of transformational journey looking at entire value streams
now instead of just individual team metrics.
Thank you for sharing your story.
I think it's really interesting how you got into Kanban, right.
I think today we are going to cover some of the important
topics you just mentioned. You know, things about flow,
Kanban, flow metrics, how to help people so that they don't
get overloaded with high cognitive load and things like
that. So I think for your book, I mean
if people haven't read it before, right.
So I think the book is really, really how to make your kind of
like all these tasks work is visible, right, So that we can
actually see what kind of problems that we have and try to
optimize how we can finish all the tasks, right.
The first thing is, I think you cover in the book the background
of the story you wrote. This book is because people now
seems to have too many things to do, like we have everything to
do, but we have. Very little time to finish it.
So maybe in the beginning, can you tell us the background of
how do you envision this book helping people to make their
work more visible? Yeah.
Well, in the book I use this concept of the five these of
time that I think resonates with everybody, whether they're in
technology or not. And these five thieves of time
are related to too much work in progress, conflicting
priorities, unplanned work, unknown dependencies and
neglected work or neglected WIP. And so most everybody has
experienced all of those and are looking for ways to deal with
that kind of time theft. So the part one and Part 2 sort
of introduce these concepts. Identify how you can see that
this is happening in your organization.
And then Part 2 talks about what to do about it.
And there are exercises. Especially in the second edition
of the book we added more exercises.
I like to make things provide a lot of utility for the readers
so that they can do exercises to practice exposing and bringing
these time thieves out into the open and collecting data around
these issues. Because I think that's when you
can start to have the really good conversations, when you can
start seeing, yeah, how much WHIP do you have on our team has
you know, 110 items just in the validate state, you know, and we
only have five people on our team.
So right there you can start to see and expose just how
overloaded the teams are. And then when we look at the
pain points, one of the most prominent exercises in the book
is what I call a demand analysis where we have the teams identify
what is the nature of their demand.
Do they have a lot of unplanned work?
Do they work primarily on technical debt or security?
And then the second part of the exercise is identifying what
prevents them from getting their work done, what randomizes their
day. And then the third part is what
do their customers grumble about?
And we call that business pain? And when I'm using the term
customer there, I'm talking about the internal customer,
like their boss or the product manager, but somebody internal
to the company who's making requests from them, what are
they not so happy about? And we find that there's this
correlation or almost this mirror of what causes pain for
the team is correlated to what the customer is grumbling about.
For example, if the customer is unhappy because things take too
long, You know, we asked for this feature six months ago and
we still don't have it. You know, it's taking too long.
We need it already. We needed it six months ago.
And if we look at the team pane side, it's because they have too
much WIP. They're overloaded with so much
WIP that it's taking them longer to deliver those feature
requests. So they often mirror one
another. And if people are complaining
that things are taking too long, then it makes sense to clearly
understand, to clearly measure how long things actually take.
And so with there, then we get into the metrics which I cover
in Part 3, how to measure your flow time, why it's important to
measure that. So usually that will be an
outcome of the demand analysis exercise is now that you've
identified team pain and business pain, if everybody on
your team had two votes, what would you vote on?
What would provide the biggest return or improvement or
increased morale and happiness if you could make a dent in this
bit of a pain area, Yeah. So just sort of going through
each time with EVE, with that, you know, identifying the
problem, why it matters, exercises to dig into it deeper,
ultimately leading to experiments that people can do
to find their way through the challenges.
I think that this work that we're doing really does require
experimentation in many cases because we don't always know
causality of a problem. You know, we don't always know
cause and effect, and so when that occurs, we don't really
have a best practice. We have a best practice.
If we've done it before and we know why it happens, then we can
have a playbook for that. But if the team is doing
something new and novel and they haven't done it before, then I
think experimentation is very powerful.
And looking at the change curve and looking at the Kubler Ross
change curve, the one that everybody's familiar with that
was adapted from this grief model, but it's been made
applicable for business. And so it goes to like shock,
denial, frustration, depression, experiment, decision and then
integration. And I think what's represented
so well on that change curve is the turning point.
And it's when experimentation starts happening because that's
when people can start to take some ownership in what's going
on in their world and all the change that's occurring and
participate and come up with ideas for improvements and work
to get buy in for experiments from stakeholders.
I think that is very useful. Right.
So I think if people haven't heard about WIP before, right,
it stands for Work in Progress. This is one of the core thing in
Lean and also in Kamban and also Dominica's book So the Five
Thieves of Time. When I read them, I laughed
because I can relate to all of them actually.
So those are like too much work in progress, unknown
dependencies, unplanned work, conflicting priorities and
neglected work. I'm sure all the listeners here
can also relate to them. Maybe let's just cover them one
by one, right? So starting with too much WIP.
You have mentioned this a few Times Now and in your book you
mentioned this is like the ultimate ringleader.
You know if your if your analogy is a thief, right?
This is like the thief of all thieves.
So tell us more. What is too much WIP?
Why is it a problem and what can we do about it?
In textbook terms, too much WIP is when demand outweighs
capacity, so you have too many requests than your team can
handle, and it's a problem. And it's why it's the
ringleader. For example, if you have
unplanned work that disrupts your day, now you have to work
on that in addition to all the planned work, right?
So it creates more work in progress for the teams, and the
more things that we try to juggle at the same time, the
more scattered we are, the less time we can focus deeply on this
one important item that we need to complete as soon as possible.
WIP is a leading indicator, right?
We know that, say, as soon as you commute home, if there's a
lot of traffic on the roads, your commute is going to take
longer. So it's the same thing with too
much knowledge, work in play. The more WIP we have, the longer
things take and the increase in cognitive load in our
functioning, which can cause stress, cause all kinds of
health issues and can lead to burnout and depression.
So it's very important to try and limit the amount of work so
that we can have higher quality on what we're delivering.
That is going to provide more confidence in our ability to
deliver high quality things when our customers are expecting
them. But we find more and more that
that's a rare scenario because we have a hard time saying no,
that we're human. And so we want to say yes, yes,
I can do that. Yes, I can do that.
And there's many reasons why we say yes when we probably really
ought to say no. If we say yes to everything,
then we can't deliver our most important yes, if that makes
sense to you. So I think it's really essential
that we get really brutally honest about what is the one
most important thing to get done today, or at least to get to a
nice stopping point so that we can make progress on that.
We have to ruthlessly protect our time so that we can complete
our most important work, which is really hard to do if we just
have too much demand, too much stuff on our plates.
But I think the nature of wanting to be helpful and
wanting to be valuable to our teammates and to our
organization, we end up saying yes more than we should.
So I think this, when you say it's a leading indicator, right.
So I think people just need to, you know, understand the concept
of cycle time and WIP and throughput, right.
Maybe if you can go through, you know why Too much WIP actually
is a leading indicator. Yeah.
So people always say, well, what should our WIP be?
Usually the answer to that is lower.
You know 100 is better than 110, but there is an equation that we
can use to have this conversation and it's called
Little's law and it's based on averages.
And it's where your average flow time or cycle time equals your
average web over your average throughput, your throughput
being the number of items completed over a period of time.
And when we look at the math, because WIP, your work in
progress is the numerator in the equation.
As soon as that WIP increases, we know that it's going to
extend your lead time cycle time, flow time, whatever you're
using as long as the assumptions are in place.
There are some assumptions in that law.
You know you have to have a stable system.
Your WIP needs to remain fairly relative and the, you know, you
shouldn't have cancelled work, that kind of thing, all all
things that everybody has. But that conversation alone and
looking at that math, I can show you why this is so important and
why it's a leading indicator. Leading because WIP is partially
completed work. We've started it, but it's not
done yet. Most of all the other metrics
are based on work that's completed.
You know, throughput, flow time, flow efficiency, those metrics
are all based on work that's already completed.
But your WIP metric, which we call flow load is work that's in
progress. So that's why it's considered a
leading indicator and so powerful to use because you can
look at it right now and have it spark a conversation about what
do we need to delay for now because most they'll have their
planned work. Can we talk about unplanned work
now? It's yeah, because they'll be
working on their planned work and usually they're allocated
100% right to work on this planned work.
But then priorities change and or unplanned work hits them and
now they have to stop what they're doing.
They have to stop their planned work, context switch, pick up
the unplanned work, work on that context switch, get back to the
planned work. It's like being at their grocery
store and somebody jumps the queue in front of you, right?
You're at the checkout line, ready to go next, and somebody
cuts in front and then they check out because they have the
urgent need to get through fast. What happens with that unplanned
work now is that the work that you are going to get through
checkout faster, but now your checkout time is going to be
longer because of this unplanned work.
So I think that one of the exercises is identifying what is
the criteria for unplanned work and be really clear on that.
Sometimes teams will want to Group A lot of different things
into the unplanned work category.
But I think it's important to be really clear, could you have
anticipated that? Could you have anticipated this
audit was going to happen, you know, at least once this year,
things like that. So that's sort of the just as a
circle back on the relationship between WIP throughput and flow
time or your cycle time. I'm using flow time and cycle
time interchangeably. We're talking about just
tracking how long things take from beginning to end.
And for flow time, that's the conversation that needs to occur
is when does the clock start and when does the clock stop, right?
Yeah, so speaking about unplanned work, I'm sure these
days in software engineering team, right, they can relate to
things like for example if there's a customer complaints,
incidents, right, downtime or whatever that is, or sometimes
it's just bugs, right? Like you work on something or
actually it caused a bug, right. This is what you categorize as
rework. So something urgent you need to
fix it and things like that. And it actually creates a lot of
unpredictable workload for the team.
So if we go back to the too much work in progress kind of a
problem, right? I think it's granted like almost
every team now is you know a burden by a lot of these tasks.
And some of the solutions actually are things like for
example, you set up a come button, make it like a pull
system and also limit your work in progress.
So tell us a little bit more how we can, you know, make sense
about our web and and kind of like solve this problem.
Yeah, a number of ways. One of my favourite and useful
ways is to look at the rate of arrival of work and the rate of
departure. So the rate of departure has to
do with looking at your throughput, how many items were
delivered over a period of time, Understanding that that is the
capacity of the team that they were able to deliver X number of
things over this period of time. And you can combine that with
the various different types of work features, bugs, technical
debt, security. Or you could just look at those
individually. But the idea is to understand
this departure rate determines arrival rate.
Departure rate of completing work is going to determine what
the arrival rate, what your WIP limit should be and when we do,
will have capacity to pull more work into our workflow because
we finished work. And this stems from ARN Rook's
work and his famous quote about the stop starting and start
finishing. Yeah.
So the concept of limiting work in progress, right, how can we
use that? Because I think that's one of
the key probably for leaders, especially for managers or
leaders, right, in order to actually manage their work.
So you mentioned about rate of delivery and rate of arrival,
right. So when the arrival is getting
too many, right, how can we manage them by limiting our work
in progress. Yeah, yeah.
This is we're having a crystal clear prioritization policy and
process in place is going to help.
It's we're having psychological safety and a generative culture
comes into play so that people can be OK with knowing when they
have to say, actually we don't have capacity for that right now
or say, oh, OK, this is now the number one priority.
This is when yesterday's is #1. Priority is not today's number
one priority because priorities change and we need to be able to
adapt to that. But when that happens, we need
to give people permission to say, you know, hold on, we have
a new priority, one. That means something has to
give, like we only have 100% for good or for bad.
This is our current amount of capacity that our group has.
So knowing that what should be the number one priority and what
should we say no to. So when I worked at Corbis, the
way that we solved this with executives in leadership was we
told them that well first we measured how long it took us.
You know, basically we get to X number of features over a period
of six weeks and we had a capacity for five of those like
5 features and we put the decision on the leaders to
prioritize that list. So there might have been 100
requests in the backlog. And instead of all of those
being thrown on the team and the team scrambling and trying to do
all those and trying to prioritize them, we explained to
leadership the idea about WIP limits and the team's capacity
and said you got five spaces, we can have 5 feature requests on
this team at a time. We would like you to decide on
what those five things are and when we deliver one, there will
be another opening. And when we first started this
process, it was quite chaotic. And the leaders used to, you
know, whoever yelled the loudest would usually get their way.
But over time, it turned into more of a democratic approach.
I voted for years last week. You need to vote for mine this
week. They would meet once a week.
You know, the head of marketing, the head of engineering, the
head of sales would be in this room.
And because the question was very simple, which item should
we pull in next? They didn't have to delegate
that. They didn't have to bring in
their engineers to talk about details and provide estimates.
We did away with estimates because the question to leaders
became knowing that it takes us six weeks to deliver something.
Once we start on it, which thing do you want us to deliver next?
So it was a very simple question that leaders could then ponder
and think about. And first it was arguing that it
was democratic decision. And then over time it turned
into a analysis of the business case, what makes the most sense,
what is the highest value for our company to deliver in six
weeks for our customers. So we simplified a lot.
So we reduced the time that had been spent on estimation by
having our customers prioritize that work based on data that we
provided them on our cycle time, on our flow time.
Thanks for covering this conflicting priorities, right?
Because prioritization probably is one of the root cause of too
much work in progress, right? Because like like you mentioned,
like I think it's typical in most of the companies, right,
leaders have their own objectives and they just throw
it to the team, but they actually don't get visibility of
the team, probably struggling on how to prioritize, you know, the
upcoming tasks to them, right? And I think what you mentioned
is very important that leaders should clearly identify which
one is the most priority, right? Because all cannot be the
priority. And if we have to choose one by
one sequentially, what would that be, right.
So maybe we have covered the three of the thieves of time,
right. So the too much WIP, the
unplanned work and conflicting priorities just now let's move
to the next one, which I find it is also tricky managing
dependencies, right. So what do you call unknown
dependencies? Sometimes work.
You know you can't finish just by yourself, right?
You need to collaborate. Maybe you need to rely on third
parties and things like that, right?
So how can we tackle this problem?
First of all, like, maybe sometimes we don't know we have
dependencies. Or sometimes, if we do know
dependencies, how do we manage them?
Yeah, my thoughts on dependencies have altered a bit
because there's different kinds of dependencies.
Dependencies in many ways are just prerequisites.
You know, A has to happen before B happens, and A is done by a
different team and their priorities different than our
priority. So scheduling and all of that is
a problem. But the real issue is when
there's a blocker, what is blocking our capability to
deliver these items within the expected time frame?
And it's those blockers that we need to bring visibility to and
find a way to reduce the cost. Maybe it doesn't make sense to
have every skill set on every team just because there are
prerequisites for them in the book.
I do have some exercises and a dependency matrix, but my
thinking now more is to try and really get a handle on the
expensive blockers and understanding the cost of delay
of having this critical element blocked and then using, say the
theory of constraints to reduce the risk of costly blockers.
Most people right away they want to say we need to hire more
people, we need more people on the team, which is a valid
approach, but it's usually the last thing that we would look
for, right? Because how long does it take to
onboard an engineer in your department?
People will say six months to a year when I ask them that
because it's not just getting them up to speed, but it's the
onboarding, it's the interviewing, all the resume
hunting. It can be very costly to onboard
new talent. And so before we go down that
path, let's look at how to take an essential work off of the
bottlenecks plate. Right.
Here's where we talk about bottlenecks with blockers.
How can we find help for that bottlenecked area?
How can we invest in new tools and processes to help that
bottlenecked area? That's really what the Theory of
Constraints is about, is finding these other ways that will
unblock dependencies and blockers faster than trying to
hire new talent. That could take 6 to 12 months.
Yeah, I think, yeah, what you mentioned about hiring people or
even find outsourcing team, right.
It's kind of like common when we see that the team maybe cannot
deliver fast, yeah, we just tend to.
Go to the easy solution, seems to easy, right?
But what you mentioned is actually really expensive, you
know, onboarding interviews, getting them up to speed and
things like that. So also dependencies, right?
Sometimes you know it's caused by the organization structure,
you know, this Conway's law communication pattern and things
like that. I mean, I just want to highlight
one quote that you put in the book.
So every dependency double S your chance of being delayed or
late. So I think this is really
important because sometimes leaders don't see the impact of
dependencies in the team or maybe the organization
structure. Maybe from your experience,
anything you want to cover on that?
Yeah, that quote actually came from Troy Mcgannis, whose work I
borrowed heavily on when I talk about dependencies and blockers
and bottlenecks. And the story behind that one
is, imagine that you're going out to dinner at a fine dining
restaurant and you're meeting three other people there.
Well, what is the probability the fine dining where they won't
see you until everybody arrives and only then you get to your
table? What is the probability of being
seated on time when there's four people involved that are on
different teams or coming from different locations?
And it's really quite low because of the probabilities.
You know, you could be on time, but I'm late and the two other
people are late, or I'm on time but you're late and the other
two people, you know, there's like 8 different scenarios that
could occur. And so every time you add an
additional dependency to that list, it just double S the
probability that you're going to be that much later.
So the number of blockers and dependencies impacts it and
that's why, you know, like Team Topology is such a popular book
where they talk about organization structure and sort
of what to do about that. And you mentioned Conway's Law.
You know for those on listening Conway's Law as how a system
design will mirror the communication structures of the
organization which designs it, right.
And so if we're looking at individual teams, optimizing at
the team level, a group that's organized that way and that is
focused just on their silo. It's unlikely that they're going
to follow practices that are well optimized for optimization
of an end to end workflow, an end to end value stream, the
goal of which is to deliver high level this value to the
customer. Yeah.
So I think that we need to be clear about what practices we're
going to use for decisions and organization and how those
groups are going to be measured because how people are measured
within an organization effectively constrains the
production of the metrics that they're going to implement.
We want to make sure that how teams are measured are in line
with the desired results of that organization.
I don't know I could, I could go on on about how teams are
measured and how it can negatively impact, You know,
tell me how you're going to measure me and I'll tell you how
I'm going to behave. And we need to be really careful
about how we're measuring groups.
But depending on how they're organized, we see this a lot.
We have all these individual teams that have dependencies
across each other, and each of those teams is measured for
optimizing their slice of the value stream.
Then we have conflicting goals and we wonder why it's so
difficult to get something delivered on time.
Right. I think that's a very important
point you just brought up, right.
So knowing like how the teams or the group of teams are measured,
right? Because sometimes.
They can optimize locally based on how they are measured, but
systematically, right, or maybe holistically they're actually
conflicting to each other. So I think that's also another
important point you just brought up.
So thanks for covering that for this unknown dependencies, the
last one that we haven't covered is the neglected work.
Some people call it, you know, work in progress that is delayed
or maybe things that are just not or partially done right.
Some people call it partially done.
So tell us more. What is this neglected work?
How can we tackle it? And how come it can cause a
problem? Yeah, neglected work.
It just doesn't get the love or the attention that it needs.
It keeps getting deprioritized. And others, you know, jump the
queue and cut in front of it. It's often really important
work. If it doesn't get done, it will
become urgent and then it will become unplanned.
Work like technical debt is a good example of very important
work that does need to be done. But because it's not an
immediate emergency, it will often get, deprioritize or have
a lower priority. And it also is waiting.
It's gets stuck in the queue waiting to be done.
It's like when work displaces other work, the neglected work,
other new work comes in and gets a higher priority.
It's like, have you heard, like robbing Peter to pay Paul?
No, I haven't. OK.
It's a term that we use to describe we're going to take
away something from one person in order to get this other thing
delivered. But we keep taking away from a
very important resource and now because that work is important,
it will eventually become very urgent to do.
And now we add risk into our decision making process in
delaying that work. So we call that neglected work
and the longer it's neglected then when it does get delivered,
it will increase our flow time. It'll take that much longer
because it's been neglected and sitting in the queue and waiting
for so long. So this neglected work
contributes to us thinking that say we're measuring our cycle
time and we're saying, hey, look, we're doing great.
We're getting these things delivered in two and three
weeks. But then the neglected work that
was so important that kept getting neglected gets delivered
and it took six months, say, to finally get that out.
What does that do to your flow time now?
It kicks your flow time way up. And so now it impacts your
ability to be predictable. If we're looking to be more
predictable and how long it takes to deliver things, the
more neglected work we have in the system, the lower the
probability is that we're going to be able to deliver.
When we say we are neglected, WIP is like this hidden
important time thief that we don't pay enough attention to
because we think everything is going really well.
And then we have some important neglected work that finally gets
done and we realize, oh wow, that took much longer to do.
And we have unhappy customers and leaders.
It's sort of like we think we're here when we really should be
here. I wish I could show you this
cartoon. It's about like, you're here,
but you thought you were here and we really should be here.
Neglected work plays into that problem.
Like where are we and where should we really be when it
comes to how realistic we are with being predictable and when
we're going to deliver requests? And neglected work just will
blind side us to that because we we don't see it coming until it
turns into an emergency sometimes.
Yeah, yeah. So I think it's very important
to understand this quadrant, important, urgent, right.
Neglected was probably so like an important thing, but
sometimes not urgent. And it's always important for us
to analyse and make sure that we erase, you know, the urgency or
the priorities for the team to work on.
Yeah, just one more .1 more point on that is neglected work
is often technical debt that is not on the radar.
Business teams or project teams, you know, not in my project,
Don't do that kind of stuff in my project.
So that's another reason why it keeps getting delayed and
neglected until it becomes an emergency.
And because business people don't always see or understand
the need to fix this technical debt.
That's why it can be so insidious.
Right. Thanks for adding that.
Yeah, technical that is always tricky whenever engineering team
wants to erase it, right. So how can their business also
prioritize that? So the whole important thing
about your book is actually to make work visible, right?
So I'm sure most of the teams these days have some sort of
Kanban, you know, the boards to do in progress and done.
But I think apart from that, from organization point of view,
how can we also make work more visible so that the leaders from
top to down can actually see how things you know flow, how things
are blocked and things like that.
Maybe from your experience, can you give us some tips how to
actually make work visible in a larger scope?
Yes, absolutely. Working with the team right now
where one of their OK Rs, their objectives and key results was
to show that 30% of their defects would be fixed before
the next planning cycle. So within 10 weeks that they
would fix 30% of their defects. OK, well, in their tool set,
they have a work item type, it's called defect.
So they can measure how many defects they have and they can
look at their start and end dates and they can measure over
time how many they did. And then from there, the math is
pretty simple, right? They just have to divide their
throughput by the total defects to come up with a percentage.
You know, did they meet their 30%?
So that's pretty that's so far so good.
But defects aren't their only. OK Rs show another OK R is that
10% of their work would be fixing technical debt and 10% of
their work would be fixing security risks.
Well, they don't have artifacts for technical debt or security
risks. They're all just kind of hidden
in with the stories and the other work that they do.
And so we see this again and again.
And it's fairly, I mean we have to ask the question, what flows
in software delivery? And there are 4 main work item
types that we look at. We have features, user facing
functionality requested usually by external customers or
internal customers. We have defects, you know, bugs
in production. Then there's technical debt, and
then there's like security vulnerabilities, patching risks,
those kinds of things, and the debts and the risks.
The security item rarely have their own artifact type in the
tool set so that you can get visibility on just those types
of work. Usually people just have
visibility on their feature requests, their stories and
their defects. So being able to clearly see,
you know that these four major types of work that organizations
need to work on is important. So you can look at what your
ratio is and have conversations about what should it be.
Should we in this case, you know, should debt be 10% of our
demand, should security work be 10% of our demand, Why 10%?
How much was it when these organizations measured that?
Well, first of all, they didn't have the capability to see that
for five months into their implementation of their flow
metrics. And when they did, when they
were in a position to start measuring their technical debts
that you know, outside of their features and their security
items outside of their stories, they only were able to deliver
less than 2, 1/2% of security items.
So then you can see how that would spark a conversation of we
need to allocate more capacity to do security.
Well, where do we take that from?
Should we do less features? Should we do less technical
debt? Maybe security needs to be 20%
of our demand, maybe technical debt needs to be higher.
Once you can make all of those types of work visible, you can
have these conversations on how much should we allocate for each
different type of work and how do we set up our tool set so
that we can measure each of those types of work.
So I think that's one off the top that people can do to get
more visibility of their work is what kind of work do they have
and how much is getting done. And it's a trade off.
If we decide to work on more security items, that means we're
going to work. We only got 100%.
What are we going to work less on?
And then some organizations can actually set their WIP limits
per that artifact type. Right so I think this techniques
making work visible. You cover so many examples in
the book, so for people who would love to get ideas how you
can visualize your work better. You can refer to Dominica's book
and I think it's the phrase right.
So if you cannot see, you cannot manage, right?
So I think that's why maybe people these days have a mental
juggle, like which things that they they have to prioritize
first or they feel that they are blocked somehow but they just
couldn't understand where. So I think making things visible
definitely will help a lot. Yeah, well, there's one other
important thing to make your work visible.
A bit of a suggestion here. And so if you have your
different types, you'll make all your types of work visible and
then broaden the focus, broaden the span of the visibility.
It's fairly easy to get visibility on the smaller
individual team artifacts like stories.
But when we do that, it's like we're sort of chasing down the
wrong problem. We should have visibility on our
stories. I'm not saying not to measure
your stories, but it's important to get the big picture and to
look at the end to end value stream.
Our team coined this phrase. It's called Stuck in Storyland
and Stuck in Storyland. It's a phrase that refers to a
micro workflow, just a small slice of an end to end overall
value stream versus a macro workflow, which is sort of the
Gold Star of visualizing business value because it starts
with a customer and it ends with a customer.
And and some organizations, if they're just chasing team
efficiency by only looking at stories, because stories are
easy to measure because you have an artifact in your tool set
that's called a story, you're missing out on looking at the
customer value, the business value that's at the higher
level. And this is much harder to get
visibility on because work that's way upstream, maybe in a
discovery process or waiting on funding or approval or
prioritization, maybe in a different tool set.
It may be in a spreadsheet. But when we can start looking at
just how much WIP is upfront ahead of development and
engineering and we can do the math and see how much is
invested in starting these big initiatives that get delayed for
sometimes up to a year. What is the cost of that?
We looked at this recently at a company and it discovered that
they had eleven months of large capabilities queued up that they
were only delivering one in six of those capabilities in 1/4
compared to what was planned. And so they had $4 million
invested in starting capabilities that were taking
almost a year. And so now they're considering
introducing capability limits for them.
A capability is a chunk of value that's bounded by 1/4 by 90
days. So it's supposed to be done in
90 days, but it's taking almost a year to do for 84% of them.
This is a huge eye opener for leaders and then when you add
the cost of that, it will get the attention and hopefully help
to change some partisation decisions that are happening
that may be outside of the team's control.
Yeah, thanks for the plug. So the two things that I got
from your insights just now, right, so first of all is always
try to broaden the visibility, not just at the team level, the
stories, you know, the, the features that the team is
working. But look at it at it from the
higher level. And second thing you mentioned
about capabilities, 90 days long, sometimes we don't have
equal bat size, right. So that's why it's very, very
important to reduce your bat size so that we can get more
predictability. So Dominica, thanks so much for,
you know, covering this, making the work more visible.
So hopefully leaders take that as the cue to, you know, get
things much, much better to organize then manage them
properly. So the other thing is about how
to measure right? So after you make the work
visible. You mentioned a couple times
about flow metrics maybe. What can the leaders or managers
do in order to measure? Start measuring how they get
things done? Well, I would start with what
prevents the team from getting their work done.
And if the response to that is too much WEP on our plate, then
we need to measure how much WEP the team has, which most tool
sets. You can just query your system
and say show me everything that's been started but it's not
completed yet. How many things do we have in
place? And then create an aging report.
Aging report is so powerful, you just can say show me everything
that has been started, but it hasn't been updated in X number
of days. So that could be 30 days, 60
days, 90 days, 200 days, however long and you can see the age.
Then we have all this work in the funnel that hasn't been
touched in a long, long time, 6090 hundred 20 days.
And what are we going to do about that?
So aging report, excellent report to start reviewing on at
least a monthly basis. And then the other pain point
about things taking too long. OK, well, let's measure how long
things actually take. So this is your cycle time or
what I sometimes refer to as flow time.
And with this, now it's important to set the criteria
for when to stop the clock. Because if you ask if teams are
measured at the individual team level, they're going to want to
stop the clock when they hand off their work to another team.
However, if we're working to measure when the customer can
use that feature or that service, then we want to measure
when the customer can access that change that request.
So conversations on when to stop the clock and also when to start
the clock, you know, how soon upstream can we start it during
the discovery phase, do we have the capability to do that?
So that's where I work with a lot of organizations is helping
them. We've had those conversations
about where can we get the most visibility from the broadest
sense like can we see when a capability is in discovery, can
we start the clock then to when that capability is delivered to
the customer. That's a great way to expand
visibility on your flow time. I like the metric of flow
distribution. I briefly touched on it earlier.
This is the ratio of the different types of work.
So if you have features and defects and security work and
technical debt, what is that distribution look like?
And yeah, things will be different sized.
But you know, if you work for small batch size then you can
get a general idea of the ratio of say defects to technical debt
and have that conversation a flow efficiency.
I think it's a really hard metric to measure.
And because usually there's never enough weight States.
And even if an organization has a lot of weight, you know,
waiting on design or ready for design or ready for development
or ready for test or ready for release, even if they do have
those ready for or wait states, often times people won't put the
work in that state. I don't know.
They say there's too much overhead, or they don't want to
make their teammate look bad, or there's a lot of reasons why
those wait states don't get completed or filled out, or it's
just really hard to calculate the wait time.
So flow efficiency is the ratio of active time versus wait time,
and flow efficiency is almost always optimistically high.
I see it all the time. It'll be 8090%, which just is
inaccurate because there's insufficient weight states in
the tool sets. If you are able to measure if
you do have good weight states. I think that it's just a more
advanced practice, but I rarely see that being practiced well,
so that's why I tend to focus more on measuring WIP, measuring
your flow time, and measuring your throughput.
Yeah. Thanks for mentioning all these
metrics. I think we get some ideas how we
can, you know, try to optimize our flow, optimize our work,
right. So again, thank you so much for
this insightful conversation. So, Dominica, unfortunately, due
to time, we have to cut it here. But I have one last question for
you, which I asked to all of my guests, which I call the three
technical leadership wisdom. Think of it just like an advice
you want to give to us listeners here to learn from you.
So what will be your 3 technical leadership wisdom?
Yeah, well, I think that we're asking people to adapt to change
rapidly now, and that people are overloaded and stressed out and
just more and more work to do. And so I encourage leaders to
understand the need for focus time for teams.
You know, this is complicated work, this knowledge work that
we do. It's complex.
It's complicated. And we need allocated time,
uninterrupted time, to do that. And so we need to give our
people, you know, 90 minutes to 120 minutes of uninterrupted
time during business hours that they can be heads down in their
work without getting interrupted.
And so I think we need to be careful about what time we
schedule our weekly meetings and other meetings and provide
people with uninterrupted time to do their most important work.
Because if they can't get it done during business hours, you
end up doing it at 10:00 at night after you put the kids to
bed. Or are you doing it on Sundays,
when really we want people to do their most important work during
the work day? And so create some psychological
safety #2 Create some psychological safety in your
organization, what we would call a generative culture where
people are OK acknowledging that they have too much on their
plate, they're overloaded cognitively, that they need more
space and need to reduce the load so they can finish their
most important work. And then the measures, how
people are incentivized and measured, because how people are
measured is very important to them and they will behave
accordingly to make the metrics look good.
And so there can be unintended consequences for that.
For example, in one organization I worked with, they thought it
was a good idea in their cafeteria to put the names of
developers who had more than 10 bugs assigned to them.
Because like we called it the naughty list, your name went on
the board if you had more than 10 bugs.
And what started happening was people were saying, well, no,
that's that shouldn't really be assigned to me, That should be
assigned to somebody else. And it just caused so much angst
that it made things take even longer because people were so
fearful and worried about getting on the naughty list.
And those bugs, some of them weren't high priority, they were
low priority. So I think it's be very careful
about how people are measured and incentivized in your
organization. I really love all of them,
right? So space, psychological safety
and also, you know, measurement, right?
So I think really, really important how you measure
people. So, Dominica, I can't highly
recommend enough for your book, right?
So for people who want to check out Dominica's book Making work
visible, I think highly, highly recommended.
But for people who want to follow up other resources or
your work, is there a place where they can find you online?
Yeah, LinkedIn is probably the best place.
LinkedIn. There's not too many Dominica
degrandises on LinkedIn, so you should have no problem finding
me. Just reach out.
I'll put it in the show notes. So thank you so much for your
time today. Dominica really learned a lot
from you. Thank you, Henry.
Appreciate it. Thank you for listening to this
episode and for staying right until the end.
If you highly enjoyed it, I would appreciate if you share it
with your friends and colleagues who you think would also benefit
from listening to this episode and if you're new to the
podcast. Make sure to subscribe and leave
me your valuable review and feedback.
It helps me a lot in order to grow this podcast better.
You can also find the full show notes of this conversation on
the episode page at Techlyjournal dot dev website,
including the full transcript, interesting quotes, and links to
the resources mentioned from the conversation.
And lastly, make sure to subscribe to the show's mailing
list on techlyjournal dot dev to get notified for any future
episodes. Stay tuned for the next Techly
Journal episode, and until then, goodbye.