Hacker News Reader

Comment by evilolive | Hacker News Reader

I tend to have a problem with managers who think doing Agile™ yields a better quality product.

I've done agile agile (the process being agile) before which worked great. 3 week planning with one to three tasks per week and weekly sync, no detailed estimates. This was pleasant, I felt trusted, empowered and as a result more committed.

Right now I'm doing the full cargo cult Agile, with daily standup, sprint planning, backlog grooming, sprint retrospectives, end of sprint demos. I get regularly dinged for not following the process, never mind if the work is actually done. Also there is 5 manager/pm at our standup, for 6 engineers. I don't know for you but this kind of stuff makes me completely indolent, before I start searching for something new.

View on HN

"Agile", or "XP", or anything else along those lines is no substitute for leadership. For giving a damn about the team, the product, or the company.

No amount of sprint planning, backlog grooming[1], or sock-monkeys flying across the room during a standup can make up for a lack of leadership.

In your current situation, I would wager that -- early on -- the development team committed to a lot of deliverables and then failed to deliver, either due to overconfidence, or pressure from an overeager management team. Afterwards, an Agile Process was installed to ensure that This Sort Of Thing Never Happens Again.

The end result is what I like to call Agile Bondage, where everybody focuses on the process, rather than the product or the customer.

[1] Backlog grooming, with the entire team, is generally an antipattern. You do not need the entire team to grind to a halt to make sure the stories in the backlog are actionable. Have the product owner grab a pair after the standup to review upcoming stories to make sure that things look kosher for the rest of the team.

A clear sign of a broken Scrum process is having daily standups with 5+ people who know/care little about what the other team members do.

Teams need to be tight and involved with eachother, otherwise the standup makes no sense.

What makes this a little difficult is that Scrum™ insists on cross-functional teams, i.e. all teams have a UI guy, a backend developer, a tester, etc. So you can end up with some very disjointed teams, like the one mainframe dude who works on stuff no one understands or cares about. Yet you have to hear about it every. morning.

Somehow "Individuals and interactions over processes and tools" become "Follow this process and you'll get better software" and people mostly don't even criticise agile methodologies of hipocrisy.

Even the phrase "agile methodology" is wrong.

Totally agree - i'm currently a scrum master and doing development in the team. I try to reduce meetings as much as possible because the process itself doesn't yield results - te team does. An empowered, enthusiastic and communicative team gets stuff done. And mostly, developers enjoy their work which is the actual software development so they should spend as much time as possible doing that (plus issues with context switching).

People also assume Agile means you'll do more faster - I don't think this is always the case. Quality generally is better but again not because of the process but because of the team. A team in full flow and working really well together needs no process.

The biggest benefit for me is that if the team is given accountability then there is total transparency about what the team is doing. Organisations tend to add additional layers of management to supposedly shield the team from politics - but it's the additional layer of management that actually creates the politics.

The Agile that works is the manifesto. I was once reduced to literally quoting the manifesto in a retrospective, to try to get across the point that our process was excessive and not helping.

(It didn't work, and then I left. In my experience you can't change places with that kind of process. I'd love to hear from anyone who's succeeded)

There is something ironic in how the Agile movement, originally the antidote to heavyweight processes, has been used to justify an explosion in highly detailed and prescriptive methodologies. To be clear, this is not intended as a criticism of agile methods per se, but merely a comment on how the world works.

> Right now I'm doing the full cargo cult Agile,

> Also there is 5 manager/pm at our standup

These statements cannot both be true. Those 5 managers are violating the "process".

> Those 5 managers are violating the "process".

Only if they speak

They don't.

Also one of the "managers" (that's his title), manages no one.

He's a scrum master of sorts, who goes around interrupting people programming to remind them to move their tasks to "in progress" or to "closed". I assume so our burndown chart moves down. I've been tempted to replace this guy with a script.

I'm tempted to replace developers who can't be bothered to help the rest of the team out by putting in the tiny amount of effort required to keep everyone up to date with what's happening with the current tasks. Really, it's five minutes out of your day which makes everyone happy because they know that tasks aren't stuck or forgotten about and doesn't require you to interrupt your flow.

I think that you and evilolive can be each experiencing your respective problems. At times I've been the developer who has failed to update tasks for days/weeks. I've also been pressed for updates 5-6 times in a day by different managers and "managers". Both problems are fixed by all parties respecting others as people and doing their jobs correctly.

I literally work in a team of 2, that also has a PM. We've been parachuted in another team's standup.

We all know what the other member of the team works on, so the standup is clearly not for us but for a minute update to all the managers who are sitting in on several "standups" in a row.

If you read my comments, it's not really the standup itself that I complain about. It's disguised micro management with an Agile shell.

Since teams are supposed to be self organized and the process itself should be agile, you could ask the member of the team to comment on the process and if they think the standup help them.

If the team needs to be reminded to move tasks to "in progresss" or to "closed", there is a serious problem with the team -not the Scrum Master...

The version control hoster that we use has an integrated ticketing/bug tracking solution, which lets you easily reference tickets in your commits to do this sort of task updating.

We don't make huge use of it, since we've only got about four developers, so communication is pretty easy, but it can be helpful.

Ours does too. I find that it is nice to have the additional information when the commit message is a bit general. Although this is a problem with the message itself.

It also can be helpful months later when needing a reminder why something was changed based on an assumed unimportant detail at the time.

Yeah, it's fine if you have external people listening in. If there's five people at your standup though, it means they probably don't have anything better to do (like idk, manage).

Agile™ isn't for the engineer's benefit -- all the rituals are there to make it easier to manage engineers (or maybe to manage engineering managers?).

Reply on news.ycombinator.com