Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> As the software matures, I don't think it's healthy to strive for squeezing your devs for every last drop of productivity.

This is why I hate agile, it's incredibly stressful. Daily stand ups to justify your last 24 hours, affirmations in said stand ups which must begin with "Yesterday I committed to... and did/did not achieve this because..." followed by "By this time tomorrow I commit to delivering....".

JIRA burn down charts dropped in our group chat to "remind us" to keep following the planned burn down line, looking for stories we can close out to try and sneak the chart to match the line and somehow try and catch up after they're closed. It's horrible.



All you say is agile not implemented correctly (which is very common). I am a contractor and switch projects and development environments very often. I've seen agile working really well when it is properly implemented, and really poorly when it is wrongly implemented. The biggest problem I see that people never really get educated in agile. I see PMs/POs/Developers etc. that never had any formal training in agile/Scrumm (books, courses, experience) but rather learn-by-observation, i.e. "do what others do". And I have seen scrum master with zero expierience as a developer, just blindly trying to follow written guidelines in the books (scrum manual etc.) without being able to adopt those to a real development process.

Take for example your metion of standups: They are really valuable, and are not meant to "justify" your last 24h - but some managers think that this is the case, i.e. make sure your developers are not slacking and surfing on hacker news all day. Instead, one of the purposes is to detect blockages in any way. I mean if a dev takes very long for a task without it being justified (i.e. no other developer would understand why it would take so long), it might just be due to lack of skill and the dev might need some more training or senior assistance. It could also be that the task is more difficult than originally anticipated, in which case the team should possible act on it and change the scope etc. Sometimes it could also be a very eager junior dev, who just doesn't want to admit struggling with something out of pride or even fear etc. As a developer I can totally say, it actually takes quite some guts to come out in a group of devs and freely admit: "Hey, I struggle with that task, I don't know what I am supposed to do, or am not familiar enough to debug that code, can somebody help me on this?" - but admitting that you are not perfect is something lot of people struggle, especially juniors as they think they must be capable of doing everything.


> I see PMs/POs/Developers etc. that never had any formal training in agile/Scrumm (books, courses, experience) but rather learn-by-observation, i.e. "do what others do".

Ahh, good old cargo cult Scrum.

I've seen a bunch of this when consulting. People use all the right terms, but nothing else really makes sense. There is a "daily standup" done sitting down and it lasts up to 45 minutes. There are "sprints" that last from 2 to 12 weeks with no deliverables. There is grooming, which is just chatting and maybe looking at Jira a bit.

Scrum can be done right, but it requires the WHOLE organisation to be trained to do it properly. Preferably by a very very very expensive Scrum Consultant so that even the C-staff put some weight in their words. (expensive == good)


> "Yesterday I committed to... and did/did not achieve this because..." "By this time tomorrow I commit to delivering....".

99% of the time this is an underhanded way to implement micromanagement.


None of that is a requirement for agile processes. (Indeed I would argue that unless you have decided that's the best tool for your team, you're probably not being very agile. And no, when management of a big-co dictates how you work, they can call it "agile" as often as they want, it's not. Of course still extremely common, sadly)


That is not agile it is SCRUM.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: