Earlier quoted context omitted.
Here's one to add onto your list: pair/mob programming is bosses weaponizing employees against each other to "prevent goofing off". I've started to form a belief[0] that large software projects in general are A Bad Idea. Whatever it is, if it requires more than a handful of people to build, it's probably for the greater good of everyone--the workers involved, the users, humanity in general, anyone-not-identifying-as-…
I agree with most of this. I’ve done some stupidly complex things using microservices, and I’ve come to similar conclusions - that there are few or no cases where you need a huge monolith, and it’s much better to have small teams working on small tools. Once you get things working at this level, everything becomes easier. Setting aside the Linux kernel, this is how Unix itself works, and one of the reasons it was suc…
Eight points for one team is two points for another team
61–70 of 105 posts
Re: Eight points for one team is two points for another team
#62This post is starting to fill up with what sounds like a kind of hopelessness mixed with anger against Agile. It's possible to do sprints, pointing, demos, and retros well, but you have to own it as the engineering team. This means understanding and adapting the process to your needs. Agree on your definition of done. Set boundaries for pointing. Prevent confusing or unfinished stories from being point. Communicate h…
When there is so much overhead in process, the process is a waste of time. Management needs to skill up.
Personally, I've found retros to be most important area for a manager to focus. They can be a wonderful source of discussion and improvement for the team, or one of the most boring hours of your week.
Re: Eight points for one team is two points for another team
#63Once I got over the initial horror it actually worked out pretty well. I would keep a stack of trivial work on standby for any time I needed to show some board progress and then used the majority of my time to dig into whatever work looked most interesting.
Re: Eight points for one team is two points for another team
#64> “Building the wrong thing on time and within budget doesn’t buy you much.” Let's get one elephant out of the room out right away. Many in the #NoEstimates camp are speaking from the position of some enterprise context where the business technically has already built the right thing, they have revenue, aren't innovating much (by design), and as long as they keep the ship afloat and don't make too much of a mess of t…
It also means nothing if all your estimates are so totally wrong and not based in reality, as I mentioned a few times in the bullet points.
Re: Eight points for one team is two points for another team
#65Whatever Agile was, it's absolute garbage these days. It largely exists to hold developers maximally accountable to the business, at the expense of technical excellence or even maintenance, which can be expressed in its gun-language of Jira tickets and so get ignored. Fuck user stories, fuck sprints, fuck Jira, and fuck product management (a job in which one defines success by getting into one's boss's job as fast as…
Your anger sounds directed at the dysfunction within your organization. In particular if you hate product management then you've clearly ended up in a bad place. A good product manager is a joy, someone who is a partner to the engineering team instead of an antagonist.
Re: Eight points for one team is two points for another team
#66Whatever Agile was, it's absolute garbage these days. It largely exists to hold developers maximally accountable to the business, at the expense of technical excellence or even maintenance, which can be expressed in its gun-language of Jira tickets and so get ignored. Fuck user stories, fuck sprints, fuck Jira, and fuck product management (a job in which one defines success by getting into one's boss's job as fast as…
Big A Agile is what happened after management consultants got hold of little a agile and its manifesto. Now people get certifications in scrum dogma and claim we have to follow the one true way. Now it's entirely about managing people instead of about satisfying customers. That's why a bunch of folks left years ago to work on development as craft.
> managing people instead of about satisfying customers.
I wrote another article that somewhat alludes to this, it's linked at the start of this one. If I'm not helping people, either customers, or developers by making their jobs easier, then what exactly am I doing as a professional?
Re: Eight points for one team is two points for another team
#67Whatever Agile was, it's absolute garbage these days. It largely exists to hold developers maximally accountable to the business, at the expense of technical excellence or even maintenance, which can be expressed in its gun-language of Jira tickets and so get ignored. Fuck user stories, fuck sprints, fuck Jira, and fuck product management (a job in which one defines success by getting into one's boss's job as fast as…
Re: Eight points for one team is two points for another team
#68"points" are just a way to avoid being held accountable. If we were to use hours (even buckets of hours, aka: 1, 2, 4, 8 hrs) we'd be better off. It'd be more transparent and while it may differ between team members, we can hold people to account who over / under deliver based on their estimations. The entire point is to estimate velocity (supposedly), so why not have a feedback mechanism that's let engineers learn t…
That sounds wildly micro-managey. I often don't know how long something is going to take until I dig into it; sometimes I don't know how long something is going to take until I'm almost done. The ambiguity/fuzziness of points is a feature, not a bug. If I'm going to be "held to account" based on my estimates, I will optimize for producing work that matches my (naive, uninformed, up-front) estimate, rather than produc…
And points do not stop anyone from holding you to account, if that is what they want to do.
Re: Eight points for one team is two points for another team
#69Earlier quoted context omitted.
> Whatever Agile was Has it changed? The Manifesto[1] is still there, unmodified, to provide thoughts on what you need to consider if you are going to run a software project without managers. > Fuck user stories, fuck sprints, fuck Jira, and fuck product management That does not sound like Aglie, especially given that you specifically call out managers, which are incongruent with Agile. The top-down organization wher…
Look, when a job req goes out and it says "experience with Agile development methodologies" what it means is "experience doing Scrum with Jira". The Manifesto has sweet fuck all to do with what is meant when companies say Agile.
Re: Eight points for one team is two points for another team
#70Whatever Agile was, it's absolute garbage these days. It largely exists to hold developers maximally accountable to the business, at the expense of technical excellence or even maintenance, which can be expressed in its gun-language of Jira tickets and so get ignored. Fuck user stories, fuck sprints, fuck Jira, and fuck product management (a job in which one defines success by getting into one's boss's job as fast as…
Big A Agile is what happened after management consultants got hold of little a agile and its manifesto. Now people get certifications in scrum dogma and claim we have to follow the one true way. Now it's entirely about managing people instead of about satisfying customers. That's why a bunch of folks left years ago to work on development as craft.
We can't say with a straight face that we expected IBM or Accenture like conpanies to move to an "agile" process.
And smal and/or smart conpanies were already doing "agile" without making manifesto and boasting it at every occasion. What's left is the middle ground wh
'll blindly follow any trend and get certifications to proudly have the buzzwords on their company site, and "agile" weren't for them either.