Welcome to Pragmatic.
Pragmatic is a discussion show contemplating the practical application of technology. By
exploring the real-world trade-offs, we look at how great ideas are transformed into products
and services that can change our lives. Nothing is as simple as it seems.
This episode is brought to you by Clubhouse, the first project management platform for
software development that brings everyone on every team together to build better products.
Visit this URL clubhouse or one word dot IO slash TEN the word for more information. We'll
talk more about them during the show. Pragmatic is part of the Engineered Network to support
our shows including this one. Head over to our Patreon page and for other great shows
visit engineered.network today. I'm your host John Chidjy and I'm joined today by Casey
Liss. How you doing Casey?
Hello. How are you sir?
Very well. Very well. Thanks for coming on the show. It's been a little while since we've
had a chat?
Yeah, the last time was slightly antagonistic because I was explaining to you why metric
units are silly, and at least I believe that was the last time.
Yes, well, I just love the way you phrased that, and that was not exactly my recollection,
but you know what, yes, listeners, if you'd like to go back in here.
I poke fun because I laugh.
No, just before you get a million emails, "Imperial units are dumb with the exception
of Fahrenheit."
defend Fahrenheit until my dying breath, but everything else that we do in America is silly.
So we can just move on as quickly as possible.
And on that point, by the way, because I actually agree with that and I have occasionally referred
to temperature in Fahrenheit to my family and they look at me funny and I just smile.
So never mind that.
But today we're not talking about Fahrenheit.
We're going to talk about, I would like to talk about something else, something that
has more recently come into my professional life and something that I think that you've
been enjoying/dealing with for probably longer than your career.
That's very accurate, very well put.
So yeah, and that's Agile software development.
You ready for this?
Yeah, yeah, let's do it.
Okay, so I just want to start at just roughly a little bit of a history and timeline of
Agile, not to go into too much depth, but during the 90s, I think a lot of people in
in the software space in particular sort of said,
well, we need to look at some way
of doing development differently
'cause software is different, software is special.
So we're gonna try some different things.
And so in the '90s,
there was this rapid sort of series of ideas
every few years.
And one of the first one that I could find
that it was tangentially related to Agile
was something called Rapid Application Development or RAD.
Not one I personally came across,
nor was the next one, the Unified Process in '94.
I'm not sure, did you ever come across either of those?
- I've heard of them, but I can't say I've ever practiced,
or knowingly practiced either,
but I've certainly heard of them, yeah.
- Yeah, so this is the thing is that I sort of,
I was aware of them, but it wasn't until Agile
that some of their methodology sort of became,
oh, okay, so that's what everyone now calls Agile.
So the next one was Dynamic Systems Development Method,
or DSDM.
Apparently that was quite popular, apparently.
I actually had never heard of it
until I was doing the research.
But this is the one everyone does know in 95 and that's Scrum.
So, yeah, we're going to get to that.
And then 96 was extreme programming.
And that's where I started to write.
Yes. Okay.
I came across extreme programming and then 97 feature driven development, which when,
when I said that was a programming methodology that came up in 97, I thought that's,
isn't that the way it was always done?
But no, apparently there was a specific.
Anyway, whatever.
So bottom line is all of these rolled up
and certain elements of them in 2000 or 2001.
So the story goes, apparently 17 developers
and there was a list of names, I'm not gonna read them,
but anyway, they went to somewhere in Utah,
again, not too concerned where, but it was in Utah.
And they came back with a manifesto
for agile software development.
And that's more or less where the whole term agile
came from and a lot of things being attributed to agile
over the last, over the 10 years since then,
in that decade, led this group,
they call themselves the Agile Alliance.
And in 2011, they published the Guide to Agile Practices,
just like a reference book of sorts.
There's a link in the show notes
if you're really keen and interested.
I actually find, because, yeah, in my,
as I'm trying to ramp up my understanding and knowledge
of what the heck Agile is,
I've actually found that site to be very, very helpful
because people will fire off some term
and I'll be like, what?
And they're like, oh, that's agile.
So I'm like, oh, okay, great.
So I have a look in this, oh yeah, right.
Okay, that's what that means, okay.
So I'm kind of glad they did that.
And to be honest, in my personal experience then,
I'm an electrical engineer,
I do control system software development,
but the funny thing, I say funny,
well, the thing is that in engineering in my space,
it's taken a bit more time to sort of encroach upon our area of development.
And it has in the last probably two to two and a half years.
And that's just been the company that I've worked in has had some, shall we say, consultants
of whatever, and they're from some of them have had extensive experience in Silicon Valley.
And so several things came over with them when they came over to consult and Agile was
one of them.
to the point at which our entire organization is now embracing agile, which is in fact one
of our, I don't know what you call them, tenants or whatever else. It's one of those mottos
that they go on and talk about regularly, embrace agile. So, can you tell me a little
bit about your history with agile at all, Casey?
Yeah. So, most of my development career, pretty much everything I did up until my very last
regular job was doing consulting. So it was either government contracting, which is kind
of a corollary to consulting. It's consulting, but it isn't. Or just regular straight up
consulting. And so what that means is a company, Acme Widgets Incorporated, comes to my company
and says, "Hey, we have this software that we need written custom for us. Can you provide
us a team to do it. And so I was doing project-based consulting where it was a team of myself and
my coworkers would get embedded with a team of the clients and we would work as one unified
team to create a bit of software. And typically that meant that there were either no developers
on the client side or just one or two. And generally speaking, there would be a product
owner, which we'll probably end up talking about later, on the client side that's kind
of directing things and making decisions, but for the most part, it was just myself
and my coworkers doing all the work.
And that was most of my career.
I definitely, especially in the government contracting, which was very early on in my
career, we had something, we definitely worked more in a waterfall method.
So the two kind of poster children for the two generally accepted ways of doing software
development that are not that radical, one of which is waterfall, which basically my
summary and I'll let you correct me John is let's figure out as much as we
possibly can up front so writing the software when we finally get to that
point it's almost paint by numbers you know it's as much as possible has
already been figured out all of the all of the weird edge cases have been
figured out all of the decisions have been made and by the time you're
starting to write software if everything goes according to plan then there there
are no questions left to be answered you just have to write the code is that kind
of a fair summary? Yeah, I think so. And I definitely do think that it's those are the
comparison with Agile that people most regularly make is Waterfall is what it's Agile versus
Waterfall. And the funny thing I always thought about Waterfall is back when we were doing
engineering development, we didn't actually call it Waterfall, we just called it like,
you know, programming. So I don't think it's exactly quite as clear cut as a retronym or
or something like that. - Sure.
- But I do think that it was just something that,
yes, that's what it was called,
but no one talked about it like that.
But since Agile came around, yeah.
And I think your description of waterfall is pretty accurate.
The way I describe it is you've got
extensive requirements definitions,
you do a detailed design,
development or implementation comes next,
then you do your verification and tests,
and then you hand over and maintain.
And that's kind of the waterfall methodology.
Whereas Agile's not designed quite like that.
It's more about- - No, not at all.
- No, and I always,
and so this is my turn to have a stab at Agile.
So tell me how it goes.
That requirements are essentially whittled down
into very small deliverable components
and documentations generally very light,
then development and tests are part of each iteration
and with each idea and each iteration
is a single usable component.
And then the result of that is used
to inform the next iteration,
whereby the requirements can change along the way
based on each iteration can actually
impact the final direction, rather than having
a complete set of detailed requirements up front.
- Yeah, yeah, I think that's exactly right.
So the idea is in Waterfall,
you're not actually writing any code
until pretty much all the decisions have been made.
And again, there's gray areas in everything we're saying,
but the generally accepted version of Waterfall
is let's figure out all our requirements,
let's figure out how we're gonna test it,
and then let's write the code, and then let's test it,
and just like you said, then let's deliver it.
Whereas with Agile, the idea is,
hey, we may not even know exactly what we want.
And the only way we're really gonna figure out
what we want is to start using the thing, the widget.
And so let's break off, just like you said, John,
let's break off a small piece of this widget
that we really need to get done and let's try it
and let's see how it goes.
And then based on how this small component of the widget is,
then we can either continue down the same path
we had before, or we can pretty violently swing,
you know, left, right, up or down,
and make different decisions now that we've actually had a
chance to use that widget.
So the idea is that you are constantly delivering something
of value, and you're constantly changing your direction based
on those deliverables.
You could say, John, that you're acting in an agile
manner, and hence the name.
And so if you look at the manifesto for Agile software
development that you had brought up earlier, I think
there's a small portion that is worth reading verbatim.
And this is from the original 12 or 15 or whatever authors.
And it says, "Blah, blah, blah, blah, blah.
Through this work, we have come to value individuals and interactions over processes
and tools, working software over comprehensive documentation, customer collaboration
over contract negotiation, and responding to change over following a plan."
And then it continues, "That is, while there is value in the items on the right,
which is processes and tools, comprehensive documentation, contract negotiation,
following a plan, we value the items on the left more.
individuals and interactions, working software, customer
collaboration, and responding to change. So my understanding of
the history of agile, and the spirit of agile was, in summary,
let's put a team together, let them figure out their own team
norms, you know, let's let them figure out how they want to work
and just start working and then change if something isn't
working. And that's basically it. Now, what's ended up
happening, though, is because business and because big
business, there has become a kind of accepted series of steps and rules and processes in
order to do what is "agile."
As you were saying earlier, John, I think what's kind of unfortunate about agile and
waterfall actually is that they've kind of become these all-encompassing terms that are
basically distilled to, "Do you figure it out in the beginning and then write code,
or do you write code and figure it out as you go along?"
kind of the big difference if you were to distill it as much as possible.
And so I really like Agile and I've seen it work really, really, really well, but
I've also seen it work really poorly.
And unfortunately, in my experience, it is way more likely that you will have a
poor implementation, for lack of a better word, of Agile than you will a successful
one.
And certainly whenever you're ready, we can start talking about what I see is the
differences between the two and my recommendations for them.
But I think that the crummy thing about Agile is that I
really do believe in the spirit of what it's trying to
accomplish.
And I even believe in the kind of prescriptive way that most
companies, at least here in the States, tend to do it.
But all too often, it gets twisted up and mutated into
something that will also often derisively
be called scrummer fall.
So scrum is a generally accepted component of Agile,
which we'll get to in a minute.
And then waterfalls exactly what we described.
And so what ends up happening is you kind of end up with waterfall
where you get together for a 15 minute meeting every day to talk about how things are going.
But everything else is waterfall.
And that's not really agile at all.
And that's a trap that's easy to fall into.
Oh, for sure.
Absolutely.
And it's one of those things that I've observed as well is that if you were to adhere more strictly to the whole intent of agile, then,
I guess ultimately organizations, the whole thing that you said about how people get together
and figure out how it works as they go, kind of thing is it's sort of a bit fraught with
danger because sometimes you can sort of get off on totally different tangents, typically
have different ideas about how it should work or shouldn't work.
It's interesting and they have this idea of an agile coach and a lot of teams have an
an agile coach to try and prevent some of that stuff,
which is another interesting role, but nevermind,
I'll talk about my experiences of that a little bit later on.
But so I guess from my take then is the ultimate aim
of Waterfall is to ensure that you have well-documented,
detailed requirements up front, agreed and understood.
And you accept the fact that detailed design
is gonna take a significant amount of effort up front.
But the ultimate aim is that if you design it right
with the correct objectives from the very beginning,
then you only need to do one implementation
and that will avoid scope creep and it'll avoid rework.
That's the theory, anyhow.
Agile, on the other hand,
aims to ensure that you just keep those requirements
to a bare minimum set
to make something that a customer could see or use
that they can agree quickly.
And then rather than document it to death,
you just iterate a small step at a time
until you've got a happy customer with that outcome.
And you just keep doing that
until you reach something where they're like,
"Yep, we're done."
That was another way I think of sort of like spinning it.
But another way of thinking about it is predictive
versus sort of adaptive whereby Agile is intended
to be more like an adaptive sort of a technique
with a much looser change control
when you can adjust direction as it develops.
Whereas predictive,
which is more like the waterfall approach
is more about you have strict change control.
And if you wanna actually change scope
and change your requirements and such,
you have very strict rules around actually ensuring
that doesn't happen unless it's costed, funded and so on to reduce the scope creep that would
otherwise affect your deliverable deadline.
In any case, whichever way you want to think about it between Agile and Waterfall, it always
comes back to the customer because in the end, the customer or the owner, the fact is
that the people do change their minds irrespective of what model you want to use.
As we do do iterations, people learn things as they go and they feedback that back into
whatever project you're working on.
And the other problem is of course,
that as time progresses,
that can change requirements as well.
So, you know, markets change, you know,
so suddenly we've been spending six months
developing something for a certain purpose,
though that's no longer required anymore
because some other technology in the marketplace
has completely and utterly made that,
you know, no longer relevant.
So I guess my thing is with,
my take on Agile, generally speaking,
is that it was born out of that fast paced sector,
and I don't wanna say that all development is like this
'cause it isn't, but I think it's come more
from the fact that it's like maybe a Silicon Valley
sort of VC backed, maybe a bit web centric
or consumer software areas,
where there's a lot of movement in the market
and to be relevant and successful, you have to be agile,
or otherwise you get left behind, I think.
And I think that seems to have been where
the whole idea was really born and is driven from.
Yeah, and I think what you said a moment ago about, you know, the customer or the product
owner will change their minds.
I think that's kind of the critical piece here is that inevitably the person you're
delivering software for or persons you're delivering software for, they're going to
make a change or decide that they want to go left instead of right.
And what Agile is about is embracing that change and trying to uncover that change
as quickly as you possibly can.
So the idea behind Agile is let's just do little pieces at a time and let's see what
happens.
So the times that I've seen Agile work really well is when we have short sprints, which
is to say for usually about two weeks, we will bite off a chunk of work and say, "Okay,
we are dedicating ourselves to complete this work in two weeks."
And generally speaking, the chunk of work you bite off, which we'll get to in a minute,
with story points and things like that.
The chunk of work you bite off,
that may not be that much because it's typically better
to underestimate your own speed than overestimate.
And every developer I've ever met
always thinks it will go easier than it ends up going.
So, the idea is each developer
and the other members of the team
will bite off some chunk of work
that is pretty clearly deliverable within a two week
or whatever your sprint length is,
but typically it's two week timeframe.
And then the idea is you work, work, work, work, work,
get through those two weeks,
and hopefully at the end of those two weeks,
you have something tangible to deliver to the customer,
or at least demo to the customer.
And then the customer or the product owner can say,
"Oh, I like this, I don't like that,
"I like this, I don't like that."
And that will inform what the next two weeks,
the next sprint will be.
And generally speaking,
there's some ceremony around that.
You'll typically at the end of each sprint,
you'll have a retrospective,
which is a meeting wherein you say,
"Okay, this is what did work,
this is what didn't work. Let's change this. Let's change that. Typically, you'll have planning at
the beginning of the sprint where you'll figure out, okay, you'll do estimation and figure out,
okay, how much time do we think each of, well, I shouldn't say that. How many points do I think
each of these things will take? And again, we'll get to that in just a second. And then we'll
figure out, okay, well, John, you'll do this story. Casey will do this story. Susan will do
that story. And Jennifer will do this story and so on and so forth. And then we'll just kind of go
into our corners, if you will, and work, work, work, work, work until the end of the sprint.
Now, what I've seen go terribly wrong, and I've already made that mistake myself, is
where you judge effort based on time rather than relative difficulty.
So there's no real prescription, if you look at the manifesto, for how you manage what
work you're doing and when you're doing it.
But the generally accepted way of doing Agile, at least in my experience, is you use something
called stories and story points.
So a story is an executable thing.
And oftentimes it'll be written in the form of, as a, some kind of user, I
would like to do something in order to accomplish something.
So as a user, I would like to register for the service so I can use it as an example.
So it's clear who is interested in this, what the persona is, what it is they
want to do and why they want to do it.
And that would be your story.
And of course, there's other requirements and things and whatnots and addendums
that may be involved in that.
But at its core, a story is as a user, I would like to register
for the service so I can use it.
Then what you do is during the planning period or planning meeting or what have
you, and sometimes it's called grooming, you'll see very different names for this
that serve ever so slightly different purposes, but the idea is sometime before
the sprint begins, you and your team will get together and figure out, okay, how
difficult is this to accomplish?
How difficult is it to allow a user to register for this service?
And the idea is you want to use relative difficulty.
So you don't say this'll take me eight hours because it never takes eight hours.
It either takes two hours or 40 hours.
So don't describe it in terms of hours.
Just describe it in terms of how hard is this.
And sometimes you'll use what I've often heard called t-shirt sizing.
So you'll either say it's small difficulty, medium difficulty, or large
difficulty, and that's as granular as you need to get.
Occasionally you'll see that, but more often than not, you'll use story points,
which is a Fibonacci, is that right?
A Fibonacci sequence of, oh God, it's been a while since we've done it now.
So one, two, three, five, eight.
No, that's not right.
One, two, three, is it right?
Something like that.
I, I, yeah, but yes, Fibonacci indeed.
Yes.
That.
I'm a little out of practice cause I haven't done it in a few months, but,
But you get the idea.
And so the idea is, okay, what is the smallest tangible change that we can make?
And let's call that one.
So maybe it's changing a color on a web page.
Maybe it's changing copy on a web page.
Or maybe it's moving a button on an iOS app or something like that.
What is the smallest piece of work that we can all agree upon?
Everyone in the team.
Let's call that one point.
Okay, well with that in mind, with changing the background color of a web page being one,
is allowing a user to register for the site, is that twice as hard?
That would be a two.
Three times as hard?
Well, guess what?
You've got a three.
Is it five times as hard?
Well, now you've got a five.
Maybe it's eight times as hard.
Now you've got an eight.
And this continues on to 16 and whatever else comes after.
But generally speaking, in my experience, if you find something that is more than eight
times more difficult than whatever you think a one is, then it's probably
too complex to be one story and you probably want to break it down into,
you know, kind of subordinate or child stories.
But I don't come into a point here.
I promise.
The idea is each of these stories, you will, as a team, you will figure out,
okay, this story is one point that's six, or six isn't an option, five
points, that's eight points, and you will kind of figure out, okay, what
is the relative difficulty of each of these stories?
Yeah.
And for the first sprint or two, you just kind of bite off some
arbitrary amount of points as a team.
So maybe as a team, you think, thumb in the air, we'll do 20 points this sprint.
And maybe you accomplish 15.
And so the next sprint, you'd maybe bite off 18 because you think that
first sprint was a little weird.
And maybe the second sprint you accomplish 14.
Well, after you get a couple sprints under your belt, you start to figure
out that no matter how optimistic or pessimistic this team is, history
tells us this is how many points we can accomplish.
And this is where agile gets to be magical because you now have a
history and unemotional, it has nothing to do with estimates.
It's just a history of how much work this team can get done.
Well, now if you keep your estimation of story points, pretty
consistent across sprints, now, you know how to plan because you know
that your, it's not cadence.
What's the word I'm looking for?
Velocity.
Your velocity is 15 points, and I'm making that up, of course.
Well, you know that this team tends to be able to do 15 points per sprint.
And we have a backlog, we have a list of stories that's 300 points long.
I'm not going to do that mental math because I'm too lazy, but you know
that that will take X amount of sprints to get through those 300 points.
And suddenly you've gotten a very predictable outcome in terms of real
world time, even though at no point during the Agile process
have you said anything about how many hours this is going to
take. And this is quite the contrary for many waterfall
implementations where you'll say, okay, that unit of work is
16 hours, that unit of work, at least the way I've done it, is
24 hours, etc, etc. But inevitably, like I said earlier,
no matter how many hours you think something is, you're going
to be wrong. So the key is, screw talking about time, let's
just talk about relative difficulty. And again, don't
Don't trust what your developers think because we're all idiots.
None of us, I mean, I'm sorry, John, but I'm going to lump you in there.
None of us can estimate worth a darn.
So let's just say how hard is this and about how much work is it, have we demonstrated
we can accomplish?
And then that's where it becomes so great because now it becomes predictable.
I've been talking for a long time.
Does that make any darn sense at all?
The scary thing is that all of that makes perfect sense.
And the interesting thing and okay, so you covered a lot of ground there.
So let's just go back a couple of steps or points.
Anyhow, that wasn't funny.
Sorry.
Sorry, delete reaction on that one.
That's all good.
Anyhow, so all right.
So on the story points, with the velocity, just before I get stuck into my little rant
is did they ever do different teams and have different KPIs for their velocities?
Then they sort of play them off against each other.
this team's doing this falsely, this team's doing it.
Did I ever do that to you?
- Yeah, occasionally.
So a KPI is Key Performance Indicator.
And a lot of that's very trendy these days,
that all of your work as a developer, as a product owner,
as a designer, as a QA engineer,
should be at what am I doing to affect
the key performance indicator, whatever that may be.
And yeah, that's the problem,
is that if you really do Agile right,
every individual Agile team
could have a wildly different velocity.
So as an example,
maybe John and I think everything is impossible.
And so all of our estimates are like 8 points, 16 points, you know, 24 or whatever points.
Sure.
That, I wouldn't advise that, but that's okay because as long as we're consistently
overestimating, then it's fine.
But you can't take our estimates, John and Maya's estimates, and compare it to
Jennifer and Susan's estimates because they might be actually quite a bit better
at estimating where a one is really a one and eight is really an eight and so on and so forth.
forth so yeah playing playing teams off each other is a terrible terrible terrible idea.
Yeah and that's why people do it generally because it's a terrible idea. I just you know it's just
it's it's just something with me that I find very grating it's like no no no sooner had I learned
what story points were did I find out that there were different teams already being graded against
how much they could get through in terms of points I'm like seriously guys anyway all right not
Not wishing to go down that road too much,
but in any case, the thing that I find interesting
about Agile versus Waterfall is that the way in which
the points and the collaboration,
the collaborative nature, I guess you'd say,
before the sprints actually kick off,
you know, you actually get into them.
Yeah, that whole discussion is, it's more collaborative
and that has both positives and negatives.
In Waterfall, the way it's been previously done,
is my observation, is that it'll go to
whoever the senior designer is or the senior developer is.
And they'll be told, okay,
well, how long is it gonna take this?
And they'll draw based on their knowledge
of the individuals involved,
throw in some fudge factors for how long,
how many interruptions they think they're gonna get
with other activities,
other calls on other people's time during,
'cause if you're outside of a sprint,
you've got all sorts of distractions and so on,
and you have to account for that in your time estimate.
So, the old rule thumb was,
if you have a long you think it is double it and add some.
- Yup.
- And yeah, exactly right.
And so you start building out that schedule
all based on experience, based on,
rather than a prescriptive,
like this team can produce X amount of points
in this amount of time, generally speaking,
based on previous cycles and such.
With Waterfall, it's all,
most of it seems to come down to a negotiation.
And the problem, this is the next part,
is in negotiation, when schedule,
because you're dealing with time,
you will often be butted up against a project manager
and the project manager is gonna say,
"Wow, could you shave a few weeks off that?
Could you please, that'd be great."
And I've had many, many an argument
with project managers in my career about,
can you deliver this sooner?
And I'm looking at it and I'm thinking,
have you read the mythical man month just for a start?
(laughing)
And are you feeling pregnant today?
And of course it usually goes right over their head,
but in any case, that's, yeah, anyway, nevermind.
So the funny thing is that I actually liked the approach
of two parts of this with Agile,
which is the first one is the decoupling of time from it
so that you're based on points.
I always found Fibonacci to be a bit weird,
but then I sort of understood the thinking behind it
is to provide that decoupling.
So it's more based on effort than time.
And it's also about relativeness.
I was gonna say relativity, but no.
(laughing)
Relativeness, yeah.
because effort of how hard is this function
versus this function versus this function,
humans are really good at telling the difference
between is something bigger or smaller
and when it's put side by side.
But if you give them something on its own and you say,
well, is that bigger or smaller than something else
that you can't observe, then people are like,
well, I don't know, maybe.
So I do like that concept.
And I also like the fact that it's more collaborative
and that's really good.
Now, those are the positives.
And the negative side of that is that I have also found the whole Story Points thing to
be quite, it can become very, it's like any group think kind of situation where you've
got a group of people and I find that sometimes the estimates tend to be either way too aggressive
or way too relaxed.
And certainly that's something that gets refined the more sprints you do, but that all assumes
that you've always got the same group of people in the same environment in each subsequent
sprint.
And that has, my observation has been that is not the case.
And maybe that's just because we've been doing agile stuff when we've been in the midst of
reorgs and so on and so forth, and people come and go from different teams.
And maybe we never had enough time to settle over a longer period.
It's possible that my perception of that is tainted by the environment that I've been
in.
I'm not sure.
Did you ever see anything like that?
Oh, absolutely.
And the tough thing is, in order to really have a velocity that counts and that is repeatable
and accurate. In order to do that, you need to allow yourself two to four similar sprints where
you're not having a lot of interruptions, or if you are having a lot of interruptions, there's a
similar amount of interruptions across each sprint. But it isn't until sprint three, four, or five
that you really start to settle into a velocity. Now, that doesn't sound that bad until I remind
you that each of these sprints is at least two weeks. So two sprints means you need at least a
month of real-world time before you have even a prayer of knowing what your velocity is. And even
then I would argue you haven't really settled down for another one to two sprints, which means up to
two months before you've really figured out a velocity. And that's the tough thing is that
I think Agile's promise is that it's a silver bullet that will give you
repeatable results immediately, when in reality, it will give you those repeatable results, but you've got to give it time to kind of settle out and debounce itself and figure out what is this team's velocity.
And to come back to your point earlier, yeah, I mean, it is unfortunate when everyone thinks everything is easy, and it's also similarly unfortunate when everyone thinks everything is hard.
But as long as you are treating that team in isolation, and as long as that team is
consistently saying everything is easy or consistently saying everything is hard, the
velocity will reflect that.
Because if you have a team that was constantly saying, "Oh, this is cake.
That's one point.
That's two points.
That's one point.
That's two points."
Maybe your velocity is five for a team of six people.
Maybe you're only delivering five points every two weeks.
And that's okay as long as you're consistently estimating everything as
being super easy, because the velocity will be super low.
Similarly, if you think that everything is eights and thirteens and whatever's, as
long as you're consistent about it, maybe that team's velocity is 60.
And the key here, and this is what you've been saying a couple of times, John, and
I can't agree with you enough, is that you have to treat that number in isolation.
My 60 on my team could be even slower than the 10 that your team is getting.
It's just about the way in which that particular group of individuals estimates.
And so you just have to look at, okay, I have 60 points of sprint, but I might have a backlog of 7,000 points. You have five points of sprint, but based on that, your backlog is only 50 points, you know, and so it ends up that even though your velocity is numerically lower, because the way everything shakes out, your real world velocity, your speed at which you're going to deliver the final product is actually quicker.
Yeah, exactly. And that's something that's not always cleared when people get involved
with an agile. And they try and turn it into - well, my experience is that some managers tend
to turn it into a KPI driven sort of contest and I find that really, really irritating. And
mind you, I also have general mistrust of KPIs no matter what they are but
irrespective of that. So, just to focus on something in particular and it's something
that technically, and I said before, it was a 1995 thing, Scrum, and it sort of becomes
synonymous with Agile and the whole idea of sprints as well. And if you haven't been involved
in one of these things, I don't know, maybe I'm just deluding myself that there's any
software developer in the world right now that hasn't ever done any Agile. Surely, I
think at this point it's been around for well, over 15 years. I think most people would have
at least had some experience with it, but how would you best describe the process of
a sprint, let's say?
Yeah, so again, every team, if you really follow the spirit of what Agile says, every
team will come up with their own process. But the generally accepted way of doing Agile
is that either at the very beginning of the sprint or even better toward the end of the
prior sprint, you will have grooming is what we typically called it, which is to say you'll
look at the next, I don't know, 5 to 10 to 15 cards on the
backlog, the things that are the most important things to be done
next, and you'll point them. You'll say, "Okay, that card,
that story, that user story is one point, that's eight points,
that's five points, that's three points, etc." That's step one.
And then sometimes in the same meeting, sometimes in planning,
which is a different meeting occasionally, you will actually
start saying, "Okay, given our velocity is 10, Casey needs
three points, John needs five points and Jennifer needs, you know, what
does that eight to two points.
And, and let's just, you know, that's kind of fish out this work and let's get,
let's get everyone situated for the next sprint.
Then occasionally people will do a kickoff at the beginning of
the sprint, but typically not.
But basically once the sprint begins and once planning has happened, everyone
just kind of goes into their corners and does their work and is mostly left alone.
If all goes according to plan, except for a daily scrum and the, the idea behind a
daily scrum is let's all come together, typically for 15 minutes or less, and say, "What did
I do?" either today or yesterday, depending on if it's an early scrum or a late scrum.
But basically, "What did I just do? What am I about to do? And what's in my way?" So,
oftentimes you'll find these done in the morning. So it's typically yesterday, today, and blockers.
So yesterday I worked on the foo widget. Today I'm working on the bar widget. And my blocker
is I need a design from our designer for the bar widget. And that's a nice way to force
the entire team to come together, talk to each other, and figure out kind of the state
of the world. And this predates Slack. This predates most IM services. I mean, it doesn't
predate IRC, but you get the idea. It forces everyone to come together and talk to each
other. A lot of companies will actually force you. Well, first of all, they'll call them
stand-ups rather than scrums, and that's because they will literally force you to stand up.
Because the idea is, if you're sitting in a chair, you'll be more than happy to talk
for three hours about all of your particular problems and quibbles and so on.
But if you're standing up, you and everyone around you is going to want to get the hell
out of that meeting room as quickly as possible so you can go sit down.
And when it's done well, scrums can be very effective because it lets everyone understand
what everyone else is doing without really slowing the team down too much.
The pitfall with Scrum or stand-ups is that oftentimes it becomes, "Let's engineer a solution
to a problem right now in this 15-minute meeting."
That is what everyone does.
I've done it a thousand times, and it is completely the antithesis of the idea of what that stand-up
is.
The stand-up is to say, "Hey, I, Casey, am having this real hard design challenge.
I'd like to talk to John about it, and can we do that after the meeting?"
That's the purpose of standup.
But what ends up happening is John says, "Well, wait.
What's going on?"
And I say, "Well, let me tell you, John."
It just spirals out of control.
But again, in principle, I am fully behind the idea of a standup.
The problem is it is so easy to execute on this the wrong way.
And that's why agile coaches, which John, you brought up a while ago, that's why they
get paid is because an agile coach's job, among many other things, is to say, "Whoa,
whoa, whoa, whoa, whoa, Casey, bite your tongue.
We'll talk about that after the meeting, but let's continue on with standup."
And it seems so silly.
It seems preposterous that you would need a full-time employee to do that.
But some of the best run Agile teams have a full-time either Scrum Master and/or Agile
coach in order to facilitate those kinds of conversations because it really is that easy
to screw it up.
Yeah.
And I'm really glad you brought that point up actually, Casey, because when I first heard
Agile coach, I almost threw up in my mouth.
I thought it was a ridiculous thing.
I was like, what?
But the funny thing is that the longer I've sort of, the more I've been involved, I should
say with agile methodology and agile teams is that they actually perform a function that
ordinarily the senior design lead or design manager or lead developer would actually would
have or would simply say, right, okay, you two in the back, quiet.
But by taking that away from someone, it's sort of like you're offloading them to actually
just be a developer and you can sort of like take that aspect of the senior role and someone
else can deal with that.
And the funny thing is that that actually can work really well.
But it all comes down to personalities, obviously.
If you get a dodgy coach, then you get what you get.
But the point is that, so positives and negatives with agile coaches, and I'll talk a little
bit about some of my experiences in a minute.
But the other point about the sprints
that I just wanted to focus on is that for me,
and I thought your description was perfect.
And I think that the key aspects for me
are that there's a lockdown period
and that's usually two weeks.
And they just, I think empirically arrived on two weeks
as a period of time where you can have sustained focus
on a set of tasks to deliver an outcome
and be too much less than that.
And it's not efficient, too much more than that
and people lose focus.
And I realized that it's not a hard and fast rule.
Some people do three weeks, some people do one week,
short sprints, long sprints, whatever, whatever.
But the reality is that two seems to be the,
I think globally accepted best compromise.
But in any case, the point is that the whole idea
is that you have a group that are locked down.
And I call it lockdown.
That's just what I used to call it.
The idea is that you're in a sprint,
you're not doing anything else.
So, and one of the interesting problems
that I've observed in organizations
is that organizations typically have a maintain component
and they have a development component.
And obviously, depending on what industry it is,
what, how mature it is,
depends on how many people are involved
in those different arms of the organization.
Yeah, so if you're a company that's running,
you know, let's say it's, I don't know,
I was gonna say Google, that's really,
I don't want to talk at Google.
I'm trying to think of a company that's pretty,
let's just say Microsoft for the hell of it.
Okay.
Well, Apple, whatever, it doesn't matter.
You've got a bunch of software that's already out there
that you have to maintain.
Someone files a bug report, go deal with it.
Yeah, someone's having a problem logging into their account.
Yeah, trivial stuff, whatever.
You know, that's sort of levels of support,
first level, second level, third level support.
And then you've got your actual designers and developers
and they'll be developing the next set of features.
but the reality is that sometimes things get past
that first level, sometimes it get past the second level
and then you need to have your experienced designer
or developer come in and actually have a look
at the problem and resolve it.
So they can't always wear that hat of saying,
I'm just doing new feature development,
don't talk to me about anything else.
It doesn't matter if I wrote the code,
it doesn't matter if it was my bug,
someone else can deal with that, right?
And I found that in larger organizations
where you have a reasonable pool of resources
in either side of that, Agile can work very well
in terms of the sprint component anyhow,
because you can actually get those people,
you can afford to put them in a room and say,
don't talk to them, they're focused on a sprint,
leave them alone.
Whereas in organizations that are trying to be,
I would say that by nature have to be leaner
or where people have to wear two hats
because of either the organizational structure
or simply because there's a large
and high priority maintenance component.
And it could just be that if things fall over in the system, you need to actually get them
back up and running again as quickly as possible.
There could be all sorts of reasons why that is, but in any case, that's where people being
locked in a room doing a sprint can actually become a problem.
And of course, once you start taking people out of that room and saying, "You know what?
I need you on this, I need you on that," or whatever else, then the whole thing collapses.
So it's a difficult balance and what I've observed is that essentially, if it doesn't
quite fit the balance in the organization, then Agile is almost doomed to fail in terms
of the sprint component of it.
Anyhow, it's difficult to actually deliver on its promise and then people say, "Well,
Agile failed."
It's like, "Well, no, I did it."
Or was it more the fact that the organization couldn't support it properly?
And I've observed some of that.
Yeah.
I agree mostly with what you just said.
The only thing I would disagree with is that in principle, if one or more of your team
members is getting distracted constantly, in theory, that would be reflected in your
velocity.
So maybe your velocity was a steady 20 points sprint, and then suddenly there's some catastrophe
that runs across multiple sprints that causes your developers to get distracted.
Well, theoretically, then your velocity will fall.
Maybe it'll fall to 15 or 10 or something like that.
Now that's clearly not what you want.
I agree with you, John, that really this is not desirable behavior for anyone involved.
But the good news is if you really believe in Agile, if you really trust Agile, hypothetically,
that'll all kind of come out in the wash and you'll just have to react to the fact that
your velocity has gone way down.
This is also why Agile and Sprints oftentimes have these kind of weird cards that are not
deliverables. So, Casey needs to consult with John about some
thing, just because that's what John needs in order to get his
job done, even if he's in a completely other team. And maybe
that gets like three points, which really is a bastardization
of what agile is supposed to be because now you're kind of
implying a time-based component to what a point is. But the idea
behind it, and the reason people do it is because you're trying
to manage the fact that work is being accomplished, even if it
doesn't work against your actual goal.
And I'm of two minds whether or not this is a wiser, poor
choice to do those sorts of things.
But no matter how you slice it one way or another, it should be reflected in
your velocity, either because your velocity will go down or because you'll
just have all these other cards that suddenly appear on your board that take
up time.
But one thing I think that you were kind of glancing off the outer atmosphere of,
and I think is very important, is that especially in consultative roles, the
The place that I've seen Agile both work tremendously and work terribly is the product owner.
The idea of a product owner in Agile is that some human being has to be where the buck
stops.
My understanding of the way Apple works internally is that they call this the DRI, the directly
responsible individual.
At some point, it will all roll down to one human being to make the decision about when
we go left and when we go right.
Typically, if you're doing Agile the way most people like to, that
individual is not a developer and is not even a member of your own company,
potentially, it's a member of the client.
So again, I'm speaking from the perspective of a consultant.
So for me, I am working for Acme Widget Company.
I want somebody at Acme, not my company, but not Cases Consulting Incorporated.
I want someone at Acme that I'm building the software for to be the product owner.
And I want them to be a product owner darn near full time.
That's the other thing that often goes wrong is they'll say,
oh, well, this person has 300 other responsibilities,
but yeah, they'll make time for you.
No, no, no, no, no.
You want a full-time product owner
that will be there at a moment's notice
to answer questions and help steer the ship.
And if Agile is really working properly,
then you'll have the experience
that I had once several years ago
with a product owner at a local insurance company.
We were building an intranet thing for them.
And the product owner, I believe her name is Jen, she had said to us at some point,
"Oh, I'd really like this other thing to get done, this brand new widget that
we've never talked about before.
I really, really, really want it to get done."
How many points do you think that will be?
And the skies opened, John, and angels fluttered down and you heard that
"Ahh," because that is exactly what she should have said.
She shouldn't say, "When will it get done?"
She shouldn't say, "When can I fit it in?"
She should ask us, "How many points will it be?"
Because if we tell her it's five points,
then she can look at her own backlog,
which is really our backlog, but you know what I mean?
She can look at her own backlog and say, "Okay,
if I'm going to slot in five points real soon,
then what five points am I going to postpone to be later?"
Suddenly, you as a team of developers and designers and QA engineers,
and the broader team, including the product owner,
now your currency becomes story points,
and it's an understood currency with understood value.
Then all of these angry negotiations that you were talking about earlier, again, completely
agree with you.
"Well, don't you think you could skim off a couple of weeks from that thing?
That would be really great because I got to deliver my stuff by such and such date and
that means it's your problem."
All those conversations, they just kind of go away because now it's up to Jen or whomever
to say, "Okay, I really, really, really, really want this new thing I never told the
team about, but the team has told me it's five points.
So that just means I got to move five other points somewhere else and then everybody's
happy.
Does that make any sense at all?
Yeah, that's absolutely.
And I guess my experience is I've yet to come across a product, an owner who actually spoke
that.
So I'm glad that you found someone like that.
In my space, it's still people are still getting used to this.
And I think that that hopefully will come in time and then we can be speaking in the
the same sort of language.
So I think that that is awesome when you can get to that point and that is awesome.
I guess I just wanted to circle back quickly and talk about just quickly on agile coaches.
One of the things I said before about people being able to like being locked in a room
to actually focus on the sprint and not have too many distractions, I mean, I guess my
problem was also with that is that the agile coaches and one of my first experiences with
an agile coach by the way, was when I had an engineer who was given to a sprint and
by really, really, really, really needed him to address an issue that was causing us a
lot of grief.
And I went down to what they called the engine room.
I kid you not, they actually called it that.
I don't know if that's a common terminology but I hadn't come across it before but in
any case.
So, I went down to the engine room and was trying to speak to my guy and was promptly
escorted to the door by the agile coach, we're in the middle of a sprint, you're not allowed
to speak to them and you need to look at the folks who are delivering.
And I'm like...
Yeah, that's kind of their job, but that is not a very friendly way of accomplishing their
job.
No, it was pretty, yeah.
It was pretty confronting for me because technically...
Oh, totally.
Yeah, because I mean, like he was, you know, he worked for me, he had deliverables and
other things and he was essentially promised by someone over my head and said, "Oh yeah,
we can have this person for the next two and a half weeks
or whatever it is of which the majority of that time
was a two week sprint.
And during those two weeks,
you won't be able to access your guy.
And I'm like, well, hang on a minute,
but I really need it 'cause this thing was broken,
this part of the plant was down,
I really, really needed his help
and I wasn't allowed to get it.
So we had to fumble our way through it
and took us two or three times as long to figure it out.
I mean, we got there in the end,
but so where the sprint won,
the rest of the business lost kind of thing.
It's sort of, that was when I had that realization
that when you have a critical maintenance function
that you're performing and you've got developers
and engineers wearing two hats,
then the balance of that will drive how successful Agile
can be in that sense.
But in any case, Agile coaches, yeah.
I mean, like you said, that's their job.
And I didn't appreciate that at the time,
but as I've sort of like gone along a bit further,
they're kind of like playing the bit of like the good cop.
Well, not really like the person that directs
where agile is not being followed,
but they are also a bit of an enforcer in saying,
well, you know what, you two in the back stop talking.
Oh yeah, no, you can't have him, he's in a sprint.
Yeah, whatever.
So I see them as a necessary component.
And I kind of like that fact anyway,
because in the end they take some of that stress away
from what did it be previously something born by managers.
- Yeah, very much so.
And I think just to build on what you were saying
that oftentimes a scrum master in my world
will also be a project manager, the sort of person who would work at a Gantt chart in
Waterfall World.
A lot of times I've found that my best project managers/scrum masters, what they do is they
are total jerks to their own team in favor of advocating on behalf of the client, but
then they'll turn around and be total jerks to the client in order to advocate for the
team.
Does that make sense?
They're kind of the taskmasters, but that's kind of their job.
Really good project managers, in my experience, will defend the other party that isn't there
because that's kind of what they need to do.
And just on a quick other note, that experience I had with Jen, the product owner, that was
a once-in-a-career kind of experience.
I have done agile projects, had been doing agile projects for something like 10 years,
And I think I had that kind of experience once, maybe twice.
So don't be discouraged if you, John, or anyone listening to this has yet to have that experience.
It is very rare and very difficult.
And it only really works if you've gotten all of the other stuff squared away, where
you've got repeatable, reliable story points, you've got repeatable, reliable velocity.
It takes a lot to get to that point, and it is very difficult.
And I think that's where Agile gets a bad reputation, is that so often it's done half-heartedly
or it's done not terribly religiously, and that probably implies something I don't want
to imply, but hopefully you get the point, that you have to kind of go all in on Agile,
and if you don't, then it's not really going to work the way it's designed.
And you could treat that as a detriment, you could treat that as an advantage, I don't
know, but don't feel bad if you've never found that product owner, because there's a product
owner out there for you that will be that way.
You just got to give it time.
Absolutely.
One of the other things I want to talk about a little bit as well is the standup.
It's funny when you mentioned that before, circling back to that,
is that standups have existed as a concept long before Agile was even discussed in the 90s.
When I worked at Nortel, for example, that was when I first came across that.
that. I was in 1997 and yeah, basically the- I walked into a
meeting room, literally as the chairs were being wheeled out of
the meeting room. And I'm like, okay. So, we walked in this
meeting room. There's now no- there's now no chairs. And it
wasn't that we needed more standing room. And the manager
says, this is a stand up. You have 15 minutes. Go. And I'm
looking around. I'm like, yep. So, we talk now. Because I'd
I'd never, you know, and the whole idea that you like the whole concept in has been attributed
I think by some to agile, but the fact is that no, it's simply a good way of stopping
people waffling on, which is kind of good.
So in any case, I also want to talk a little bit about the whole, the utilization of visual
management boards.
I'm not sure.
Yeah.
One of the things is that I found that during stand-ups,
there's a lot of,
you tend to stand around that visual management board
and sort of like go through each of the key things.
Well, when you talk about what you're doing,
then there should be something up on the board
that's talking about that.
You shouldn't be doing something necessarily
that isn't in some respect represented on the board.
So the thing is that Kanban and I guess,
the thing is I always call them Kanban boards,
But I think Kanban is also more broadly another methodology,
but Scrum also utilizes a Kanban-like board.
And hence the names sort of get a little bit conflated,
but in any case, the bottom line is it's,
my understanding of the differences
is more about how often it's updated.
So if you're updating a board,
a Kanban board could be representative
of a continuous process or a project or a team,
whereas the Scrum board is specifically focused
on the sprint, even if it's representing
the same kind of board.
That's my take on the difference.
- Yeah, so to kind of back up just a half step,
a lot of times it's very useful to see
a visual representation of where the work is.
And so typically what that's done,
the way that's done is either via some sort of software
or via a literal whiteboard somewhere in your office,
you'll have a board with several columns
and maybe the first column is backlog,
maybe the second column is like in progress,
Maybe you have in test, maybe you have in review and maybe you have delivered.
You know, and those don't have to be the exact four or five, whatever
columns, but something along those lines.
And you have literal cards, usually post-its or what I can recommend
is something called Slicky Notes, which is, this is not a sponsor, but
at ecostaticink.com, these are basically like post-its, but they work via static.
So you can slide them around, which is really, really cool.
Um, anyways, you have something that, that represents, okay, this
card is in this column, which means it's in that part of the process.
And, uh, I suspect that our sponsor this week probably does something like that.
Uh, where you via software, where you can kind of see where things lie.
Um, but one way or another, be it via, via Slicky Notes, via Post-its, be it,
um, you know, some other software, then it's a really nice way to visually
see where the sprint is.
Because typically speaking, you will
find that at the beginning of a sprint,
all the cards are on the left-hand side of the board,
whatever your columns may be.
And over the two weeks or however long,
all of the cards are hopefully moving over
to the right side of the board, which means done.
And that's a really nice way not only
to visually see what's going on, but also
to kind of manage your scrums.
Because typically, the way you do a scrum
is either you go around the room person by person,
or you go around the board card by card and say, OK,
who's working on this card?
What's the status?
And yeah, I quite like doing that.
It obviously becomes very difficult
and you kind of really need a software solution
if you are a distributed team,
but if everyone's in the same spot,
having, you know, slickie notes or post-it notes
on a whiteboard is tremendous.
- Absolutely.
And actually, since you brought it up,
it's probably a good time for me to quickly talk about
our sponsor for this episode, and that's Clubhouse,
the first project management platform
for software development that brings everyone
on every team together to build better products.
Clubhouse was built from the outset
with agile development in mind.
What have we just been talking about?
And with an intense focus on intuitiveness
and responsiveness.
With their web app backed by Fastly CDN,
it really feels like a local app on any platform.
Clubhouse delivers developer-centric tools
for everything from Kanban boards to epics,
milestones, cards, with different card classifications
for features, bugs, and chores.
But it's more Clubhouse's ability
to interconnect all of them together
that's so impressive.
Users have reported creating less duplicates,
navigation is very fast using a common board,
but with as many configurable workspaces
as you'd like to customize that board
for whatever purpose you might need.
Morning standups for different teams, sub teams,
or all the teams, it's entirely up to you.
Ultimately, any collaborative project management platform
has to be as low friction as possible,
and not just for software developers,
but for everyone in the organization.
Marketing, support, management, you name it, the lot.
so everyone can contribute
and actual collaboration actually happens.
Finally, the other part of Clubhouse that really shines
is its ability to zoom out from individual tasks
to the overall project status
that not only keeps project managers happy,
but keeps the team connected
on how their part contributes to the greater project
and keeps them focused on what matters,
delivering a result their customers will enjoy.
There are others in the market,
but they're not like Clubhouse.
And what makes Clubhouse so different
is the balance between the right amount of simplicity without sacrificing key functionality
structured to allow genuine cross-functional team collaboration on your project.
Clubhouse is a modern software as a service platform with seamless integrations for popular
tools like GitHub, Slack, Sentry and lots more. And if the tools you want to integrate
it with aren't available out of the box, that's okay. There's an extensible REST API in Clubhouse
that makes integrations straightforward.
If you visit this URL clubhouse or one word.io/10 the word, you can take advantage of a special
offer for Engineered Network listeners.
Of course, you'll get the 14-day free trial, but if you sign up, you'll get the first two
months free and because this is a team-centric solution, this offer will work for your team,
not just for you.
The offer is only available to Engineered Network listeners for a limited time, so take
advantage of it while you can.
Thank you to Clubhouse for sponsoring the Engineered Network.
So yeah, just then circling back to the whole physical
versus virtual thing.
When I first came across Agile, it was only,
well, as I said, about two and a half years ago,
like I knew I'd heard of it, I knew what it was basically,
but my first true experience with it
was only two and a half years ago.
And I walked into this room
and they had this visual management board up
and it was just a whole bunch of,
they weren't even posted notes.
They were using the magnetic clips.
So you clip a small square card
into kind of like a clipboard clip style thing,
but it's got a magnet on the back of it.
Now we're holding that up on the board.
And I looked at all this and I thought to me,
well, that's how beautifully archaic.
It's like, come on, what century is this?
'Cause as a software guy, I'm looking at it thinking,
there's software that can do this.
Why aren't we using software and a big screen?
And of course, it came down to,
it was a preference of the agile coach
and it was a preference of management who are more tactile.
And, you know, they're all generally older people
that weren't, you know what I mean?
They were happy to use a pen and paper.
Whereas there was me with my iPad and my Apple pencil.
I haven't used an ink pen in four years.
And you know what I mean?
It's like, but here we are shuffling around
bits of dead tree on a, anyway.
But those posts that you mentioned sound really cool.
I'm actually gonna look into that
for a completely different reason, but you know what?
That sounds really cool.
I've made a note of that.
Thank you.
Yeah, the only caveat to them is they only last like a couple of weeks
when once they've actually been stuck on a board.
You know, if they're sitting in the package, I don't know what magic is
happening, that it's fine, but as soon as you take them out of the board, you've
only got like a sprint or two before they're going to start falling off.
But man, they are magical during that first couple of weeks, two to four weeks
when the static electricity is really clinging.
So when they fall off the board, does that mean you don't have to
worry about them anymore?
Like that's.
- That is what I have tried many a time, John,
and it has yet to stick.
- Dang, okay, well, it was worth a shot.
Anyhow, very good.
So I guess my experience with them, as I say,
is that this is a fixation on them being physical boards,
despite the fact that we are supposed to be flexible
in our work location,
because one of the things that they've also done
in our recent reorganization
is that we've changed buildings
and then our new building,
It was a new building, fresh start kind of thing.
And there's not allocated seating.
And they finally figured out Skype as a thing.
I mean, my business was a bit slow in that respect,
my current employer,
but they're finally on board with that and it's fantastic.
So I mean, I can work just as effectively from home
as I can work from the office,
which is important since technically the number of people
versus the number of seats,
if everyone showed up to the office on one day,
then not everyone would get a seat,
But hey, I guess.
Anyway, the bottom line is that
I think that a visual management boards,
like a software version of one having up on a screen
is nine times out of 10, the better result
because in the end that gives you ultimate flexibility
into where you can be.
And it's also a reference for others.
So anyone can log in and have a look at the board
depending on how you set up your sharing, of course.
But the fact is that to see a physical board,
you have to physically be in that physical room.
and sometimes it's just not possible.
And if you wanna catch up on the high level overview
and status of whether you're red or green
and whatever part of the project you're working on,
then you have to be in the room to tell that.
And that's the only downside.
But that also leads into the discussion
is what's the value of the board
and what's the value of like who gets value from it.
And I've always had this concern
with the reporting of statuses of projects.
And no matter how, if it's through KPIs,
if it's through a visual management board,
or whatever it is, who is it really for?
There's one group, one school of thought that will say,
well, its sole purpose is to keep the team focused
and to, so the team knows where they're at
and where they should be pushing harder
or where they know they're on track.
And the other school of thought as well,
it could also be for management to have an idea
of where your particular sprint is up to,
so they can get an idea of how you're tracking.
And the problem is that if everyone's doing
these visual management boards,
there's lots and lots of them all around the organization.
Generally speaking, people don't actually have time
to go and ingest all of that.
And generally speaking, from a management point of view,
most of the managers will come down,
will simply look at the red green and then keep on walking
and not actually comprehend the content of the board.
So I say all of that considering the flip side
that ultimately people still need to comprehend.
So if a manager comes in to have a look at what's going on
and see where everything's up to,
then they need to have spent some time comprehending
speaking to the scrum master or the product owner, they got to comprehend what's going
on.
It's not just enough to have a board and you walk past and say, "Yeah, that's great."
So I've always believed, I firmly believe that the value of the board is for the actual
team that's doing the work more than anything else.
Yeah, I agree.
I think that there's something to be said for an at-a-glance way of looking at what
the state of the world is.
doesn't necessarily have to be this kind of Kanban-y, you know, Scrum board, but I do feel like it is a nice way to do it.
And like I said, it's, in my experience, maybe just because I'm a worrier by nature, but as I see us getting closer and
closer to the end of a sprint, and I see more and more of the kind of weight of the board being on the left-hand side, which
is, you know, in progress or not even started yet or something like that, then I know that if I've been goofing off, I need
to stop goofing off. And I know that it is really time to put the pedal to the
metal and really crank if I'm going to make my obligations and commitments for
this sprint. And again, it doesn't have to be a board to do it. You could just
have like a speedometer style needle if you wanted. But one way or another, I
think it works out really well. I completely concur with what you're saying
about management oftentimes not getting the nuance of these sorts of things. But
nevertheless, I do think it's useful. The other thing I've seen useful from time
to time is a burndown chart, which I'm going to butcher the description. But
Basically, the idea is if you are keeping to this current velocity, this is how many
points you should be doing each sprint.
And given the backlog of items, this is how long it will take to complete this entire
project.
And you can see how you track against your velocity, are you doing better or worse, and
what the final real-world end date is for your entire effort, assuming you keep this
velocity.
so kind of useful to know, because especially in the consulting world, like typically a
project or a project team or maybe just an individual is going to be booked by a client
for some number of months or years.
And if you're coming to the end of that some number of months, you see that that burndown
chart says you've got another month after that before this project's done.
Well, that's time for some contract renegotiations, I'd say.
And so that's sometimes can be useful too.
Absolutely.
Alrighty.
- Well, I just wanna refocus a little bit now
and look at some of the consequences or common issues
that they come across if you apply
the agile methodology and work practices.
And there's a couple that I wanna talk about.
You may well have your own short list or longer list,
but in any case.
So when the first comes to mind is,
it's all about motivation and what are people's motivation?
And the more we motivate people to actually execute
on functionality driven by a product owner,
ultimately, that preference will always be
product owners want the shiny, shiny,
they want the features and functionality.
They don't necessarily want all of the code to be written
as beautifully and elegantly as possible.
You can debate whether that's right or wrong,
but the reality is my experience is that
the technical debt is more problematic with Agile
because generally speaking,
people will wanna have a better velocity
and to have a better velocity,
you will typically take a faster solution
rather than actually having a more scalable,
flexible implementation that's gonna take longer
to design and develop,
but will give you something that once you're finished
will be easy to maintain.
- Oh, absolutely.
I think you've absolutely nailed it.
This is very, very common because what Agile values is literally
reading from the manifesto, working software over, now they say
comprehensive documentation, but you could also say working software
over a flexible software.
Now that's probably a little bit unfair because I would bet the
writer, the authors of the Agile manifesto would say, "Whoa, whoa,
whoa, whoa, whoa, whoa, you can have working and flexible software
all at the same time."
And that's true.
Sure.
But it is just like you said, John, it is much more difficult to have both
working and hyperflexible software than it is just to have something that works.
And I think one of the most difficult things of software development is
something that I still struggle with 15 years into my career is when do you
design for flexibility and when do you not take shortcuts, but just, you
know, do the more direct path.
And sometimes I make those calls well, and sometimes I make them very poorly.
And I think one of the ideas behind Agile is it should become relatively
obvious, relatively quickly, what sorts of things the product owner is going to
want to renege on or change their mind about, and maybe those are the things
that you should be more flexible about.
And then there are other things that you know are unlikely to change.
And in the spirit of moving fast, you're just going to have to take, again, maybe
not take shortcuts, but kind of hard code things or just be more direct in your implementation.
But yeah, I completely agree with you that technical debt is always a problem, always,
no matter how you write software, but especially with Agile. And that's why a lot of times
after several sprints of work, a lot of teams I've worked on will take like, I forget the
term we've used, but like a kind of a breather sprint where we'll take a full sprint's worth
of time, a full two weeks or what have you, and just do cleanup and kind of batten down
the hatches and kind of reset everything and fix some of those shortcuts that we had taken
in the past.
And it doesn't always work out well because you're now delaying the final deliverable
in terms of real-world time.
Oftentimes clients don't understand why you need to do that.
Like, "Why didn't you write it right the first time?"
But oftentimes I've found that can make a tremendous difference in the robustness of
software and the ability for the software to bend in the future, you know, when the same product
owner does make a different choice. And a very quick tangent kind of off of this, another thing
I've seen a lot, especially when you're working with a client, and especially when that client
is a very big business, like something banking related, for example, where there's a lot of
security problems and things like that, a lot of times I'll see what's called a sprint zero.
And what that means is, let's spend a couple of weeks just getting the administrivia taken care
of. If we need to use a laptop that is owned by the client, does every member of the team
have one of those laptops? If we don't need to use a laptop owned by the client, can we
get on the client's VPN? Do we have the user access that we need? Do we have access to
the database servers that we need? Do we need to stand up a database server or web server
or what have you? And we'll spend one to two sprints just getting the administrivia done.
Because inevitably, if you don't do that, what happens is you spend that same month
doing those things while you're supposed to be delivering.
So let's just embrace the fact that this is going to take some time and just cart it out
and treat it as a sprint.
Yeah, sprint zero is an interesting name actually.
I hadn't heard that one.
I've heard people refer to that sort of thing as a chore sprint where you basically are
Yeah, same thing.
Yeah.
And I think that's fantastic.
And for me, it comes down to the powers that be accepting that that is a thing as opposed
to it will just happen magically.
Like here's a whole bunch of stuff that you need to deliver.
And it's all the administrivia.
If you don't do it upfront,
you essentially you're set up to fail.
You know, and it's like, well,
what's the point of doing a sprint?
'Cause that'll directly affect your velocity.
So what are you gonna do?
- Exactly.
- Yes, it's, but that's a good one actually.
All right, so just on the product owner,
actually just quickly,
I've also struggled with the concept that one person,
and I know that this is a common problem
in no matter what part of business you want to be in.
One person to make the final decision.
Finding a person that can honestly
and realistically comprehend the relative importance
of all the competing objectives.
It doesn't matter if they're the client or not.
That's a hard thing to find.
And my frustration has been that a good product owner
has a good focus and a good grasp of what needs to happen
and what rather what needs to be done,
what they really do need as an owner.
But the reality is that that's a very rare thing.
Most of the time, my experience has been that
these client representatives,
I guess you could call them
in the more waterfall strategy approach,
or product owners, they tend to be,
they tend to blow on the breeze a bit.
They tend to be distracted by the new shiny, shiny.
They don't fully comprehend the trade-offs.
No matter, if you can get a conversation about points,
that's fantastic.
But generally speaking, they just,
or how hard could that possibly be and not comprehend?
(laughing)
So that's my frustration with that.
And to be honest,
that's nothing to do specifically with Agile.
It's more the fact that Agile empowers the owner
with so much power insofar as directing where the work goes.
Whereas in more of a waterfall approach,
it's more of a negotiation of, well, if you want this,
it's gonna take this much more time
and that's gonna be equal to this much more money.
And we have all these other things you've already agreed to
that we're halfway through working towards
and there's six months of momentum in our documentation
and you're now saying we've got to pivot
and do something else.
And so agile sort of empowers a lot of that,
but that's in the flip side being
that's the whole point of agile.
So, you know, it's like you're empowering people
that if they're too wishy-washy
and blow on the breeze a bit and change their minds,
then that can have a massive blowout
in your ability to deliver something.
So that's been a frustration of mine.
I'm not sure how often you've come across that, if at all.
- Yeah, I definitely have seen that for sure.
But again, if everything is going according to plan,
that will be drawn out or kind of spelled out
in the burndown chart or the lack of good velocity.
- True.
- And I feel like that will often fix itself in the wash.
What is more challenging to me
in a corollary of what you were saying
is I have definitely had occasions
where we've had a very engaged, very, very interested,
very skilled product owner.
And that individual is great, but the organization they
work in is a disaster.
And what ends up happening is you have a product owner that is doing
everything right by the team, but they're not empowered on the client side.
So they know exactly what they want.
They know exactly how to get it done.
They have a general understanding of what the rest of the business
around them needs and wants.
But then you'll have some higher up that feels like they just want to make their
appearance. We used to call this a swoop and poop. A bird swoops in, poops, and flies away.
Oftentimes you'll have a product owner who is engaged but not empowered, and then
you'll have the product owner's boss or boss's boss or boss's boss's boss come in,
swoop and poop, and say, "Oh, no, no. Don't do it that way. Do it this other way."
And suddenly, three sprints worth of work, just like you were saying, John, just goes
up in a puff of smoke. And that can be very challenging. And again, the best product owners
are ones who are not only engaged, preferably full-time, but I didn't say this earlier,
also empowered. Empowered to make decisions for the product in order to get things done.
And finding someone that is both engaged and empowered is very hard. You will very often
find either somebody that is engaged but not empowered or empowered but not engaged.
- Yeah, absolutely nailed it.
And then that, exactly.
And I've unfortunately had too many bad experiences
with yeah, with never finding both.
And it's quite frustrating,
but that's not the fault of Agile, let's be clear.
Necessarily, it's more about the power that they wield
and hence by not getting that right mix right
in an individual can have more negative consequences
than you would get in a waterfall is more the point.
But all right, next issue with Agile that I've seen,
And I don't know if this is an issue with Agile or Paul,
again, getting back to it's how it's implemented,
overreaching on each iteration
and just essentially taking on too many tasks
and the effect that that has on the overall,
the stress level and indirectly, therefore the velocity.
And then if you have too much of that,
then that will drive constant context switching
for an individual trying to deliver on all of these things.
and it's not actually possible to do that in the timeframe.
And that drives inefficiency.
And the funny thing is that this is something that
I know that you'll say,
well, in the longer term that'll balance out.
And it's like, well, yes,
but what I've observed is that
if there's too much of this KPI driven attitude,
then that may not happen.
And there will be this drive to churn through points
and to improve that velocity.
And taking on more is the natural reaction
try and get through more to improve the velocity to drive the KPI. And then that creates a
behavior which is where you continually overreach. And maybe that's the job of the coach to stop.
I don't know.
Yeah, I think you nailed it. I think the coach or scrum master or whomever should be putting
the kibosh on that. But ultimately, if you're overenthusiastic about signing up for cards,
you're just ruining things for yourself. Because again, if you're realistic about how much
work you're getting done, then the velocity becomes accurate and then everything falls
into place.
But so often what'll happen is exactly what you described and the team will overreach
and they'll sign up for 50 points worth of work, but maybe 30 points of which are actually
delivered and 20 points of which are in this kind of nebulous zone where they've started,
but it's not really delivered.
And then that just means the velocity is just an arbitrary number.
It doesn't really represent anything.
And so my recommendation in those situations is try to force yourself and your team to
be conservative because it is much better to only complete five points but get them
all the way out the door, written, tested, approved, etc., than starting 50 points and
delivering 10 of them.
And so what I try to do in teams that I've been managing either in terms of being a scrum
master or like a technical lead is to try to encourage people to do a couple of
things.
One, don't bite off more than you can chew, just like you said, John.
But number two, try not to context switch if you can avoid it.
So yeah, you might think you can do 15 points worth of work just yourself,
John, but only pull into the sprint five points worth of work until you are sure
that those five points are done.
As much as you can get done on them, they are done.
Preferably they've been tested and maybe they haven't been approved yet,
but at least done and tested.
And at that point, sure.
Pull in another five, even if it wasn't originally slated for the sprint,
because then guess what?
That means your velocity was, you know, your team's velocity was 15, but
because John did a great job this time, maybe it's 17 next sprint again.
Like just trust the system.
And like, I'm yelling in your direction, not at you, but trust the system, man.
And it'll all work itself out.
Yeah, absolutely.
Right.
And the whole thing about context switching
is just good advice,
no matter what you're doing in any aspect of anything.
'Cause I find that the more you keep trying to juggle
all these different tasks at once,
the more you're switching out what you've got to focus on,
it just completely,
your efficiency just collapses in a heap.
And the funny thing is that people need to think about
things as like, I'm going on a very long walk.
How do I get from A to B?
Well, you take it one step at a time, right?
And that's the whole point is that every step is a task,
do that task, then go to the next task.
And then once you've done all those tasks
and you've got through all those points
in the context of Agile,
you'll look back and you'll say,
"Oh, wow, look at all the stuff I did."
As opposed to, I'm gonna try and jump
between all these different things at once,
get a little bit of a progress on each of them
and then end up achieving very little net movements.
Kind of like I'm kind of wandering slightly
in a circle sort of spiraling outward slightly.
So I've kind of moved a little bit that way,
but not really far enough.
But anyway, dear me.
Okay, so two more issues then
that I wanna make sure we talk about is burnout.
And that is not burned down as in a chart,
but burnout from burned down or something.
And that's terrible.
Anyway, the point is that my observation
is that people in a sprint environment,
particularly if there's a lot of management pressure
an organization to have multiple back-to-back sprints.
Probably you could argue too close together, which from a churning through a large number
of points is a tendency I've noticed in some organizations.
And I think, and this is the problem is I had to dig to see if there were any actual
documented studies about whether or not engineer programmer burnout was higher under Agile
than under Waterfall.
nothing definitive but there seems to be a lot of noise in that space.
And I sort of thought about this and it's like, well, it doesn't matter what methodology
you use, you work your people too hard, they're going to burn out.
And it doesn't matter.
That's not necessarily a failing of agile but I think that it's something that if you
do have too many sprints, they're too close together and they're back to back, you're
basically going to work people too hard and ultimately, you can't sprint constantly.
Yeah, I think that's true of really any engineering, I was going to say
software, but really any engineering I think can fall into that trap.
I don't think it's unique to agile.
Something that my last company did that I really, really liked was that it was
either once a quarter or a couple of times a year, like once every couple of
quarters, I forget exactly what it was, but they would allow us to basically
just go goof off for a half a day.
And so sometimes we would go and race go-karts.
Sometimes we would play mini golf or something like that.
And these are not terribly expensive things to do.
And it also helped that this last company was a product
company, not a consulting firm.
And so us going away for four hours doesn't have a direct
difference on our bottom line.
But nevertheless, they would fund us going and goofing
off for a little while.
And I cannot recommend that enough.
I don't think that offering, that having the team leader
whatever, say, "Hey, let's go get drinks after work," is the right answer because
A, not everyone drinks and B, after work time is sacred to a lot of people, myself
included.
But if your company is flexible enough that you are allowed to do something
that preferably has no financial input from the team members, even if it's as
silly as going out to lunch but having the company pick up the tab and letting
that lunch be like a one or two hour lunch instead of the 20 minute run, grab
something and run back, you know, dance that a lot of people typically do.
Um, I found that that makes a world of difference, especially if it's
something more than just lunch, you know, lunch is a good start, but
something more than just lunch going out to, to watch a movie together or
to, to race go-karts or I don't know, do any number of things.
I was going to let my American come out and say, you know, go target shooting,
which is weird because I don't even own a gun, but anyway, um, you know, do
something hopefully less American than that.
And I feel like that makes a tremendous difference.
Obviously, I think Americans especially, and I don't want to speak for
Australians, Americans especially have a very complicated relationship
with what we call vacation time.
I believe you call it holiday time.
And oftentimes Americans will get to the end of their year and have some of
their paid time off, some of their holiday or vacation time unused.
And I'm of the opinion that vacation time should be compulsory.
Like it is a big problem and it is a big ding on your record if you do not take vacation
because that is critical.
That time away from work is critical for you in order for you to be an effective worker.
Not everyone feels that way, but that's the way I feel.
And I think just being aware of your team's morale is something that the technical lead,
the product lead, and or product owner, and especially the project manager/scrum master,
something that the three of them, well, typically that's three people,
but you get my point, the three of them need to work through and pay attention
to because you're exactly right.
Especially if it's in a high pressure situation, especially if the team
is firing on all cylinders, that's almost worse because that means
everyone has just been cranking.
And this is what you were saying a minute ago, you know, when everyone's
cranking at some point, you need to release that, that, that pressure
and you need to let that valve open.
And my, my favorite way to do that is during work hours because that
doesn't necessarily affect families.
It doesn't necessarily affect the person's personal financial world.
You know, it, it, it, and it's, and it's like a treat that you get to miss work for a
little while, you know?
Yeah, absolutely.
But, but see, that's, that's the key part is that, you know, it's an acknowledgement, um,
by the, by the organization that, uh, we value your sanity and therefore, um, exactly.
Yeah.
Take a few hours on the company and go and unwind.
And you know, it's like, and that's fantastic.
Right.
And it's been, I think in my case,
well, we've just been through a bit of a rough time
in our company in terms of downsizing and such,
but the reality is that we used to regularly go out
every probably month or so for like a team lunch.
It was like a very extended team lunch.
So normally you mentioned the mad dash out,
go out, grab something, come back kind of thing,
and try and get it done in an hour, in a lunch hour,
lunch break, what have you.
This is actually was more like a,
we'd head out on a Friday afternoon,
typically once a month and most people wouldn't come back
to the office if you did, you'd meander back
at maybe 2.30 or something like that.
And it was pretty easy in the afternoon after that.
But yeah, actual team building or getting out there
and getting the go-karts and everything like that,
that's something that periodically
when you're in a high productivity environment
is absolutely critical.
It's an acknowledgement from the company
that you know what, you're a human being, you're not a robot.
And so far as the holiday thing goes,
I'm almost applauding when you were saying that
because my problem is that that is a thing here too,
where people just stack up their annual leave
and they never take it.
And so we have this thing, it's not actually called this,
but we refer to it as the naughty list.
And the naughty list is essentially,
if you have more than 20 hours of leave,
then you're yellow, you're in the yellow.
If you've got more than, sorry, 20 days,
if you've got more than 30 days of annual leave
that hasn't been booked, then you're in the red.
And if you're entering the red, you're on the naughty list.
So I went beyond the warning list and into the naughty list.
And my boss said, "Right, John,
you're gonna be taking some leave, aren't you?"
And I'm like, "Well, of course, yes,
of course I'm taking some leave, yes, absolutely.
I'll take five weeks."
And he's like, "Oh, no, no, no, you don't have to overdo it."
I'm like, "Oh no, I'm taking five weeks."
And I tell you what, I'm so glad I did.
I feel so much better.
And I literally only been back at work two weeks since then.
So, that beautiful holiday bubble where you chill,
it's still mostly intact.
So, I'm happy with that.
Good outcome.
- I had a coworker at my last consulting job
and I could not do this personally,
but the way he favored doing things was
he would take literally no days off for the entire year,
but then every single year,
it was just understood that he would be gone
from roughly American Thanksgiving,
so the third or fourth Friday in November,
until the next year.
So he would take all five or whatever weeks of his vacation,
all in one shot, all the end of the year.
And that's what he did every year.
And I think that's bananas personally,
like I couldn't do that all the time,
but for whatever reason, that's the way he liked it.
And that's what he did.
And every time, you know, January came around
and he was quite a bit more refreshed
than he was in late November, you know.
- Yeah, absolutely.
I'm not sure I could do the same thing every year either,
but, 'cause this is actually the first year
I took five weeks off in one block.
And yeah, I'd like to be able to say I'll do it every year,
but I think common sense will prevail.
I won't do it every year,
but at least two weeks, I think, at a time is the minimum.
'Cause if it's only a week,
then you just sort of getting into the swing of things
and then it's back to work again.
I think to sort of decompress,
you really need that second week, but in any case.
So interesting aside,
but not necessarily to do with Agile, but anyhow.
So we're just gonna circle back into Agile again,
just to, while we sort of wrap this up a little bit,
is one of my other frustrations with Agile
is that it tends to lead to poor documentation.
And I know that that's the intent,
but I guess my problem is that I've always been brought up
on the value of documentation.
Like in engineering in general,
software is just another form of engineering.
So I've always believed in it,
but the problem is the debate
about how much needs to be documented.
Yeah, and I feel like there's the code is this,
What's the saying?
The code is the documentation
as opposed to the documentation is the documentation
and the code is the code.
And I guess the problem with that is that
code is never going to be as good as documentation
in so far as you'll never be able to describe in code
as easily as you could read English,
sorry, whatever language you're programming in
versus whatever language you're speaking and vice versa.
I mean, you're never gonna be able to write
unless you're gonna write something like pseudocode.
But if you're starting to write pseudocode to describe code
in a specification, I'd suggest you've potentially
lost the plot.
'Cause I seriously had a manager tell me to do that
in my younger years and I looked at him
with a raised eyebrow and I'm like, "Are you serious?"
So anyhow, I've always believed that
when you're developing any formal software
that you need to have a few essential components
in terms of your documentation.
The first one is a coding standard.
And that's just more of a common comprehension
so that everyone in the team or the company organization
can follow what other people have done,
just basic naming conventions
for variables, object structures.
And I know some people say,
"No one reads the coding standard."
It's like, yeah, well, you're gonna read my coding standard
when I write, you're gonna read that.
But anyway, the point is that
I think that that's an essential cornerstone.
It should not be ridiculously prescriptive,
but it should have the basics.
The next thing you've gotta have, I think,
is a functional specification
about what you're actually delivering,
meaning just what it has to do.
Doesn't have to be ridiculously detailed necessarily,
but there needs to be something saying,
this is what our widget's gonna do.
And then finally,
you need to have an interface specification
for all of your points of interface
with whatever it might be.
Sometimes you don't actually have any
if it's a fully self-contained product,
but generally speaking, you're going to have something.
And in my world,
we sort of tend to combine the interface specifications
and the functional specifications together
because our primary interfaces
are just a human machine interface or HMI.
So we wanna say like what data points,
what's logged, what's alarmed,
what screen the information is displayed on.
But we're gonna stop short of saying,
well, it's 10 pixels down, three pixels across,
or something like that.
We don't bother with that.
We don't do detailed mock-ups generally,
'cause that's just too much detail.
So, 'cause after all, finally,
whatever you produce will be vetted by the end user anyway.
So, what's the point of doing that
other than simply saying,
well, we're gonna have the following items on the screen,
and we'll show you the iterations as we go,
and you can give us feedback along the way.
But what I found with Agile is that,
and I guess your mileage may vary
depending upon the Agile coach maybe,
but in the end I found that it's,
that follows that idea of just barely good enough.
And for me, just barely good enough isn't good enough,
but that's just, I don't know,
that's just my take on it, what do you think?
- Yeah, it's tough because as you said
in the beginning of what you were just talking about,
that the kind of tenet of Agile is not to document.
But this is especially complicated
when you're talking about a consultative role,
because at some point, the team that wrote all this code
is going to go away.
And it's up to the client to maintain it oftentimes.
And so then the client is looking
at this hopefully really great piece of software
with zero documentation on it.
And I think that I agree that not having enough documentation
is a very common ailment with Agile.
But I would argue that if it's something that's really important to either the team or the client,
then you can build in time for that.
You can either build it in in terms of just assuming that it's part of a delivered story.
You can build it in in that you could make an entire story for documentation.
You know, there's several ways in which that you can kind of build all this in
and have it work within the system of Agile.
But I 100% agree with you that it is a very common pitfall
that has happened to pretty much every Agile project I've ever worked on.
And it is kind of disheartening to get to the end of a project
and then realize, oh, I have like one to two to four sprints
worth of work that is nothing but documentation.
Most developers, myself included,
don't really enjoy that.
And so if you can avoid it and kind of keep an eye on it
from the front, I strongly recommend it.
Fair enough.
All right, cool.
So honestly, I guess just to sort of wrap up a little bit
Now, I feel like the fundamental problem
with any kind of, whether it's waterfall, agile,
whatever methodology you might choose to use,
the common thing in all of them is us, like human beings.
The fundamental rule with human beings is that we're,
well, we're lazy.
We don't like responsibility, generally speaking.
And what I mean is we don't like
to be held responsible necessarily.
I think people, that's as a general rule that holds,
there will always be some people
that are happy to be responsible for everything,
but I don't know, maybe they end up being basket cases
or something in the corner at the end of the project.
But anyhow, people also, I think,
generally confuse activity with productive activity.
And I think that just because people are scurrying
around doing things doesn't necessarily mean
that that is actually, you know,
to borrow one of those industry expressions,
moving the needle necessarily.
And I think that ultimately,
whatever system you choose to come up with,
any system can be gamed.
Because the problem with humans is humans think up a system,
whichever it might be, waterfall or agile,
and then all the other humans implementing it,
will then think about ways they can game the system
because they are lazy,
they don't wanna be held responsible,
and they're happy just to be active,
but not necessarily produce anything.
And I realized that that's generic,
but it's meant to be generic
because I don't think that Agile wins or loses over Waterfall
for exactly these reasons.
It's an attempt I think,
and I think largely successful in certain environments,
it can be far better than Waterfall
where you don't have high documentation requirements
where you do have to pivot
because the success of your business,
depends on it being as agile as possible
because if you can't pivot and actually change the direction
because the product or the market has moved
in a different direction.
If you don't do that, you'll just cease to exist.
So, and when you're threatened with that sort of thing,
you have to work very hard and compete very hard
in order to survive.
And that's just the way it is with survival of the fittest.
So applied to Silicon Valley terms, I guess, but anyway.
So I don't think that agile in the end is bad in isolation.
I think the problem is that agile
and I think you may have even led into this
from the very beginning is that it's,
there are lots of little pitfalls
and people can let their egos get in the way,
people try to game the system.
Ultimately, it can be just a bad implementation
just because people don't understand
how it's supposed to work.
They haven't comprehended what it's intending to do.
And in the end, it's given Agile a bit of a mixed reputation.
Some people love it and embrace it.
Some people can't stand it.
Some people say it's just the latest buzzword methodology
that is this going to, in another five years, not only talking about it, but in the end,
I think that the overall, the software industry as a whole is better for it than without it.
Yeah, I think you're right that as with anything, it is easy to fall into the trap of this is
not really working for my team or for my company and for whatever reason, and maybe it's innocent,
it's been sabotaged, whatever. But I have lived many, many poorly done Agile projects, and they
are a slog, and they are tough, and they are frustrating. But I've also lived at least a
handful of really good Agile projects. And I can't stress enough that in that perfect scenario,
when everything really, really works the way it's supposed to, it really is like magic.
and you have repeatable results, predictable results,
which is what Waterfall really strives to be,
is deeply predictable.
You have that in Agile.
I've seen it in Agile.
But you gotta trust the system,
and you gotta have an environment
where the system can work.
And obviously, I've had very, very many prescriptive thoughts
about what I think is a good implementation of Agile.
But ultimately, if you really trust Agile through and through,
you've gotta figure out your own system
that works for you and your organization.
But in a perfect world where story points aren't really ours in disguise and where
product owners understand the trade-offs and where you're not getting swoop and
poops all the time, in a perfect world, Agile is an unbelievably fun and reliable
way to write software.
And so I don't see it going away anytime soon, but it is one of those things where
you know, we've given you a length of rope that you can quite easily strangle
yourself with, but you can also fashion it into a very nice knot.
And so I hope you end up with a knot and not a noose.
Nice. And in, in the end, ultimately it comes down to, um,
you know, people in the end, how motivated they are,
how aligned they are with delivering an outcome, you know,
keeping it technical, listening to the,
the leads involved in the product owners and just, and delivering on that.
And I think that in the end, people that are determined to not make agile work will be
determined to not make it work and will then complain and that'll be evidence to say, "Well,
that's why it doesn't work."
So I feel like if you do, like you said, if you actually go all in and you actually work
within the methodology, then it can be - it can actually work out quite well in the right
situation and it may well be magic.
I'll be honest with you, I haven't actually seen that firsthand,
but I do know that it's possible.
So I'm not going to be too old and curmudgeonly and say anything about,
Agile is just never going to work or whatever else. No, no, not at all.
Not at all. I think it has some interesting merit. So in any case.
Alrighty. Well, if you want to talk more about this,
you can reach me on the Fediverse at chigi@engineered.space,
or you can follow engineered_net on Twitter
to see show specific announcements.
We also have a YouTube channel
with more content going live regularly
if you're interested in that.
If you're enjoying Pragmatic
and you wanna support the show, you can.
Like some of our backers, Carsten Hansen and John Whitlow.
They and many others are patrons of the show via Patreon
and you can find it at patreon.com/johnchidjie or one word.
Patron rewards include a named thank you on the website,
a named thank you at the end of episodes,
access to raw detailed show notes,
as well as ad-free high quality releases of every episode.
So if you'd like to contribute something, anything at all, there's lots of great rewards
and beyond that, it's all really appreciated.
Beyond Patreon, there's also a PayPal for one-time contributions at paypal.me/jheg.
But if you're not in a position to support the show that way, that's completely fine.
There's lots of other ways you can help, leaving a rating or review on iTunes, favoriting the
episode in your podcast player app, or you can share this episode or the show with your
friends or via social.
And all these things help others to discover the show and can make a huge difference as
well.
to thank Clubhouse for sponsoring the Engineer Network. If you're looking for an easy to use
software development project management solution that everyone can use, remember to specifically
visit this URL clubhouse or oneword.io/10theword to check it out and give it a try. It'll surprise
you just how easy it can be. Pragmatic is part of the Engineer Network and you can find it at
engineer.network along with other great shows like Causality, which is a solo podcast that I do that
looks at the cause and effect of major events and disasters in history, including the Deepwater
Horizon just recently, the Columbia Space Shuttle, Concorde, and lots more. Causality
is on track to overtake Pragmatic. It's growing in popularity. So if you haven't yet checked
it out, make sure you give it a listen. If you'd like to get in touch with Casey, what's
the best way to get in touch with you, mate?
I am on Mastodon somewhere, but almost never pay attention to it and don't remember what
my handle is, so I'll just skim right through that. But you can find me on the dumpster
That is Twitter at Casey lists
Casey YL ISS you can also find my website at Casey list comm and
My other podcasts that I do the external tech podcast is an ATP dot FM and analog is that relay dot FM slash?
Analog spelled either the correct way or the way that has a unit
Smooth okay, well once again a special
Thank you to our patrons a big thank you to everyone for listening and as and as always
Thank you once again for coming on the show Casey. Yep. Thank you John
It's oh, it's always a pleasure. I appreciate
[MUSIC PLAYING]
(upbeat music)
(Music)
(upbeat music)
[Music]
(upbeat music)
♪ ♪
[Music]