@sleepyfox @Patricia @petealexharris Agile was meant to be a rock in starting negotiations in what will be delivered, when, and how. The issue is that most devs didn't and don't know they even *need* to negotiate anything, so they hate on the process because they don't want to be accountable. Management have always just been freely changing the terms to suit them because there's no push back.
Like it or not, if you don't negotiate then the decision still gets made, just to suit the parties which turned up. This is why Agile "sucks". Sorry but this is 100% on us devs. "Fuck off" is not a development methodology.
@Patricia
I can relate to that, having seen the inception of 'Agile' and its foundations.
And then its inevitable fall due to "agile" management: cargo cult rather than insights.
@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.
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.
@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
@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.
@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 @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.
@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.
@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.
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 @drgroftehauge
Someone was explaining the "breaking into subtasks" as "reduce uncertainty". I found this a much better analogy.
For some parts, we will still have high uncertainty, but we have isolated it better.
@Patricia @drgroftehauge
It is useful for me as a mental model.
(But the way we use "agile" in our company, I don't think any mental model helps, though.)
@drgroftehauge @marcel
1. Make app
2. Get lots of users
3. Profit!
I am so good at this 😇