Then you are using Scrum to obfuscate a core communications problem in your company.
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?
> 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.
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.
> 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
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.
Agreed. Most of the complaints I read that aren’t just related to awful management are typically to the effect of “I’m being required to function as part of a larger organization instead of doing what I want.”
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.
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?