Hacker News new | ask | show | jobs
by cygned 1627 days ago
Aren’t these interactions put in place to create transparency across the team regarding progress and purpose as well as empirical validation? I am not sure how that necessarily clashes with social structures inside the Scrum Team or micro manages its members.
3 comments

> I am not sure how that necessarily clashes with social structures inside the Scrum Team or micro manages its members.

I would expect emergent behavior from said team (which I consider a team; not a SCRUM team; a human team working on software) to be a better representation of who they are as humans and of how they best think they should organize in order to attain the company goals.

As for the micromanagement, I would love to hear an explanation of how SCRUM is *not* micromanagement when every day, a guy (which in my decade long experience has always been either a manager-role or someone wanting to be a manager) comes and gets the report on the tasks that you work to the granularity of one hour (sometimes even 30 minutes for properly crazy SCRUM masters) and intervenes afterwards if he considers it needed.

> Aren’t these interactions put in place to create transparency across the team regarding progress and purpose as well as empirical validation?

Depends on how big you think the team is... If we're talking about a small cross-functional team, I've never had as much transparency and signal over noise over progress, purpose as well as empirical validation, than I had working with a bunch of great people (healthy mix of junior, middle and senior), going out eating every day for lunch (usually more than one hour :o) and discussing. If we're talking about the organization as a team, then yeah, clearly more transparency regarding progress for them because before this whole SCRUM thing they didn't have a load & run way of creating an analytics pipeline for their software projects.

Look, you're clearly in the SCRUM side of the stadium and I'm squarely in the emergent-process side, and it's been a discussion for aeons of which I am tired. What I am arguing is not pro / anti SCRUM, what I am arguing is that SCRUM as most enforced things "micromanage and/or ignore human psychology".

> what I am arguing is that SCRUM as most enforced things "micromanage and/or ignore human psychology".

I think you are arguing Scrum can lead to these situations - which you cover in your other thoughts. And I agree, I have seen that often, however, I’d still don’t say it’s inherent to Scrum itself.

> how SCRUM is not micromanagement when every day, a guy (which in my decade long experience has always been either a manager-role or someone wanting to be a manager) comes and gets the report on the tasks that you work to the granularity of one hour (sometimes even 30 minutes for properly crazy SCRUM masters) and intervenes afterwards if he considers it needed.

Yeah that’s awful micro management. I know it’s easy to dismiss that way, but what you are describing is not Scrum, that’s just saying Scrum and making people miserable.

In the end, I do not want to argue for Scrum as the solution for everything. It’s really hard to do it right. On one of the teams I am consulting right now, we went away from Scrum because it didn’t work - fascinatingly due to different reasons as you mention, different mindset in terms of what management does and how control is exercised.

> I know it’s easy to dismiss that way, but what you are describing is not SCRUM

I think it's easy to dismiss because this was easy to digest in the first years and first teams, but after a decade and corporations and some smaller companies and some startups, I just don't believe it anymore.

I am actually a certified SCRUM-master (but not practicing) and sometimes google 'what is SCRUM?' just to check up on the new articles. I find a million of them each with their own interpretation that could just work and each of them seemingly valid while mostly ignoring the agile manifesto they love so much.

> On one of the teams I am consulting right now, we went away from Scrum because it didn’t work

Congratulations on actually attempting to solve the problem and not cargo-culting a magic solution.

Status updates every hour or half hour sound like a productivity hellscape. How do people get anything done with such invasive interruptions throughout their working day? You can't even enter a flow state with those sorts of requirements.
> Status updates every hour or half hour sound like a productivity hellscape

(SCRUM-master / AGILE coach / Project Manager / Line Manager) felt like she was losing control of the development and doubled down on processes to the point where nothing moved anymore and this was her solution to it. It was amazing!

One software solution (nothing fancy, just a shit payment processor integrator), three teams, three technical leads, three team leads and one incompetent master overseeing the Kafkaesque nightmare.

Now you're making me curious if the project is still ongoing. :P

> How do people get anything done with such invasive interruptions throughout their working day?

They mostly didn't really, the biggest concern in that company was how to tweak your timesheets to match the estimations as requested by the master.

----

A lot of times when I'm hating on SCRUM I wonder if I really got unlucky, especially due to my outsourcing beginnings, but then I find it hard to understand how come I get lucky to work with great teams when there are no such barriers in place.

I'm not even against the whole process thing, used to build emergency management systems where we spent 80% of the time planning, estimating, figuring out what can go wrong, working in heavy processes. But they made sense.

> Aren’t these interactions put in place to create transparency across the team regarding progress and purpose as well as empirical validation?

Original motivation does not changes anything, we are talking about effect here. Effect is the same.

Also, transparency regarding progress and purpose does not require scrum. I dont know what you mean by "empirical validation".

I don't recall the "not knowing the progress" being issue in any methodology for developers. Maybe, most of the time we dont really need to know how fast tasks are progressing. Speed on other tasks is important for management, but not for me. I need to know their thoughts about codebase, about where to go, what they consider issues and such. But progress, not so much.

Transparency is provided by a Jira board - and the board is always up to date. Purpose and blockers are better discussed 1:1 or in small groups with whoever is in charge of dealing with the stakeholders.