[CodeMage]

The issue with the process itself is how that justification is provided. If you have data to justify something, then the process works fine. If you don't have that data and need to put in some work to obtain it, then you have to somehow justify that work, and the only way to do that is by "getting permission", i.e. buy-in from the rest of the team.

If you put it in context of the situation described in "You Don't Need Permission", doing the customer discovery cannot be justified except through buy-in from the CEO. If Suresh (from the story) has a daily standup with his CEO, then he can't do customer discovery because of the process.

[Delmania]

I think I'd disagree here. This article is not about scrum but about trust. Here's a quote from the article:

>As head of sales and marketing, Suresh didn’t need his CEO to buy into the process or give his permission to start the discovery process. He was in charge.

Suresh is a VP of marketing. It's his job to develop a plan, get buy-in, and execute on it. If the CEO is standing in the way, then all this boils down to is that the CEO is micromanaging his VPs. No process can solve for that.

[CodeMage]

The article is not about scrum. This particular thread of discussion is about scrum, because that's what the comment that started it was about, and also your comment that I replied to.

I was merely framing the discussion in terms of what is written in the article, to illustrate what the problem with scrum (or capital-A agile in general) is.

You are now replying to my specific example, instead of my argument about the problems with scrum.

[Delmania]

Yes, because context matters. If you want me to respond to agile, this is why you don’t have management at standup. To prevent micromanagement. My whole point is that there’s nothing inherently wrong (or right) with agile. It’s a process. The success of it depends partly on the people involved. One principle of agile is the right people on the right team.

[CodeMage]

This kind of reply makes discussions about agile very frustrating for me. Not only does it conflate agile software development, as a set of practices, with the myriad of processes and practices like scrum, but it also deflects perfectly valid criticisms with insinuation that "you're doing it wrong".

Most people would never think of either pretending that the waterfall model is without problems, nor that it can never be successfully applied to any project. Why, then, is it not acceptable to admit that scrum does, indeed, have limitations that stem from the way it reduces the autonomy of the individual team members?

I'm not sure where "the right people on the right team" comes from -- it's certainly not in the agile manifesto -- but it's just the right grade of vague to be less than useful in practice. It's like saying that every problem can be solved in only two steps: 1) determine what you have to do, and 2) do it.

I don't see any reason for denying that scrum, in its most widely-practiced form, complicates or even discourages certain tasks and behaviors that can be beneficial under correct circumstances. It shouldn't be controversial.

[Delmania]

Yes, scrum limits individual autonomy. An effective team that is working together is far more productive than an individual. As a manager/director/executive, I'm far more interested in optimizing and rewarding one of my team's performance than any individual on the team. That's what I mean by "right team right people". I would rather get rid of the 10x developer who is unable to work and communicate with others and instead put a 1x developer who is capable of improving his team. That is what I see as the divide here. Developers are focused on their individual performance whereas I am focused on the whole team.