Mastodawn

Patricia Aas May 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.

Morten May 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

@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.

Morten May 25, 2025

@Patricia Haha, yeah I upset the scrum dude a bit by giving things a lot of points when there was high uncertainty and then completing it quickly.
I do naturally break things down into the parts I need to do on a daily basis. But that's a post it, not something for an ITMS like JIRA.

jjj May 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.

Patricia Aas May 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.

Patricia Aas May 25, 2025

@jjj @drgroftehauge but it’s like every stat collected: the moment you use it for something, it influences the data.

John-Mark Gurney May 26, 2025

I'm not sure how much my previous manager used the data, but after a couple of years at it, the team got good at pointing (if it takes longer than a couple days break it down even more) and apparently our velocity (how many points per week) was steady, and our point got reliable.

So it could be used for planning, but also, you couldn't plan out very far, as you can't necessarily know if that 2 week task really will take that, but at the same time you know if you can get the work done in the next month or not.

It did take a couple of years to get a smooth rhythm with the process.

@jjj @drgroftehauge

Lars Ivar May 25, 2025

@Patricia Some years ago I was part of a product team, initially small but ramped up to about 12 devs + product owner + external graphical designers. There was a base product, that was supposed to be extended to overtake an ancient thing. We spent 3 weeks estimating using cards and fibonacci numbers. Totally grueling. Estimate was (at least) 3 years with that team. Got back from CEO "You have 1-2" and from there things just broke down. @jjj @drgroftehauge

Patricia Aas May 25, 2025

@larsivi @jjj @drgroftehauge yeah, those numbers are dangerous, I didn’t realize that in the beginning. We were lucky in that first team in that nobody cared about them except us, tbh maybe we didn’t tell anyone 🤔

Thomas Depierre May 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

bmaxv May 25, 2025

@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.

Patricia Aas May 25, 2025

@bmaxv @Di4na @jjj @drgroftehauge I like that example

Mike Anderson May 25, 2025

@Di4na @Patricia @jjj @drgroftehauge it's very important to understand that the process doesn't stop when you've made your estimates. You then have to *do* something with them.

If you are going to do the work regardless of the estimate, then making estimates is indeed a waste of time.

If you are going to choose what to work on based (partly) on whether they are easy to deliver or cost a lot, then it is a worthwhile exercise.

jjj May 25, 2025

@mspcommentary @Di4na @Patricia @drgroftehauge "If you are going to do the work regardless of the estimate, then making estimates is indeed a waste of time." - this I very much agree with. Maybe have an overall estimate of the feature, ballpark, but estimating stories that we have to do no matter what seems meaningless. And if time or difficulty blows up, bring it up for discussion.

Patricia Aas May 25, 2025

@jjj @mspcommentary @Di4na @drgroftehauge you two literally didn’t read (or maybe didn’t agree with or understand) my observation: the only time I’ve seen estimates be useful in real life is the one time they weren’t used for anything. Because they became the catalyst for conversations where we, as a team, learned things that were actually useful.

All other times it has been worthless.

jjj May 25, 2025

@Patricia @mspcommentary @Di4na @drgroftehauge Sorry, I did read but maybe I don't reply in Mastodon in the right way, or maybe I'm just bad at communicating. I didn't mean to disagree with your observation, my reply was to someone else in the thread.

Patricia Aas May 25, 2025

@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.

jjj May 25, 2025

@Patricia @drgroftehauge Oh, you focused on the points part while my, eh, point was mostly the breaking up stories part. But understandable, since points is probably a more controversial subject. But especially as a junior or when starting working on some code/domain I have never seen before, at some point breaking things up even more feels meaningless, and just for show.

Regarding points I reluctantly admit they are useful when used right. Having some transparency, and also some overview of the planning, however bad, is better than nothing. But I have worked at places where those points are collected and then used to show graphs of how teams perform. I think this technically contains some information, but it is so little and so buried in what you naively think the data says, that I doubt this information should be used. Drawing big conclusions on these graphs I think is a mistake and counterproductive.

I have also worked in a team where no points were used and we delivered a lot. Time estimates were just informally "probably this sprint", "a couple of sprints", " bigger" or "I don't know". And performance was judged on what we actually delivered to customer. Imagine that?!

I bow to you who can put your thoughts into meaningful and internally consistent toots, it is hard.

CartyBoston May 25, 2025

@Patricia @drgroftehauge

Sorry if I am taking us afield, but *this* is what's valuable about "agile".

Simply allocate budget for the currently unknown - which more experienced engineers should be able to scope somewhat accurately.

Patricia Aas May 25, 2025

@CartyBoston @drgroftehauge it was in there in the beginning, but it’s almost always one of the first things to be abandoned by management, also the «stop doing what isn’t working» and actual retrospectives.

Patricia Aas May 25, 2025

@CartyBoston @drgroftehauge in my experience, spending a few days taking a rough stab at something gives you more information than 5 weeks of thinking about it.