0:00

Welcome to Pragmatic.

0:02

Pragmatic is a discussion show contemplating the practical application of technology. By

0:20

exploring the real-world trade-offs, we look at how great ideas are transformed into products

0:23

and services that can change our lives. Nothing is as simple as it seems.

0:27

This episode is brought to you by Clubhouse, the first project management platform for

0:30

software development that brings everyone on every team together to build better products.

0:34

Visit this URL clubhouse or one word dot IO slash TEN the word for more information. We'll

0:40

talk more about them during the show. Pragmatic is part of the Engineered Network to support

0:44

our shows including this one. Head over to our Patreon page and for other great shows

0:48

visit engineered.network today. I'm your host John Chidjy and I'm joined today by Casey

0:53

Liss. How you doing Casey? Hello. How are you sir?

0:56

Very well. Very well. Thanks for coming on the show. It's been a little while since we've

0:59

had a chat? Yeah, the last time was slightly antagonistic because I was explaining to you why metric

1:05

units are silly, and at least I believe that was the last time.

1:09

Yes, well, I just love the way you phrased that, and that was not exactly my recollection,

1:14

but you know what, yes, listeners, if you'd like to go back in here.

1:19

I poke fun because I laugh. No, just before you get a million emails, "Imperial units are dumb with the exception

1:26

of Fahrenheit." defend Fahrenheit until my dying breath, but everything else that we do in America is silly.

1:31

So we can just move on as quickly as possible.

1:34

And on that point, by the way, because I actually agree with that and I have occasionally referred

1:38

to temperature in Fahrenheit to my family and they look at me funny and I just smile.

1:43

So never mind that. But today we're not talking about Fahrenheit.

1:45

We're going to talk about, I would like to talk about something else, something that

1:49

has more recently come into my professional life and something that I think that you've

1:52

been enjoying/dealing with for probably longer than your career.

1:57

That's very accurate, very well put.

2:00

So yeah, and that's Agile software development.

2:06

You ready for this? Yeah, yeah, let's do it.

2:08

Okay, so I just want to start at just roughly a little bit of a history and timeline of

2:15

Agile, not to go into too much depth, but during the 90s, I think a lot of people in

2:19

in the software space in particular sort of said,

2:21

well, we need to look at some way of doing development differently

2:24

'cause software is different, software is special. So we're gonna try some different things.

2:28

And so in the '90s, there was this rapid sort of series of ideas

2:33

every few years. And one of the first one that I could find

2:35

that it was tangentially related to Agile was something called Rapid Application Development or RAD.

2:41

Not one I personally came across, nor was the next one, the Unified Process in '94.

2:47

I'm not sure, did you ever come across either of those?

2:50

- I've heard of them, but I can't say I've ever practiced,

2:53

or knowingly practiced either, but I've certainly heard of them, yeah.

2:56

- Yeah, so this is the thing is that I sort of, I was aware of them, but it wasn't until Agile

3:01

that some of their methodology sort of became, oh, okay, so that's what everyone now calls Agile.

3:05

So the next one was Dynamic Systems Development Method,

3:08

or DSDM. Apparently that was quite popular, apparently.

3:13

I actually had never heard of it until I was doing the research.

3:16

But this is the one everyone does know in 95 and that's Scrum.

3:19

So, yeah, we're going to get to that.

3:22

And then 96 was extreme programming.

3:24

And that's where I started to write. Yes. Okay.

3:27

I came across extreme programming and then 97 feature driven development, which when,

3:31

when I said that was a programming methodology that came up in 97, I thought that's,

3:35

isn't that the way it was always done? But no, apparently there was a specific.

3:40

Anyway, whatever.

3:43

So bottom line is all of these rolled up

3:45

and certain elements of them in 2000 or 2001.

3:49

So the story goes, apparently 17 developers

3:52

and there was a list of names, I'm not gonna read them,

3:54

but anyway, they went to somewhere in Utah,

3:56

again, not too concerned where, but it was in Utah.

4:00

And they came back with a manifesto for agile software development.

4:05

And that's more or less where the whole term agile

4:08

came from and a lot of things being attributed to agile

4:11

over the last, over the 10 years since then,

4:15

in that decade, led this group,

4:17

they call themselves the Agile Alliance.

4:20

And in 2011, they published the Guide to Agile Practices,

4:23

just like a reference book of sorts. There's a link in the show notes

4:26

if you're really keen and interested. I actually find, because, yeah, in my,

4:31

as I'm trying to ramp up my understanding and knowledge

4:34

of what the heck Agile is, I've actually found that site to be very, very helpful

4:38

because people will fire off some term

4:41

and I'll be like, what? And they're like, oh, that's agile.

4:43

So I'm like, oh, okay, great. So I have a look in this, oh yeah, right.

4:46

Okay, that's what that means, okay.

4:49

So I'm kind of glad they did that. And to be honest, in my personal experience then,

4:55

I'm an electrical engineer,

4:58

I do control system software development,

5:00

but the funny thing, I say funny, well, the thing is that in engineering in my space,

5:05

it's taken a bit more time to sort of encroach upon our area of development.

5:12

And it has in the last probably two to two and a half years.

5:16

And that's just been the company that I've worked in has had some, shall we say, consultants

5:23

of whatever, and they're from some of them have had extensive experience in Silicon Valley.

5:29

And so several things came over with them when they came over to consult and Agile was

5:33

one of them. to the point at which our entire organization is now embracing agile, which is in fact one

5:41

of our, I don't know what you call them, tenants or whatever else. It's one of those mottos

5:46

that they go on and talk about regularly, embrace agile. So, can you tell me a little

5:53

bit about your history with agile at all, Casey?

5:56

Yeah. So, most of my development career, pretty much everything I did up until my very last

6:02

regular job was doing consulting. So it was either government contracting, which is kind

6:10

of a corollary to consulting. It's consulting, but it isn't. Or just regular straight up

6:16

consulting. And so what that means is a company, Acme Widgets Incorporated, comes to my company

6:23

and says, "Hey, we have this software that we need written custom for us. Can you provide

6:28

us a team to do it. And so I was doing project-based consulting where it was a team of myself and

6:34

my coworkers would get embedded with a team of the clients and we would work as one unified

6:41

team to create a bit of software. And typically that meant that there were either no developers

6:47

on the client side or just one or two. And generally speaking, there would be a product

6:51

owner, which we'll probably end up talking about later, on the client side that's kind

6:55

of directing things and making decisions, but for the most part, it was just myself

6:59

and my coworkers doing all the work.

7:01

And that was most of my career. I definitely, especially in the government contracting, which was very early on in my

7:07

career, we had something, we definitely worked more in a waterfall method.

7:12

So the two kind of poster children for the two generally accepted ways of doing software

7:19

development that are not that radical, one of which is waterfall, which basically my

7:23

summary and I'll let you correct me John is let's figure out as much as we

7:27

possibly can up front so writing the software when we finally get to that

7:32

point it's almost paint by numbers you know it's as much as possible has

7:35

already been figured out all of the all of the weird edge cases have been

7:39

figured out all of the decisions have been made and by the time you're

7:42

starting to write software if everything goes according to plan then there there

7:46

are no questions left to be answered you just have to write the code is that kind

7:49

of a fair summary? Yeah, I think so. And I definitely do think that it's those are the

7:55

comparison with Agile that people most regularly make is Waterfall is what it's Agile versus

8:01

Waterfall. And the funny thing I always thought about Waterfall is back when we were doing

8:05

engineering development, we didn't actually call it Waterfall, we just called it like,

8:09

you know, programming. So I don't think it's exactly quite as clear cut as a retronym or

8:16

or something like that. - Sure. - But I do think that it was just something that,

8:19

yes, that's what it was called, but no one talked about it like that.

8:22

But since Agile came around, yeah. And I think your description of waterfall is pretty accurate.

8:25

The way I describe it is you've got

8:27

extensive requirements definitions, you do a detailed design,

8:31

development or implementation comes next,

8:35

then you do your verification and tests, and then you hand over and maintain.

8:38

And that's kind of the waterfall methodology.

8:41

Whereas Agile's not designed quite like that.

8:44

It's more about- - No, not at all. - No, and I always,

8:48

and so this is my turn to have a stab at Agile.

8:51

So tell me how it goes. That requirements are essentially whittled down

8:56

into very small deliverable components

8:58

and documentations generally very light,

9:00

then development and tests are part of each iteration

9:03

and with each idea and each iteration

9:06

is a single usable component. And then the result of that is used

9:10

to inform the next iteration,

9:12

whereby the requirements can change along the way

9:15

based on each iteration can actually

9:19

impact the final direction, rather than having

9:21

a complete set of detailed requirements up front.

9:24

- Yeah, yeah, I think that's exactly right. So the idea is in Waterfall,

9:28

you're not actually writing any code until pretty much all the decisions have been made.

9:31

And again, there's gray areas in everything we're saying,

9:33

but the generally accepted version of Waterfall

9:35

is let's figure out all our requirements, let's figure out how we're gonna test it,

9:39

and then let's write the code, and then let's test it, and just like you said, then let's deliver it.

9:43

Whereas with Agile, the idea is, hey, we may not even know exactly what we want.

9:48

And the only way we're really gonna figure out what we want is to start using the thing, the widget.

9:52

And so let's break off, just like you said, John,

9:55

let's break off a small piece of this widget

9:57

that we really need to get done and let's try it

10:01

and let's see how it goes. And then based on how this small component of the widget is,

10:07

then we can either continue down the same path

10:09

we had before, or we can pretty violently swing,

10:12

you know, left, right, up or down, and make different decisions now that we've actually had a

10:16

chance to use that widget. So the idea is that you are constantly delivering something

10:21

of value, and you're constantly changing your direction based

10:26

on those deliverables. You could say, John, that you're acting in an agile

10:30

manner, and hence the name.

10:32

And so if you look at the manifesto for Agile software

10:35

development that you had brought up earlier, I think

10:37

there's a small portion that is worth reading verbatim.

10:40

And this is from the original 12 or 15 or whatever authors.

10:43

And it says, "Blah, blah, blah, blah, blah.

10:45

Through this work, we have come to value individuals and interactions over processes

10:49

and tools, working software over comprehensive documentation, customer collaboration

10:54

over contract negotiation, and responding to change over following a plan."

10:59

And then it continues, "That is, while there is value in the items on the right,

11:04

which is processes and tools, comprehensive documentation, contract negotiation,

11:07

following a plan, we value the items on the left more.

11:11

individuals and interactions, working software, customer

11:13

collaboration, and responding to change. So my understanding of

11:17

the history of agile, and the spirit of agile was, in summary,

11:21

let's put a team together, let them figure out their own team

11:25

norms, you know, let's let them figure out how they want to work

11:27

and just start working and then change if something isn't

11:30

working. And that's basically it. Now, what's ended up

11:33

happening, though, is because business and because big

11:35

business, there has become a kind of accepted series of steps and rules and processes in

11:44

order to do what is "agile."

11:46

As you were saying earlier, John, I think what's kind of unfortunate about agile and

11:49

waterfall actually is that they've kind of become these all-encompassing terms that are

11:54

basically distilled to, "Do you figure it out in the beginning and then write code,

11:59

or do you write code and figure it out as you go along?"

12:01

kind of the big difference if you were to distill it as much as possible.

12:05

And so I really like Agile and I've seen it work really, really, really well, but

12:12

I've also seen it work really poorly.

12:14

And unfortunately, in my experience, it is way more likely that you will have a

12:19

poor implementation, for lack of a better word, of Agile than you will a successful

12:24

one. And certainly whenever you're ready, we can start talking about what I see is the

12:27

differences between the two and my recommendations for them.

12:30

But I think that the crummy thing about Agile is that I

12:35

really do believe in the spirit of what it's trying to

12:38

accomplish. And I even believe in the kind of prescriptive way that most

12:41

companies, at least here in the States, tend to do it.

12:44

But all too often, it gets twisted up and mutated into

12:50

something that will also often derisively

12:53

be called scrummer fall. So scrum is a generally accepted component of Agile,

12:58

which we'll get to in a minute. And then waterfalls exactly what we described.

13:03

And so what ends up happening is you kind of end up with waterfall

13:06

where you get together for a 15 minute meeting every day to talk about how things are going.

13:09

But everything else is waterfall. And that's not really agile at all.

13:13

And that's a trap that's easy to fall into.

13:16

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,

13:27

I guess ultimately organizations, the whole thing that you said about how people get together

13:34

and figure out how it works as they go, kind of thing is it's sort of a bit fraught with

13:41

danger because sometimes you can sort of get off on totally different tangents, typically

13:45

have different ideas about how it should work or shouldn't work.

13:49

It's interesting and they have this idea of an agile coach and a lot of teams have an

13:55

an agile coach to try and prevent some of that stuff,

13:57

which is another interesting role, but nevermind,

14:02

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

14:08

of Waterfall is to ensure that you have well-documented,

14:11

detailed requirements up front, agreed and understood.

14:14

And you accept the fact that detailed design

14:17

is gonna take a significant amount of effort up front.

14:20

But the ultimate aim is that if you design it right

14:22

with the correct objectives from the very beginning, then you only need to do one implementation

14:26

and that will avoid scope creep and it'll avoid rework.

14:29

That's the theory, anyhow.

14:31

Agile, on the other hand, aims to ensure that you just keep those requirements

14:35

to a bare minimum set to make something that a customer could see or use

14:40

that they can agree quickly. And then rather than document it to death,

14:44

you just iterate a small step at a time

14:46

until you've got a happy customer with that outcome.

14:48

And you just keep doing that until you reach something where they're like,

14:50

"Yep, we're done." That was another way I think of sort of like spinning it.

14:54

But another way of thinking about it is predictive

14:56

versus sort of adaptive whereby Agile is intended

15:00

to be more like an adaptive sort of a technique with a much looser change control

15:03

when you can adjust direction as it develops. Whereas predictive,

15:06

which is more like the waterfall approach is more about you have strict change control.

15:10

And if you wanna actually change scope

15:14

and change your requirements and such, you have very strict rules around actually ensuring

15:21

that doesn't happen unless it's costed, funded and so on to reduce the scope creep that would

15:26

otherwise affect your deliverable deadline.

15:29

In any case, whichever way you want to think about it between Agile and Waterfall, it always

15:35

comes back to the customer because in the end, the customer or the owner, the fact is

15:39

that the people do change their minds irrespective of what model you want to use.

15:45

As we do do iterations, people learn things as they go and they feedback that back into

15:49

whatever project you're working on. And the other problem is of course,

15:52

that as time progresses, that can change requirements as well.

15:55

So, you know, markets change, you know,

15:57

so suddenly we've been spending six months

15:59

developing something for a certain purpose, though that's no longer required anymore

16:02

because some other technology in the marketplace

16:05

has completely and utterly made that,

16:07

you know, no longer relevant. So I guess my thing is with,

16:14

my take on Agile, generally speaking,

16:17

is that it was born out of that fast paced sector,

16:21

and I don't wanna say that all development is like this

16:25

'cause it isn't, but I think it's come more from the fact that it's like maybe a Silicon Valley

16:30

sort of VC backed, maybe a bit web centric

16:33

or consumer software areas,

16:35

where there's a lot of movement in the market

16:38

and to be relevant and successful, you have to be agile,

16:41

or otherwise you get left behind, I think.

16:43

And I think that seems to have been where the whole idea was really born and is driven from.

16:48

Yeah, and I think what you said a moment ago about, you know, the customer or the product

16:52

owner will change their minds. I think that's kind of the critical piece here is that inevitably the person you're

16:59

delivering software for or persons you're delivering software for, they're going to

17:03

make a change or decide that they want to go left instead of right.

17:08

And what Agile is about is embracing that change and trying to uncover that change

17:13

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

17:21

happens. So the times that I've seen Agile work really well is when we have short sprints, which

17:28

is to say for usually about two weeks, we will bite off a chunk of work and say, "Okay,

17:35

we are dedicating ourselves to complete this work in two weeks."

17:40

And generally speaking, the chunk of work you bite off, which we'll get to in a minute,

17:44

with story points and things like that.

17:46

The chunk of work you bite off, that may not be that much because it's typically better

17:51

to underestimate your own speed than overestimate.

17:54

And every developer I've ever met

17:57

always thinks it will go easier than it ends up going.

18:00

So, the idea is each developer

18:03

and the other members of the team will bite off some chunk of work

18:07

that is pretty clearly deliverable within a two week

18:10

or whatever your sprint length is, but typically it's two week timeframe.

18:14

And then the idea is you work, work, work, work, work,

18:16

get through those two weeks, and hopefully at the end of those two weeks,

18:20

you have something tangible to deliver to the customer,

18:24

or at least demo to the customer. And then the customer or the product owner can say,

18:27

"Oh, I like this, I don't like that, "I like this, I don't like that."

18:30

And that will inform what the next two weeks,

18:32

the next sprint will be. And generally speaking,

18:35

there's some ceremony around that. You'll typically at the end of each sprint,

18:38

you'll have a retrospective, which is a meeting wherein you say,

18:40

"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

18:47

the beginning of the sprint where you'll figure out, okay, you'll do estimation and figure out,

18:51

okay, how much time do we think each of, well, I shouldn't say that. How many points do I think

18:55

each of these things will take? And again, we'll get to that in just a second. And then we'll

18:59

figure out, okay, well, John, you'll do this story. Casey will do this story. Susan will do

19:06

that story. And Jennifer will do this story and so on and so forth. And then we'll just kind of go

19:10

into our corners, if you will, and work, work, work, work, work until the end of the sprint.

19:15

Now, what I've seen go terribly wrong, and I've already made that mistake myself, is

19:20

where you judge effort based on time rather than relative difficulty.

19:25

So there's no real prescription, if you look at the manifesto, for how you manage what

19:33

work you're doing and when you're doing it.

19:35

But the generally accepted way of doing Agile, at least in my experience, is you use something

19:40

called stories and story points. So a story is an executable thing.

19:45

And oftentimes it'll be written in the form of, as a, some kind of user, I

19:50

would like to do something in order to accomplish something.

19:54

So as a user, I would like to register for the service so I can use it as an example.

20:00

So it's clear who is interested in this, what the persona is, what it is they

20:05

want to do and why they want to do it. And that would be your story.

20:08

And of course, there's other requirements and things and whatnots and addendums

20:12

that may be involved in that. But at its core, a story is as a user, I would like to register

20:17

for the service so I can use it. Then what you do is during the planning period or planning meeting or what have

20:23

you, and sometimes it's called grooming, you'll see very different names for this

20:26

that serve ever so slightly different purposes, but the idea is sometime before

20:31

the sprint begins, you and your team will get together and figure out, okay, how

20:35

difficult is this to accomplish? How difficult is it to allow a user to register for this service?

20:42

And the idea is you want to use relative difficulty.

20:47

So you don't say this'll take me eight hours because it never takes eight hours.

20:51

It either takes two hours or 40 hours.

20:54

So don't describe it in terms of hours.

20:57

Just describe it in terms of how hard is this.

21:00

And sometimes you'll use what I've often heard called t-shirt sizing.

21:03

So you'll either say it's small difficulty, medium difficulty, or large

21:07

difficulty, and that's as granular as you need to get.

21:09

Occasionally you'll see that, but more often than not, you'll use story points,

21:13

which is a Fibonacci, is that right? A Fibonacci sequence of, oh God, it's been a while since we've done it now.

21:18

So one, two, three, five, eight.

21:21

No, that's not right. One, two, three, is it right?

21:24

Something like that. I, I, yeah, but yes, Fibonacci indeed.

21:29

Yes. That. I'm a little out of practice cause I haven't done it in a few months, but,

21:32

But you get the idea. And so the idea is, okay, what is the smallest tangible change that we can make?

21:41

And let's call that one. So maybe it's changing a color on a web page.

21:46

Maybe it's changing copy on a web page. Or maybe it's moving a button on an iOS app or something like that.

21:52

What is the smallest piece of work that we can all agree upon?

21:56

Everyone in the team. Let's call that one point.

21:58

Okay, well with that in mind, with changing the background color of a web page being one,

22:03

is allowing a user to register for the site, is that twice as hard?

22:09

That would be a two. Three times as hard?

22:11

Well, guess what? You've got a three.

22:13

Is it five times as hard? Well, now you've got a five.

22:15

Maybe it's eight times as hard. Now you've got an eight.

22:17

And this continues on to 16 and whatever else comes after.

22:21

But generally speaking, in my experience, if you find something that is more than eight

22:27

times more difficult than whatever you think a one is, then it's probably

22:30

too complex to be one story and you probably want to break it down into,

22:34

you know, kind of subordinate or child stories.

22:36

But I don't come into a point here.

22:38

I promise. The idea is each of these stories, you will, as a team, you will figure out,

22:44

okay, this story is one point that's six, or six isn't an option, five

22:47

points, that's eight points, and you will kind of figure out, okay, what

22:50

is the relative difficulty of each of these stories?

22:52

Yeah. And for the first sprint or two, you just kind of bite off some

22:56

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.

23:02

And maybe you accomplish 15.

23:05

And so the next sprint, you'd maybe bite off 18 because you think that

23:09

first sprint was a little weird.

23:11

And maybe the second sprint you accomplish 14.

23:15

Well, after you get a couple sprints under your belt, you start to figure

23:19

out that no matter how optimistic or pessimistic this team is, history

23:25

tells us this is how many points we can accomplish.

23:27

And this is where agile gets to be magical because you now have a

23:32

history and unemotional, it has nothing to do with estimates.

23:37

It's just a history of how much work this team can get done.

23:41

Well, now if you keep your estimation of story points, pretty

23:46

consistent across sprints, now, you know how to plan because you know

23:51

that your, it's not cadence. What's the word I'm looking for?

23:54

Velocity. Your velocity is 15 points, and I'm making that up, of course.

23:58

Well, you know that this team tends to be able to do 15 points per sprint.

24:03

And we have a backlog, we have a list of stories that's 300 points long.

24:07

I'm not going to do that mental math because I'm too lazy, but you know

24:10

that that will take X amount of sprints to get through those 300 points.

24:13

And suddenly you've gotten a very predictable outcome in terms of real

24:20

world time, even though at no point during the Agile process

24:24

have you said anything about how many hours this is going to

24:27

take. And this is quite the contrary for many waterfall

24:30

implementations where you'll say, okay, that unit of work is

24:32

16 hours, that unit of work, at least the way I've done it, is

24:35

24 hours, etc, etc. But inevitably, like I said earlier,

24:38

no matter how many hours you think something is, you're going

24:41

to be wrong. So the key is, screw talking about time, let's

24:44

just talk about relative difficulty. And again, don't

24:48

Don't trust what your developers think because we're all idiots.

24:50

None of us, I mean, I'm sorry, John, but I'm going to lump you in there.

24:52

None of us can estimate worth a darn.

24:55

So let's just say how hard is this and about how much work is it, have we demonstrated

25:01

we can accomplish? And then that's where it becomes so great because now it becomes predictable.

25:07

I've been talking for a long time. Does that make any darn sense at all?

25:12

The scary thing is that all of that makes perfect sense.

25:15

And the interesting thing and okay, so you covered a lot of ground there.

25:18

So let's just go back a couple of steps or points.

25:22

Anyhow, that wasn't funny.

25:24

Sorry. Sorry, delete reaction on that one.

25:28

That's all good. Anyhow, so all right.

25:30

So on the story points, with the velocity, just before I get stuck into my little rant

25:35

is did they ever do different teams and have different KPIs for their velocities?

25:41

Then they sort of play them off against each other.

25:44

this team's doing this falsely, this team's doing it.

25:46

Did I ever do that to you? - Yeah, occasionally.

25:48

So a KPI is Key Performance Indicator.

25:50

And a lot of that's very trendy these days,

25:52

that all of your work as a developer, as a product owner,

25:55

as a designer, as a QA engineer,

25:57

should be at what am I doing to affect

25:59

the key performance indicator, whatever that may be.

26:01

And yeah, that's the problem,

26:03

is that if you really do Agile right,

26:06

every individual Agile team

26:08

could have a wildly different velocity.

26:10

So as an example, maybe John and I think everything is impossible.

26:13

And so all of our estimates are like 8 points, 16 points, you know, 24 or whatever points.

26:18

Sure. That, I wouldn't advise that, but that's okay because as long as we're consistently

26:24

overestimating, then it's fine.

26:26

But you can't take our estimates, John and Maya's estimates, and compare it to

26:31

Jennifer and Susan's estimates because they might be actually quite a bit better

26:35

at estimating where a one is really a one and eight is really an eight and so on and so forth.

26:38

forth so yeah playing playing teams off each other is a terrible terrible terrible idea.

26:43

Yeah and that's why people do it generally because it's a terrible idea. I just you know it's just

26:49

it's it's just something with me that I find very grating it's like no no no sooner had I learned

26:55

what story points were did I find out that there were different teams already being graded against

27:01

how much they could get through in terms of points I'm like seriously guys anyway all right not

27:05

Not wishing to go down that road too much,

27:08

but in any case, the thing that I find interesting

27:11

about Agile versus Waterfall is that the way in which

27:14

the points and the collaboration,

27:18

the collaborative nature, I guess you'd say, before the sprints actually kick off,

27:21

you know, you actually get into them.

27:23

Yeah, that whole discussion is, it's more collaborative

27:27

and that has both positives and negatives.

27:29

In Waterfall, the way it's been previously done,

27:32

is my observation, is that it'll go to

27:34

whoever the senior designer is or the senior developer is.

27:37

And they'll be told, okay, well, how long is it gonna take this?

27:40

And they'll draw based on their knowledge

27:42

of the individuals involved,

27:45

throw in some fudge factors for how long, how many interruptions they think they're gonna get

27:48

with other activities, other calls on other people's time during,

27:52

'cause if you're outside of a sprint,

27:55

you've got all sorts of distractions and so on,

27:58

and you have to account for that in your time estimate.

28:01

So, the old rule thumb was,

28:04

if you have a long you think it is double it and add some.

28:06

- Yup. - And yeah, exactly right. And so you start building out that schedule

28:10

all based on experience, based on,

28:13

rather than a prescriptive, like this team can produce X amount of points

28:18

in this amount of time, generally speaking, based on previous cycles and such.

28:23

With Waterfall, it's all, most of it seems to come down to a negotiation.

28:27

And the problem, this is the next part,

28:29

is in negotiation, when schedule,

28:31

because you're dealing with time, you will often be butted up against a project manager

28:35

and the project manager is gonna say, "Wow, could you shave a few weeks off that?

28:40

Could you please, that'd be great."

28:42

And I've had many, many an argument

28:44

with project managers in my career about,

28:46

can you deliver this sooner?

28:49

And I'm looking at it and I'm thinking, have you read the mythical man month just for a start?

28:53

(laughing) And are you feeling pregnant today?

28:56

And of course it usually goes right over their head,

28:59

but in any case, that's, yeah, anyway, nevermind.

29:02

So the funny thing is that I actually liked the approach

29:06

of two parts of this with Agile, which is the first one is the decoupling of time from it

29:11

so that you're based on points. I always found Fibonacci to be a bit weird,

29:15

but then I sort of understood the thinking behind it

29:18

is to provide that decoupling. So it's more based on effort than time.

29:22

And it's also about relativeness.

29:25

I was gonna say relativity, but no. (laughing)

29:28

Relativeness, yeah. because effort of how hard is this function

29:33

versus this function versus this function,

29:35

humans are really good at telling the difference

29:37

between is something bigger or smaller

29:39

and when it's put side by side. But if you give them something on its own and you say,

29:43

well, is that bigger or smaller than something else that you can't observe, then people are like,

29:47

well, I don't know, maybe.

29:50

So I do like that concept.

29:52

And I also like the fact that it's more collaborative

29:54

and that's really good. Now, those are the positives.

29:58

And the negative side of that is that I have also found the whole Story Points thing to

30:03

be quite, it can become very, it's like any group think kind of situation where you've

30:09

got a group of people and I find that sometimes the estimates tend to be either way too aggressive

30:14

or way too relaxed. And certainly that's something that gets refined the more sprints you do, but that all assumes

30:20

that you've always got the same group of people in the same environment in each subsequent

30:24

sprint. And that has, my observation has been that is not the case.

30:26

And maybe that's just because we've been doing agile stuff when we've been in the midst of

30:30

reorgs and so on and so forth, and people come and go from different teams.

30:33

And maybe we never had enough time to settle over a longer period.

30:37

It's possible that my perception of that is tainted by the environment that I've been

30:41

in. I'm not sure.

30:43

Did you ever see anything like that? Oh, absolutely.

30:45

And the tough thing is, in order to really have a velocity that counts and that is repeatable

30:53

and accurate. In order to do that, you need to allow yourself two to four similar sprints where

31:05

you're not having a lot of interruptions, or if you are having a lot of interruptions, there's a

31:08

similar amount of interruptions across each sprint. But it isn't until sprint three, four, or five

31:15

that you really start to settle into a velocity. Now, that doesn't sound that bad until I remind

31:19

you that each of these sprints is at least two weeks. So two sprints means you need at least a

31:25

month of real-world time before you have even a prayer of knowing what your velocity is. And even

31:31

then I would argue you haven't really settled down for another one to two sprints, which means up to

31:36

two months before you've really figured out a velocity. And that's the tough thing is that

31:41

I think Agile's promise is that it's a silver bullet that will give you

31:47

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.

31:59

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.

32:08

But as long as you are treating that team in isolation, and as long as that team is

32:13

consistently saying everything is easy or consistently saying everything is hard, the

32:18

velocity will reflect that. Because if you have a team that was constantly saying, "Oh, this is cake.

32:22

That's one point. That's two points. That's one point. That's two points."

32:25

Maybe your velocity is five for a team of six people.

32:28

Maybe you're only delivering five points every two weeks.

32:31

And that's okay as long as you're consistently estimating everything as

32:35

being super easy, because the velocity will be super low.

32:38

Similarly, if you think that everything is eights and thirteens and whatever's, as

32:43

long as you're consistent about it, maybe that team's velocity is 60.

32:47

And the key here, and this is what you've been saying a couple of times, John, and

32:51

I can't agree with you enough, is that you have to treat that number in isolation.

32:55

My 60 on my team could be even slower than the 10 that your team is getting.

33:01

It's just about the way in which that particular group of individuals estimates.

33:06

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.

33:33

Yeah, exactly. And that's something that's not always cleared when people get involved

33:37

with an agile. And they try and turn it into - well, my experience is that some managers tend

33:42

to turn it into a KPI driven sort of contest and I find that really, really irritating. And

33:47

mind you, I also have general mistrust of KPIs no matter what they are but

33:52

irrespective of that. So, just to focus on something in particular and it's something

33:57

that technically, and I said before, it was a 1995 thing, Scrum, and it sort of becomes

34:04

synonymous with Agile and the whole idea of sprints as well. And if you haven't been involved

34:12

in one of these things, I don't know, maybe I'm just deluding myself that there's any

34:17

software developer in the world right now that hasn't ever done any Agile. Surely, I

34:21

think at this point it's been around for well, over 15 years. I think most people would have

34:26

at least had some experience with it, but how would you best describe the process of

34:32

a sprint, let's say?

34:34

Yeah, so again, every team, if you really follow the spirit of what Agile says, every

34:39

team will come up with their own process. But the generally accepted way of doing Agile

34:43

is that either at the very beginning of the sprint or even better toward the end of the

34:47

prior sprint, you will have grooming is what we typically called it, which is to say you'll

34:52

look at the next, I don't know, 5 to 10 to 15 cards on the

34:55

backlog, the things that are the most important things to be done

34:59

next, and you'll point them. You'll say, "Okay, that card,

35:03

that story, that user story is one point, that's eight points,

35:06

that's five points, that's three points, etc." That's step one.

35:09

And then sometimes in the same meeting, sometimes in planning,

35:12

which is a different meeting occasionally, you will actually

35:15

start saying, "Okay, given our velocity is 10, Casey needs

35:19

three points, John needs five points and Jennifer needs, you know, what

35:23

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,

35:29

let's get everyone situated for the next sprint. Then occasionally people will do a kickoff at the beginning of

35:34

the sprint, but typically not. But basically once the sprint begins and once planning has happened, everyone

35:40

just kind of goes into their corners and does their work and is mostly left alone.

35:43

If all goes according to plan, except for a daily scrum and the, the idea behind a

35:49

daily scrum is let's all come together, typically for 15 minutes or less, and say, "What did

35:55

I do?" either today or yesterday, depending on if it's an early scrum or a late scrum.

35:59

But basically, "What did I just do? What am I about to do? And what's in my way?" So,

36:05

oftentimes you'll find these done in the morning. So it's typically yesterday, today, and blockers.

36:10

So yesterday I worked on the foo widget. Today I'm working on the bar widget. And my blocker

36:16

is I need a design from our designer for the bar widget. And that's a nice way to force

36:22

the entire team to come together, talk to each other, and figure out kind of the state

36:26

of the world. And this predates Slack. This predates most IM services. I mean, it doesn't

36:32

predate IRC, but you get the idea. It forces everyone to come together and talk to each

36:35

other. A lot of companies will actually force you. Well, first of all, they'll call them

36:39

stand-ups rather than scrums, and that's because they will literally force you to stand up.

36:43

Because the idea is, if you're sitting in a chair, you'll be more than happy to talk

36:47

for three hours about all of your particular problems and quibbles and so on.

36:52

But if you're standing up, you and everyone around you is going to want to get the hell

36:55

out of that meeting room as quickly as possible so you can go sit down.

36:59

And when it's done well, scrums can be very effective because it lets everyone understand

37:05

what everyone else is doing without really slowing the team down too much.

37:09

The pitfall with Scrum or stand-ups is that oftentimes it becomes, "Let's engineer a solution

37:16

to a problem right now in this 15-minute meeting."

37:20

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

37:29

is. The stand-up is to say, "Hey, I, Casey, am having this real hard design challenge.

37:35

I'd like to talk to John about it, and can we do that after the meeting?"

37:39

That's the purpose of standup. But what ends up happening is John says, "Well, wait.

37:42

What's going on?" And I say, "Well, let me tell you, John."

37:44

It just spirals out of control.

37:47

But again, in principle, I am fully behind the idea of a standup.

37:50

The problem is it is so easy to execute on this the wrong way.

37:54

And that's why agile coaches, which John, you brought up a while ago, that's why they

37:57

get paid is because an agile coach's job, among many other things, is to say, "Whoa,

38:02

whoa, whoa, whoa, whoa, Casey, bite your tongue.

38:04

We'll talk about that after the meeting, but let's continue on with standup."

38:07

And it seems so silly.

38:09

It seems preposterous that you would need a full-time employee to do that.

38:14

But some of the best run Agile teams have a full-time either Scrum Master and/or Agile

38:18

coach in order to facilitate those kinds of conversations because it really is that easy

38:23

to screw it up. Yeah.

38:25

And I'm really glad you brought that point up actually, Casey, because when I first heard

38:28

Agile coach, I almost threw up in my mouth.

38:32

I thought it was a ridiculous thing. I was like, what?

38:36

But the funny thing is that the longer I've sort of, the more I've been involved, I should

38:41

say with agile methodology and agile teams is that they actually perform a function that

38:47

ordinarily the senior design lead or design manager or lead developer would actually would

38:53

have or would simply say, right, okay, you two in the back, quiet.

38:57

But by taking that away from someone, it's sort of like you're offloading them to actually

39:04

just be a developer and you can sort of like take that aspect of the senior role and someone

39:12

else can deal with that. And the funny thing is that that actually can work really well.

39:16

But it all comes down to personalities, obviously.

39:19

If you get a dodgy coach, then you get what you get.

39:23

But the point is that, so positives and negatives with agile coaches, and I'll talk a little

39:28

bit about some of my experiences in a minute. But the other point about the sprints

39:32

that I just wanted to focus on is that for me,

39:35

and I thought your description was perfect.

39:37

And I think that the key aspects for me

39:40

are that there's a lockdown period

39:42

and that's usually two weeks. And they just, I think empirically arrived on two weeks

39:47

as a period of time where you can have sustained focus

39:52

on a set of tasks to deliver an outcome and be too much less than that.

39:55

And it's not efficient, too much more than that

39:58

and people lose focus. And I realized that it's not a hard and fast rule.

40:01

Some people do three weeks, some people do one week, short sprints, long sprints, whatever, whatever.

40:05

But the reality is that two seems to be the,

40:08

I think globally accepted best compromise.

40:12

But in any case, the point is that the whole idea

40:16

is that you have a group that are locked down.

40:18

And I call it lockdown.

40:21

That's just what I used to call it. The idea is that you're in a sprint,

40:25

you're not doing anything else. So, and one of the interesting problems

40:29

that I've observed in organizations is that organizations typically have a maintain component

40:36

and they have a development component.

40:38

And obviously, depending on what industry it is,

40:41

what, how mature it is, depends on how many people are involved

40:45

in those different arms of the organization.

40:48

Yeah, so if you're a company that's running,

40:50

you know, let's say it's, I don't know,

40:53

I was gonna say Google, that's really, I don't want to talk at Google.

40:56

I'm trying to think of a company that's pretty,

41:00

let's just say Microsoft for the hell of it.

41:02

Okay. Well, Apple, whatever, it doesn't matter.

41:04

You've got a bunch of software that's already out there

41:07

that you have to maintain. Someone files a bug report, go deal with it.

41:11

Yeah, someone's having a problem logging into their account.

41:13

Yeah, trivial stuff, whatever. You know, that's sort of levels of support,

41:16

first level, second level, third level support. And then you've got your actual designers and developers

41:20

and they'll be developing the next set of features.

41:22

but the reality is that sometimes things get past

41:25

that first level, sometimes it get past the second level

41:27

and then you need to have your experienced designer

41:29

or developer come in and actually have a look

41:32

at the problem and resolve it. So they can't always wear that hat of saying,

41:36

I'm just doing new feature development,

41:39

don't talk to me about anything else. It doesn't matter if I wrote the code,

41:42

it doesn't matter if it was my bug, someone else can deal with that, right?

41:45

And I found that in larger organizations

41:47

where you have a reasonable pool of resources

41:51

in either side of that, Agile can work very well

41:54

in terms of the sprint component anyhow,

41:56

because you can actually get those people,

41:59

you can afford to put them in a room and say,

42:01

don't talk to them, they're focused on a sprint,

42:03

leave them alone. Whereas in organizations that are trying to be,

42:07

I would say that by nature have to be leaner

42:10

or where people have to wear two hats

42:12

because of either the organizational structure

42:14

or simply because there's a large and high priority maintenance component.

42:19

And it could just be that if things fall over in the system, you need to actually get them

42:23

back up and running again as quickly as possible.

42:26

There could be all sorts of reasons why that is, but in any case, that's where people being

42:31

locked in a room doing a sprint can actually become a problem.

42:37

And of course, once you start taking people out of that room and saying, "You know what?

42:41

I need you on this, I need you on that," or whatever else, then the whole thing collapses.

42:45

So it's a difficult balance and what I've observed is that essentially, if it doesn't

42:54

quite fit the balance in the organization, then Agile is almost doomed to fail in terms

42:58

of the sprint component of it. Anyhow, it's difficult to actually deliver on its promise and then people say, "Well,

43:05

Agile failed." It's like, "Well, no, I did it."

43:07

Or was it more the fact that the organization couldn't support it properly?

43:10

And I've observed some of that. Yeah.

43:13

I agree mostly with what you just said.

43:15

The only thing I would disagree with is that in principle, if one or more of your team

43:21

members is getting distracted constantly, in theory, that would be reflected in your

43:26

velocity. So maybe your velocity was a steady 20 points sprint, and then suddenly there's some catastrophe

43:32

that runs across multiple sprints that causes your developers to get distracted.

43:36

Well, theoretically, then your velocity will fall.

43:39

Maybe it'll fall to 15 or 10 or something like that.

43:41

Now that's clearly not what you want. I agree with you, John, that really this is not desirable behavior for anyone involved.

43:48

But the good news is if you really believe in Agile, if you really trust Agile, hypothetically,

43:53

that'll all kind of come out in the wash and you'll just have to react to the fact that

43:56

your velocity has gone way down.

43:59

This is also why Agile and Sprints oftentimes have these kind of weird cards that are not

44:05

deliverables. So, Casey needs to consult with John about some

44:11

thing, just because that's what John needs in order to get his

44:14

job done, even if he's in a completely other team. And maybe

44:17

that gets like three points, which really is a bastardization

44:20

of what agile is supposed to be because now you're kind of

44:22

implying a time-based component to what a point is. But the idea

44:28

behind it, and the reason people do it is because you're trying

44:30

to manage the fact that work is being accomplished, even if it

44:34

doesn't work against your actual goal.

44:36

And I'm of two minds whether or not this is a wiser, poor

44:40

choice to do those sorts of things. But no matter how you slice it one way or another, it should be reflected in

44:47

your velocity, either because your velocity will go down or because you'll

44:50

just have all these other cards that suddenly appear on your board that take

44:53

up time. But one thing I think that you were kind of glancing off the outer atmosphere of,

44:57

and I think is very important, is that especially in consultative roles, the

45:04

The place that I've seen Agile both work tremendously and work terribly is the product owner.

45:11

The idea of a product owner in Agile is that some human being has to be where the buck

45:16

stops. My understanding of the way Apple works internally is that they call this the DRI, the directly

45:21

responsible individual.

45:25

At some point, it will all roll down to one human being to make the decision about when

45:30

we go left and when we go right.

45:32

Typically, if you're doing Agile the way most people like to, that

45:35

individual is not a developer and is not even a member of your own company,

45:39

potentially, it's a member of the client. So again, I'm speaking from the perspective of a consultant.

45:44

So for me, I am working for Acme Widget Company.

45:48

I want somebody at Acme, not my company, but not Cases Consulting Incorporated.

45:55

I want someone at Acme that I'm building the software for to be the product owner.

46:00

And I want them to be a product owner darn near full time.

46:03

That's the other thing that often goes wrong is they'll say, oh, well, this person has 300 other responsibilities,

46:07

but yeah, they'll make time for you. No, no, no, no, no.

46:10

You want a full-time product owner that will be there at a moment's notice

46:13

to answer questions and help steer the ship.

46:15

And if Agile is really working properly,

46:20

then you'll have the experience that I had once several years ago

46:22

with a product owner at a local insurance company.

46:25

We were building an intranet thing for them.

46:27

And the product owner, I believe her name is Jen, she had said to us at some point,

46:33

"Oh, I'd really like this other thing to get done, this brand new widget that

46:37

we've never talked about before. I really, really, really want it to get done."

46:41

How many points do you think that will be?

46:43

And the skies opened, John, and angels fluttered down and you heard that

46:48

"Ahh," because that is exactly what she should have said.

46:52

She shouldn't say, "When will it get done?"

46:54

She shouldn't say, "When can I fit it in?"

46:57

She should ask us, "How many points will it be?"

47:00

Because if we tell her it's five points,

47:03

then she can look at her own backlog, which is really our backlog, but you know what I mean?

47:06

She can look at her own backlog and say, "Okay,

47:09

if I'm going to slot in five points real soon,

47:13

then what five points am I going to postpone to be later?"

47:16

Suddenly, you as a team of developers and designers and QA engineers,

47:20

and the broader team, including the product owner,

47:23

now your currency becomes story points,

47:26

and it's an understood currency with understood value.

47:30

Then all of these angry negotiations that you were talking about earlier, again, completely

47:35

agree with you. "Well, don't you think you could skim off a couple of weeks from that thing?

47:39

That would be really great because I got to deliver my stuff by such and such date and

47:43

that means it's your problem." All those conversations, they just kind of go away because now it's up to Jen or whomever

47:49

to say, "Okay, I really, really, really, really want this new thing I never told the

47:53

team about, but the team has told me it's five points.

47:56

So that just means I got to move five other points somewhere else and then everybody's

48:01

happy. Does that make any sense at all?

48:03

Yeah, that's absolutely. And I guess my experience is I've yet to come across a product, an owner who actually spoke

48:13

that. So I'm glad that you found someone like that.

48:16

In my space, it's still people are still getting used to this.

48:19

And I think that that hopefully will come in time and then we can be speaking in the

48:24

the same sort of language.

48:26

So I think that that is awesome when you can get to that point and that is awesome.

48:32

I guess I just wanted to circle back quickly and talk about just quickly on agile coaches.

48:38

One of the things I said before about people being able to like being locked in a room

48:44

to actually focus on the sprint and not have too many distractions, I mean, I guess my

48:48

problem was also with that is that the agile coaches and one of my first experiences with

48:53

an agile coach by the way, was when I had an engineer who was given to a sprint and

48:57

by really, really, really, really needed him to address an issue that was causing us a

49:03

lot of grief. And I went down to what they called the engine room.

49:09

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

49:14

any case. So, I went down to the engine room and was trying to speak to my guy and was promptly

49:21

escorted to the door by the agile coach, we're in the middle of a sprint, you're not allowed

49:26

to speak to them and you need to look at the folks who are delivering.

49:30

And I'm like... Yeah, that's kind of their job, but that is not a very friendly way of accomplishing their

49:36

job. No, it was pretty, yeah.

49:38

It was pretty confronting for me because technically...

49:41

Oh, totally. Yeah, because I mean, like he was, you know, he worked for me, he had deliverables and

49:44

other things and he was essentially promised by someone over my head and said, "Oh yeah,

49:50

we can have this person for the next two and a half weeks

49:54

or whatever it is of which the majority of that time

49:56

was a two week sprint. And during those two weeks,

50:00

you won't be able to access your guy.

50:02

And I'm like, well, hang on a minute, but I really need it 'cause this thing was broken,

50:06

this part of the plant was down, I really, really needed his help

50:09

and I wasn't allowed to get it. So we had to fumble our way through it

50:11

and took us two or three times as long to figure it out.

50:14

I mean, we got there in the end, but so where the sprint won,

50:17

the rest of the business lost kind of thing. It's sort of, that was when I had that realization

50:22

that when you have a critical maintenance function

50:24

that you're performing and you've got developers

50:26

and engineers wearing two hats,

50:28

then the balance of that will drive how successful Agile

50:32

can be in that sense.

50:35

But in any case, Agile coaches, yeah.

50:38

I mean, like you said, that's their job. And I didn't appreciate that at the time,

50:41

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.

50:46

Well, not really like the person that directs

50:49

where agile is not being followed,

50:51

but they are also a bit of an enforcer in saying,

50:53

well, you know what, you two in the back stop talking.

50:55

Oh yeah, no, you can't have him, he's in a sprint.

50:58

Yeah, whatever. So I see them as a necessary component.

51:03

And I kind of like that fact anyway, because in the end they take some of that stress away

51:09

from what did it be previously something born by managers.

51:11

- Yeah, very much so. And I think just to build on what you were saying

51:14

that oftentimes a scrum master in my world

51:17

will also be a project manager, the sort of person who would work at a Gantt chart in

51:21

Waterfall World.

51:23

A lot of times I've found that my best project managers/scrum masters, what they do is they

51:30

are total jerks to their own team in favor of advocating on behalf of the client, but

51:36

then they'll turn around and be total jerks to the client in order to advocate for the

51:40

team. Does that make sense?

51:42

They're kind of the taskmasters, but that's kind of their job.

51:47

Really good project managers, in my experience, will defend the other party that isn't there

51:52

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

51:59

a once-in-a-career kind of experience.

52:02

I have done agile projects, had been doing agile projects for something like 10 years,

52:08

And I think I had that kind of experience once, maybe twice.

52:12

So don't be discouraged if you, John, or anyone listening to this has yet to have that experience.

52:17

It is very rare and very difficult.

52:19

And it only really works if you've gotten all of the other stuff squared away, where

52:23

you've got repeatable, reliable story points, you've got repeatable, reliable velocity.

52:28

It takes a lot to get to that point, and it is very difficult.

52:32

And I think that's where Agile gets a bad reputation, is that so often it's done half-heartedly

52:37

or it's done not terribly religiously, and that probably implies something I don't want

52:42

to imply, but hopefully you get the point, that you have to kind of go all in on Agile,

52:47

and if you don't, then it's not really going to work the way it's designed.

52:50

And you could treat that as a detriment, you could treat that as an advantage, I don't

52:54

know, but don't feel bad if you've never found that product owner, because there's a product

52:58

owner out there for you that will be that way.

53:00

You just got to give it time. Absolutely.

53:03

One of the other things I want to talk about a little bit as well is the standup.

53:09

It's funny when you mentioned that before, circling back to that,

53:13

is that standups have existed as a concept long before Agile was even discussed in the 90s.

53:21

When I worked at Nortel, for example, that was when I first came across that.

53:27

that. I was in 1997 and yeah, basically the- I walked into a

53:32

meeting room, literally as the chairs were being wheeled out of

53:35

the meeting room. And I'm like, okay. So, we walked in this

53:40

meeting room. There's now no- there's now no chairs. And it

53:44

wasn't that we needed more standing room. And the manager

53:46

says, this is a stand up. You have 15 minutes. Go. And I'm

53:51

looking around. I'm like, yep. So, we talk now. Because I'd

53:55

I'd never, you know, and the whole idea that you like the whole concept in has been attributed

54:01

I think by some to agile, but the fact is that no, it's simply a good way of stopping

54:06

people waffling on, which is kind of good.

54:09

So in any case, I also want to talk a little bit about the whole, the utilization of visual

54:16

management boards.

54:18

I'm not sure. Yeah.

54:20

One of the things is that I found that during stand-ups,

54:24

there's a lot of, you tend to stand around that visual management board

54:28

and sort of like go through each of the key things.

54:32

Well, when you talk about what you're doing, then there should be something up on the board

54:35

that's talking about that. You shouldn't be doing something necessarily

54:38

that isn't in some respect represented on the board.

54:41

So the thing is that Kanban and I guess,

54:46

the thing is I always call them Kanban boards,

54:49

But I think Kanban is also more broadly another methodology,

54:52

but Scrum also utilizes a Kanban-like board.

54:57

And hence the names sort of get a little bit conflated,

55:01

but in any case, the bottom line is it's,

55:04

my understanding of the differences is more about how often it's updated.

55:07

So if you're updating a board, a Kanban board could be representative

55:10

of a continuous process or a project or a team,

55:14

whereas the Scrum board is specifically focused

55:17

on the sprint, even if it's representing

55:19

the same kind of board. That's my take on the difference.

55:22

- Yeah, so to kind of back up just a half step,

55:26

a lot of times it's very useful to see

55:28

a visual representation of where the work is.

55:31

And so typically what that's done, the way that's done is either via some sort of software

55:36

or via a literal whiteboard somewhere in your office,

55:40

you'll have a board with several columns and maybe the first column is backlog,

55:43

maybe the second column is like in progress,

55:46

Maybe you have in test, maybe you have in review and maybe you have delivered.

55:50

You know, and those don't have to be the exact four or five, whatever

55:53

columns, but something along those lines. And you have literal cards, usually post-its or what I can recommend

55:58

is something called Slicky Notes, which is, this is not a sponsor, but

56:02

at ecostaticink.com, these are basically like post-its, but they work via static.

56:10

So you can slide them around, which is really, really cool.

56:13

Um, anyways, you have something that, that represents, okay, this

56:19

card is in this column, which means it's in that part of the process.

56:23

And, uh, I suspect that our sponsor this week probably does something like that.

56:29

Uh, where you via software, where you can kind of see where things lie.

56:32

Um, but one way or another, be it via, via Slicky Notes, via Post-its, be it,

56:37

um, you know, some other software, then it's a really nice way to visually

56:42

see where the sprint is. Because typically speaking, you will

56:45

find that at the beginning of a sprint, all the cards are on the left-hand side of the board,

56:48

whatever your columns may be. And over the two weeks or however long,

56:52

all of the cards are hopefully moving over to the right side of the board, which means done.

56:56

And that's a really nice way not only to visually see what's going on, but also

57:00

to kind of manage your scrums. Because typically, the way you do a scrum

57:03

is either you go around the room person by person,

57:05

or you go around the board card by card and say, OK,

57:08

who's working on this card? What's the status?

57:10

And yeah, I quite like doing that.

57:13

It obviously becomes very difficult and you kind of really need a software solution

57:17

if you are a distributed team,

57:20

but if everyone's in the same spot, having, you know, slickie notes or post-it notes

57:24

on a whiteboard is tremendous.

57:26

- Absolutely. And actually, since you brought it up,

57:30

it's probably a good time for me to quickly talk about

57:33

our sponsor for this episode, and that's Clubhouse,

57:36

the first project management platform for software development that brings everyone

57:39

on every team together to build better products.

57:41

Clubhouse was built from the outset with agile development in mind.

57:45

What have we just been talking about? And with an intense focus on intuitiveness

57:49

and responsiveness. With their web app backed by Fastly CDN,

57:52

it really feels like a local app on any platform.

57:56

Clubhouse delivers developer-centric tools

57:58

for everything from Kanban boards to epics,

58:00

milestones, cards, with different card classifications

58:03

for features, bugs, and chores. But it's more Clubhouse's ability

58:07

to interconnect all of them together

58:09

that's so impressive. Users have reported creating less duplicates,

58:13

navigation is very fast using a common board,

58:16

but with as many configurable workspaces

58:18

as you'd like to customize that board for whatever purpose you might need.

58:22

Morning standups for different teams, sub teams,

58:24

or all the teams, it's entirely up to you.

58:27

Ultimately, any collaborative project management platform

58:29

has to be as low friction as possible,

58:31

and not just for software developers, but for everyone in the organization.

58:36

Marketing, support, management, you name it, the lot.

58:38

so everyone can contribute and actual collaboration actually happens.

58:43

Finally, the other part of Clubhouse that really shines

58:45

is its ability to zoom out from individual tasks

58:48

to the overall project status

58:50

that not only keeps project managers happy,

58:53

but keeps the team connected on how their part contributes to the greater project

58:57

and keeps them focused on what matters, delivering a result their customers will enjoy.

59:02

There are others in the market, but they're not like Clubhouse.

59:04

And what makes Clubhouse so different is the balance between the right amount of simplicity without sacrificing key functionality

59:11

structured to allow genuine cross-functional team collaboration on your project.

59:16

Clubhouse is a modern software as a service platform with seamless integrations for popular

59:21

tools like GitHub, Slack, Sentry and lots more. And if the tools you want to integrate

59:25

it with aren't available out of the box, that's okay. There's an extensible REST API in Clubhouse

59:30

that makes integrations straightforward.

59:33

If you visit this URL clubhouse or one word.io/10 the word, you can take advantage of a special

59:40

offer for Engineered Network listeners.

59:43

Of course, you'll get the 14-day free trial, but if you sign up, you'll get the first two

59:46

months free and because this is a team-centric solution, this offer will work for your team,

59:52

not just for you. The offer is only available to Engineered Network listeners for a limited time, so take

59:57

advantage of it while you can.

59:59

Thank you to Clubhouse for sponsoring the Engineered Network.

1:00:02

So yeah, just then circling back to the whole physical

1:00:06

versus virtual thing. When I first came across Agile, it was only,

1:00:11

well, as I said, about two and a half years ago,

1:00:13

like I knew I'd heard of it, I knew what it was basically,

1:00:16

but my first true experience with it was only two and a half years ago.

1:00:19

And I walked into this room and they had this visual management board up

1:00:22

and it was just a whole bunch of,

1:00:24

they weren't even posted notes. They were using the magnetic clips.

1:00:28

So you clip a small square card

1:00:31

into kind of like a clipboard clip style thing,

1:00:34

but it's got a magnet on the back of it. Now we're holding that up on the board.

1:00:37

And I looked at all this and I thought to me, well, that's how beautifully archaic.

1:00:41

It's like, come on, what century is this?

1:00:45

'Cause as a software guy, I'm looking at it thinking,

1:00:49

there's software that can do this. Why aren't we using software and a big screen?

1:00:52

And of course, it came down to,

1:00:55

it was a preference of the agile coach and it was a preference of management who are more tactile.

1:01:01

And, you know, they're all generally older people

1:01:03

that weren't, you know what I mean? They were happy to use a pen and paper.

1:01:07

Whereas there was me with my iPad and my Apple pencil.

1:01:10

I haven't used an ink pen in four years.

1:01:14

And you know what I mean? It's like, but here we are shuffling around

1:01:17

bits of dead tree on a, anyway.

1:01:20

But those posts that you mentioned sound really cool.

1:01:23

I'm actually gonna look into that for a completely different reason, but you know what?

1:01:25

That sounds really cool. I've made a note of that.

1:01:27

Thank you. Yeah, the only caveat to them is they only last like a couple of weeks

1:01:31

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

1:01:35

happening, that it's fine, but as soon as you take them out of the board, you've

1:01:38

only got like a sprint or two before they're going to start falling off.

1:01:42

But man, they are magical during that first couple of weeks, two to four weeks

1:01:47

when the static electricity is really clinging.

1:01:49

So when they fall off the board, does that mean you don't have to worry about them anymore?

1:01:52

Like that's. - That is what I have tried many a time, John,

1:01:55

and it has yet to stick.

1:01:57

- Dang, okay, well, it was worth a shot.

1:01:59

Anyhow, very good. So I guess my experience with them, as I say,

1:02:05

is that this is a fixation on them being physical boards,

1:02:09

despite the fact that we are supposed to be flexible

1:02:12

in our work location, because one of the things that they've also done

1:02:15

in our recent reorganization

1:02:18

is that we've changed buildings and then our new building,

1:02:20

It was a new building, fresh start kind of thing.

1:02:22

And there's not allocated seating.

1:02:25

And they finally figured out Skype as a thing.

1:02:29

I mean, my business was a bit slow in that respect,

1:02:32

my current employer, but they're finally on board with that and it's fantastic.

1:02:35

So I mean, I can work just as effectively from home as I can work from the office,

1:02:39

which is important since technically the number of people

1:02:42

versus the number of seats, if everyone showed up to the office on one day,

1:02:45

then not everyone would get a seat, But hey, I guess.

1:02:50

Anyway, the bottom line is that

1:02:53

I think that a visual management boards,

1:02:55

like a software version of one having up on a screen

1:02:59

is nine times out of 10, the better result

1:03:02

because in the end that gives you ultimate flexibility

1:03:06

into where you can be. And it's also a reference for others.

1:03:09

So anyone can log in and have a look at the board

1:03:11

depending on how you set up your sharing, of course. But the fact is that to see a physical board,

1:03:16

you have to physically be in that physical room. and sometimes it's just not possible.

1:03:19

And if you wanna catch up on the high level overview

1:03:21

and status of whether you're red or green and whatever part of the project you're working on,

1:03:25

then you have to be in the room to tell that. And that's the only downside.

1:03:29

But that also leads into the discussion is what's the value of the board

1:03:32

and what's the value of like who gets value from it.

1:03:35

And I've always had this concern

1:03:38

with the reporting of statuses of projects.

1:03:42

And no matter how, if it's through KPIs,

1:03:44

if it's through a visual management board, or whatever it is, who is it really for?

1:03:49

There's one group, one school of thought that will say, well, its sole purpose is to keep the team focused

1:03:54

and to, so the team knows where they're at and where they should be pushing harder

1:03:57

or where they know they're on track.

1:03:59

And the other school of thought as well, it could also be for management to have an idea

1:04:03

of where your particular sprint is up to,

1:04:06

so they can get an idea of how you're tracking.

1:04:08

And the problem is that if everyone's doing

1:04:12

these visual management boards, there's lots and lots of them all around the organization.

1:04:16

Generally speaking, people don't actually have time

1:04:19

to go and ingest all of that.

1:04:21

And generally speaking, from a management point of view,

1:04:24

most of the managers will come down, will simply look at the red green and then keep on walking

1:04:27

and not actually comprehend the content of the board.

1:04:30

So I say all of that considering the flip side

1:04:33

that ultimately people still need to comprehend.

1:04:36

So if a manager comes in to have a look at what's going on

1:04:38

and see where everything's up to, then they need to have spent some time comprehending

1:04:42

speaking to the scrum master or the product owner, they got to comprehend what's going

1:04:50

on. It's not just enough to have a board and you walk past and say, "Yeah, that's great."

1:04:54

So I've always believed, I firmly believe that the value of the board is for the actual

1:04:59

team that's doing the work more than anything else.

1:05:01

Yeah, I agree.

1:05:03

I think that there's something to be said for an at-a-glance way of looking at what

1:05:07

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.

1:05:17

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

1:05:24

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

1:05:30

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

1:05:36

to stop goofing off. And I know that it is really time to put the pedal to the

1:05:41

metal and really crank if I'm going to make my obligations and commitments for

1:05:44

this sprint. And again, it doesn't have to be a board to do it. You could just

1:05:47

have like a speedometer style needle if you wanted. But one way or another, I

1:05:52

think it works out really well. I completely concur with what you're saying

1:05:54

about management oftentimes not getting the nuance of these sorts of things. But

1:05:59

nevertheless, I do think it's useful. The other thing I've seen useful from time

1:06:02

to time is a burndown chart, which I'm going to butcher the description. But

1:06:05

Basically, the idea is if you are keeping to this current velocity, this is how many

1:06:12

points you should be doing each sprint.

1:06:15

And given the backlog of items, this is how long it will take to complete this entire

1:06:19

project. And you can see how you track against your velocity, are you doing better or worse, and

1:06:27

what the final real-world end date is for your entire effort, assuming you keep this

1:06:32

velocity. so kind of useful to know, because especially in the consulting world, like typically a

1:06:38

project or a project team or maybe just an individual is going to be booked by a client

1:06:43

for some number of months or years.

1:06:46

And if you're coming to the end of that some number of months, you see that that burndown

1:06:50

chart says you've got another month after that before this project's done.

1:06:53

Well, that's time for some contract renegotiations, I'd say.

1:06:56

And so that's sometimes can be useful too.

1:06:59

Absolutely. Alrighty.

1:07:01

- Well, I just wanna refocus a little bit now

1:07:04

and look at some of the consequences or common issues

1:07:09

that they come across if you apply

1:07:12

the agile methodology and work practices.

1:07:14

And there's a couple that I wanna talk about. You may well have your own short list or longer list,

1:07:20

but in any case. So when the first comes to mind is,

1:07:25

it's all about motivation and what are people's motivation?

1:07:29

And the more we motivate people to actually execute

1:07:33

on functionality driven by a product owner,

1:07:37

ultimately, that preference will always be

1:07:40

product owners want the shiny, shiny, they want the features and functionality.

1:07:44

They don't necessarily want all of the code to be written

1:07:47

as beautifully and elegantly as possible.

1:07:50

You can debate whether that's right or wrong,

1:07:52

but the reality is my experience is that

1:07:55

the technical debt is more problematic with Agile

1:08:00

because generally speaking,

1:08:03

people will wanna have a better velocity

1:08:06

and to have a better velocity, you will typically take a faster solution

1:08:09

rather than actually having a more scalable,

1:08:13

flexible implementation that's gonna take longer

1:08:16

to design and develop, but will give you something that once you're finished

1:08:19

will be easy to maintain. - Oh, absolutely.

1:08:22

I think you've absolutely nailed it. This is very, very common because what Agile values is literally

1:08:30

reading from the manifesto, working software over, now they say

1:08:33

comprehensive documentation, but you could also say working software

1:08:36

over a flexible software.

1:08:39

Now that's probably a little bit unfair because I would bet the

1:08:43

writer, the authors of the Agile manifesto would say, "Whoa, whoa,

1:08:45

whoa, whoa, whoa, whoa, you can have working and flexible software

1:08:47

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

1:08:55

working and hyperflexible software than it is just to have something that works.

1:09:00

And I think one of the most difficult things of software development is

1:09:04

something that I still struggle with 15 years into my career is when do you

1:09:09

design for flexibility and when do you not take shortcuts, but just, you

1:09:13

know, do the more direct path. And sometimes I make those calls well, and sometimes I make them very poorly.

1:09:20

And I think one of the ideas behind Agile is it should become relatively

1:09:25

obvious, relatively quickly, what sorts of things the product owner is going to

1:09:30

want to renege on or change their mind about, and maybe those are the things

1:09:34

that you should be more flexible about. And then there are other things that you know are unlikely to change.

1:09:39

And in the spirit of moving fast, you're just going to have to take, again, maybe

1:09:44

not take shortcuts, but kind of hard code things or just be more direct in your implementation.

1:09:50

But yeah, I completely agree with you that technical debt is always a problem, always,

1:09:56

no matter how you write software, but especially with Agile. And that's why a lot of times

1:10:01

after several sprints of work, a lot of teams I've worked on will take like, I forget the

1:10:07

term we've used, but like a kind of a breather sprint where we'll take a full sprint's worth

1:10:13

of time, a full two weeks or what have you, and just do cleanup and kind of batten down

1:10:18

the hatches and kind of reset everything and fix some of those shortcuts that we had taken

1:10:22

in the past. And it doesn't always work out well because you're now delaying the final deliverable

1:10:28

in terms of real-world time.

1:10:30

Oftentimes clients don't understand why you need to do that.

1:10:33

Like, "Why didn't you write it right the first time?"

1:10:37

But oftentimes I've found that can make a tremendous difference in the robustness of

1:10:42

software and the ability for the software to bend in the future, you know, when the same product

1:10:46

owner does make a different choice. And a very quick tangent kind of off of this, another thing

1:10:52

I've seen a lot, especially when you're working with a client, and especially when that client

1:10:56

is a very big business, like something banking related, for example, where there's a lot of

1:11:00

security problems and things like that, a lot of times I'll see what's called a sprint zero.

1:11:05

And what that means is, let's spend a couple of weeks just getting the administrivia taken care

1:11:09

of. If we need to use a laptop that is owned by the client, does every member of the team

1:11:13

have one of those laptops? If we don't need to use a laptop owned by the client, can we

1:11:17

get on the client's VPN? Do we have the user access that we need? Do we have access to

1:11:22

the database servers that we need? Do we need to stand up a database server or web server

1:11:26

or what have you? And we'll spend one to two sprints just getting the administrivia done.

1:11:31

Because inevitably, if you don't do that, what happens is you spend that same month

1:11:36

doing those things while you're supposed to be delivering.

1:11:39

So let's just embrace the fact that this is going to take some time and just cart it out

1:11:43

and treat it as a sprint. Yeah, sprint zero is an interesting name actually.

1:11:47

I hadn't heard that one. I've heard people refer to that sort of thing as a chore sprint where you basically are

1:11:52

Yeah, same thing. Yeah, same thing.

1:11:54

Yeah. And I think that's fantastic.

1:11:57

And for me, it comes down to the powers that be accepting that that is a thing as opposed

1:12:05

to it will just happen magically.

1:12:07

Like here's a whole bunch of stuff that you need to deliver. And it's all the administrivia.

1:12:10

If you don't do it upfront, you essentially you're set up to fail.

1:12:13

You know, and it's like, well,

1:12:16

what's the point of doing a sprint? 'Cause that'll directly affect your velocity.

1:12:20

So what are you gonna do? - Exactly. - Yes, it's, but that's a good one actually.

1:12:24

All right, so just on the product owner, actually just quickly,

1:12:27

I've also struggled with the concept that one person,

1:12:30

and I know that this is a common problem

1:12:33

in no matter what part of business you want to be in.

1:12:36

One person to make the final decision.

1:12:38

Finding a person that can honestly and realistically comprehend the relative importance

1:12:43

of all the competing objectives. It doesn't matter if they're the client or not.

1:12:47

That's a hard thing to find. And my frustration has been that a good product owner

1:12:53

has a good focus and a good grasp of what needs to happen

1:12:57

and what rather what needs to be done, what they really do need as an owner.

1:13:01

But the reality is that that's a very rare thing.

1:13:04

Most of the time, my experience has been that

1:13:07

these client representatives,

1:13:10

I guess you could call them in the more waterfall strategy approach,

1:13:13

or product owners, they tend to be,

1:13:16

they tend to blow on the breeze a bit. They tend to be distracted by the new shiny, shiny.

1:13:20

They don't fully comprehend the trade-offs.

1:13:25

No matter, if you can get a conversation about points,

1:13:28

that's fantastic. But generally speaking, they just,

1:13:31

or how hard could that possibly be and not comprehend?

1:13:34

(laughing) So that's my frustration with that.

1:13:36

And to be honest, that's nothing to do specifically with Agile.

1:13:39

It's more the fact that Agile empowers the owner

1:13:42

with so much power insofar as directing where the work goes.

1:13:47

Whereas in more of a waterfall approach,

1:13:50

it's more of a negotiation of, well, if you want this,

1:13:53

it's gonna take this much more time and that's gonna be equal to this much more money.

1:13:57

And we have all these other things you've already agreed to

1:14:01

that we're halfway through working towards

1:14:03

and there's six months of momentum in our documentation

1:14:06

and you're now saying we've got to pivot and do something else.

1:14:09

And so agile sort of empowers a lot of that,

1:14:12

but that's in the flip side being

1:14:14

that's the whole point of agile. So, you know, it's like you're empowering people

1:14:20

that if they're too wishy-washy and blow on the breeze a bit and change their minds,

1:14:24

then that can have a massive blowout

1:14:26

in your ability to deliver something.

1:14:29

So that's been a frustration of mine.

1:14:32

I'm not sure how often you've come across that, if at all.

1:14:34

- Yeah, I definitely have seen that for sure.

1:14:36

But again, if everything is going according to plan,

1:14:39

that will be drawn out or kind of spelled out

1:14:41

in the burndown chart or the lack of good velocity.

1:14:44

- True. - And I feel like that will often fix itself in the wash.

1:14:48

What is more challenging to me in a corollary of what you were saying

1:14:52

is I have definitely had occasions

1:14:54

where we've had a very engaged, very, very interested,

1:14:58

very skilled product owner.

1:15:00

And that individual is great, but the organization they

1:15:04

work in is a disaster. And what ends up happening is you have a product owner that is doing

1:15:09

everything right by the team, but they're not empowered on the client side.

1:15:14

So they know exactly what they want.

1:15:17

They know exactly how to get it done. They have a general understanding of what the rest of the business

1:15:22

around them needs and wants. But then you'll have some higher up that feels like they just want to make their

1:15:29

appearance. We used to call this a swoop and poop. A bird swoops in, poops, and flies away.

1:15:36

Oftentimes you'll have a product owner who is engaged but not empowered, and then

1:15:42

you'll have the product owner's boss or boss's boss or boss's boss's boss come in,

1:15:45

swoop and poop, and say, "Oh, no, no. Don't do it that way. Do it this other way."

1:15:48

And suddenly, three sprints worth of work, just like you were saying, John, just goes

1:15:52

up in a puff of smoke. And that can be very challenging. And again, the best product owners

1:15:58

are ones who are not only engaged, preferably full-time, but I didn't say this earlier,

1:16:03

also empowered. Empowered to make decisions for the product in order to get things done.

1:16:10

And finding someone that is both engaged and empowered is very hard. You will very often

1:16:14

find either somebody that is engaged but not empowered or empowered but not engaged.

1:16:17

- Yeah, absolutely nailed it.

1:16:20

And then that, exactly. And I've unfortunately had too many bad experiences

1:16:24

with yeah, with never finding both.

1:16:27

And it's quite frustrating,

1:16:29

but that's not the fault of Agile, let's be clear.

1:16:31

Necessarily, it's more about the power that they wield

1:16:35

and hence by not getting that right mix right

1:16:37

in an individual can have more negative consequences

1:16:40

than you would get in a waterfall is more the point.

1:16:43

But all right, next issue with Agile that I've seen,

1:16:46

And I don't know if this is an issue with Agile or Paul,

1:16:49

again, getting back to it's how it's implemented,

1:16:52

overreaching on each iteration

1:16:55

and just essentially taking on too many tasks

1:16:58

and the effect that that has on the overall,

1:17:02

the stress level and indirectly, therefore the velocity.

1:17:06

And then if you have too much of that,

1:17:09

then that will drive constant context switching

1:17:12

for an individual trying to deliver on all of these things.

1:17:15

and it's not actually possible to do that in the timeframe.

1:17:18

And that drives inefficiency.

1:17:20

And the funny thing is that this is something that

1:17:23

I know that you'll say, well, in the longer term that'll balance out.

1:17:26

And it's like, well, yes, but what I've observed is that

1:17:30

if there's too much of this KPI driven attitude,

1:17:33

then that may not happen. And there will be this drive to churn through points

1:17:38

and to improve that velocity.

1:17:40

And taking on more is the natural reaction

1:17:44

try and get through more to improve the velocity to drive the KPI. And then that creates a

1:17:50

behavior which is where you continually overreach. And maybe that's the job of the coach to stop.

1:17:57

I don't know. Yeah, I think you nailed it. I think the coach or scrum master or whomever should be putting

1:18:01

the kibosh on that. But ultimately, if you're overenthusiastic about signing up for cards,

1:18:07

you're just ruining things for yourself. Because again, if you're realistic about how much

1:18:14

work you're getting done, then the velocity becomes accurate and then everything falls

1:18:18

into place. But so often what'll happen is exactly what you described and the team will overreach

1:18:24

and they'll sign up for 50 points worth of work, but maybe 30 points of which are actually

1:18:30

delivered and 20 points of which are in this kind of nebulous zone where they've started,

1:18:34

but it's not really delivered.

1:18:37

And then that just means the velocity is just an arbitrary number.

1:18:40

It doesn't really represent anything. And so my recommendation in those situations is try to force yourself and your team to

1:18:48

be conservative because it is much better to only complete five points but get them

1:18:54

all the way out the door, written, tested, approved, etc., than starting 50 points and

1:19:01

delivering 10 of them.

1:19:04

And so what I try to do in teams that I've been managing either in terms of being a scrum

1:19:08

master or like a technical lead is to try to encourage people to do a couple of

1:19:13

things. One, don't bite off more than you can chew, just like you said, John.

1:19:16

But number two, try not to context switch if you can avoid it.

1:19:21

So yeah, you might think you can do 15 points worth of work just yourself,

1:19:27

John, but only pull into the sprint five points worth of work until you are sure

1:19:33

that those five points are done.

1:19:36

As much as you can get done on them, they are done.

1:19:39

Preferably they've been tested and maybe they haven't been approved yet,

1:19:42

but at least done and tested. And at that point, sure.

1:19:45

Pull in another five, even if it wasn't originally slated for the sprint,

1:19:48

because then guess what? That means your velocity was, you know, your team's velocity was 15, but

1:19:53

because John did a great job this time, maybe it's 17 next sprint again.

1:19:57

Like just trust the system. And like, I'm yelling in your direction, not at you, but trust the system, man.

1:20:03

And it'll all work itself out. Yeah, absolutely.

1:20:05

Right. And the whole thing about context switching

1:20:08

is just good advice, no matter what you're doing in any aspect of anything.

1:20:13

'Cause I find that the more you keep trying to juggle

1:20:17

all these different tasks at once, the more you're switching out what you've got to focus on,

1:20:21

it just completely, your efficiency just collapses in a heap.

1:20:24

And the funny thing is that people need to think about

1:20:28

things as like, I'm going on a very long walk.

1:20:31

How do I get from A to B? Well, you take it one step at a time, right?

1:20:34

And that's the whole point is that every step is a task,

1:20:36

do that task, then go to the next task.

1:20:38

And then once you've done all those tasks

1:20:41

and you've got through all those points in the context of Agile,

1:20:43

you'll look back and you'll say, "Oh, wow, look at all the stuff I did."

1:20:46

As opposed to, I'm gonna try and jump

1:20:49

between all these different things at once, get a little bit of a progress on each of them

1:20:53

and then end up achieving very little net movements.

1:20:56

Kind of like I'm kind of wandering slightly

1:20:58

in a circle sort of spiraling outward slightly.

1:21:01

So I've kind of moved a little bit that way, but not really far enough.

1:21:05

But anyway, dear me.

1:21:08

Okay, so two more issues then

1:21:12

that I wanna make sure we talk about is burnout.

1:21:16

And that is not burned down as in a chart,

1:21:19

but burnout from burned down or something.

1:21:23

And that's terrible. Anyway, the point is that my observation

1:21:27

is that people in a sprint environment,

1:21:31

particularly if there's a lot of management pressure

1:21:33

an organization to have multiple back-to-back sprints.

1:21:38

Probably you could argue too close together, which from a churning through a large number

1:21:42

of points is a tendency I've noticed in some organizations.

1:21:47

And I think, and this is the problem is I had to dig to see if there were any actual

1:21:53

documented studies about whether or not engineer programmer burnout was higher under Agile

1:21:59

than under Waterfall. nothing definitive but there seems to be a lot of noise in that space.

1:22:06

And I sort of thought about this and it's like, well, it doesn't matter what methodology

1:22:09

you use, you work your people too hard, they're going to burn out.

1:22:13

And it doesn't matter. That's not necessarily a failing of agile but I think that it's something that if you

1:22:18

do have too many sprints, they're too close together and they're back to back, you're

1:22:23

basically going to work people too hard and ultimately, you can't sprint constantly.

1:22:27

Yeah, I think that's true of really any engineering, I was going to say

1:22:33

software, but really any engineering I think can fall into that trap.

1:22:36

I don't think it's unique to agile. Something that my last company did that I really, really liked was that it was

1:22:42

either once a quarter or a couple of times a year, like once every couple of

1:22:46

quarters, I forget exactly what it was, but they would allow us to basically

1:22:50

just go goof off for a half a day.

1:22:54

And so sometimes we would go and race go-karts.

1:22:56

Sometimes we would play mini golf or something like that.

1:22:58

And these are not terribly expensive things to do.

1:23:01

And it also helped that this last company was a product

1:23:03

company, not a consulting firm.

1:23:06

And so us going away for four hours doesn't have a direct

1:23:11

difference on our bottom line.

1:23:14

But nevertheless, they would fund us going and goofing

1:23:17

off for a little while. And I cannot recommend that enough.

1:23:21

I don't think that offering, that having the team leader

1:23:24

whatever, say, "Hey, let's go get drinks after work," is the right answer because

1:23:27

A, not everyone drinks and B, after work time is sacred to a lot of people, myself

1:23:32

included. But if your company is flexible enough that you are allowed to do something

1:23:38

that preferably has no financial input from the team members, even if it's as

1:23:41

silly as going out to lunch but having the company pick up the tab and letting

1:23:45

that lunch be like a one or two hour lunch instead of the 20 minute run, grab

1:23:50

something and run back, you know, dance that a lot of people typically do.

1:23:53

Um, I found that that makes a world of difference, especially if it's

1:23:58

something more than just lunch, you know, lunch is a good start, but

1:24:01

something more than just lunch going out to, to watch a movie together or

1:24:05

to, to race go-karts or I don't know, do any number of things.

1:24:09

I was going to let my American come out and say, you know, go target shooting,

1:24:13

which is weird because I don't even own a gun, but anyway, um, you know, do

1:24:16

something hopefully less American than that. And I feel like that makes a tremendous difference.

1:24:22

Obviously, I think Americans especially, and I don't want to speak for

1:24:26

Australians, Americans especially have a very complicated relationship

1:24:29

with what we call vacation time. I believe you call it holiday time.

1:24:31

And oftentimes Americans will get to the end of their year and have some of

1:24:37

their paid time off, some of their holiday or vacation time unused.

1:24:42

And I'm of the opinion that vacation time should be compulsory.

1:24:46

Like it is a big problem and it is a big ding on your record if you do not take vacation

1:24:52

because that is critical.

1:24:55

That time away from work is critical for you in order for you to be an effective worker.

1:25:01

Not everyone feels that way, but that's the way I feel.

1:25:03

And I think just being aware of your team's morale is something that the technical lead,

1:25:09

the product lead, and or product owner, and especially the project manager/scrum master,

1:25:15

something that the three of them, well, typically that's three people,

1:25:17

but you get my point, the three of them need to work through and pay attention

1:25:20

to because you're exactly right. Especially if it's in a high pressure situation, especially if the team

1:25:25

is firing on all cylinders, that's almost worse because that means

1:25:29

everyone has just been cranking.

1:25:31

And this is what you were saying a minute ago, you know, when everyone's

1:25:34

cranking at some point, you need to release that, that, that pressure

1:25:37

and you need to let that valve open. And my, my favorite way to do that is during work hours because that

1:25:42

doesn't necessarily affect families. It doesn't necessarily affect the person's personal financial world.

1:25:47

You know, it, it, it, and it's, and it's like a treat that you get to miss work for a

1:25:51

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,

1:25:58

by the, by the organization that, uh, we value your sanity and therefore, um, exactly.

1:26:04

Yeah. Take a few hours on the company and go and unwind.

1:26:08

And you know, it's like, and that's fantastic.

1:26:10

Right. And it's been, I think in my case,

1:26:14

well, we've just been through a bit of a rough time in our company in terms of downsizing and such,

1:26:17

but the reality is that we used to regularly go out

1:26:20

every probably month or so for like a team lunch.

1:26:24

It was like a very extended team lunch.

1:26:27

So normally you mentioned the mad dash out,

1:26:29

go out, grab something, come back kind of thing, and try and get it done in an hour, in a lunch hour,

1:26:34

lunch break, what have you. This is actually was more like a,

1:26:38

we'd head out on a Friday afternoon, typically once a month and most people wouldn't come back

1:26:42

to the office if you did, you'd meander back at maybe 2.30 or something like that.

1:26:46

And it was pretty easy in the afternoon after that.

1:26:49

But yeah, actual team building or getting out there

1:26:52

and getting the go-karts and everything like that,

1:26:54

that's something that periodically

1:26:56

when you're in a high productivity environment

1:26:59

is absolutely critical. It's an acknowledgement from the company

1:27:02

that you know what, you're a human being, you're not a robot.

1:27:05

And so far as the holiday thing goes,

1:27:08

I'm almost applauding when you were saying that

1:27:10

because my problem is that that is a thing here too,

1:27:12

where people just stack up their annual leave

1:27:15

and they never take it.

1:27:18

And so we have this thing, it's not actually called this,

1:27:21

but we refer to it as the naughty list. And the naughty list is essentially,

1:27:25

if you have more than 20 hours of leave, then you're yellow, you're in the yellow.

1:27:29

If you've got more than, sorry, 20 days,

1:27:31

if you've got more than 30 days of annual leave

1:27:34

that hasn't been booked, then you're in the red.

1:27:36

And if you're entering the red, you're on the naughty list.

1:27:39

So I went beyond the warning list and into the naughty list.

1:27:42

And my boss said, "Right, John,

1:27:46

you're gonna be taking some leave, aren't you?" And I'm like, "Well, of course, yes,

1:27:52

of course I'm taking some leave, yes, absolutely.

1:27:55

I'll take five weeks." And he's like, "Oh, no, no, no, you don't have to overdo it."

1:27:58

I'm like, "Oh no, I'm taking five weeks."

1:28:01

And I tell you what, I'm so glad I did.

1:28:03

I feel so much better. And I literally only been back at work two weeks since then.

1:28:06

So, that beautiful holiday bubble where you chill,

1:28:10

it's still mostly intact.

1:28:13

So, I'm happy with that. Good outcome.

1:28:15

- I had a coworker at my last consulting job

1:28:17

and I could not do this personally,

1:28:19

but the way he favored doing things was

1:28:22

he would take literally no days off for the entire year,

1:28:26

but then every single year, it was just understood that he would be gone

1:28:30

from roughly American Thanksgiving, so the third or fourth Friday in November,

1:28:33

until the next year. So he would take all five or whatever weeks of his vacation,

1:28:38

all in one shot, all the end of the year. And that's what he did every year.

1:28:41

And I think that's bananas personally,

1:28:43

like I couldn't do that all the time, but for whatever reason, that's the way he liked it.

1:28:47

And that's what he did. And every time, you know, January came around

1:28:50

and he was quite a bit more refreshed than he was in late November, you know.

1:28:54

- Yeah, absolutely. I'm not sure I could do the same thing every year either,

1:28:57

but, 'cause this is actually the first year I took five weeks off in one block.

1:29:01

And yeah, I'd like to be able to say I'll do it every year,

1:29:04

but I think common sense will prevail. I won't do it every year,

1:29:06

but at least two weeks, I think, at a time is the minimum.

1:29:11

'Cause if it's only a week, then you just sort of getting into the swing of things

1:29:15

and then it's back to work again.

1:29:17

I think to sort of decompress, you really need that second week, but in any case.

1:29:21

So interesting aside, but not necessarily to do with Agile, but anyhow.

1:29:25

So we're just gonna circle back into Agile again,

1:29:27

just to, while we sort of wrap this up a little bit,

1:29:30

is one of my other frustrations with Agile

1:29:33

is that it tends to lead to poor documentation.

1:29:38

And I know that that's the intent, but I guess my problem is that I've always been brought up

1:29:44

on the value of documentation.

1:29:47

Like in engineering in general, software is just another form of engineering.

1:29:51

So I've always believed in it, but the problem is the debate

1:29:53

about how much needs to be documented.

1:29:56

Yeah, and I feel like there's the code is this,

1:30:02

What's the saying? The code is the documentation

1:30:04

as opposed to the documentation is the documentation

1:30:06

and the code is the code. And I guess the problem with that is that

1:30:11

code is never going to be as good as documentation

1:30:14

in so far as you'll never be able to describe in code

1:30:17

as easily as you could read English, sorry, whatever language you're programming in

1:30:22

versus whatever language you're speaking and vice versa.

1:30:25

I mean, you're never gonna be able to write unless you're gonna write something like pseudocode.

1:30:29

But if you're starting to write pseudocode to describe code

1:30:31

in a specification, I'd suggest you've potentially

1:30:34

lost the plot. 'Cause I seriously had a manager tell me to do that

1:30:39

in my younger years and I looked at him with a raised eyebrow and I'm like, "Are you serious?"

1:30:43

So anyhow, I've always believed that

1:30:47

when you're developing any formal software that you need to have a few essential components

1:30:52

in terms of your documentation. The first one is a coding standard.

1:30:54

And that's just more of a common comprehension

1:30:57

so that everyone in the team or the company organization

1:31:00

can follow what other people have done, just basic naming conventions

1:31:03

for variables, object structures. And I know some people say,

1:31:06

"No one reads the coding standard." It's like, yeah, well, you're gonna read my coding standard

1:31:09

when I write, you're gonna read that. But anyway, the point is that

1:31:13

I think that that's an essential cornerstone.

1:31:16

It should not be ridiculously prescriptive,

1:31:18

but it should have the basics. The next thing you've gotta have, I think,

1:31:21

is a functional specification about what you're actually delivering,

1:31:24

meaning just what it has to do.

1:31:27

Doesn't have to be ridiculously detailed necessarily,

1:31:29

but there needs to be something saying, this is what our widget's gonna do.

1:31:34

And then finally, you need to have an interface specification

1:31:37

for all of your points of interface with whatever it might be.

1:31:40

Sometimes you don't actually have any if it's a fully self-contained product,

1:31:43

but generally speaking, you're going to have something.

1:31:45

And in my world, we sort of tend to combine the interface specifications

1:31:51

and the functional specifications together because our primary interfaces

1:31:53

are just a human machine interface or HMI.

1:31:56

So we wanna say like what data points,

1:31:59

what's logged, what's alarmed, what screen the information is displayed on.

1:32:03

But we're gonna stop short of saying, well, it's 10 pixels down, three pixels across,

1:32:07

or something like that. We don't bother with that. We don't do detailed mock-ups generally,

1:32:11

'cause that's just too much detail.

1:32:13

So, 'cause after all, finally,

1:32:15

whatever you produce will be vetted by the end user anyway.

1:32:18

So, what's the point of doing that

1:32:20

other than simply saying, well, we're gonna have the following items on the screen,

1:32:24

and we'll show you the iterations as we go,

1:32:27

and you can give us feedback along the way.

1:32:30

But what I found with Agile is that,

1:32:33

and I guess your mileage may vary

1:32:35

depending upon the Agile coach maybe,

1:32:37

but in the end I found that it's,

1:32:40

that follows that idea of just barely good enough.

1:32:43

And for me, just barely good enough isn't good enough,

1:32:47

but that's just, I don't know, that's just my take on it, what do you think?

1:32:50

- Yeah, it's tough because as you said

1:32:52

in the beginning of what you were just talking about,

1:32:55

that the kind of tenet of Agile is not to document.

1:33:00

But this is especially complicated when you're talking about a consultative role,

1:33:04

because at some point, the team that wrote all this code

1:33:07

is going to go away. And it's up to the client to maintain it oftentimes.

1:33:11

And so then the client is looking

1:33:13

at this hopefully really great piece of software

1:33:15

with zero documentation on it.

1:33:17

And I think that I agree that not having enough documentation

1:33:22

is a very common ailment with Agile.

1:33:25

But I would argue that if it's something that's really important to either the team or the client,

1:33:29

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.

1:33:35

You can build it in in that you could make an entire story for documentation.

1:33:39

You know, there's several ways in which that you can kind of build all this in

1:33:42

and have it work within the system of Agile.

1:33:45

But I 100% agree with you that it is a very common pitfall

1:33:49

that has happened to pretty much every Agile project I've ever worked on.

1:33:53

And it is kind of disheartening to get to the end of a project

1:33:58

and then realize, oh, I have like one to two to four sprints

1:34:01

worth of work that is nothing but documentation.

1:34:03

Most developers, myself included,

1:34:05

don't really enjoy that.

1:34:07

And so if you can avoid it and kind of keep an eye on it

1:34:10

from the front, I strongly recommend it.

1:34:13

Fair enough. All right, cool. So honestly, I guess just to sort of wrap up a little bit

1:34:20

Now, I feel like the fundamental problem

1:34:25

with any kind of, whether it's waterfall, agile,

1:34:27

whatever methodology you might choose to use,

1:34:30

the common thing in all of them is us, like human beings.

1:34:34

The fundamental rule with human beings is that we're,

1:34:36

well, we're lazy. We don't like responsibility, generally speaking.

1:34:42

And what I mean is we don't like to be held responsible necessarily.

1:34:44

I think people, that's as a general rule that holds,

1:34:47

there will always be some people that are happy to be responsible for everything,

1:34:50

but I don't know, maybe they end up being basket cases

1:34:52

or something in the corner at the end of the project. But anyhow, people also, I think,

1:34:57

generally confuse activity with productive activity.

1:35:03

And I think that just because people are scurrying

1:35:07

around doing things doesn't necessarily mean that that is actually, you know,

1:35:11

to borrow one of those industry expressions,

1:35:13

moving the needle necessarily.

1:35:17

And I think that ultimately,

1:35:19

whatever system you choose to come up with,

1:35:22

any system can be gamed. Because the problem with humans is humans think up a system,

1:35:26

whichever it might be, waterfall or agile,

1:35:28

and then all the other humans implementing it,

1:35:31

will then think about ways they can game the system

1:35:33

because they are lazy, they don't wanna be held responsible,

1:35:36

and they're happy just to be active, but not necessarily produce anything.

1:35:40

And I realized that that's generic,

1:35:44

but it's meant to be generic because I don't think that Agile wins or loses over Waterfall

1:35:50

for exactly these reasons.

1:35:52

It's an attempt I think, and I think largely successful in certain environments,

1:35:57

it can be far better than Waterfall

1:36:00

where you don't have high documentation requirements

1:36:02

where you do have to pivot because the success of your business,

1:36:06

depends on it being as agile as possible

1:36:10

because if you can't pivot and actually change the direction

1:36:14

because the product or the market has moved

1:36:16

in a different direction. If you don't do that, you'll just cease to exist.

1:36:19

So, and when you're threatened with that sort of thing,

1:36:23

you have to work very hard and compete very hard

1:36:26

in order to survive. And that's just the way it is with survival of the fittest.

1:36:30

So applied to Silicon Valley terms, I guess, but anyway.

1:36:34

So I don't think that agile in the end is bad in isolation.

1:36:40

I think the problem is that agile

1:36:43

and I think you may have even led into this

1:36:45

from the very beginning is that it's,

1:36:47

there are lots of little pitfalls

1:36:49

and people can let their egos get in the way,

1:36:52

people try to game the system. Ultimately, it can be just a bad implementation

1:36:56

just because people don't understand how it's supposed to work.

1:36:58

They haven't comprehended what it's intending to do.

1:37:01

And in the end, it's given Agile a bit of a mixed reputation.

1:37:06

Some people love it and embrace it.

1:37:08

Some people can't stand it. Some people say it's just the latest buzzword methodology

1:37:12

that is this going to, in another five years, not only talking about it, but in the end,

1:37:16

I think that the overall, the software industry as a whole is better for it than without it.

1:37:22

Yeah, I think you're right that as with anything, it is easy to fall into the trap of this is

1:37:30

not really working for my team or for my company and for whatever reason, and maybe it's innocent,

1:37:35

it's been sabotaged, whatever. But I have lived many, many poorly done Agile projects, and they

1:37:44

are a slog, and they are tough, and they are frustrating. But I've also lived at least a

1:37:49

handful of really good Agile projects. And I can't stress enough that in that perfect scenario,

1:37:56

when everything really, really works the way it's supposed to, it really is like magic.

1:38:01

and you have repeatable results, predictable results,

1:38:06

which is what Waterfall really strives to be,

1:38:08

is deeply predictable. You have that in Agile.

1:38:11

I've seen it in Agile. But you gotta trust the system,

1:38:14

and you gotta have an environment where the system can work.

1:38:17

And obviously, I've had very, very many prescriptive thoughts

1:38:21

about what I think is a good implementation of Agile.

1:38:24

But ultimately, if you really trust Agile through and through,

1:38:28

you've gotta figure out your own system

1:38:30

that works for you and your organization. But in a perfect world where story points aren't really ours in disguise and where

1:38:37

product owners understand the trade-offs and where you're not getting swoop and

1:38:41

poops all the time, in a perfect world, Agile is an unbelievably fun and reliable

1:38:48

way to write software. And so I don't see it going away anytime soon, but it is one of those things where

1:38:57

you know, we've given you a length of rope that you can quite easily strangle

1:39:00

yourself with, but you can also fashion it into a very nice knot.

1:39:03

And so I hope you end up with a knot and not a noose.

1:39:07

Nice. And in, in the end, ultimately it comes down to, um,

1:39:12

you know, people in the end, how motivated they are,

1:39:16

how aligned they are with delivering an outcome, you know,

1:39:18

keeping it technical, listening to the,

1:39:21

the leads involved in the product owners and just, and delivering on that.

1:39:25

And I think that in the end, people that are determined to not make agile work will be

1:39:31

determined to not make it work and will then complain and that'll be evidence to say, "Well,

1:39:36

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

1:39:46

within the methodology, then it can be - it can actually work out quite well in the right

1:39:51

situation and it may well be magic.

1:39:54

I'll be honest with you, I haven't actually seen that firsthand,

1:39:57

but I do know that it's possible.

1:40:00

So I'm not going to be too old and curmudgeonly and say anything about,

1:40:05

Agile is just never going to work or whatever else. No, no, not at all.

1:40:10

Not at all. I think it has some interesting merit. So in any case.

1:40:14

Alrighty. Well, if you want to talk more about this,

1:40:17

you can reach me on the Fediverse at [email protected],

1:40:21

or you can follow engineered_net on Twitter

1:40:23

to see show specific announcements. We also have a YouTube channel

1:40:27

with more content going live regularly if you're interested in that.

1:40:30

If you're enjoying Pragmatic and you wanna support the show, you can.

1:40:32

Like some of our backers, Carsten Hansen and John Whitlow.

1:40:35

They and many others are patrons of the show via Patreon

1:40:37

and you can find it at patreon.com/johnchidjie or one word.

1:40:41

Patron rewards include a named thank you on the website,

1:40:43

a named thank you at the end of episodes, access to raw detailed show notes,

1:40:47

as well as ad-free high quality releases of every episode.

1:40:50

So if you'd like to contribute something, anything at all, there's lots of great rewards

1:40:53

and beyond that, it's all really appreciated.

1:40:56

Beyond Patreon, there's also a PayPal for one-time contributions at paypal.me/jheg.

1:41:00

But if you're not in a position to support the show that way, that's completely fine.

1:41:03

There's lots of other ways you can help, leaving a rating or review on iTunes, favoriting the

1:41:06

episode in your podcast player app, or you can share this episode or the show with your

1:41:11

friends or via social. And all these things help others to discover the show and can make a huge difference as

1:41:16

well. to thank Clubhouse for sponsoring the Engineer Network. If you're looking for an easy to use

1:41:21

software development project management solution that everyone can use, remember to specifically

1:41:26

visit this URL clubhouse or oneword.io/10theword to check it out and give it a try. It'll surprise

1:41:32

you just how easy it can be. Pragmatic is part of the Engineer Network and you can find it at

1:41:36

engineer.network along with other great shows like Causality, which is a solo podcast that I do that

1:41:41

looks at the cause and effect of major events and disasters in history, including the Deepwater

1:41:45

Horizon just recently, the Columbia Space Shuttle, Concorde, and lots more. Causality

1:41:50

is on track to overtake Pragmatic. It's growing in popularity. So if you haven't yet checked

1:41:55

it out, make sure you give it a listen. If you'd like to get in touch with Casey, what's

1:41:59

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

1:42:05

my handle is, so I'll just skim right through that. But you can find me on the dumpster

1:42:09

That is Twitter at Casey lists

1:42:11

Casey YL ISS you can also find my website at Casey list comm and

1:42:16

My other podcasts that I do the external tech podcast is an ATP dot FM and analog is that relay dot FM slash?

1:42:22

Analog spelled either the correct way or the way that has a unit

1:42:26

Smooth okay, well once again a special

1:42:31

Thank you to our patrons a big thank you to everyone for listening and as and as always

1:42:36

Thank you once again for coming on the show Casey. Yep. Thank you John

1:42:39

It's oh, it's always a pleasure. I appreciate

1:42:41

[MUSIC PLAYING]

1:42:44

(upbeat music)

1:42:47

(upbeat music)

1:42:49

(upbeat music)

1:42:52

(upbeat music)

1:42:54

(upbeat music)

1:42:57

(Music)

1:42:59

(upbeat music)

1:43:02

(upbeat music)

1:43:04

[Music]

1:43:11

(upbeat music)

1:43:14

♪ ♪

1:43:24

[Music]