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 threadPatricia Aas

@Di4na @jjj @drgroftehauge I don’t know about the system stuff, I’m not enough into that to judge, but my experience is something like that. And estimation as an exercise triggers something in us nerds, we start asking questions, discussing solutions, it makes us talk, because we can’t commit to a number, even one nobody cares about, unless we have a better idea what job is about.

Related, but completely different, I tried in a team to ask each person to sum up the last sprint in a word, but then I walked in on one of the guys very busy before the retrospective going through all mail, chat and commits to figure out his word. We stopped doing that.

May 25, 2025 at 6:18pmWeb