Patricia AasThis 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.
This shit is going on LinkedIn 🤣
Apparently annoying agile coaches is becoming a problematic hobby of mine.
Tomas Ekeli@Patricia "queen of snark" was whispered among the attendants of your NDC talk.
You own it.
You own it.
Carl Myrland@tomasekeli
Viewed from the outside, I feel IT/agile management people are the yaps of the 2010/20's?
@Patricia
Viewed from the outside, I feel IT/agile management people are the yaps of the 2010/20's?
@Patricia
@cmyrland @tomasekeli I would need you to expand a bit on that one
0xC0DEC0DE07E9@Patricia problematic for who?
Daniel Carosone@Patricia collaboration, most especially, by managing ourselves more than being managed.
pa28
Pete Alex Harris🦡🕸️🌲/∞🪐∫@Patricia
Not to mention a lot of it (e.g. the original idea of estimating work in non-negotiable points) seemed designed to limit certain kinds of damage that management can do to the development process, not give them more ways to interfere in it.
Not to mention a lot of it (e.g. the original idea of estimating work in non-negotiable points) seemed designed to limit certain kinds of damage that management can do to the development process, not give them more ways to interfere in it.
@petealexharris Even that was after the initial agile manifesto
Not🐧A🐧Convicted🐧Felon@Patricia @petealexharris The manifesto is decidedly anarchic. This has been spoken about by the originators at length.
Management was - and still is - broken.
Agile is a way of being able to work *in spite* of management being broken, rather than being a way of redesigning management as a discipline.
Management was - and still is - broken.
Agile is a way of being able to work *in spite* of management being broken, rather than being a way of redesigning management as a discipline.
@sleepyfox @petealexharris tbh I think it’s failing at that goal
@Patricia @petealexharris The future is already here, it's just unevenly distributed.
@sleepyfox @petealexharris my experience is that that is the past rather than the future or present
Bakunin Boys@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.
@sleepyfox @Patricia @petealexharris we can't even negotiate among ourselves. Management can literally shop around between teams and go with the lower number. No team observes that this is a bad position to be in. Product tend to organise themselves collectively. Designers tend to organise themselves collectively. We're here crying about it like we have our hands tied. Why are software architects not doing more scheduling work? Why are product and design able to eke out 2/3 of the project lifetime?
@Patricia @sleepyfox @petealexharris the saddest part is that I did not reflexively say "engineering manager" despite that being in the job title.
Dani (
modules addict)@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.
Morten Grøftehauge@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
- 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.
@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.
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@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.
@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.
@jjj @drgroftehauge but it’s like every stat collected: the moment you use it for something, it influences the data.
John-Mark GurneyI'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.
Lars Ivar@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
@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@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@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.
Mike Anderson@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.
@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.
@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.
@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.
@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.
CartyBostonSorry 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.
@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.
@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.
Marcel Waldvogel@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.
@marcel @drgroftehauge is it useful tho?
@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 😇
joep schuurkes@Patricia Reminds me of @einarwh saying in a talk at @boosterconf:
"Individuals and interactions over processes and tools. And what do we end up with? Scrum and Jira."
"Individuals and interactions over processes and tools. And what do we end up with? Scrum and Jira."
@joeposaurus @einarwh @boosterconf oh my, what a gut-punch. He’s speaking the truth tho, as he does uncomfortably often and well.
Einar W. Høst@Patricia @joeposaurus @boosterconf What's crazy but needs recognition I guess is that in many cases, for many people, Scrum and Jira were a great improvement on whatever came before. As Alistair Cockburn put it, "Scrum struck a magnificent bargain in hostile territory", the deal being that management could change their mind between sprints, and no-one would pester the team during the sprints.
@Patricia @joeposaurus @boosterconf That's not to say it's a deal that delivered on the promises of the Agile manifesto (how could it?) or that it's the best possible deal today. (Though my impression is that many think that realistically, we won't be able to do much better than that.)
@Patricia @joeposaurus @boosterconf I should make another go at writing my blogpost about The Scrum Pact and The Developer Terrarium.
@einarwh @joeposaurus @boosterconf I’ve seen better. And not only once. I know it can be done. But it requires leadership that allows it to happen, and I feel that tech leadership has drifted over to «career leadership» and they don’t get what we do. They come from all over and they don’t get the process. They want something «cleaner». But it is messy, and that’s not a bug. We are trying to figure out what we should build by building it, we’re learning what we should’ve built by living with it.
@Patricia @joeposaurus @boosterconf I agree with that. I’ll add that so-called “technical people” or more broadly “those who build” also need to step up to the plate. Not everyone wants to. Quite a few prefer life as well-paid, well-protected slik worms feeding on Jira tickets, leaving the messy parts to “the grown-ups” (the most undignified phrase that developers utter).
@einarwh @joeposaurus @boosterconf fair. But I also think that many people think that «they» («the grownups») must know what they’re doing. And, in theory, I don’t think that’s an unfair expectation. But «they» don’t, and it’s affecting what we build and how we build.
@Patricia @joeposaurus @boosterconf I agree that's a fair assumption, and also that it quite often doesn't hold. I have met some "grown-ups" who knew their stuff though, real product people if you like, who cared about the domain and could go deep. But obviously I've also met generic managers doing generic management.
@Patricia @joeposaurus @boosterconf Which really exacerbates the problems with the Scrum pact and the developer terrarium arrangement btw, since they're typically the messengers between "the business" and the development team. Clueless messengers cause a lot of problems.
@Patricia @joeposaurus @boosterconf But I've also seen plenty of learned helplessness in development teams, people wailing "if only they'd let us do the right thing" "actually, you can just do it, no-one's stopping you" "IF ONLY THEY'D LET US"
@Patricia @joeposaurus @boosterconf So it cuts all ways in my experience. But that's not to say that we can't do better. I definitely think we can.