[MUSIC] Hello, welcome to Picture Me Coding with Erik Aker and Mike Mull, I think.

Mike Mull, my co-host.

Last week, Mike, we spent almost about 40 minutes talking about Agile about the history of Agile, where Agile comes from.

By popular request, we've had listeners write in and say, "You guys need to do a better job talking about this thing that plagues me on a day-to-day basis as a software developer, Agile, methods, scrum, things like that."

Really, last week, we didn't have enough time to get into the criticisms of Agile.

It's been around long enough and there have been a lot of criticisms that have accumulated for it.

And so that's what I want to talk about this week.

Are you up for that, Mike?

Let's do it.

All right.

So, I'm not sure how to really ground this.

Last week, we were talking about the Agile manifesto, what they were responding to.

Maybe we should just start by enumerating the types of criticisms we see and then we can get into them, maybe see if they're valid, see if there are others that we don't see people raising regularly.

I'll tell you the first one that I see a lot and it's the same response pretty much everybody has to the thing.

You read the Agile manifesto and it's these bullet points that are real wishy-washy, vague, aspirational, almost metaphysical goals.

We would like to have customer collaboration.

Huh?

What the hell is this stuff?

So, here's the thing.

If I produce an Agile manifesto and it's really just a lot of vague, there's no system, there's no process.

And somehow, what we've inherited as software developers is some kind of process, even with weird rigidity.

And yeah, you can blame that on Scrum, but it's like, I go to standups every day and I've got retrospectives after two weeks and I've got sprint planning, I've got all these meetings.

But you look at the manifesto and they don't talk about any of that garbage.

So, there's no way to know what I'm supposed to do based on the manifesto.

And one of the common critiques I see is people say, "Oh, Agile sucks."

And the response is, "Well, you're doing it wrong."

But if everybody's doing it wrong, then we should question the value of something that's so easy to get wrong.

I think this is a common critique.

Am I off base here?

Yeah, Posner talks about that in that essay that we talked about last time as well, where she said that, I think she referred to it as the "no true Scotsman" problem.

Yeah, exactly.

Yeah.

So, the essay is called "Aggile and the Long Crisis of Software."

I actually have that quote if you want me to read it.

Yeah, do that.

So, Posner, Miriam Posner, Professor UCLA writes, "Part of the issue with it is Agile's flexibility."

And then she quotes someone she knows, "Jan Wishway, a freelance developer, calls this the quote, 'no true Scotsman' problem.

Any Agile practice someone doesn't like is not Agile at all."

It inevitably turns out the construction of the manifesto makes this almost inescapable because the manifesto doesn't prescribe any specific activities.

One must gauge the spirit of the methods in place, which all depends on the person experiencing them because it insists on its status as a quote mindset, not a methodology.

Agile seems destined to take on some of the characteristics of any organization that adopts it.

And it is remarkably immune to criticism since it can't be reduced to a specific set of methods.

Quote, "If you do one thing wrong and it's not working for you, people will assume it's because you're doing it wrong."

And quote, "One product manager told me," and this is following on another quote, "not because there's anything wrong with the framework."

Tell me what you think about that.

I think that's absolutely true.

I think so.

There's two ways to look at this.

The one thing that I've heard frequently is that the Agile manifesto was a really good set of principles and right on the right track for what we needed.

But what happened was that people took that and turned it into something that was not in the spirit of the Agile manifesto.

And John Kern, one of the original signatories, has referred to this as the Agile industrial complex.

What does that mean, the Agile industrial complex?

I think what he's getting at is that there are these organizations and these people who took these fairly broad ideas and said, "Okay, here's a thing that we can sell services and sell products.

And if we put some specifics into this, then there's an industry here for us to leverage to sell our tools and sell our services."

Okay, but sidebar, I have always been mystified, just shocked and astounded that there are people who will pay for some sort of learnings or mystical teachings about a thing which can be reduced to these four abstract aspirational things.

I think my counter-opinion, which is not an opinion that a lot of people hold, is that I think the manifesto itself is at fault here.

So that's a spicy take.

It's really common for people to say, "Well, you're not doing it right.

The manifesto is correct."

And people don't usually say what you just said, "The manifesto is wrong and I want to go there.

Take me there."

I think parts of it are wrong, but I also think it was left too vague.

So I think what's wrong about it was when they wrote it down, they were trying to be as broad as possible.

They were trying to cover all of the techniques that they were developing.

And so they left this sort of vacuum.

And people have, you know, I hate to compare it to a religion, but it seems like people have taken this as sort of like a religious text and then interpreted it in whatever way was useful for their purposes.

So anyway, I think they would have done the profession and at least the software profession a favor had they been a little more specific about what they meant.

If they said, "Well, you should have meetings every two weeks that reflect it on that plan, what you're going to do for two weeks, and then at the end of two weeks reflecting on what you did, that'd be a favor."

Yeah.

I mean, there's like a few, they drilled down a little bit in what they call the agile principles.

So there's these 12 principles of agile.

But even these are pretty broad and interpretable.

And some of them, I'm not sure if they're even correct.

You know, like there's this very famous one, "The best architectures requirements and designs emerge from self-organizing teams."

Self-organizing teams, yeah.

Yeah.

So I, for one, I don't know if this is true or not.

And two, it's not clear to me that a self-organizing team is something that you can create by some process of just hiring the right people.

I think self-organizing teams happen because you end up with, sometimes with teams, where you have a lot of good people who are really committed to the product and who are technically good.

And teams do tend to self-organize.

People take on things that other people don't want to do.

They have a specialization that is beneficial to the team as a whole.

Or you have people who are kind of, you know, an information nexus who facilitate communication from one part of the team, the other part of the team.

And so I've had the good fortune to be on a couple of teams like that.

And it is really nice.

And I think, you know, you do get good designs from that type of team.

But it's not clear to me that that is something at all that you can make happen by some prescribed method of hiring the right people or finding the right skills or whatever.

What you just referred to right there is exactly the crux of the problem.

I have been on teams that were really good.

They produced high-quality software.

They produced it really efficiently.

And they gelled.

And that quality of that team was often because of the people who comprised the team and their connections with each other.

And the agile manifesto is this extremely abstract, wishy-washy, like blobby, hey, you should try to produce that.

And scrum is a, here's a process which will force people to work like that.

And both seem like miserable failures in bottling the magic of the really good teams.

Self-organizing team sounds like Fred George's developer anarchy.

And I've been in instances where developer anarchy was pretty much what we had.

And it seemed to work great.

And the people worked great.

And our working relationships were phenomenal.

And there's another critique that has occurred to me.

And I've heard other people say that you can apply it to a really well-working team.

And that's fine.

It won't make them work more poorly.

And you can apply it to a team that's kind of dysfunctional and not doing well.

And it will not turn them into the really well-working team.

Yeah, I've seen both things happen.

So I've seen cases where you had teams that were frustrated about not being able to make progress.

And then you imposed some sort of more formal agile process on them.

And they felt as if they were making more progress.

So I think that does happen.

Oh, okay.

You said they felt.

So they may not have actually been making.

They just felt like it.

They're motivated.

They're morale improved is what you said.

Yeah.

The meetings will continue, Mike, until morale improves.

I think I'm reluctant to say they were clearly doing better work because I'm not sure how measurable that is.

Okay, all right.

So I have this very bad attitude about software management in general.

And I think it comes from experiences that I had being a software manager.

Oh, it's not from having bad managers.

It's from having been a bad manager.

Yeah.

So...

That is beautiful.

So I have been a manager at various levels, from team lead up to CTO.

And so I had this experience.

One of my first sort of higher level management jobs was in the early 2000s.

And I worked with this team where everybody was brilliant.

It was just kind of amazing.

We had three people on the team.

We had PhDs.

We had a software developer who was one of the best developers I've worked with.

And this team was just crank stuff out.

And it was always good.

And it was, you know, sometimes I was just surprised at the breadth and quality of stuff they would do.

And I started to think, "Man, I am kicking the ass of this management thing."

I'm really good at this.

I'm really good at this.

And, you know, at some point we started to have more working we can do.

We started to hire more people.

And so we brought in some people who are less senior and who, to be frank, weren't as skilled as the previous people on the team.

And I noticed that they needed a lot of hand-holding.

You know, they needed a lot of guidance about what they were doing.

And I realized that I was not particularly helpful to them.

So those other people who were being successful as a team, you couldn't necessarily take credit for it, you realize?

Yeah, I couldn't take credit for it.

And it gave me this attitude that, you know, the best way to manage software development teams is to hire people who don't need to be managed.

And get out of their ways.

But so that sounds like self-organizing teams.

It's just a thing you can't create.

Yeah, I think that's, you know, I've always felt that's probably what they meant by self-organizing teams.

But again, it's, I think that's a thing that happens by luck, not by process.

So anyway, I can't remember where we're going with this, but...

We were talking about critiques.

You said the manifesto is probably wrong.

Let me read the four lines from the manifesto.

Individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, responding to change over following a plan.

It's four bullet points that are all framed as contrast.

Thing A is better than thing B.

And maybe by implication, don't even bother doing thing B.

You don't need processes and tools.

You don't need comprehensive documentation.

You don't need contract negotiation.

And I kind of look at that like, when would I ever need that?

And you don't need following a plan.

You need these other things.

And you had said the manifesto is a lie.

You think it's true that it's really a lie.

Let me tell you one of the principles that I read and I'm like, that sounds like bullshit.

Here's one of the principles.

Welcome changing requirements even late in development.

Agile processes harness change for the customer's competitive advantage.

What?

I don't want to welcome, I want to build a thing.

Yeah, sometimes I have to change what I built because I've misunderstood what they wanted.

But what are you guys talking about?

We're going to just adapt constantly and then somehow that will translate to quote unquote, the customer's competitive advantage.

What?

That sounds like bullshit.

Yeah, that's in the principles.

I have to say.

Principles, yeah.

Yeah.

And I struggle with that one too.

This should be sort of the key selling point of Agile, is that requirements change and.

Yeah.

Be flexible.

Don't be rigid.

Right.

Be flexible.

If you work on shorter cycles, theoretically, that lets you respond more quickly to things that have changed.

I do have some issues with that.

I think it depends a lot on the degree of the change.

And I think it depends a lot on where you are with the thing that you're building.

Yes, if you do a sprint review and the customer says, I think this button should be over here.

Yes, you can move the button.

That's pretty easy to do.

If you're two weeks from deploying it and the customer says, okay, now I need this to run on the mainframe on a boat.

It's just, you've really gained nothing by doing shorter cycles.

So I think it's kind of questionable.

There's no question, I think, that this helps address changing requirements in some situations to say that it, well, first of all, harnesses change for the customer's competitive advantage, I think, is, as you say, bullshit.

It just doesn't mean anything.

It doesn't mean anything.

So there's two problems with this.

One, we have to build something specific.

At some point, we've got to say, okay, we're going to build a specific thing, whether it's a small thing or a big thing.

We're going to try to build it.

We have to commit, at some point in the process, to building the thing.

So being infinitely flexible doesn't help anybody.

It means we could just iterate forever.

The secondarily, I might show up to the customer and they might say, like you said, I just want to change something.

And I should adapt to that.

That's great.

They're going to use it.

Cool.

They're happy with what I've got, but they just want to change it a little bit.

Fine.

I will be flexible.

If I show up to the customer and they say, that's not what I wanted at all, then there's a couple problems here.

Why the hell did I build this thing?

Or does a customer have any clue what they want?

It's like Jobs is famous.

They don't know what they want.

We're going to give them the iPad.

They didn't know they wanted the iPad.

Sometimes that happens.

They might say, oh, I don't really want this.

I want that.

And they might start drooping up something.

But that isn't what they want.

They really need this other thing.

Yeah.

I remember a situation.

This was again probably 25 years ago.

But I was working with a group of clients and we were trying to build this tool for them.

And one aspect of this tool had some statistical methods in it.

And they were relatively sophisticated methods that were related to the industry they worked in.

So we tried to nail down.

There's a lot of stuff we needed to do.

And so we were trying to nail down with the customers what they wanted that particular part of the software to do.

And the response from the customer base was, well, there's this tool that we use and this tool that we use and this tool that we use.

And we want your software to do the union of those three things.

But also it needs to be simpler than any of those.

I have a similar example, which is, I worked with a lot of these underwriters over the past few years.

They're underwriting loans and they love Excel.

And what they want me to build, what their heart burns for, yearns for, is a software application that produces their beautiful Excel spreadsheet.

Whatever program I run, the output should get shoved into a cell in a real Excel spreadsheet.

And I got to tell you, I don't want to build that.

And I don't think it helps them ultimately if I built that.

My customer is wrong, Mike.

Yeah, yeah, another good example.

We should probably someday have an entire episode about Excel.

So here's another criticism.

We're talking now this week about criticism of Agile.

And we already brought up that it's extremely vague.

It's extremely imprecise what they're talking about.

It's just these abstract principles.

It's almost metaphysical.

And the great irony is if you look at the actual implementation of Agile today, it's blended with Scrum.

And maybe you could blame us on Scrum, but whatever.

They're pretty much what we deal with in our industry.

There's too many meetings.

There's too much process that you mentioned, the Agile Industrial Complex.

That's like, I got to sell you a framework, Mike.

I got to make money on teaching you some structure to make your software engineering teams go great.

So I'm going to talk about these types of meetings that you're going to run.

And you're going to be like, oh, yeah, okay, this is my structure now.

It's going to work.

There's an article where they talked to John Curran and he says, "The proliferation of processes and frameworks that have sprung up in the wake of the manifesto."

It's like, he calls them, "It feels like we step back in time as if the manifesto never existed and we're back to heavy processes."

This is like irony that they didn't want rigidity and process.

And because they didn't commit to saying you should do these specific things, all this cruddy process got created anyway.

He says, "Why are we back with these giant diagrams or giant processes?"

And he actually says, "Well, because it gives comfort to those middle managers who really don't know what's going on as much as they think they do.

I can latch on to this.

I can see roles.

It's nice.

The diagram looks great.

It's almost like waterfall.

It gives me a false sense of security and I'll just pretend to ignore reality."

What do you think he's saying there?

How would you describe this, characterize this critique?

Well, I tend to agree with it, but I try not to be too cynical about this stuff.

I think there is this general sense in our business about all this stuff would be a lot better if we could just get the suits to leave us alone.

I often referenced this essay I read when I was a very young programmer by the science fiction author, Orson Scott Card, about comparing software teams to a swarm of bees.

You just let the bees do what they do and bees are going to be fine.

When they're not paying attention, you swoop in and steal their honey.

I think there's this tendency of people who write software to want to just be left alone to do their thing.

But the beautiful team you described sounded like that was the self-organizing team, just like that.

Sorry, there's a tendency to want that.

But I think that's also a little bit divorced from reality.

The team that I was working on that I described earlier, which I thought was a really great team, I think they also had a good sense of what the end product needed to be.

I think they had a good sense of budgets were not infinite.

We had to put out quality software that people were paying money for.

I do think there's this tendency of people who are not developers and they don't have the sort of intuitive feel for how software is made.

They do want something that checks boxes and looks like there's another layer of bricks on the wall this week.

I don't want to be the guy who says those people are just getting in our way because that really does need to exist in our industry.

In 40 years, we are not great.

They come to us and they say, "How long it's going to take?"

I don't know.

Nobody's ever done that before.

They're like, "What?

People have been doing this for 40 years.

What do you mean nobody's ever done that before?

How much is it going to cost me to get that thing built?"

You're like, "Can you just leave me alone because I really just want to go back to my art room and paint on my canvas for a bit, okay?"

Yeah.

Let me go back to Posner.

Last week, I read that quote from Posner, Mary Posner, about the waterfalls promise.

Here's the interesting about this quote.

"You could drop the reference to waterfall and carry it forward 20 years and say she's talking about agile scrum.

Listen, the promise of tightly controlled management was a mirage.

No amount of documentation process or procedure seemed capable of wrestling development into predictability.

Software projects were big, expensive, and they seemed to be spiraling out of control."

Am I wrong in reading that and going, "Well, geez, you could make that criticism of all what we do today?"

I think that's probably fair.

One thing that's, I think, maybe not emphasized enough is things have changed a lot since 2001.

So when people were doing agile originally, there was no Jira.

That sounds great.

Yeah.

I'm down with that.

There was no GitHub.

There was no cloud.

You're saying you had to use real post-it notes and a real whiteboard.

Yeah.

When I first started doing scrum, we literally used post-it notes.

We moved them, we tacked them to a whiteboard and moved them from one side of the whiteboard to another side of the whiteboard.

It worked perfectly well.

The other thing though is that up until probably 2003, a lot of people were still doing physical media.

CD-ROMs.

CD-ROMs, you'd put software onto a physical thing and you'd ship it out in a shrink-wrapped box.

There's a hard end date to that.

Yeah.

It's not something where you can, like that CD-ROM, the software in that CD-ROM is not something that can be an alpha.

You can't send out a CD-ROM every three days with a new release on it because it's not the way these companies work.

The other thing is that you have to imagine an environment where everybody's going to an office, everybody works in a cube, and there's no slack.

People probably have ties on and their shirts are tucked in.

No, probably not.

They're ties.

For instance, one of probably the most well-known and celebrated ceremony of Agile Methods is the stand-up meeting.

I think the stand-up meeting made a lot more sense in 2005 than it makes in 2024.

No, because we're on slack all day talking about what we're doing anyway.

So now you're on slack all day.

You've got these tools that are sending you messages on slack.

You've got these systems that track your tickets for you and stuff like that.

In those days, you really did need these rituals to find out what other people were doing.

It made sense to gather and have everybody tell people what they did yesterday and what they were planning to do and what issues they were running into because you probably hadn't heard about them yet.

And if you didn't do that daily, you might not hear about them until next week or something.

But that is not a problem today.

And that is one of the funny ironies about it that we adhere to the daily stand-up, the purpose of which is to make sure people know what you're doing.

Everybody already knows what you're doing and we cannot stop doing the dumb ceremony because why?

We just can't.

It would look bad if we stopped doing this completely stupid ceremony that nobody needs.

Yeah, and if anything, they've gotten more formalized and longer as time has gone by.

When we were doing stand-ups in the early days, 15 minutes was a long one because a lot of times you're working on the same thing every day for a week and so your contribution was still working on ticket X and that was everything you were going to say.

And so now it seems like it's probably not this way everywhere, but in the places I've worked at at the last five or 10 years, it's been, they've got, seem to get more longer and more people are trying to figure out, I think, what we are getting out of them and so they keep adding things to them to make it seem like we're getting something out of it.

Every time I go to a stupid stand-up, I'm always like, who is the audience for this because the people participating aren't getting much out of it.

They're having a free form meeting about problems and things they should build.

Okay, so I want to go back.

We're talking this week about criticisms of agile and so far we've covered a few and there's a few more that I think come up.

One was no structure, there's no substance, there's no system, so it's impossible to do it correctly.

Another is they emphasize changing requirements, but that's not only is it amorphous and abstract, it doesn't always make a ton of sense.

Yeah, be flexible, but that doesn't help me much.

They talk about customer collaboration.

That may be actual bullshit, we've determined.

There's too many meetings now and too much structure asserted by people saying we're going to wrangle this messy software development into a thing that has structure so we can make the business leaders feel happier.

Here's a couple more, Mike.

We deal with complexity on our tasks by talking about story points.

Story points always feel like a complete lie to me.

It's like a lie that we're always participating in together.

We just agree to lie to each other and do ourselves about story points.

Yeah, story points is probably the most, for me personally, is probably the most rage inducing aspect of agile.

Let me give you a phrase that I have heard in every organization I've ever been in where we want to have story points on tickets.

Here's the phrase, story points are not time.

Let me tell you something that has happened at every single organization I've ever been in that uses story points.

There is someone who keeps a document or people all have it in their heads and they say it for how much time each story point translates into.

This is the number one lie.

It's not time, but we're going to constantly use them to revert to time.

Some places they actually just say, well, it'll take me this long.

I always thought of story points are like casino chips.

You pretend it's not money and then you spend all this money because they're not money.

It's just chips.

Then you turn them in at the end of the night, maybe you get more, you get some money back for your chips.

Just totally bullshit.

They're an approximation or they're a proxy for something real that we care about, but we're only interested in story points because we want to know how long it takes to do the work.

Can you imagine if you really cared about how complex a thing was to do if you weren't doing it?

If you hired an electrician and you say, hey, I've got a gas range.

I don't want to convert to an electric range.

I don't know what you got to do to do that.

The electrician says, well, this is more complex than adding a new circuit to your panel.

You'd probably be like, well, that's great.

I don't really give a shit.

Can you tell me how much it's going to cost to do it?

How long will it take?

I don't care how complex it is.

Is it complex, but it won't take very long?

It doesn't matter to me.

As developers, if you say to me, hey, Eric, how complex is this?

I'd be like, well, it looks kind of hard.

You'd be like, okay, all right, it's going to take more thinking.

Do we really need to put some mythical story point on that thing?

Some magical number that has some meaning?

Well, I mean, if you don't put story points, if you don't put imaginary story points on your tickets, then you won't be able to calculate imaginary velocity.

That's true.

The only thing I know about velocity is that I would like to have a high one.

Well, I guess that's true, unless you're going so fast that you can't keep control and you smash into a wall or something.

Or your car becomes airborne and starts flying into the crowd.

When you started doing Agile, when you had your post-it notes and your tickets and you had stand-ups and you said, "I still work on a ticket," did you do story points?

The company that I worked for when I first started doing Scrum was a company that had a lot of money at the time.

They actually bought us these decks of cards.

I can't remember exactly what was on them, but we did this estimation poker thing.

Oh, I've done that before, yeah.

But not with proof physical cards.

Yeah, so they...

What were you estimating at the time where you were like, "Oh, great.

I really buy into this bullshit."

I think there was this sense of, "Well, we'll give this a try," because we really don't know how long stuff is going to take, but we do have a good sense of how long things take relative to other things.

Did they cudgel you with story points aren't time?

Did you have that at that time, or was that a later invention?

Yeah, I think that was...

At least in Scrum, I think that was always a principle that you're not really estimating time.

You're estimating a relative thing.

It always sounded a little bit like multi-level marketing or something, where it's like, "This doesn't seem like a very good idea, but people will seem to be successful with it, so I'll roll the dice and see what happens."

But yeah, over the years, it's just one of those things that it just seems almost cultish at this point.

I just feel like you are lying in my face if you're telling me.

I want you to put a number on this thing, and I promise it doesn't mean time.

And we all know that you're going to use that to try to figure out how long it's going to take to do the thing.

Yeah.

I mean, what you see is...

A lot of places use the Fibonacci numbers.

And what I will concede is that you can usually tell when something is a one-point ticket or a two-point ticket, something like that.

It's something that's going to take you...

You look at it and you say, "I know how to do that.

I know what the steps are to fix that thing.

I know that I've done this in the past, and it's going to take me somewhere between two to four hours, and so I can give that again mentally.

You're mapping the story points on to time, which is what everybody does, which is...

That's the part that pisses me off.

Yeah, that's the lie.

But the problem that I also run to that annoys me probably even more than the fundamental lie is that once you get past maybe three story points, the variance in the outcomes is going to be so big, and nobody ever revisits them, and nobody ever tries to figure out where the variances were.

It just seems like the most pointless.

The other thing that happens is that you'll look at something and you'll say, "Wow, that's really complex.

I think that's going to take 13 story points," and then the judge slams the gavel on the bench and says, "Rule of violation.

We can't have that many story points in one ticket."

We're going to break it up into smaller units.

We're going to break it up into smaller units, then you arrive at this other step where it's like, "Okay, how do we do that?

Where in my methodology does that come in?"

There's this moderately well-known essay that Leslie Lamport wrote in Communications of the ACM a while back called, "Who Would Build a Bridge Without Blueprints?"

or something like that.

Who built the house without drawing blueprints?

Yeah, who built the house without drawing blueprints.

But I think the thing that bugs me about Scrum and is that, or I guess this is true of any Agile, is that there's a point where you have to stop and think about things.

There's no provision in the method for the stopping and thinking about things.

How many story points do you want for the "You're going to walk around your neighborhood and think about it?"

Mike?

Yeah.

I mean, we've seen people try to figure this out with spikes and you get into debates about, "Do spikes have story points?"

Yeah.

"Do bugs have story points?"

My favorite line was, "Asking me how long it will take to fix this bug is like asking me how long it will take to find my keys when I've lost them."

Yeah, exactly.

I'm going to give you a quote from the Leslie Lamport.

"As you brought it to me, you brought the quote to me."

I thought that was a good quote.

Lamport, "In who builds a house without drawing blueprints?"

he writes, "Specification is often taken to mean something written in a formal language with a precise syntax and hopefully a precise semantics.

But formal specification is just one end of a spectrum.

An architect would not draw the same kind of blueprint for a tool shed as for a bridge.

I would estimate that 95% of the code programmers write is trivial enough to be adequately specified by a couple of prose sentences.

On the other hand, a distributed system can be as complex as a bridge.

It can require many specifications.

Some of them formal.

A bridge is not built from a single blueprint.

Multi-threaded and distributed programs are difficult to get right and formal specification is needed to avoid synchronization errors with them."

Lamport is like, "Hey, hey, hey.

We're not going to document stuff.

We're going to emphasize on the building of it."

Lamport is going to say, "Hold on now.

You're going to have to write some junk down."

Yes, and it may just be because I'm an old man, but I read this essay and I'm kind of like, "Church."

Preach.

But do you think Lamport would be into story points?

I have not.

I don't know if he's ever profited an opinion on them, but I think he would probably not like them.

He'd be rage-induced as well.

So there's a really interesting point that shows up again.

And if you've never read this essay, strongly recommend reading it, "Aggel and the Long Crisis of Software" by Miriam Posner.

Posner says, "Aggel's good at compartmentalizing features, neatly packaging them into sprints and deliverables.

But really, that's a tendency of software engineering at large.

Modularity or, quote, "information hiding" is a critical way for humans to manage symptoms that are too complex for anyone, person, to grasp."

Slide bar, Mike.

This sounds like the hierarchies thing again, right?

Complexity.

Anyway, back to Posner.

But by turning features into, quote, "user stories" on a whiteboard, Agel has the potential to create what Yvonne Lam calls a, quote, "chain of deniability," an assembly line in which no one at any point takes full responsibility for what the team has created.

I think there's two critiques here of what Posner is saying.

With Agel, we're encouraged to break things into small, digestible pieces.

That's good.

Helps us manage complexity.

But there may be two things lurking in that.

One, the big picture is very hard to reassemble in your head.

And two, what if I'm building something horrible, awful?

Well, I'm not really in charge of that.

I just did Ticket 123.

It's those guys who really wanted to make it cool for whatever child predators to be on our platform.

I just did this ticket.

My belief is that when you look at these so-called self-organizing teams, teams that are really productive, most of the people on those teams have the sort of a shared mental model of the entire system.

And some people may have more detailed about certain specifics.

Some people may have to ask other people about details of a particular part.

But I think everybody has this sort of mental model that they share and can communicate with.

And when you bring new people into the system, I think you have to sort of, as they are doing smaller pieces, you have to sort of help them develop the same mental model so that everybody on the team knows what the way things fit together.

And I think that's one thing that I don't blame just the method, but I think sometimes the engineers are responsible to.

But I think this is something that Agel does not help with.

My experience has been both that, I think the method encourages a little bit of ticket punching, because you atomization kind of.

Right.

So you want to break things down so they can fit in a sprint.

And I think there's an extent to which certain developers want, they like that, and they want the people who are trying to figure out that atomization to be other people.

And they don't want to take responsibility for that.

And they don't want to have the mental model to figure out where the pieces fit.

So the thing you said about the really well self-organized team actually points to this attribute that I've seen in developers who I really appreciate working with.

They could hold big abstract general in their heads, and they could zero in on a specific, and they could kind of freely go back and forth between, I'm on this very tiny little node.

How does it fit into the whole software application?

How does the whole service fit into the system?

Like they could go back and forth between the layers zooming in and out freely.

And I've seen that in people who are great at being organized in general, not even in software.

Like a really good essay goes from general to specific and back.

You see this connective tissue between the zoomed out view and the zoomed in view.

So that's a quality that we would like to achieve in teams.

And I'd like to have that quality in co-workers, but it's kind of like, it's sort of this magical quality.

I don't know if you could teach people to do it.

So we've covered a number of criticisms.

There was a kind of weird study that came out earlier this year.

We'll link it.

You can draw your own conclusions about it.

I don't know how valid their results are.

I don't want to, I don't really know.

But according to this study that came out earlier this year from a company that has, that may be promoting some other process, they cite some research, which they say was done independently of them.

The research has found that projects which had a specification or documented requirements before development started were 50% more likely to succeed than those that didn't.

Projects which had clear requirements before starting were 97% more likely to succeed.

And projects which did not require making significant changes late in the development process were 7% more likely to succeed.

These numbers are in the article that have this inflammatory comment that comes out of the study which is most agile projects fail.

Yeah.

Hillel Wayne who we've referenced on the show before wrote a short piece about this study and basically concluded that it was probably bullshit.

All right.

So we should throw the study away.

We should throw the study away.

I think you should definitely take it with a grain of salt.

Okay.

So to finish, we need to talk about agile sucks.

What are we going to do instead?

To close this out, Mike, we have concluded agile is unsavageable.

We're going to throw it away.

The inevitable response to that is, what the hell are you going to do instead?

Are you going to organize the developers?

You're just going to be like, go for it.

I guess I'm assuming AI is going to solve that problem for us.

Okay.

Well, in in lieu of that, there are two problems.

I am a business owner, potentially you can imagine, right?

Hypothetically, I'm a business owner.

I have two questions for you and your team of developers.

Mike, how long will it take to build?

How much is it going to cost me?

It's possible.

Those are the same question, but I don't want to know how long, how much?

And then another question which often doesn't get asked, but also important, how much is it going to cost me to maintain this thing in the long run?

How long?

How much it'll cost me upfront?

And how much will it cost me in perpetuity?

How do we answer those questions for these business people?

If I had a really good answer for this, I would probably be selling it.

You would make classes of certification on it.

That seems so dishonest of you, Mike.

Yeah.

I think the best that we have anymore is you analyze the problem, figure out how long you think it's going to take, and then multiply everything by three.

But yeah, I think people have been talking about the software crisis since the 1960s, I guess.

At least, I guess I would claim that we still have a crisis.

And it's not because so much because things don't work and the projects fail.

It's because even now, 50 years into the profession, we still don't really know how to do it very well.

Formally.

Like one organization to another, you mean?

Yeah.

I mean, I think there are hints of people trying to do things better.

Companies like Amazon are using TLA Plus for distributed systems.

And I see there are companies that have sprung up to do formal methods and saw a company come across my newsfeed a couple of days ago that's doing a combination of formal methods and AI for embedded systems.

Wait a minute.

I came to you as a business owner, and I asked you to do me a favor.

Tell me how long it'll take to build this and how much it's going to cost.

You started talking about formal methods.

This is like my electrician.

My electrician shows up.

I want to get an electric range, and he's like, well, we're going to formally specify that for you.

And I'm like, I don't want that.

Can I just get the work done?

How much is it going to cost?

How long will it take me to build?

I just want it to not burn my house down and I want it to work.

But that's your job to figure that out.

Yeah.

I mean, I think that is sort of what we should probably be working towards.

I mean, I've been doing this for 40 years, and the argument has always been that can never happen in software because software is not like building regular things.

We don't do the same things over and over.

And so we can't know how long they're going to take, et cetera, et cetera.

It's like stacking cats together.

They all have different personalities.

Okay.

Sometimes you want to make a pyramid.

Sometimes you want to make like an arch with the cats, and it's pretty hard to know how long it'll take you to pull that off.

Honestly, I've never stacked cats before.

Let me go back to Posner.

Posner says in her research about Agile, she "discovered a long wrestling match between what managers want software to be and what it really is as practiced by the workers who write code.

Time and again, organizations have sought to contain software's most troublesome tendencies, its habit of sprawling beyond timelines and measurable goals by introducing new management styles."

Within that context, Agile looks like yet another attempt to wrangle the beast and another failed attempt.

Would you agree with that?

I would agree with that.

I think if you go back to that lamport quote, one of the things that he says in there is that 95% of tasks can be described in a couple of prose sentences.

And I think the reason, you know, this, I will probably get criticized for this, if anybody ever listens to this, but I think one reason why Agile has worked as well as it has is because most tasks are in that 95%, those tasks that could be described in a couple of sentences probably could be done with any management style just because they're not particularly complex and the consequences of getting them wrong may not be that high.

I want to give you some principles that I kind of have thought of.

I do not want to offer them as the solution.

I don't believe in a systemic solution here.

One of the problems we talked about is the jettisoning of documentation.

You're talking about rational unified process, UML, there was some utility in that.

But this impulse that I often have when we talk about planning our projects, business wants to know how long, I often want to say, "Can I just start building it so I can figure out how long it'll take me to build it?"

That's the one thing.

I just want to start building it and then I'll tell you how long it'll take me to build it.

Is that all right?

On the other hand, I do want to commit to refactoring and reshaping things as I'm building it.

That sounds like a be Agile, be flexible thing.

Another thing is I should really be committed to an MVP.

I like this idea of an MVP.

I'm producing a specific tiny thing that will be usable at the end of this.

Maybe I'm on a group of people doing it.

Here's where I think there's some room for negotiation or meetings.

We should probably renegotiate the pieces of the MVP on a weekly or bi-weekly basis.

The devs should figure out what goes into the MVP and the business should be like, "Okay, are we still going to be able to produce this minimum viable thing?"

The devs say, "No, no, no, we can't.

Okay, well, this is a negotiation.

What can you get me that I want?

Are you just spinning it real?

You've got to produce something I care about."

I think ultimately the weird thing about it is developers like us, we would build stuff without having deliverables.

We don't need to be motivated to write the code.

We just need some structure to make sure we're driving towards the eventual thing.

Maybe that structure comes in extrinsically.

The business saying, "Here's the MVP I want."

Negotiating that.

Internally, here's the design documents that we're going to use to continually agree on what it is we're actually building.

Now, I might have just committed the sin of stating some sort of process there.

I feel like one of the reasons why Agile has not been as successful as people hoped is that it really didn't make a lot of difference.

It didn't move the needle very much in terms of figuring out what the customer wants.

Part of the philosophy was more customer collaboration.

The idea was you're going to put software in front of them more frequently.

They're going to look at it.

They're going to say, "Yes, I like this.

No, I don't like that."

You're going to change it, all of which sounds great.

I think the more fundamental problem is that at some point, the user has to say, "This is what we want to do.

This is what we are trying to accomplish."

There just is not anything that has made that better in the last 20, 25 years.

I think in some ways, in some circumstances at least, it's probably gotten worse because you've put intermediaries between the customers and developers who, as part of these methodologies, you have product owners and product.

The direct communication that I think they were seeking in the original manifesto, it isn't really happening that much.

You may get lucky and have a product owner who is good in the domain and good at communicating with the customers and good at communicating with the developers, but it's pretty rare.

I just think there needs to be something on the user side where the users can say, "This is what we want.

This is what we want it to look like.

This is our goal.

This is what we're trying to accomplish."

Then somehow communicate that in a way to developers so that they can render that into software.

In a self-organizing way.

I got to tell you, if I went to interview for a company, and I said, "Do you do Agile Scrum?"

and they said, "No, we do our own thing."

We decided that Daily Standup for Pointless were all on Slack every day.

I'd immediately be like, "You have my attention."

Because it takes boldness.

Yeah.

I would definitely probably say I want to go there.

Yeah.

It takes guts, right?

To say that dogma is not working for us.

I'm not worried about looking weird by not doing it.

It takes real guts.

Yeah.

That's another thing that is kind of strange now is that not doing Agile is the days when people were, they would tell you to always buy IBM.

You can't go wrong buying IBM.

You can't get fired.

Nobody ever got fired buying it.

It's the same with Agile now.

If you don't do Agile and it doesn't work out, you're probably kind of get fired.

It just seems like it's so ingrained in the culture now that it's going to be hard to get past.

Well, I do see a lot of criticisms nowadays.

Developers like us are not drinking that Kool-Aid so freely anymore.

All right, Mike.

Thanks for tackling this topic for me.

It was a hard one.

It took a long time to get through it.

I don't know how well we smashed it, but we made an effort.

I thought we would spontaneously come up with a better alternative while talking it through, which didn't happen.

We did.

You have to read through the tea leaves of what we said to get the metaphysical properties below the surface to then turn that into the Mike and Eric process.

Yes.

If you'd like us to expound on that, we can be hired to come to your company and give seminars.

Oh, and we do offer certifications as well.

Yes.

We offer several certifications and we will be releasing tools for our process any day now.

That sounds great.

All right, Mike.

We just started a business.

Sounds great.

I had fun with you as always.

Thanks for talking about this with me.

Thank you.

We will see you next week.

Bye-bye.

See you next time.