September 27, 2025 • 44 mins
One of the biggest challenges facing the Agile community today is the way tools are used. Too often, they become a substitute for conversation and collaboration, rather than a support for them, leaving us falling short of the intent behind Agile’s values and principles. In this episode, we discuss this issue and offer strategies to avoid falling into this trap.
Join Shawna Cullinan, Jörg Pietruszka, Diana Larsen, Sheila Eckert, Sheila McGrath, April Mills, Hendrik Esser, Ray Arell, and all the callers to the monthly live event as we explore this topic. For details on the next live event or how to support our show, please visit acnpodcast.org.
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Ray Arell (00:06):
Good morning and good evening everyone.
Welcome to the Agile CommunityNetwork.
I'd like to welcome you toepisode 105.
Today we're going to be talkingabout tooling over people.
And that's a little bit of atwist on the Agile Manifesto,
which is put people first.
We want to talk about thattoday.
If this is your first time hereand you want to hear all the
(00:26):
other episodes, you can go overto acnpodcast.org or you can go
subscribe to it on almost anypodcast service.
You can just go look for ACN,put that in your put that in
your subscribe button.
That way you'll get the latestdrop when it comes out.
Also, if you could hit the likebutton on there because that
helps the magic of thealgorithm.
(00:46):
That does help us overallbecause it gets the show out to
other people.
We are brought to you by anumber of different companies as
well as individual subscribersto New Agility.
Our main title sponsor, theygot a new logo now, the Agile
Alliance.
We also have CicadaOrganizational Agility, Diana
Larson.com, Engine for Change,and of course I just mentioned
(01:09):
New Agility, which is thecompany that produces the show.
Please, if you want to supportthe organization and help us
deliver the podcast, we havesome uncertainty coming into
next year.
It's unclear whether or notwe'll have all of our sponsors
next year.
I am having those conversationsto help mitigate that.
If you are a company and you'rewanting to be a sponsor of this
(01:30):
show, please just go up toacnpodcast.org.
And there is a button therethat says, I want to become one
of those nice subscribers, or Iwant to support the show.
For those who are supporting usright now, thank you.
We couldn't do it without you.
I also can't do this withoutthese wonderful people.
Uh, Shauna, Diana, York, SheilaEckhart, Sheila McGrath, as
(01:53):
well as April and Hendrick, aremy co-hosts that join me.
They're a part of the Agilecommunity.
They've been a part of theAgile community for a long
period of time.
They help to bring theconversation or bloom the
conversation as we get going.
So, tooling over people, thisis a classic problem inside of
Agile.
(02:13):
I see this multiple times as Igo into different companies.
This happened when I was a partof other companies and watched
them get so obsessed about thetools that they suddenly lost
what we were trying to do withAgile in the first place.
If you think of the wholemanifesto, it's really weird
(02:35):
when suddenly Jira becomes themost important step.
You know, when you got to getup, a daily stand-up doesn't
occur any longer if you'repracticing Scrum.
People are just offlineupdating really long Jira cards
or whatever your favorite toolthat you're using.
And in some regards, it becomesthe driver of the process.
And that's really wasn't theintent.
(02:57):
It does help sometimes intraining and other things, but
it replaces the human factor ina lot of things that we do
inside the agile space.
I've seen this also a bit withthe metrics obsession, people
collecting every single metricthat you can possibly do.
I've talked about the humancollaboration component to it,
but the metrics themselves goingup to the upper echelons of
(03:19):
your company are seldom lookedat.
Overall, we as a community arelooking to see those sparks
occur when people collaborate.
I want to see the peopleworking together to solve the
problems because the more brainsyou can put on a problem, the
(03:40):
better things work out.
The way I look at a fix this,at least for myself, is it
deserves a decent discussionabout the role of tools within
the organization.
Not as a policy discussion, butcould turn into a policy
discussion, but what's the role?
What are we trying to achievewith it?
Prioritizing the human rituals.
(04:00):
And if you don't have them, gocreate them.
Also, just simplifying how thetools are used.
How many data fields are youcollecting?
Sometimes these cards that arecreated will the expectations of
filling some of these thingsout.
It's just too many fields.
How do you simplify themeasurement of what's relevant?
(04:21):
If we're suddenly starting towork on increasing or
stabilizing our velocity, thenthat's a metric we want to go
look at.
Otherwise, if it's not thatimportant, then that's something
we don't need to measure rightnow.
Or we're not working on that,meaning that we're not trying to
fix or improve it at this time.
We might check it from time totime, but it's something we
(04:42):
don't need to check all thetime.
Face-to-face communication.
I know since COVID,face-to-face has been hard.
And if you work in amultinational company, it's
hard.
But prioritize that.
Have a couple of meetings whereyou will be all in the same
space.
I know that sometimes isexpensive and it's hard to get
(05:03):
everyone into the same place,but per project, just at least
once.
So my questions for the groupare number one, how would you
fix the problem of tools overpeople problem?
How would you do that?
What's your approach to it?
And then I added this one as alittle bit of a joke.
You've seen the tools elots.
(05:23):
They're the enforcers of theprocess, the enforcers of the
tools.
Sometimes that's a scrum masterand scrum teams.
Sometimes it's management.
But how do you address it?
And specifically, what do youdo in order to have that
conversation with somebody andfix that?
And then lastly, if you haveany questions beyond this topic
(05:45):
that you want to ask, that'salso fair game too.
So to kick us off, Hendrik,you're here.
How would you approach this?
Hendrik (05:54):
I agree with all you said, and it is a challenge.
I think it is a biggerchallenge, especially after
COVID.
On the XP conference last year,there was a keynote where
somebody talked about the AgileManifesto saying individuals and
interactions over processes andtools.
Since COVID, it's individualsand interactions only through
(06:15):
processes and tools.
Because when you want to have ateam meeting, it needs to use
one of these board things like aMIRO board, and that needs to
be prepared and structured andso on.
And all of a sudden, it's allabout the tools.
I completely agree with whatyou were saying.
In my experience, there's maybetwo things that I have done in
the past, and that is reallychallenge the tools.
(06:36):
One thing I experienced wasthat there was a tool provider
and they got traction in ourcompany.
I asked them for a meetingbecause I did not see how their
tools were supporting my way ofworking or my team's ways of
working.
So they talked to us for awhole day and they show how we
can tweak the tools somehow toget closer to our ways of
(07:00):
working.
But in the end, what becameclear is that my team needs to
start working in a different wayif we want to use the tool.
And I just refused.
So I sent them home and we didnot start using the tool.
But neighboring organizationsdid, and they fell into the trap
that now, more or less, thetool was taking over the
process.
And when a tool has taken overthe process, adapting the
(07:22):
process becomes more and moredifficult.
I think in the first place, youneed to be very cautious with
what tools you source before youreally destroy your agility in
the process.
So that's at least oneexperience I have had in the
last years.
Ray Arell (07:40):
One person wrote in the chat line that people
sometimes don't feel that theyhave agency to change those
things.
You said you talk to the toolvendor.
I think that's great.
But the people in the processsometimes don't feel they have
the ability to change it.
How do you do that at yourcompany?
Hendrik (07:58):
Yeah, that's a problem, actually.
Over the years, we have beenafter our agile transformation,
we had an organization that wasscanning through the tools and
checking are they now helpful ornot for our processes.
I believe process is missing.
I completely agree.
In the end, it's the process,the way you work that should be
in the center, and that processshould be adaptable.
And the tools usually lock youin.
(08:21):
Often in companies, there's asourcing department that
determines which tool they talkto a lot of people.
More often than not, somethingsuboptimal is chosen.
I do not really have afantastic answer to this, other
than teaming up with thesourcing department and making
sure all voices are heard andthen picking tools that are very
(08:41):
adaptable.
You mentioned things like gyra.
It's a very powerful projectmanagement tool, and you can use
it and misuse it for anypurpose.
And the problem with Gyra, forexample, is people start filling
it with fields that need to bemaintained, updated all the
time.
Sooner or later, it's notupdated anymore because it's too
many fields, and then the wholedata consistency falls away.
(09:04):
Another thing to fight thewhole thing is to keep things as
simple as possible and not usea tool where people
communication should happen.
Tool should always be so smallthat it enables a conversation,
but it doesn't take over theconversation.
Ray Arell (09:21):
Fully agree with that.
Hendrik (09:28):
The tool for that is good because it shows you which
team needs to talk to whichother team.
A (09:49):
This is more compensary control.
When organizations feel likethey are not in control of their
destiny, they'll grab atanything.
We see this in human behavior.
They do anything to maintainthe illusion of being in
control.
They grasp whatever they can tomaintain control.
(10:11):
The best way that I've found toalways talk about that is
through the idea of this is whywe are doing this and
maintaining a narrative and afocus on their personal story,
whether as an individual or anorganization.
We do agile this way so that wecan maintain agile.
(10:34):
I think it's more of a symptomof organizations feeling like
they don't have control, feelingthe need for control lean into
the explosion of tools ratherthan the other way around.
Ray Arell (10:54):
That makes a lot of sense.
Thank you for clarifying thatfor me.
I appreciate that.
I'm curious in your coaching,do you find that, and I think I
put it on one of the priorslides, but it wasn't clear
everyone was seeing the slidesas they were going by, posing
the question from time to time,is this tool helping us
collaborate better or is itgetting in the way?
Do you find yourself incoaching that with your teams?
A (11:17):
I find myself usually saying we don't need tools, trying to
remove as many tools, but youget a lot of people who want
things.
For example, they want to usethe AI because they think that
it'll make their process easier.
They think that, and then theyget used to doing that.
(11:37):
Making any sort of change ishard for people.
So it's really difficult forany of that.
I think as people who areworking in organizations to
encourage change, one of thethings that we really need to do
is just say, let's try itwithout that.
Let's find something else,let's see how it feels.
(12:01):
We can't force them to doanything, but we can try and
prevent further harm fromhappening.
Ray Arell (12:09):
God, you've had your hand up as well.
Speaker 01 (12:13):
Yeah, good afternoon, everyone.
The first thing I do when westart talking about whether it's
JIRA or ADL or TFS or RTC orwhatever tool is usually being
forced upon us, is I bring upthe Agile Manifesto.
The first value in the AgileManifesto is individuals and
interactions over processes andtools.
(12:34):
So we talk about that and whatdoes that mean and why is that
important?
And we talk about, especiallyin this distributed world, we
need a tool to make our worktransparent because nobody's in
the office on the team that Iwork on.
They can't do a physical boardif no one's around to see it.
But as we all talked about, youcan overuse these tools as
(12:56):
well.
One of the things I talked tothe team about is we're using
ADO now.
So we can use ADO as lightly aswe need to do what we need to
do, or you can have our dev teamfilling out all these fields
and playing around in ADO allday, or you can have them work
(13:16):
on customer outcomes.
What's more valuable to you?
And I've never asked thatquestion and had anybody say,
oh, I'd rather have the teamplay around in ADO all day
instead of providing outcomesfor our customer.
The other thing that I've doneis de-emphasize metrics that
don't matter as much.
An example of that is we havedevelopers using tasks.
(13:37):
So our stories are a littlebigger than what they've been in
the past because they havethese tasks instead of
individual stories, and it'seasier for them to track.
But trying to be flexible andgetting the tool to work for us,
we've gone that route ofsaying, use the stories, use the
tasks, but your stories aregoing to be a little bit bigger
than normal.
So we don't have developersworking on five or six stories
(14:01):
of sprint.
They're working on one to twostories of sprint.
We don't spend as much time onthe metrics as far as burn down
because we don't have thatsteady burn down throughout the
sprint that we've had in thepast.
We will still use velocity.
So we'll de-emphasize metricswhere it makes sense, emphasize
ones that do make sense.
And then the other thing I'vedone, and Ray, it was very
(14:23):
similar to you, is I was askedfor burndown charts and velocity
charts so that they could becompared to other teams.
I sat down with my PO and I'mlike, what do you think?
He's let's not send it and seewhat happens.
Three months later, no one evercame to talk to us, so we never
did it.
That's how we got out ofproviding those kinds of things.
We just took a chance and thatbecame a mantra for us that if
(14:43):
we didn't agree with something,we just didn't do it.
And we waited for someone tocome slap our hand.
And I can tell you I never gotmy hand slapped.
Ray Arell (14:50):
I can tell you the way they frame that is the most
dangerous thing that someone canactually do and say, oh, well,
I'm gonna compare the number ofpoints burned by team A and team
B.
Like, ooh, that's bad.
It's not apples and oranges, orit is apples and oranges or
bananas.
I would never ever give themthat trick for that one.
Thank you for that.
(15:11):
Sure.
Well, let's see, April Mills.
What do you got?
April (15:18):
I love the conversation around agency because that's the
mechanism through which weaddress any overages of an
organization's focus on thetools over the people, but also
advocate for the right tools tosolve the problems we have.
I've encountered organizationsthat wanted to accelerate
(15:42):
software development, but didn'twant to invest in CI CD systems
to enable the developers.
So I've seen times where thetools were deficient to the task
and the outcomes.
It was incumbent upon theleaders and the developers to
band together to advocate forthe right tools to solve the
problem.
So a lot of times we talk aboutit from a they're making us
(16:06):
focus too much on the tools,which I've seen that happen
countless times.
But there's also deficienciesin tools which a lot of people
struggle with to be able to makeand meet the commitments that
are expected of them.
And so as a community, I thinkfocusing on how do we band
together to get the tools tohelp us succeed and what does
(16:27):
that look like is importantstrength building for
individuals and for teams sothat the systems are set up for
current and ongoing success.
Ray Arell (16:39):
What about the standardization problem when
suddenly everyone's gotta go usethe same tool?
April (16:47):
Yeah, in those cases, you're always balancing the
cybersecurity contract fees withthe specialization.
And that's where I think it'sabout accessibility and
effectiveness versus preference.
So many teams couch theirarguments against a standard
(17:08):
tool as we don't like it.
And I think that's the wrongargument.
It's better to say here's whyit causes us to be unable to
make and meet our commitments.
That's a more useful enterprisefirst argument than a
preference argument.
So you can not like say JIRA orsomething else, but the
(17:32):
enterprise probably isn't goingto react to your
preference-based argument thesame way it would to a business
value-based argument.
We've seen countless timeswhere tools have gotten in the
way of business value causingdeveloper delays.
Right?
(17:59):
Talking to the folks in ITtrying to drive an enterprise
consolidation.
I understand you're beingmeasured by the spend, but we
don't exist to have the cheapestIT.
We exist to have the bestproducts delivered as fast as
possible to meet the market.
How can I partner with you inIT to make the argument that
it's actually better for thebusiness to have multiple tools,
(18:23):
even if it has a slightlyhigher IT spend, if we're going
to make a lot more money fromit?
That's where organizations endup being pennywise and pound
foolish, optimizing their ITspend versus optimizing their
product flow.
Ray Arell (18:37):
Yeah, I agree with that.
I've seen that many a times incompanies when you actually sit
down with a spreadsheet and go,this is the lost productivity,
and this is what the dollar costis going to be for us by doing
that.
Yeah.
Let's see.
Luan?
Am I getting your name correct?
Speaker 03 (18:52):
Yes, there's Luan.
I wanted to have a clear, andlet me just pull out this
disclaimer.
I'm new to learning projectmanagement and agile.
This is my second time joiningone of your podcast series.
So thank you.
I wanted to ask a clarifyingquestion for the question on how
would you fix the tools overpeople problems?
(19:12):
Is it the preference of usingthe tools versus utilizing the
people?
Or is it people relying on thetools versus their people?
Ray Arell (19:25):
It comes down to where if you look at back in the
good old days, we used to dodaily stand-ups in front of a
Kanban board and everyone wassharing what they did yesterday
and having conversations in thatstand-up.
But that's gotten replaced witha tool where the stand-up might
not take place at all andpeople are just updating status
(19:48):
through the tool.
And the tool itself becomes themain communication to the rest
of the team.
Speaker 03 (19:58):
Which I'm thinking is getting in the way of the
engagement of the team, the dutyof working together.
And for agile or just it's ateam, you want that people
interaction.
Ray Arell (20:08):
Exactly.
If you look back at the agilevalues and principles, very
human-centric.
And if you think about the wayproblems get solved, as humans,
we all always get stuck.
Move forward faster.
And so the tool sometimes justgets in the way.
(20:29):
I spend more time updating mymy and I keep bashing Jira, I'm
sorry.
Rally.
We'll say rally this time.
Is Rally even around anymore?
But you just spend your dayupdating those things.
And that's not getting yourproduct out the door.
It's care and feeding of atool.
Speaker 03 (20:48):
Thank you.
Thank you for that.
Because I I wanted to approachthe question, but in the in a
because I have an idea of way toapproach this question, but I
just wanted to clarify just so Isee if my approach would be a
good way to approach it.
And the way I'm thinking iscombining the two.
Because I think both arevaluable.
People are valuable, tools arevaluable.
But with people, like you said,sometimes you just don't
(21:09):
understand something becauseit's blatant in front of you.
But when someone can explain itand articulate what it is, it
gives you a better, deeperunderstanding of how to even
utilize the tool or that thetools even benefit for you.
So like you said, the one tool,Jira, Jira, is that the name of
the tool?
Jira, yeah.
I don't know how to use it, butI've been listening to how you
guys have been explaining it.
(21:30):
And I think I got a sense ofit.
But if somebody was to explainthe update, I will be able to
connect the dots to know how Ican utilize that to bring
whatever part of the projectthat I'm working on, better
knowledge to it once we doactually meet in person.
But I think that's just amatter of setting those ground
rules before everything starts,letting people know I'm all for
(21:53):
using tools, but I want us tounderstand these tools so that
we can put the human element tothe tools as we utilize them.
That will be an approach that Iwould take for fixing that
problem.
It's just combining the twotogether.
Ray Arell (22:07):
And I think what you said about having that
meaningful discussion with theteam in the very beginning helps
because then they understandwhy the tool exists, why it's
there.
Speaker 03 (22:16):
Exactly.
And how it benefits the projector the task or whatever it is.
Because some people I thinkit's like, why are you even
using that tool?
Now you're actually expandingsomebody's knowledge on the way
to use it for something.
I know I've stumbled acrossthings like that.
Even listening to everything.
And like I said, I'm still newto this and trying to learn it.
I would use it even outside ofa project that will be agile.
It's something that I could useit for keeping track purposes
(22:37):
for just myself, or just beingable to have the experience of
even utilizing the tool when Ido need it for what it's used
for.
I already have the experienceto be able to do it.
And that's the way I wouldapproach it.
unknown (22:48):
Shh.
Ray Arell (22:49):
Yeah, and that's the reason why I use Trello.
I love Kanban boards.
As much as I've used the papertools, I just find that I have
it everywhere.
I can reference it.
We all have our preferences.
unknown (23:03):
Yeah, exactly.
Yeah.
Ray Arell (23:04):
And if it improves me, it can definitely improve
the team.
And by you using it, it alsoinfluences others to potentially
use it as well.
Thank you for your comments.
I appreciate it.
Diana Welcome back.
Diana (23:17):
My experience, I don't work directly with delivery
teams anymore.
And so my experiences with thetools of actually being a person
who is using the tool issomewhat limited.
On the other hand, I often getinvited to observe how people
are using their tool.
(23:39):
And one of the things I findmyself saying a lot is wait a
minute, folks, you get to usethe tool.
The tool doesn't get to useyou.
I see that happening often whenthere's an on-site expert in
the tool or whatever thatthey're just not being accessed
enough, or they don't have maybeenough bandwidth to come around
(24:02):
and talk to all the teams.
But in one specific instance, Iwas asked to sit in on all the
boundary meetings of a team.
It was a very large team, wellover 20 people.
And they they were doing theirreview and their retrospective
and their planning, and theywanted my feedback.
When we got into the planning,most of the people were in one
(24:27):
location, but a bunch of thepeople were in a couple other
locations.
And when they got to theplanning, they popped open their
JIRA tools, and there were 218items on the backlog.
All you could see in the field,because the description was
longer than the field wouldaccommodate, was as an engineer,
(24:49):
I want.
So they had to go through andopen up every single one of
those 218 to do any prioritizingor any understanding of what is
actually on this list or thosekinds, and that was the tool
using them.
That somebody had told them,oh, just write what you want,
(25:12):
without really telling them howto write a story problem or a
task problem.
They had grabbed the connextraformat and run with it in a way
that didn't really work forthem.
One of the things I alwaysrecommend is if there is an
(25:37):
on-site expert in the tool,given the responsibility of
really understanding this tooland then explaining it to people
and helping them set it up in away that works for them, make
sure you're accessing thatperson.
Make sure that you are gettingthe whole thing set up in a way
that is actually going to workwell for you.
And in this instance, 218items, there was it's going to
(26:04):
be very difficult to fix becauseevery single one of those,
whether it was high priority ornot, was going to have to be
looked at and going to have tobe rewritten in a way that
expressed it so that you got thenugget, the essential element
of it in the field that wherepeople could see why that was
(26:25):
why it was there and what it wastrying to accomplish for the
team.
And it's those kinds of thingsthat they had another tool that
they used that presumably was aretrospective tool that didn't
encourage them at all to get toactually improvement actions.
It encouraged them to makelists of what they thought went
(26:49):
in the last sprint and what theythought they could have done
differently or should have donedifferently in the last sprint,
but nothing about what they wereactually going to tackle and
agree that they needed to changeand do differently.
Or anything about what they hadlearned during that sprint.
I'm not completely opposed tothe single question or the three
(27:13):
question list retrospective.
I think it's not the best wayto go, but I know people who get
value from that.
It's got to lead you to thatplace where you are making
improvements or deciding thatwhat the most important thing to
do that time was to have a teamconversation about some topic
so that you could digest it overthe next front and then come
(27:36):
back to it.
Or whatever that action is, thetool needs to facilitate you
getting to that action.
And if it doesn't do that, it'snot a good tool.
It's just letting you makelists that you go, huh?
Look at that and move on.
This is particularly a problemwhen an organization is not
(27:56):
providing the teams with adedicated uh scrum master or
tech lead whose job it is tomake sure that the boundary
meetings happen.
And but and what they do isthey conflate that with that
person is also the productowner, or that person is also
(28:20):
has another role.
And so the their competingroles get in the way of those
meetings, staying focused onwhat the team needs to improve
and what's possible for them.
So that's been my frustrationwith a lot of the tools.
And now with AI, which AI agentare you using and what's its
(28:45):
sweet spot?
Because I see people choosingAI tools to do a thing that it's
not really meant to do.
Like to be creative, the onethat you choose is better suited
to helping you do research,finding out what's already
known, not putting thingstogether to discover some new
(29:05):
possibility.
And knowing what the tool iscapable of, what its limits are,
its limits may be very useful.
You may say the fact that itdoes this is a really good
thing.
And you might want to use it insome cases, but you need to
know which cases you aren'tgoing to use it in as well.
A lot of what I see is peoplegetting tools without really
(29:29):
understanding why they havethem, how they work, getting
support and making them work aswell as they possibly can.
Ray Arell (29:38):
Love all of that.
And I've seen the same problem,by the way, just the write only
memory systems where peoplethrow in their data and you know
what?
It's never used.
And that's that is really bad.
Thank you.
Dylan, how are you doing today?
Dylan (29:52):
I'm doing well.
Thank you very much.
I've been looking forward tothis conversation and it is not
disappointing at all.
So glad.
To be here.
Ray Arell (30:01):
I'm glad you made the time for it.
Dylan (30:05):
So many thoughts, Dan.
My brain was exploding whileyou were talking.
One central thing I've reallybeen thinking about is that when
it comes to teams or companiesor individuals choosing the
tools they use, this is actuallya really great time to lean
hard on a product mindset, aproduct operating model, but
(30:28):
flipping the perspective andfrom the customer's perspective,
really take the time to talkabout what problems you want to
solve with any given tool andwhy those problems are
important.
Dig with additional questionspatiently and curiously to get
down to the essence of what isthe most important value these
(30:51):
tools can deliver to us.
And then choose your tool,experiment with it, move
forward, and rinse and repeat.
What people have a hard timedoing is taking the time to have
those conversations.
However, the efficiencies youcan gain and the amount of
frustration and resentment thatyou can avoid from the employees
(31:13):
by taking that time tocontinuously make sure is this
tool solving the most importantproblems that we want to solve
goes a long way.
So that's a way that I like toframe it up in some of these
conversations.
Ray Arell (31:30):
I like that approach.
And it does go a long way.
Sheila?
Sheila (31:35):
I was just making my list of things nobody'd
mentioned.
I think it's interesting thatwe're focused on Jira and tools
like that.
JIRA started as a bug trackerand it shows.
So you're automatically forcedinto a certain perspective when
you start by using a bug trackerto track everything.
(31:56):
And it's not necessarily theright place to be.
In organizations where I'veworked, a lot of the time you
have the project or the productrolling up to the portfolio.
And whether you're looking atit from a product management
portfolio or a projectmanagement or a value
(32:18):
management, ties into theaccounting systems.
So it's worse than I alwaystalk about big enterprise level
projects as being like turning abattleship if you need to
change something.
When they tie all these thingstogether and automate it, which
a lot of companies do more andmore of, and they think they can
get information that's usablefrom the system without having
(32:42):
to consult people.
And that information will bereliable for making future
management decisions.
It gets to where you can'treally change it.
And the product people, itdepends also on who is really in
charge.
I've worked in insurancecompanies where most of the
people at the very top startedout as agents, for instance.
(33:05):
That gives a certainperspective.
And I think in a lot of ways,senior management thinks that
Agile is just a bunch of newjargon.
Unless they've really learnedAgile, they don't understand how
it's different than waterfall,except in the way things are
organized.
They don't understand themindset.
(33:26):
They don't understand whythey're losing some value by
relying so heavily on thesetools.
And I don't think it's a simpleproblem to solve because there
are some efficiencies of scalein using these tools.
But then you're limited bywhatever the limitations of the
tool are.
And I don't have any goodanswers.
(33:46):
That's not great, but this iswhere we are.
Ray Arell (33:50):
Yeah, no, and the interconnectedness is again,
most systems are they seem to beeasy to install, but very hard
to get rid of.
I used to say, don't fall inlove with your tools because
there's going to be a new onethat's going to show up.
The corporation's going to gosettle and say, okay, we're now
using X.
And I also said that they havethe life expectancy of a good
(34:12):
dog.
We're going to we're going toget it replaced.
But in the same regards, it'sit just is really unfortunate
that if you just pulled the plugfor one week, who notices?
Sheila (34:23):
I had a friend who worked in brokerage.
Every once in a while they'dturn off systems and see if
anybody noticed.
And a lot of times they didn't.
Ray Arell (34:30):
Yeah.
That's something it'sinteresting as an experiment.
Just shut it off for a week andsee what people do.
Karen, you had your hand up.
What's up?
Speaker 02 (34:40):
Okay.
Being a consultant, it justseems it's like you're taking a
little kid and showing themthere's a two-wheel bike and
just telling them, okay, justget on and try to ride this
bike.
When that the kid falls over,it seems the sequence is counter
to what Diana shared, to use atool, wait for problems, and
(35:02):
then address.
So my question is what is thepre-work that would help
establish the correct balance,the mindset, the purpose to
avoid all the pitfalls?
It's why start a tool withoutgiving it the understanding and
(35:24):
limitations that the team needsto understand.
It's okay, now we're in thequicksand.
How do I get out?
You know what I mean?
Ray Arell (35:34):
I I do, and I think that's when we lose sight on the
fact that could we get awaywith distributing a product to
our customer and not teachingthem how to use it?
Could we get away with that?
Speaker 02 (35:48):
Has anyone done that and work with them as far as
the mindset of you to use thistool and how to establish the
expansion of use in application?
Ray Arell (36:05):
As a person who goes out and trains people with
agile, I know that thediscussion typically starts with
let's go learn the values andprinciples first, and then we
ease into tools.
The tool discussion isn't dayone.
We want to first do it manuallyso you can see it operate.
And I agree with you on thefact that most people are not
(36:29):
taking that step.
And they're just there was your10 minutes of training.
Bye.
Speaker 02 (36:36):
It just seems it's like the same problems in a
different context over and overagain.
Ray Arell (36:43):
I think the total cost of ownership of something
is never really looked at.
And loss of productivityspecifically, when the tool
becomes the impediment, meaningwe're spending too much time in
this.
And I think it's back toDiane's question about her
comment about retrospectivesbeing done well.
Nobody's flagging it as anissue, or they're flagging it as
(37:04):
an issue and then taking noactions.
And last thing is probablynever roll out a tool where it's
like everyone's, we're gonna doit all at one time.
We pilot.
We want to make sure that it'sthe right choice, if that makes
sense.
Speaker 02 (37:21):
What is the approach to look at the total cost of
ownership?
Ray Arell (37:29):
I think it goes in where it's not just the
deployment of the tool, but it'salso the training costs and
other things that need to be uhincluded into it.
And then there's a refreshcycle that occurs because you
always have new people coming inand out.
Yori, you put your hand up.
Did you have something to addto this?
Jörg (37:47):
For me, this goes way before my first contact with
Agile because we were forced byour customers to use a certain
requirements management tool.
It was either do it or losetheir business.
And that was pretty simple.
So the question we started.
What is in it for us?
And we started with the why.
Because we were lucky to haveenough money to ask for a
(38:10):
consultant to teach us the toolbecause we wouldn't want to
screw up in front of thecustomer.
Very simple.
If you don't know what you wantto do with it, don't use it.
Find out what you want to dowith it first.
If you just try the demo, youwill learn a process that is
total crap but looks great inthe tool.
And you will never unlearn thatprocess again.
And he was totally right.
(38:32):
I think seven guys who reallylater on used the tool, he made
all the things going.
One guy installed the earlyversion, he never grappled with
the process that was muchslimmer, much more effective,
went through all the audits anddelivered what we needed.
But as soon as you're blindedto a tool telling you what to
do, it's really hard to unseethis thing.
(38:53):
And that is my main learning.
Most people hope that a problemis solved by a tool that they
can't name and that they justfeel as a burden.
You can probably relate tothis.
I'm dyslexic, so obviously Iwant typos just to go away.
Whatever you use, that doesn'thappen.
Never fully.
So you you just have to arrangeyourself with it and really
(39:16):
know which kind of investment isworth doing it.
And I think that is always thequestion for the tools.
What's the real benefit youwant to have from it?
And then you can have greattools and great use.
One of the tools I immenselylove is a blue plush elephant.
Just a little toy I bring intomeetings, because that's the
(39:38):
elephant in the room.
I can throw it at anybody who'sjust stepping around things.
And because it's smiling andpositive, I can get a
conversation started that Ican't get to in another way.
And that is one of the tools Ilove because I know what it's
going to give me.
I think that is very important.
Understand what is the benefityou expect from the tool and do
(40:00):
early verifications if thatbenefit really arrives.
If it doesn't, either you'reusing the tool wrong, the tool
is wrong, or if your expectationis not achievable, which is
quite probable as well.
You need to make the tooldecision irreversible.
You need to be allowed to dropthat tool again.
And don't expect a screwdriverto tell you how to build a bed,
(40:23):
because there's much more neededthan that.
Speaker 02 (40:27):
So you said you were forced by your customers to use
a certain requirementsmanagement tool.
I'm just curious, what was theprocess between them saying, we
want you to use this tool andyou starting to use it?
How you found this tool to beproductive and valuable?
Jörg (40:47):
Yeah, we had that conversation in a workshop and
we said, what is it that we arelacking?
We are lacking the informationif you really have everything
complete at the end of theproject, if you didn't the right
tests at the end of the projectand we need to prove that to
the customer and then match itto what they wanted, did we
address everything of that?
In the end, the engineers toldus that they wanted much more
detail to be documented becauseit helped them prevent
(41:10):
misunderstandings andcontradictions.
But then that came much later.
And with that in mind, we knewall we needed to do is what's
really needed in terms of therequirement, who's gonna do it,
is it done?
How is it tested?
Is it in review?
Is we don't mind if the rightthing is written and everybody
confirms we tested it, how thereview process is, whether the
(41:34):
wording is right, that wasn'tour purpose.
Is the detail right?
Do we need to check that thereare at least 100 words?
No, we don't.
It's much easier to add abenefit that you see than to
take an overhead away that youhave gotten used to.
Ray Arell (41:49):
Thank you for that.
Let's see.
We've got a few other handsthat are up.
Let's see if we can get youguys through before we hit the
top of the hour.
Z, what do you have?
Speaker 09 (41:59):
So I just want to make a comment.
I think somewhere along theway, we started worshiping uh
tools and not paying.
I see that where I am.
And I think we forget thatScrum is people powered.
So when the process in thetools are louder, then the
people, it's time to turn downthe volume on those days.
No tool will replace the magicthat happens when smart,
(42:19):
passionate people sit down andtalk.
And yeah, the dashboards justdon't deliver the same value as
people.
So I really enjoyed hearingeverybody.
Ray Arell (42:28):
Yeah, I agree with uh everyone.
We had a really livelyconversation today.
I want to thank everyone fortheir participation.
It turned out to be a liveliertopic than I was expecting,
which is typically most of thetime when we get together, that
turns out to be the case.
Just as a reminder, our nextlive event is going to be in
October, October 24th on aFriday.
(42:50):
Always on a Friday.
Also, if you can go up toACNacnpodcast.org, please go up
there and hit the donate button.
We could use the dollars to payfor the webinar system and all
those things.
Those are coming due.
I thank all of my co-hosts.
I couldn't do it without all ofyou, and thank you for your
time on this lovely Friday.
(43:11):
I hope you have a wonderfulmonth.
The ACN Podcast is foreducational and informative use
only.
If you'd like to know moreabout the ACN community, please
come up to ACN Podcast.org andsupport our show.
Good morning and good evening everyone.
Welcome to the Agile CommunityNetwork.
I'd like to welcome you toepisode 105.
Today we're going to be talkingabout tooling over people.
And that's a little bit of atwist on the Agile Manifesto,
which is put people first.
We want to talk about thattoday.
If this is your first time hereand you want to hear all the
(00:26):
other episodes, you can go overto acnpodcast.org or you can go
subscribe to it on almost anypodcast service.
You can just go look for ACN,put that in your put that in
your subscribe button.
That way you'll get the latestdrop when it comes out.
Also, if you could hit the likebutton on there because that
helps the magic of thealgorithm.
(00:46):
That does help us overallbecause it gets the show out to
other people.
We are brought to you by anumber of different companies as
well as individual subscribersto New Agility.
Our main title sponsor, theygot a new logo now, the Agile
Alliance.
We also have CicadaOrganizational Agility, Diana
Larson.com, Engine for Change,and of course I just mentioned
(01:09):
New Agility, which is thecompany that produces the show.
Please, if you want to supportthe organization and help us
deliver the podcast, we havesome uncertainty coming into
next year.
It's unclear whether or notwe'll have all of our sponsors
next year.
I am having those conversationsto help mitigate that.
If you are a company and you'rewanting to be a sponsor of this
(01:30):
show, please just go up toacnpodcast.org.
And there is a button therethat says, I want to become one
of those nice subscribers, or Iwant to support the show.
For those who are supporting usright now, thank you.
We couldn't do it without you.
I also can't do this withoutthese wonderful people.
Uh, Shauna, Diana, York, SheilaEckhart, Sheila McGrath, as
(01:53):
well as April and Hendrick, aremy co-hosts that join me.
They're a part of the Agilecommunity.
They've been a part of theAgile community for a long
period of time.
They help to bring theconversation or bloom the
conversation as we get going.
So, tooling over people, thisis a classic problem inside of
Agile.
(02:13):
I see this multiple times as Igo into different companies.
This happened when I was a partof other companies and watched
them get so obsessed about thetools that they suddenly lost
what we were trying to do withAgile in the first place.
If you think of the wholemanifesto, it's really weird
(02:35):
when suddenly Jira becomes themost important step.
You know, when you got to getup, a daily stand-up doesn't
occur any longer if you'repracticing Scrum.
People are just offlineupdating really long Jira cards
or whatever your favorite toolthat you're using.
And in some regards, it becomesthe driver of the process.
And that's really wasn't theintent.
(02:57):
It does help sometimes intraining and other things, but
it replaces the human factor ina lot of things that we do
inside the agile space.
I've seen this also a bit withthe metrics obsession, people
collecting every single metricthat you can possibly do.
I've talked about the humancollaboration component to it,
but the metrics themselves goingup to the upper echelons of
(03:19):
your company are seldom lookedat.
Overall, we as a community arelooking to see those sparks
occur when people collaborate.
I want to see the peopleworking together to solve the
problems because the more brainsyou can put on a problem, the
(03:40):
better things work out.
The way I look at a fix this,at least for myself, is it
deserves a decent discussionabout the role of tools within
the organization.
Not as a policy discussion, butcould turn into a policy
discussion, but what's the role?
What are we trying to achievewith it?
Prioritizing the human rituals.
(04:00):
And if you don't have them, gocreate them.
Also, just simplifying how thetools are used.
How many data fields are youcollecting?
Sometimes these cards that arecreated will the expectations of
filling some of these thingsout.
It's just too many fields.
How do you simplify themeasurement of what's relevant?
(04:21):
If we're suddenly starting towork on increasing or
stabilizing our velocity, thenthat's a metric we want to go
look at.
Otherwise, if it's not thatimportant, then that's something
we don't need to measure rightnow.
Or we're not working on that,meaning that we're not trying to
fix or improve it at this time.
We might check it from time totime, but it's something we
(04:42):
don't need to check all thetime.
Face-to-face communication.
I know since COVID,face-to-face has been hard.
And if you work in amultinational company, it's
hard.
But prioritize that.
Have a couple of meetings whereyou will be all in the same
space.
I know that sometimes isexpensive and it's hard to get
(05:03):
everyone into the same place,but per project, just at least
once.
So my questions for the groupare number one, how would you
fix the problem of tools overpeople problem?
How would you do that?
What's your approach to it?
And then I added this one as alittle bit of a joke.
You've seen the tools elots.
(05:23):
They're the enforcers of theprocess, the enforcers of the
tools.
Sometimes that's a scrum masterand scrum teams.
Sometimes it's management.
But how do you address it?
And specifically, what do youdo in order to have that
conversation with somebody andfix that?
And then lastly, if you haveany questions beyond this topic
(05:45):
that you want to ask, that'salso fair game too.
So to kick us off, Hendrik,you're here.
How would you approach this?
Hendrik (05:54):
I agree with all you said, and it is a challenge.
I think it is a biggerchallenge, especially after
COVID.
On the XP conference last year,there was a keynote where
somebody talked about the AgileManifesto saying individuals and
interactions over processes andtools.
Since COVID, it's individualsand interactions only through
(06:15):
processes and tools.
Because when you want to have ateam meeting, it needs to use
one of these board things like aMIRO board, and that needs to
be prepared and structured andso on.
And all of a sudden, it's allabout the tools.
I completely agree with whatyou were saying.
In my experience, there's maybetwo things that I have done in
the past, and that is reallychallenge the tools.
(06:36):
One thing I experienced wasthat there was a tool provider
and they got traction in ourcompany.
I asked them for a meetingbecause I did not see how their
tools were supporting my way ofworking or my team's ways of
working.
So they talked to us for awhole day and they show how we
can tweak the tools somehow toget closer to our ways of
(07:00):
working.
But in the end, what becameclear is that my team needs to
start working in a different wayif we want to use the tool.
And I just refused.
So I sent them home and we didnot start using the tool.
But neighboring organizationsdid, and they fell into the trap
that now, more or less, thetool was taking over the
process.
And when a tool has taken overthe process, adapting the
(07:22):
process becomes more and moredifficult.
I think in the first place, youneed to be very cautious with
what tools you source before youreally destroy your agility in
the process.
So that's at least oneexperience I have had in the
last years.
Ray Arell (07:40):
One person wrote in the chat line that people
sometimes don't feel that theyhave agency to change those
things.
You said you talk to the toolvendor.
I think that's great.
But the people in the processsometimes don't feel they have
the ability to change it.
How do you do that at yourcompany?
Hendrik (07:58):
Yeah, that's a problem, actually.
Over the years, we have beenafter our agile transformation,
we had an organization that wasscanning through the tools and
checking are they now helpful ornot for our processes.
I believe process is missing.
I completely agree.
In the end, it's the process,the way you work that should be
in the center, and that processshould be adaptable.
And the tools usually lock youin.
(08:21):
Often in companies, there's asourcing department that
determines which tool they talkto a lot of people.
More often than not, somethingsuboptimal is chosen.
I do not really have afantastic answer to this, other
than teaming up with thesourcing department and making
sure all voices are heard andthen picking tools that are very
(08:41):
adaptable.
You mentioned things like gyra.
It's a very powerful projectmanagement tool, and you can use
it and misuse it for anypurpose.
And the problem with Gyra, forexample, is people start filling
it with fields that need to bemaintained, updated all the
time.
Sooner or later, it's notupdated anymore because it's too
many fields, and then the wholedata consistency falls away.
(09:04):
Another thing to fight thewhole thing is to keep things as
simple as possible and not usea tool where people
communication should happen.
Tool should always be so smallthat it enables a conversation,
but it doesn't take over theconversation.
Ray Arell (09:21):
Fully agree with that.
Hendrik (09:28):
The tool for that is good because it shows you which
team needs to talk to whichother team.
A (09:49):
This is more compensary control.
When organizations feel likethey are not in control of their
destiny, they'll grab atanything.
We see this in human behavior.
They do anything to maintainthe illusion of being in
control.
They grasp whatever they can tomaintain control.
(10:11):
The best way that I've found toalways talk about that is
through the idea of this is whywe are doing this and
maintaining a narrative and afocus on their personal story,
whether as an individual or anorganization.
We do agile this way so that wecan maintain agile.
(10:34):
I think it's more of a symptomof organizations feeling like
they don't have control, feelingthe need for control lean into
the explosion of tools ratherthan the other way around.
Ray Arell (10:54):
That makes a lot of sense.
Thank you for clarifying thatfor me.
I appreciate that.
I'm curious in your coaching,do you find that, and I think I
put it on one of the priorslides, but it wasn't clear
everyone was seeing the slidesas they were going by, posing
the question from time to time,is this tool helping us
collaborate better or is itgetting in the way?
Do you find yourself incoaching that with your teams?
A (11:17):
I find myself usually saying we don't need tools, trying to
remove as many tools, but youget a lot of people who want
things.
For example, they want to usethe AI because they think that
it'll make their process easier.
They think that, and then theyget used to doing that.
(11:37):
Making any sort of change ishard for people.
So it's really difficult forany of that.
I think as people who areworking in organizations to
encourage change, one of thethings that we really need to do
is just say, let's try itwithout that.
Let's find something else,let's see how it feels.
(12:01):
We can't force them to doanything, but we can try and
prevent further harm fromhappening.
Ray Arell (12:09):
God, you've had your hand up as well.
Speaker 01 (12:13):
Yeah, good afternoon, everyone.
The first thing I do when westart talking about whether it's
JIRA or ADL or TFS or RTC orwhatever tool is usually being
forced upon us, is I bring upthe Agile Manifesto.
The first value in the AgileManifesto is individuals and
interactions over processes andtools.
(12:34):
So we talk about that and whatdoes that mean and why is that
important?
And we talk about, especiallyin this distributed world, we
need a tool to make our worktransparent because nobody's in
the office on the team that Iwork on.
They can't do a physical boardif no one's around to see it.
But as we all talked about, youcan overuse these tools as
(12:56):
well.
One of the things I talked tothe team about is we're using
ADO now.
So we can use ADO as lightly aswe need to do what we need to
do, or you can have our dev teamfilling out all these fields
and playing around in ADO allday, or you can have them work
(13:16):
on customer outcomes.
What's more valuable to you?
And I've never asked thatquestion and had anybody say,
oh, I'd rather have the teamplay around in ADO all day
instead of providing outcomesfor our customer.
The other thing that I've doneis de-emphasize metrics that
don't matter as much.
An example of that is we havedevelopers using tasks.
(13:37):
So our stories are a littlebigger than what they've been in
the past because they havethese tasks instead of
individual stories, and it'seasier for them to track.
But trying to be flexible andgetting the tool to work for us,
we've gone that route ofsaying, use the stories, use the
tasks, but your stories aregoing to be a little bit bigger
than normal.
So we don't have developersworking on five or six stories
(14:01):
of sprint.
They're working on one to twostories of sprint.
We don't spend as much time onthe metrics as far as burn down
because we don't have thatsteady burn down throughout the
sprint that we've had in thepast.
We will still use velocity.
So we'll de-emphasize metricswhere it makes sense, emphasize
ones that do make sense.
And then the other thing I'vedone, and Ray, it was very
(14:23):
similar to you, is I was askedfor burndown charts and velocity
charts so that they could becompared to other teams.
I sat down with my PO and I'mlike, what do you think?
He's let's not send it and seewhat happens.
Three months later, no one evercame to talk to us, so we never
did it.
That's how we got out ofproviding those kinds of things.
We just took a chance and thatbecame a mantra for us that if
(14:43):
we didn't agree with something,we just didn't do it.
And we waited for someone tocome slap our hand.
And I can tell you I never gotmy hand slapped.
Ray Arell (14:50):
I can tell you the way they frame that is the most
dangerous thing that someone canactually do and say, oh, well,
I'm gonna compare the number ofpoints burned by team A and team
B.
Like, ooh, that's bad.
It's not apples and oranges, orit is apples and oranges or
bananas.
I would never ever give themthat trick for that one.
Thank you for that.
(15:11):
Sure.
Well, let's see, April Mills.
What do you got?
April (15:18):
I love the conversation around agency because that's the
mechanism through which weaddress any overages of an
organization's focus on thetools over the people, but also
advocate for the right tools tosolve the problems we have.
I've encountered organizationsthat wanted to accelerate
(15:42):
software development, but didn'twant to invest in CI CD systems
to enable the developers.
So I've seen times where thetools were deficient to the task
and the outcomes.
It was incumbent upon theleaders and the developers to
band together to advocate forthe right tools to solve the
problem.
So a lot of times we talk aboutit from a they're making us
(16:06):
focus too much on the tools,which I've seen that happen
countless times.
But there's also deficienciesin tools which a lot of people
struggle with to be able to makeand meet the commitments that
are expected of them.
And so as a community, I thinkfocusing on how do we band
together to get the tools tohelp us succeed and what does
(16:27):
that look like is importantstrength building for
individuals and for teams sothat the systems are set up for
current and ongoing success.
Ray Arell (16:39):
What about the standardization problem when
suddenly everyone's gotta go usethe same tool?
April (16:47):
Yeah, in those cases, you're always balancing the
cybersecurity contract fees withthe specialization.
And that's where I think it'sabout accessibility and
effectiveness versus preference.
So many teams couch theirarguments against a standard
(17:08):
tool as we don't like it.
And I think that's the wrongargument.
It's better to say here's whyit causes us to be unable to
make and meet our commitments.
That's a more useful enterprisefirst argument than a
preference argument.
So you can not like say JIRA orsomething else, but the
(17:32):
enterprise probably isn't goingto react to your
preference-based argument thesame way it would to a business
value-based argument.
We've seen countless timeswhere tools have gotten in the
way of business value causingdeveloper delays.
Right?
(17:59):
Talking to the folks in ITtrying to drive an enterprise
consolidation.
I understand you're beingmeasured by the spend, but we
don't exist to have the cheapestIT.
We exist to have the bestproducts delivered as fast as
possible to meet the market.
How can I partner with you inIT to make the argument that
it's actually better for thebusiness to have multiple tools,
(18:23):
even if it has a slightlyhigher IT spend, if we're going
to make a lot more money fromit?
That's where organizations endup being pennywise and pound
foolish, optimizing their ITspend versus optimizing their
product flow.
Ray Arell (18:37):
Yeah, I agree with that.
I've seen that many a times incompanies when you actually sit
down with a spreadsheet and go,this is the lost productivity,
and this is what the dollar costis going to be for us by doing
that.
Yeah.
Let's see.
Luan?
Am I getting your name correct?
Speaker 03 (18:52):
Yes, there's Luan.
I wanted to have a clear, andlet me just pull out this
disclaimer.
I'm new to learning projectmanagement and agile.
This is my second time joiningone of your podcast series.
So thank you.
I wanted to ask a clarifyingquestion for the question on how
would you fix the tools overpeople problems?
(19:12):
Is it the preference of usingthe tools versus utilizing the
people?
Or is it people relying on thetools versus their people?
Ray Arell (19:25):
It comes down to where if you look at back in the
good old days, we used to dodaily stand-ups in front of a
Kanban board and everyone wassharing what they did yesterday
and having conversations in thatstand-up.
But that's gotten replaced witha tool where the stand-up might
not take place at all andpeople are just updating status
(19:48):
through the tool.
And the tool itself becomes themain communication to the rest
of the team.
Speaker 03 (19:58):
Which I'm thinking is getting in the way of the
engagement of the team, the dutyof working together.
And for agile or just it's ateam, you want that people
interaction.
Ray Arell (20:08):
Exactly.
If you look back at the agilevalues and principles, very
human-centric.
And if you think about the wayproblems get solved, as humans,
we all always get stuck.
Move forward faster.
And so the tool sometimes justgets in the way.
(20:29):
I spend more time updating mymy and I keep bashing Jira, I'm
sorry.
Rally.
We'll say rally this time.
Is Rally even around anymore?
But you just spend your dayupdating those things.
And that's not getting yourproduct out the door.
It's care and feeding of atool.
Speaker 03 (20:48):
Thank you.
Thank you for that.
Because I I wanted to approachthe question, but in the in a
because I have an idea of way toapproach this question, but I
just wanted to clarify just so Isee if my approach would be a
good way to approach it.
And the way I'm thinking iscombining the two.
Because I think both arevaluable.
People are valuable, tools arevaluable.
But with people, like you said,sometimes you just don't
(21:09):
understand something becauseit's blatant in front of you.
But when someone can explain itand articulate what it is, it
gives you a better, deeperunderstanding of how to even
utilize the tool or that thetools even benefit for you.
So like you said, the one tool,Jira, Jira, is that the name of
the tool?
Jira, yeah.
I don't know how to use it, butI've been listening to how you
guys have been explaining it.
(21:30):
And I think I got a sense ofit.
But if somebody was to explainthe update, I will be able to
connect the dots to know how Ican utilize that to bring
whatever part of the projectthat I'm working on, better
knowledge to it once we doactually meet in person.
But I think that's just amatter of setting those ground
rules before everything starts,letting people know I'm all for
(21:53):
using tools, but I want us tounderstand these tools so that
we can put the human element tothe tools as we utilize them.
That will be an approach that Iwould take for fixing that
problem.
It's just combining the twotogether.
Ray Arell (22:07):
And I think what you said about having that
meaningful discussion with theteam in the very beginning helps
because then they understandwhy the tool exists, why it's
there.
Speaker 03 (22:16):
Exactly.
And how it benefits the projector the task or whatever it is.
Because some people I thinkit's like, why are you even
using that tool?
Now you're actually expandingsomebody's knowledge on the way
to use it for something.
I know I've stumbled acrossthings like that.
Even listening to everything.
And like I said, I'm still newto this and trying to learn it.
I would use it even outside ofa project that will be agile.
It's something that I could useit for keeping track purposes
(22:37):
for just myself, or just beingable to have the experience of
even utilizing the tool when Ido need it for what it's used
for.
I already have the experienceto be able to do it.
And that's the way I wouldapproach it.
unknown (22:48):
Shh.
Ray Arell (22:49):
Yeah, and that's the reason why I use Trello.
I love Kanban boards.
As much as I've used the papertools, I just find that I have
it everywhere.
I can reference it.
We all have our preferences.
unknown (23:03):
Yeah, exactly.
Yeah.
Ray Arell (23:04):
And if it improves me, it can definitely improve
the team.
And by you using it, it alsoinfluences others to potentially
use it as well.
Thank you for your comments.
I appreciate it.
Diana Welcome back.
Diana (23:17):
My experience, I don't work directly with delivery
teams anymore.
And so my experiences with thetools of actually being a person
who is using the tool issomewhat limited.
On the other hand, I often getinvited to observe how people
are using their tool.
(23:39):
And one of the things I findmyself saying a lot is wait a
minute, folks, you get to usethe tool.
The tool doesn't get to useyou.
I see that happening often whenthere's an on-site expert in
the tool or whatever thatthey're just not being accessed
enough, or they don't have maybeenough bandwidth to come around
(24:02):
and talk to all the teams.
But in one specific instance, Iwas asked to sit in on all the
boundary meetings of a team.
It was a very large team, wellover 20 people.
And they they were doing theirreview and their retrospective
and their planning, and theywanted my feedback.
When we got into the planning,most of the people were in one
(24:27):
location, but a bunch of thepeople were in a couple other
locations.
And when they got to theplanning, they popped open their
JIRA tools, and there were 218items on the backlog.
All you could see in the field,because the description was
longer than the field wouldaccommodate, was as an engineer,
(24:49):
I want.
So they had to go through andopen up every single one of
those 218 to do any prioritizingor any understanding of what is
actually on this list or thosekinds, and that was the tool
using them.
That somebody had told them,oh, just write what you want,
(25:12):
without really telling them howto write a story problem or a
task problem.
They had grabbed the connextraformat and run with it in a way
that didn't really work forthem.
One of the things I alwaysrecommend is if there is an
(25:37):
on-site expert in the tool,given the responsibility of
really understanding this tooland then explaining it to people
and helping them set it up in away that works for them, make
sure you're accessing thatperson.
Make sure that you are gettingthe whole thing set up in a way
that is actually going to workwell for you.
And in this instance, 218items, there was it's going to
(26:04):
be very difficult to fix becauseevery single one of those,
whether it was high priority ornot, was going to have to be
looked at and going to have tobe rewritten in a way that
expressed it so that you got thenugget, the essential element
of it in the field that wherepeople could see why that was
(26:25):
why it was there and what it wastrying to accomplish for the
team.
And it's those kinds of thingsthat they had another tool that
they used that presumably was aretrospective tool that didn't
encourage them at all to get toactually improvement actions.
It encouraged them to makelists of what they thought went
(26:49):
in the last sprint and what theythought they could have done
differently or should have donedifferently in the last sprint,
but nothing about what they wereactually going to tackle and
agree that they needed to changeand do differently.
Or anything about what they hadlearned during that sprint.
I'm not completely opposed tothe single question or the three
(27:13):
question list retrospective.
I think it's not the best wayto go, but I know people who get
value from that.
It's got to lead you to thatplace where you are making
improvements or deciding thatwhat the most important thing to
do that time was to have a teamconversation about some topic
so that you could digest it overthe next front and then come
(27:36):
back to it.
Or whatever that action is, thetool needs to facilitate you
getting to that action.
And if it doesn't do that, it'snot a good tool.
It's just letting you makelists that you go, huh?
Look at that and move on.
This is particularly a problemwhen an organization is not
(27:56):
providing the teams with adedicated uh scrum master or
tech lead whose job it is tomake sure that the boundary
meetings happen.
And but and what they do isthey conflate that with that
person is also the productowner, or that person is also
(28:20):
has another role.
And so the their competingroles get in the way of those
meetings, staying focused onwhat the team needs to improve
and what's possible for them.
So that's been my frustrationwith a lot of the tools.
And now with AI, which AI agentare you using and what's its
(28:45):
sweet spot?
Because I see people choosingAI tools to do a thing that it's
not really meant to do.
Like to be creative, the onethat you choose is better suited
to helping you do research,finding out what's already
known, not putting thingstogether to discover some new
(29:05):
possibility.
And knowing what the tool iscapable of, what its limits are,
its limits may be very useful.
You may say the fact that itdoes this is a really good
thing.
And you might want to use it insome cases, but you need to
know which cases you aren'tgoing to use it in as well.
A lot of what I see is peoplegetting tools without really
(29:29):
understanding why they havethem, how they work, getting
support and making them work aswell as they possibly can.
Ray Arell (29:38):
Love all of that.
And I've seen the same problem,by the way, just the write only
memory systems where peoplethrow in their data and you know
what?
It's never used.
And that's that is really bad.
Thank you.
Dylan, how are you doing today?
Dylan (29:52):
I'm doing well.
Thank you very much.
I've been looking forward tothis conversation and it is not
disappointing at all.
So glad.
To be here.
Ray Arell (30:01):
I'm glad you made the time for it.
Dylan (30:05):
So many thoughts, Dan.
My brain was exploding whileyou were talking.
One central thing I've reallybeen thinking about is that when
it comes to teams or companiesor individuals choosing the
tools they use, this is actuallya really great time to lean
hard on a product mindset, aproduct operating model, but
(30:28):
flipping the perspective andfrom the customer's perspective,
really take the time to talkabout what problems you want to
solve with any given tool andwhy those problems are
important.
Dig with additional questionspatiently and curiously to get
down to the essence of what isthe most important value these
(30:51):
tools can deliver to us.
And then choose your tool,experiment with it, move
forward, and rinse and repeat.
What people have a hard timedoing is taking the time to have
those conversations.
However, the efficiencies youcan gain and the amount of
frustration and resentment thatyou can avoid from the employees
(31:13):
by taking that time tocontinuously make sure is this
tool solving the most importantproblems that we want to solve
goes a long way.
So that's a way that I like toframe it up in some of these
conversations.
Ray Arell (31:30):
I like that approach.
And it does go a long way.
Sheila?
Sheila (31:35):
I was just making my list of things nobody'd
mentioned.
I think it's interesting thatwe're focused on Jira and tools
like that.
JIRA started as a bug trackerand it shows.
So you're automatically forcedinto a certain perspective when
you start by using a bug trackerto track everything.
(31:56):
And it's not necessarily theright place to be.
In organizations where I'veworked, a lot of the time you
have the project or the productrolling up to the portfolio.
And whether you're looking atit from a product management
portfolio or a projectmanagement or a value
(32:18):
management, ties into theaccounting systems.
So it's worse than I alwaystalk about big enterprise level
projects as being like turning abattleship if you need to
change something.
When they tie all these thingstogether and automate it, which
a lot of companies do more andmore of, and they think they can
get information that's usablefrom the system without having
(32:42):
to consult people.
And that information will bereliable for making future
management decisions.
It gets to where you can'treally change it.
And the product people, itdepends also on who is really in
charge.
I've worked in insurancecompanies where most of the
people at the very top startedout as agents, for instance.
(33:05):
That gives a certainperspective.
And I think in a lot of ways,senior management thinks that
Agile is just a bunch of newjargon.
Unless they've really learnedAgile, they don't understand how
it's different than waterfall,except in the way things are
organized.
They don't understand themindset.
(33:26):
They don't understand whythey're losing some value by
relying so heavily on thesetools.
And I don't think it's a simpleproblem to solve because there
are some efficiencies of scalein using these tools.
But then you're limited bywhatever the limitations of the
tool are.
And I don't have any goodanswers.
(33:46):
That's not great, but this iswhere we are.
Ray Arell (33:50):
Yeah, no, and the interconnectedness is again,
most systems are they seem to beeasy to install, but very hard
to get rid of.
I used to say, don't fall inlove with your tools because
there's going to be a new onethat's going to show up.
The corporation's going to gosettle and say, okay, we're now
using X.
And I also said that they havethe life expectancy of a good
(34:12):
dog.
We're going to we're going toget it replaced.
But in the same regards, it'sit just is really unfortunate
that if you just pulled the plugfor one week, who notices?
Sheila (34:23):
I had a friend who worked in brokerage.
Every once in a while they'dturn off systems and see if
anybody noticed.
And a lot of times they didn't.
Ray Arell (34:30):
Yeah.
That's something it'sinteresting as an experiment.
Just shut it off for a week andsee what people do.
Karen, you had your hand up.
What's up?
Speaker 02 (34:40):
Okay.
Being a consultant, it justseems it's like you're taking a
little kid and showing themthere's a two-wheel bike and
just telling them, okay, justget on and try to ride this
bike.
When that the kid falls over,it seems the sequence is counter
to what Diana shared, to use atool, wait for problems, and
(35:02):
then address.
So my question is what is thepre-work that would help
establish the correct balance,the mindset, the purpose to
avoid all the pitfalls?
It's why start a tool withoutgiving it the understanding and
(35:24):
limitations that the team needsto understand.
It's okay, now we're in thequicksand.
How do I get out?
You know what I mean?
Ray Arell (35:34):
I I do, and I think that's when we lose sight on the
fact that could we get awaywith distributing a product to
our customer and not teachingthem how to use it?
Could we get away with that?
Speaker 02 (35:48):
Has anyone done that and work with them as far as
the mindset of you to use thistool and how to establish the
expansion of use in application?
Ray Arell (36:05):
As a person who goes out and trains people with
agile, I know that thediscussion typically starts with
let's go learn the values andprinciples first, and then we
ease into tools.
The tool discussion isn't dayone.
We want to first do it manuallyso you can see it operate.
And I agree with you on thefact that most people are not
(36:29):
taking that step.
And they're just there was your10 minutes of training.
Bye.
Speaker 02 (36:36):
It just seems it's like the same problems in a
different context over and overagain.
Ray Arell (36:43):
I think the total cost of ownership of something
is never really looked at.
And loss of productivityspecifically, when the tool
becomes the impediment, meaningwe're spending too much time in
this.
And I think it's back toDiane's question about her
comment about retrospectivesbeing done well.
Nobody's flagging it as anissue, or they're flagging it as
(37:04):
an issue and then taking noactions.
And last thing is probablynever roll out a tool where it's
like everyone's, we're gonna doit all at one time.
We pilot.
We want to make sure that it'sthe right choice, if that makes
sense.
Speaker 02 (37:21):
What is the approach to look at the total cost of
ownership?
Ray Arell (37:29):
I think it goes in where it's not just the
deployment of the tool, but it'salso the training costs and
other things that need to be uhincluded into it.
And then there's a refreshcycle that occurs because you
always have new people coming inand out.
Yori, you put your hand up.
Did you have something to addto this?
Jörg (37:47):
For me, this goes way before my first contact with
Agile because we were forced byour customers to use a certain
requirements management tool.
It was either do it or losetheir business.
And that was pretty simple.
So the question we started.
What is in it for us?
And we started with the why.
Because we were lucky to haveenough money to ask for a
(38:10):
consultant to teach us the toolbecause we wouldn't want to
screw up in front of thecustomer.
Very simple.
If you don't know what you wantto do with it, don't use it.
Find out what you want to dowith it first.
If you just try the demo, youwill learn a process that is
total crap but looks great inthe tool.
And you will never unlearn thatprocess again.
And he was totally right.
(38:32):
I think seven guys who reallylater on used the tool, he made
all the things going.
One guy installed the earlyversion, he never grappled with
the process that was muchslimmer, much more effective,
went through all the audits anddelivered what we needed.
But as soon as you're blindedto a tool telling you what to
do, it's really hard to unseethis thing.
(38:53):
And that is my main learning.
Most people hope that a problemis solved by a tool that they
can't name and that they justfeel as a burden.
You can probably relate tothis.
I'm dyslexic, so obviously Iwant typos just to go away.
Whatever you use, that doesn'thappen.
Never fully.
So you you just have to arrangeyourself with it and really
(39:16):
know which kind of investment isworth doing it.
And I think that is always thequestion for the tools.
What's the real benefit youwant to have from it?
And then you can have greattools and great use.
One of the tools I immenselylove is a blue plush elephant.
Just a little toy I bring intomeetings, because that's the
(39:38):
elephant in the room.
I can throw it at anybody who'sjust stepping around things.
And because it's smiling andpositive, I can get a
conversation started that Ican't get to in another way.
And that is one of the tools Ilove because I know what it's
going to give me.
I think that is very important.
Understand what is the benefityou expect from the tool and do
(40:00):
early verifications if thatbenefit really arrives.
If it doesn't, either you'reusing the tool wrong, the tool
is wrong, or if your expectationis not achievable, which is
quite probable as well.
You need to make the tooldecision irreversible.
You need to be allowed to dropthat tool again.
And don't expect a screwdriverto tell you how to build a bed,
(40:23):
because there's much more neededthan that.
Speaker 02 (40:27):
So you said you were forced by your customers to use
a certain requirementsmanagement tool.
I'm just curious, what was theprocess between them saying, we
want you to use this tool andyou starting to use it?
How you found this tool to beproductive and valuable?
Jörg (40:47):
Yeah, we had that conversation in a workshop and
we said, what is it that we arelacking?
We are lacking the informationif you really have everything
complete at the end of theproject, if you didn't the right
tests at the end of the projectand we need to prove that to
the customer and then match itto what they wanted, did we
address everything of that?
In the end, the engineers toldus that they wanted much more
detail to be documented becauseit helped them prevent
(41:10):
misunderstandings andcontradictions.
But then that came much later.
And with that in mind, we knewall we needed to do is what's
really needed in terms of therequirement, who's gonna do it,
is it done?
How is it tested?
Is it in review?
Is we don't mind if the rightthing is written and everybody
confirms we tested it, how thereview process is, whether the
(41:34):
wording is right, that wasn'tour purpose.
Is the detail right?
Do we need to check that thereare at least 100 words?
No, we don't.
It's much easier to add abenefit that you see than to
take an overhead away that youhave gotten used to.
Ray Arell (41:49):
Thank you for that.
Let's see.
We've got a few other handsthat are up.
Let's see if we can get youguys through before we hit the
top of the hour.
Z, what do you have?
Speaker 09 (41:59):
So I just want to make a comment.
I think somewhere along theway, we started worshiping uh
tools and not paying.
I see that where I am.
And I think we forget thatScrum is people powered.
So when the process in thetools are louder, then the
people, it's time to turn downthe volume on those days.
No tool will replace the magicthat happens when smart,
(42:19):
passionate people sit down andtalk.
And yeah, the dashboards justdon't deliver the same value as
people.
So I really enjoyed hearingeverybody.
Ray Arell (42:28):
Yeah, I agree with uh everyone.
We had a really livelyconversation today.
I want to thank everyone fortheir participation.
It turned out to be a liveliertopic than I was expecting,
which is typically most of thetime when we get together, that
turns out to be the case.
Just as a reminder, our nextlive event is going to be in
October, October 24th on aFriday.
(42:50):
Always on a Friday.
Also, if you can go up toACNacnpodcast.org, please go up
there and hit the donate button.
We could use the dollars to payfor the webinar system and all
those things.
Those are coming due.
I thank all of my co-hosts.
I couldn't do it without all ofyou, and thank you for your
time on this lovely Friday.
(43:11):
I hope you have a wonderfulmonth.
The ACN Podcast is foreducational and informative use
only.
If you'd like to know moreabout the ACN community, please
come up to ACN Podcast.org andsupport our show.
Popular Podcasts
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com
The Joe Rogan Experience
The official podcast of comedian Joe Rogan.