It establishes a set of steps that need to be followed (often time daily) and interactions to be had regardless of the nature of the work and the psychology of evolving unique set of relationships inside a social group? How does it not?
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.
> 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.
Micromanagement - there is literally ability to make own decisions. You have to accountability either. Every single tiny aspect of work is dictated by somebody else, commitee or some kind of process.
Personal guess: groups full of people with high interest in people and great social skills won't produce something like scrum. It exists only because tech can give decision power to people who don't have those.
Human psychology: to large extend the above. It leads to absurd conflicts and power struggles over nonsense. Then it blames people who actually reacted in predictable way. It creates unnecessary hard social situations.
It is also massively demotivating. In fact, the components of motivations in pretty much any other fields are autonomy, mastery, accountability. Scrum lacks all three.
> Every single tiny aspect of work is dictated by somebody else, commitee or some kind of process.
That is not the way Scrum is meant to be implemented. The goal is to have a cross-functional, empowered team with the ability to make their own decision. The Product Owner - as part of that team - makes ultimate decisions as to what the product will be.
> It creates unnecessary hard social situations
Yes, social conflicts in team can be tough. Following the values of Scrum, respect and openness in particular, helps teams sort these things out. I know that in practice, it involves a lot of skill to guide a team through those phases.
> the components of motivations in pretty much any other fields are autonomy, mastery, accountability
You are absolutely right. If you read through the Scrum guide, you will find all those aspects in there. I think what you are describing, though, is how Scrum is "lived" in many organizations, which have difficulties empowering teams and provide the environment necessary to do Scrum.
In these situations, the answer is often that Scrum simply don't work, it's clashing with your culture and structure. Many teams opt to implement parts of Scrum - which is fine and might work exceptionally well, but it's not Scrum.
They might not meant it, but that is what it creates. It does not create empowered workers. It does not even talk about people or individuals, it is always team. But "the team" does not make decisions, individuals do. There are emergent decisions, coming out of the system, but no empowerment to anyone (maybe except PO).
> Following the values of Scrum, respect and openness in particular, helps teams sort these things out. I know that in practice, it involves a lot of skill to guide a team through those phases.
"Respect" helps to solve conflicts in literally any kind of methodology. And healthy asertivity too. That does not make Scrum special. It still makes it harder then other methodologies. It still leads to harder and more emotional conflicts. Probably because people with no feeling of control are fighting over control
> If you read through the Scrum guide, you will find all those aspects in there.
That is not true. Scrum does not give any agency to people working in team, only to "team" as a collective entity. People working inside the team work at 2-4 hours long tasks at maximum, all the problem solving was done "by system". Individuals are not improving, except in following the process.