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