[Delmania]

> If "scrum" is being followed properly, there's somebody listening who's actually recording what you said you were going to do yesterday and compare it to what you say you did yesterday and call out any discrepancies.

Seems to me that if you can't justify why not keeping your stated commitments was in the interest of the team and the company, then the issue is with your communication and not the process itself.

[dkarl]

Exactly. And if somebody wants to complain about a process methodology not working because management at their company is stupid or a bunch of assholes: nothing fixes that.

90% of the time the cure for needing to do "undercover" work is explaining that it is needed to accomplish what the company expects to get out of a task. It often happens that incorrect assumptions get embedded in a plan, and an engineer is asked to do X on the assumption that doing X will also accomplish Z, and they think, "Ugh, they want me to do X but they won't give me time to do Y and Z, what the fuck do I do, Z isn't going to get done and then it will be my fault because I was tasked to do X and they think that's the same thing." Just communicate: "I think what is expected is that if we do X then Z will also be accomplished. In this case, doing X won't accomplish Z. We will also need to do Y and Z, which is additional work."

Then if they say, "Just do X," you don't have to fret about Y and Z, because you have set expectations appropriately. In a dysfunctional environment, where the scrum master or project manager is mechanically executing a process without knowing what any of it means, you may need to escalate or reach out beyond the team to find somebody who appreciates your warning that X will not accomplish Z.

Of course there may be no such person, but in that case, no process will save you.

I've even seen this used effectively to talk about technical debt. "Look, I think the assumption in management is that we're making progress on moving away from the legacy services and deprecating our old auth solution, but in fact, if we do this we will be making ourselves even more dependent on the legacy services, and we'll be adding new public APIs that can't be properly secured. I just want to be sure that [manager's name] is aware that that is how we're shaving a month off this plan." Needle scratch, management wasn't aware that there was any downside to the expedited plan that project management had squeezed out of the engineers, because project management did not understand the language of technical debt. It was all engineer blah blah to them, and it didn't occur to them that management needed to hear it.

[milesvp]

Very much this. I find it necessary to make even the most simple and obvious connections explicit in group contexts. This is even more useful when dealing with people who are further away from the problem, or aren't focused on the issue at the level of detail of the people in the trenches. I'm not sure I can tally the number of hours that I spent reminding people at the C-level that, while all the work being done related to removing dependencies on system Foo was useful work, if they still wanted application Bar, then system Foo was never going to go away and they'd still be stuck with ongoing licensing costs for system Foo. And I wasn't even trying to convince them to stop spending time and effort, I just wanted to make sure that they knew the actual cost that application Bar was going to be solely responsible for, so they could plan for it, or do better cost/benefit analysis.

It's sort of crazy, I'd get an oh, yeah, every time I'm mention some of these things, but the facts would sort of slip out of their minds. I think they'd also get together with other managers who were confident that system Foo would be going away in a few quarters who either didn't know about application Bar, or didn't need to care about it, and their enthusiasm would cause the details to sort of get mentally overridden.

There is definitely an art to managing expectations and making sure that efforts and goals and scope are aligned.

[dkarl]

> Very much this. I find it necessary to make even the most simple and obvious connections explicit in group contexts.

This took me years, and I mean many years, to fully understand. I would say things like, "If we're doing X, shouldn't we also do Y? I mean, we need Y for Z...." which is not nearly as effective as, "If we are doing X, I think the expectation is that we will accomplish Z, but doing X will not accomplish Z."

Both statements say that if Z is desired, X will not suffice. But the scrum masters and project managers hear the first as "the engineers want something," which primes them to ignore you, and the second as "management expects something," which primes them to pay attention and process what you're saying.

[commandlinefan]

> I find it necessary to make even the most simple and obvious connections explicit

So, in other words - "yes, you do need permission".

[hallway_monitor]

The simple solution, I think, is to give permission. Look for ways to optimize, simplify, refactor. Do it within story work when that makes sense. Don't "hide" it but if you have some time, do what you feel is important and interesting let the team know what you found out. Set the example. You shouldn't need a JIRA ticket to improve the system, do a quick spike or take a s** and on my team, you don't.

[Delmania]

Yes, at some point, management can ask you to justify the work you did. They are paying you, after all. Scrum and agile was never about letting people do whatever they wanted do. Management has already had a role in making sure there were appropriate limits set. In other words, if you're responsible for building a word processor and end up building a video game, I think it's appropriate for someone to ask what are you doing?

[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.

[Consultant32452]

How do you think skunkworks projects fit into this paradigm?

[Delmania]

To be honest, I don't have an answer for you. If scrum doesn't help you with a skunkworks project, then choose a different methodology.