51–60 of 66 posts
Duh.
The entire supposed premise of agile is defining goals and constructing a product iteratively, so misunderstandings and changes in design can happen more quickly.
The "quick" part being a change in direction.
Given a perfect definition of a program and skilled ciders and unified vision from the beginning, agile would be meaningless.
HN is pretty much in agreement that lines of code per day is a bad measurement of progress/accomplishment, right?
We've seen so many bad variations on this concept:
* Butts in seats means work is being done
* Movement is progress
etc. It's all bunk, of course, and here we are with agile. Corporate types are collecting some metric and the larger the value the higher the developer speed. Or so they think.
Ideally, "speed" in this context is about direction. They are almost interchangeable. If you are going in the right direction, you have some amount of positive speed. Otherwise, it is negative or zero.
Earlier quoted context omitted.
It's because a lot of agile is just plain stupid in real world use. For example, story points are always being converted back to wall time because in the real world you have resources who can work x amount of hours and you need to plan around that. What's the point of using an intermediate unit?
Story points shouldn't get converted back to resource time. They're just a way of ballparking estimates sufficient to let product managers make broad choices, and to help teams keep from getting excessive amounts of worked crammed into an iteration. So don't use them as an intermediate unit. If you want hours, just ask for estimates in hours. I think that's not a great idea for all sorts of reasons, but if you're in…
I'm new to this. Are we agile?
There has never been a better strategy for letting engineers steer the ship and make decisions that ship code instead of getting micromanaged by non-experts that generally bungle things up and insert a bunch of external priorities without reconciling them with reality.
The reality in my mind is that agile is the reaction to excess management, which is a massive problem in technology organizations.
I’m sure there are other things too. Some of the other comments are gold. But that’s my 2c.
Next.
Seriously, there's very little substance to the article. It effectively says "agile doesn't work without customers."
I'm pretty sure "customer collaboration" mattered back when it was a developer movement and not some kind of training sold to management.
Earlier quoted context omitted.
Only if you adjust into the right direction, and keep it after the adjustment. Theoretically, scrum was aimed at adjusting faster. But if the adjustments just keep coming, you won't go anywhere.
If the adjustments just keep coming you have a business problem and no "process" will save you.
Thus, the odds of a team knowing where they are going reduces drastically if they start doing scrum.
Earlier quoted context omitted.
Your comment strikes me as a bit odd, let me explain why. Yes you're correct in saying that op was talking about scrum not agile, but "scrum uses agile" is a very confusing phrase. Scrum predates agile by 8 years, so how could it use something that wasn't invented when i was created. Also agile isn't something "to use" since it's not a framework. Scrum is something that you use, since it is an actual framework, and o…
Damn, didn't even know Agile and Scrum had such deep lore.
The largest problem with so many of these discussions is that people talking about them have pinned themselves to the noun of capital "A" Agile instead of recalling that the point is to curate and practice an empirical process instead of a defined process like in manufacturing.
Scrum became one of the more popular process tool kits because it was a lot simpler to use than the entirety of eXtreme Programming (for example). Later a lot of consultant artifacts got piled on including a mishmash of other practices like Kanban, planning poker... etc. You won't find any of those in the original book on Scrum.
The point was always frequent course examination and correction. Ken Schwaber, author of the Scrum book, was also one of the original signatories to the manifesto: https://agilemanifesto.org/
Earlier quoted context omitted.
Story points shouldn't get converted back to resource time. They're just a way of ballparking estimates sufficient to let product managers make broad choices, and to help teams keep from getting excessive amounts of worked crammed into an iteration. So don't use them as an intermediate unit. If you want hours, just ask for estimates in hours. I think that's not a great idea for all sorts of reasons, but if you're in…
In our process, we've been consistently told that a weight of 8 corresponds to a two week (10d) sprint, and that 80% of our time should be spent on scrum tasks. Then, if any developer closes more than 8 points in a sprint, we are told that we aren't estimating properly. They have all but equated 1 point to 1 day, but the scrum master consistently denies that weight corresponds to time. I'm new to this. Are we agile?
To me, the agile movement, at least initially, was about empowering teams to get things done for users. I came out of the Extreme Programming end of things, which had a dozen practices to start with. But the people behind it said that they offered that set of practices as a place to start. From there, teams were supposed to use the short feedback loops to inspect and adapt.
So in my opinion, that is not agile. However, as I've written about elsewhere [1], I think the Agile movement got taken over by something that was more marketable to executives with a top-down orientation.
So in short, I think what they're saying sounds like bunk to me. The way I used points was as purely relative estimates. Point velocity per iteration was a measured quantity, used mainly to make sure the team didn't oversubscribe an iteration. E.g., if the team did 10 last week, this week we'd take on 10. If we thought we might get done early, we could always pull another card in.
But alas, it sounds like you're trapped in what I think of as mini-waterfall, where people who have waterfall biases have broken their big thing down into two-week-sized waterfall lumps.
For what it's worth, I long ago stopped doing estimates entirely except in special circumstances. I now prefer the Kanban-style approach where there's a backlog of modestly sized units of work and the team has a limit of the number of things that can be in progress at once (my starting point is half of the number of team members). You then release each thing as it's done.
[1] E.g., https://williampietri.com/writing/2011/agiles-second-chasm-a...
Earlier quoted context omitted.
Where I currently work it's absolutely a process problem (of Scrum). The version of scrum they're running wants you to just get the committed stuff done, and it's irrelevant what it leads to. There is no room for understanding the end goal and making sure you reach it, with a set deadline as well. You might as always happens attack them for not doing Scrum right, and I'll tell you that's the age-old cry of the agile-…
What prevents the committed stuff from going in the right direction? Is it that the business leaders keep changing the direction or that the from the business leaders direction is unclear? Or something lower-level? I was picturing the former in the above convo.