[deleted]
Eight points for one team is two points for another team
11–20 of 105 posts
Re: Eight points for one team is two points for another team
#12This reminds me of the now classic article: http://steve-yegge.blogspot.com/2006/09/good-agile-bad-agile...
It essentially claims that "good agile" is Kanban, and Kanban is essentially abolishing of any forecasting in favor of actually doing the tasks, like the CPUs do when executing programs.
Re: Eight points for one team is two points for another team
#13Whatever 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
#14"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 to estimate better; instead of using an abstraction.
I for reference, have multiple agile certifications and just don't understand.
Re: Eight points for one team is two points for another team
#15This 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 how you work to the greater org, and get buy in. Use retros to constantly iterate and improve your process.
Re: Eight points for one team is two points for another team
#16Whatever 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…
> 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…
And lo, OP read The Manifesto, so as truly to understand Agile, and was therefore enlightened.
- The Agile Prayer
Re: Eight points for one team is two points for another team
#17Whatever 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.
[deleted]
Re: Eight points for one team is two points for another team
#18Whatever 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.
Maybe they're rare, too. I am but one person, but I've yet to work with one that I'd describe as a "joy".
Re: Eight points for one team is two points for another team
#19"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…
The point of "points" is nobody can estimate how long a task will take and it gets worse the larger it is. So it's better to have reference tasks of a certain size and complexity that you do know how long they took and compare to those to get a general idea. You could use hours in that context but it's trying to make you think is terms of size and complexity not hours.
Re: Eight points for one team is two points for another team
#20This reminds me of the now classic article: http://steve-yegge.blogspot.com/2006/09/good-agile-bad-agile... It essentially claims that "good agile" is Kanban, and Kanban is essentially abolishing of any forecasting in favor of actually doing the tasks, like the CPUs do when executing programs.
Not debating about estimating or not. I'm only replying to the example:
CPUs can only execute, what the instructions tell them to do—like a production line—and not solve / create something (new).