Patricia AasMay 25, 2025
This whole Agile Coach debacle has helped me realize something that hadn’t fully landed with me before: agile started as a movement driven by builders to «build better», but it is largely dominated now with people who don’t know how to build and look at agile as a management process style. These are MBA-like folks who are trying to figure out how to manage an IT organization. But that wasn’t what agile was about. It was about a better way to build stuff, better stuff, by collaboration and not getting stuck in our ways.
Show threadMortenMay 25, 2025
@Patricia Yeah, the parts are good.
- Break projects into tasks and task into smaller parts
- Go quickly to a product (so you can talk to end user)
- Being attention to when you need something from coworker or vendor to progress
Show threadPatricia AasMay 25, 2025
@drgroftehauge Tbh I think «breaking something into subtasks» is often an illusion. Some things that we know how to do sure, but a lot of dev is figuring out stuff we don’t know and there is no way to break that down. And we have not been great at explaining that.
Show threadjjjMay 25, 2025
@Patricia @drgroftehauge Thank you for saying this. When I switched to software development and was told to estimate points and to break up stories, my reaction was that that's not how it works. Or rather, that is not the process when I'm working. But still, I had to. Now I am pretty good at playing the game, to get the job done.
Show threadPatricia AasMay 25, 2025

@jjj @drgroftehauge I am of two minds on estimation (plus a personal observation):
1. As an individual dev this is mostly a meaningless exercise
2. As a person who has plumbers and electricians etc in my house occasionally, I have no idea if plan A vs plan B takes takes 2 weeks vs 2 days, and that might be a big part of my decision on which way to go.

Observation: in early agile I was on a team trying many things, and one was estimating, but we didn’t share these estimates outside the team, as numbers they had no meaning, the work took the time it took. But estimating as a group brought out new information (why do you say 1 day and I say 1 month?), and also it made collaboration easier, because everyone had a rough idea about all the stuff we were doing as a group.

Show threadThomas DepierreMay 25, 2025

@Patricia @jjj @drgroftehauge estimation is like planning. The process is useful (sometimes). The output is not.

The trick is to stop seeing the output of process as the solution. The "thing" is the dynamic process. Because the outside world is not static but dynamic. That is one element of "system thinking" i think miss the point. The map of the system is not useful. Mapping is. Because the thing that make a system work is how it changes over time. The *dynamic* aspects of it.

That is why copying a system doesn't produce comparable results. It misses the fundamental dynamic part. How it changes.

More than "planning", what is helpful is *replanning*.

I am probably too deep

Show threadbmaxv

@Di4na @Patricia @jjj @drgroftehauge

I think this is a confusion stemming from using "planning" both for describing scaling from making 20 cupcakes to making 200, which is easy and also from 20 to 20 million a week. Which has some superficial overlap, but is actually a completely different problem. In a new space that's probably mostly unknown.

The first kind makes sense, is static and transferring the same system description is useful.

And the rest is just hard.

May 25, 2025 at 12:19pmWeb
Show threadPatricia AasMay 25, 2025
@bmaxv @Di4na @jjj @drgroftehauge I like that example