We just have a list of tasks we need to work on organised by priority and a quick estimate of the time needed to implement it. We don't need to meet every morning to follow that list, going through the list and re-arranging it once a week is fine.

If someone outside of our team wants to know what we're doing, they can look it up. And they trust us that we know how to prioritise tasks related to our own product.

I've worked within a scrum team before this and I prefer this approach so much more. Prior to this I never knew what I would face that day. It's whatever the project manager told me I should face in the morning meeting, even if it meant setting aside something I didn't quite finish yesterday but could finish within an additional hour or two.

> It's whatever the project manager told me I should face in the morning meeting

Just to be really clear - this is not "scrum". People can have a really difficult time with "agile" and related practices because they're often conflated with bad people/managers/teams. For most of my developmement career I've followed some sort of agile-two-week-sprint-scrum-with-daily-standup process and I've never been told what tasks I'm doing each morning. I've never experienced this problem you started (but ive definitely had other problems!)

At the risk of being a bit no true Scottsman, the best agile practicioners (and I don't mean the Deloitte/Thoughtworks paid-by-the-buzzword type) advocate for finding a process that works well for your team, picking bits from the larger "Agile Toolbox". That's True Agile.

The number one issue I've encountered in my area is companies that say they use Scrumm when they really don't. Scrumm is a very specific, defined process, and as they clearly state in their "handbook" if you're not following the process exactly as it's described then you aren't doing Scrumm. Period.

Absolutely this.

I accept that not everyone's like me, though.

Then you are using Scrum to obfuscate a core communications problem in your company. Either the business people are clueless about what they want and are flailing around in a panic, or they are not able to communicate their needs to you properly, or you are unable to understand their real business requirements, or they insist on micromanaging every aspect of your product. Or some combination of these factors.

You should not have to "fend off" your professional colleagues, you should be able to have an adult conversation with your peers and frame requirements and expectations accordingly. If your company culture prevents this then that's what you need to fix, not further burden the team with the demands of Scrum.

You're phrasing it as if OP is the problem but he isn't, at least not the most significant part about it. Have you ever been in an enterprise environment where people simply and subtly tell you to fuck off if you want to "have an adult conversation with your peers"?

Now you're stuck with the shitty situation and need to start fending idiots off because there is often ZERO interest to improve things like communication. It's often not a startup with 10 people where you can grab a coffee and go "Hey guys let's talk about our communication issues!".

These topics are highly political once a company is large enough and they are extremely rigid and hierarchical. Exceptions exist but they are, well, exceptions.

Sorry, but I felt this post was almost accusing OP of inaction when that's a pretty easy thing to say from the outside.

Communication overheard is an inherit trait of large organizations. To some degree we can improve this with digital technology, but it’s a fundamental problem.

If you need to rewire the communication pathways of 10 people, the complexity can be up to O(n^2) because you might need to make adjustments for how every individual is getting signal from other individuals. As organizations grow the old pathways of communication are less optimal, but it’s also more expensive to rewire communication. To some degree corporate communication overhead buys stability and consistency across the organization.

You should attempt to optimize communication with those nearest to you in a large workforce, but at a certain point all you can do is give feedback to corporate about the communication pain points. If you work in a large organization and you can optimize your local communications to be completely optimal you probably aren’t communicating with enough people to have a full impact on the organization.

What I am saying is that using Scrum to paper over a dysfunctional organization merely adds more dysfunction. It's a bit like the old joke: you have a problem, you adopt XML as the solution, now you have two problems. If you have a dysfunctional organization, then you either fix that if it's in your power, grin and bear it if you can't, or leave if that's an option. You're not going to fix it with Scrum (or for that matter, Kanban or any other off-the-shelf process).

Thus far, your position on this is too rigid and does not account for the spectrum of: org size, type, age, etc. It lacks maturity and awareness of the realities of many organizations.

If you’ve found a place where you can implement this stance: great! The vast majority of people are not in that position, and criticizing them for it is not a great look.

The implication that this is “the solution” is pretty naive.

No, they're using scrum to guarantee a minimum level of effective communication. Business people don't have to be "clueless" to be constantly shifting priorities: they are reacting to the day-to-day business realities of client requests and biz dev opportunities. They're acting professionally, and in good faith. But if the dev team constantly reacted to those shifting priorities, the constant context shifting would kill their productivity and morale. Scrum provides a minimal set of tools and practices to ensure stability for the dev team, so they aren't constantly in reaction mode and have space to think about the product and be proactive.

I'm constantly amazed by people who talk about the "burdens" of scrum, like it's a lot of work that wouldn't otherwise happen. Really? Let's look at all that "extra" work:

- talking to your teammates daily to share progress, but more importantly raise red flags if there are impediments

- demo-ing your work periodically to verify that the stuff the team says is done actually meets expectations

- periodically taking some time to design the software, maybe refactor stuff that isn't correctly modeled, and planning your work

And that's pretty much it. Do people really work in places where they don't do any of that stuff? They just wing it, test everything at the end, and hope for the best?

That makes the business people sound a lot like the guy in Office Space who takes the specs to the engineers. If they are just a secretary who will rapidly oscillate priorities based on what customer yelled the loudest yesterday that isn't very useful to the business. The purpose of a product team or anyone in that capacity is to try and understand client needs prior to the client actually having them, rapidly changing priorities is generally evidence of that not happening.

This is a gross mischaracterization, and depends greatly on the industry, stage of the product, nature of the customer, etc. I've seen major organizations shift an entire 6-12 months of roadmap to cater to one or two key customers with unique requirements, just based on the sheer size of the revenue from the deal.

Re-prioritization happens for many reasons, and while it's absolutely true that rapidly shifting priorities can be a major red flag and may be extremely detrimental, it's also true that sometimes this is just the nature of the beast. And when that's the case, having a good business/product/whatever you label it layer to shield the engineering teams is critical.

> The purpose of a product team or anyone in that capacity is to try and understand client needs prior to the client actually having them, rapidly changing priorities is generally evidence of that not happening.

Again, this depends on the kind of software shop this is. If you're building the next social media platform, you have an entirely different set of problems and concerns from a behemoth enterprise software platform trying to beat the other behemoth for that next $30M deal.

There are no perfect solutions to project management, and if you prefer to work in tiny organized communes without corporate direction then that is your prerogative. I’ll be right there with you. Otherwise, it sounds like some developers here are just annoyed that their team and departments don’t revolve around their individual desire to not be managed.

Plus not everyone has the privilege of a good base experience, or the option to just find a better cultured company.

Billy and Bob want different things for different customers. Billie gets commission on solving stuff for his customers, Bob for his own. Both of them promise their customers everything next month.

Now you have 10 developers and Billie convinced 5 of them that building his things is important. Other 5 devs are convinced by Bob to work on his ideas. Developers are not informed about how much each customer is worth, as they don't need it for their jobs (just as Billie and Bob don't have any access to source code, databases and servers). Remember you need to have "least knowledge/privilige" principle because you don't inform all employees on all details of company deals (because I am writing about B2B products).

For me professional way is to have a product owner who listens to both of them, knows how much each customer is worth for the company, checks with the team how much each feature costs and makes priorities. You create a single line of communication and defined process. You communicate in a clear way what can be achieved when, well maybe with a bit of a slip here and there. Billie and Bob get one person to communicate with, get clear forecasts that then they can communicate back to the customers.

Maybe that is different if you have B2C products because then you don't have such scenario there.

The benefit of having a single PO is that they reconcile the competing priorities and the developers don't have to do it themselves.

Yeah, this is ridiculous; Scrum actually changed the term from ‘Commitment’ to ‘Forecast’ back in 2011. But the industry didn’t pay attention to that minor but important change.

- https://www.scrum.org/resources/commitment-vs-forecast

The drawbridge is lowered every two weeks and that's when the team delivers and demonstrates the stuff they did during that time. This is also the time the stakeholders get to present the prioritised list of work that needs to be done during the next two weeks (Product backlog).

During the two week period if the stakeholders need to communicate to the Fort of Scrum, they can shout from the other side of the moat and the Scrum Master is the only one with access to the only tower in the castle where the shouting can be heard. The team has complete autonomy and peace to work for the two weeks.

I don't feel like I am building a wall, I am building a structured approach to communication and software building that is predictable to deliver value to our business and our customers.

Using scrum/agile to fix a lack of trust, not sure how that's going to work out long-term.

How do you work as a professional autonomously without setting rules for work and setting up process for regular progress check-in?