Of course, our PM and scrum master, just went along and put us all into a room, to estimate and figure out how we could deliver. All our estimates were proclaimed wrong, and we had to estimate again, eventually devs just gave a number to make it fit within the two weeks.
Needless to stay, the product did not launch, and the developers got blamed for not being flexible enough. That’s how agile works in big companies, use agile as a term for everything wen it fits, use it as a way to blame others. Scrum masters are just there to pass along communication from the business, and absorb complains from developers. It’s just another one-way street of communication.
I've seen something like this happen, and I must wonder. The only ones that can give an estimation are the people who will actually do the work. This estimation will likely be also wrong, but it's their job and their estimation. How can anyone else dispute it?
Very tempted to reply "well, how about you do it in two weeks then?". I never do, because I want to keep my job. And nobody is ever punished for missing deadlines, anyway.
Pretty much, the general consensus amongst developers was to just go along with whatever the scrum master is saying, just so that we could at least get out of the meeting and start our work. Missing deadlines was pretty common, getting blamed was pretty common, but you won't get fired. Perhaps you'll get moved to a different team, where the same story repeats itself.
This should be fairly easy to communicate to the business people.
We don't need unions for better wages. What we're often missing is respect, dignity. (Yes, sorta like sex workers.)
You need a good PM who knows how to handle this for you. I did agile correctly in a large bureaucratic organization because our PM shielded us from those requests, and basically told the business that they could prioritize the requests appropriately in the next sprint planning session.
If they showed up and participated, they got to duke it out with the other competing business units about who got priority. If they didn't show up, we told them that their work was not prioritized because they failed to attend the planning session.
- You can only ever work on projects which are finished in one sprint.
- You have no idea how, when, or even why the big initiative you're working on will finish.
It's not practical to build a business this way, what happens when one team pulls priority and a different one next week? what happens when a multi-sprint project becomes a multi-year forever project?
You can get around this if someone (such as a manager/PM/lead) converts the sprint process back to a practical roadmap/design. However not involving the sprint team in this process merely robs them of autonomy. At best, the absence of autonomy for an individual in a scrum team might be the point of the whole process.
> It's not practical to build a business this way, what happens when one team pulls priority and a different one next week?
Someone has to own the project, and have the final say on priority. If the project is at risk due to shifting priorities, you need to escalate this to them for a final decision.
> You can get around this if someone (such as a manager/PM/lead) converts the sprint process back to a practical roadmap/design. However not involving the sprint team in this process merely robs them of autonomy.
If you have everything in your backlog, you can judge velocity to come up with an estimated timeline given all of the assumption at the current state. This isn’t a promise, it’s an estimate. When the business shows up to sprint planning and sprinkles around new ideas for high priority tasks, you always remind them that this means deprioritizing other tasks which will affect timeline.
> what happens when a multi-sprint project becomes a multi-year forever project?
Yes, at the end of the project you will likely have done something very different than what you originally put in your backlog, because the business will have changed their minds 100 times. This is the point! The point is to track close to building what they want, not to build what they wanted 8 months ago.
What’s the difference between this and “waterfall” then?
The difference between this and “traditional waterfall” is that you do this continuously, simultaneously with implementation, and not just once, up-front before building anything.
(At least that's the common picture of “waterfall” -- which of course proponents of various “agile” methodologies prefer to contrast their product against -- though IIRC Brooks or someone had proposed / recorded iteration on this in parallel with implementation long before the Agile Manifesto.)
I like to say that the whole point in the estimates is to set expectations. At that point a discussion is had with the stake holders.
If you know the velocity of the team, because it’s actually been measured (a rare thing in my experience), you will have a good idea on what is actually possible within a time frame.
Absolutely lack in long-term thinking, goals and vision.
Filter out the crazy (which can be the entirety) and then pass down to the team the best way you can figure to move things forward.
I managed to do this for a while. It's hard on the ol' mental health though.
<insert meme of soldier protecting sleeping child>[0]
The SM is supposed to be part of the team, not part of management.
[0] https://pics.me.me/the-silent-protector-sales-department-man...
My approach is the MVP way, where the team delivers everything that is necessary to meet the customers goals. All the bells an whistles can be qdded once those goals are met. If the goal can't be met within the given timeframe, then it's a problem of unrealistic expectations. But most of the times we have met the deadline while otheres with their bloated waterfall projects were late.
All of these have been unusual work environments so I’m not sure I have reproducible insight to offer (though the second case probably is more reproducible than not at all, and I highly encourage anyone with the opportunity to throw down and choose your own planning adventure to coordinate with your team and see what shakes out; you have nothing to lose but your estimation poker hand).