3 ms·
In an age where tech workers have massive autonomy and respect, it might be difficult to remember WHY the original Agile manifesto was written. Sure it talks a
by deanCommie 4y ago
In an age where tech workers have massive autonomy and respect, it might be difficult to remember WHY the original Agile manifesto was written.
Sure it talks about delivery, working software, and the like.
But a big motivator wasn't just "Craftsmen who want to do their craft more effectively", it was "Employees who are being abused by project managers, Gantt charts, and top-down waterfall death marches, who want to have sanity"
The part of 2-week sprints that says "deliver working software at the end" is just as important as the part that says "PMs can't introduce new scope into the sprint".
So the reality is It Depends on the company.
If you're lucky enough to be in a place where you have full control over your process to deliver software, Bottoms Up, Just-In-Time Process is the perfect attitude. But if management is enforcing archaic practices for no seemingly clear reason, the "rigid" nature of Scrum actually helps enforce a good way of doing things in a way that "traditional" management can reason about.
- Arcanum-XIII 4y agoAnd now we’re abused by velocity chart, retrospective about our failings, continuous change because we’re agile, under pressure all the time because of the two weeks « sprint » which end being a disguised death march… So how is it any better?
- icedchai 4y agoI worked at a place where the managers did everything they could to close out all the points by end of sprint, no matter what. A co-worker is taking longer than expected, says there is no way he'll be done in couple of days... so we close out his story, declare it done, and open a new one in the next sprint for "testing", "deployment", or whatever it takes to claim the points and move something into the next sprint. I found this truly sad. If you want accurate "velocity", you need to track it accurately. Our estimates were wrong.
- Too 4y agoSeen exactly the same, sadly not just in one shop. Half completed stories would be split into part 1,2,3, or worse: renamed to "Attempt to implement...", just to make the burndown chart align at closure of sprint and give people the pleasure of dragging items to the done-column. Didn't get better when some higher up scrum master once had the brilliant idea that all stories should be max 2 story point large, otherwise need to be refined further. Together with a company-wide policy that a story point is roughly equal to one day, for all teams, because it made the high level jira dashboards easier to aggregate. Not sure what it was meant for, since with this practice it would tautologically just show headcount * days in a sprint. More like time reporting rather than measure of progress.
- urthor 4y agoThe beautiful thing is there is a built into Scrum solution to this. You alter estimation. The fact story points are made up BS numbers means developers have full control over the velocity chart. My favorite part of Scrum is it makes it IMPOSSIBLE to track velocity. By making velocity IMPOSSIBLE to track, management MUST pivot to OKR lead management. And OKR lead management is by far the best approach to software development.
- icedchai 4y agoIf your estimates are too crazy, you are forced to break them down into smaller tasks. This means lots of meetings. I think most engineers would rather have a bad estimate and "face the consequences" (generally not much), rather than put up with more meetings. Can you describe "OKR lead management"? I am familiar with OKRs.
- HowTheStoryEnds 4y agoAnd at the very least with waterfall they thought about their requirements, now it's: shove 3 sentences in a JIRA and off you go, clairvoyant developer!