Just once in my career I'd like to work on a project that resembles the original intent of agile. So far I've had 3 jobs that "did agile" and in each case there was a long list of requirements and a fixed deadline many months in the future for each "agile" project. No one wants to hear "We don't know when we will deliver X because we're working on Y this sprint".
In one company that proclaimed to do “agile”, our release was suddenly halted by the business, because they came up with some new requirements. These were regulatory requirements they of course long knew about, but only now decided to throw at us, because “agile” and it’s an ongoing product. All good and well, except that they now demanded the product to be released within two weeks, because that’s when the marketing campaign went live.
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.
> 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.
They dispute it because they assume that developers are padding their estimates. You know, it will probably take 2 weeks, so double it and then double it again.
And for every story like this, where developers can't do things they know they need to because all decisions are top-down . . . I say unionize. Management needs to know that IC devs are a force to be reckoned with and not code-bots. And then use the union to get contracts that allow devs more control over decision-making.
We don't need unions for better wages. What we're often missing is respect, dignity. (Yes, sorta like sex workers.)
> No one wants to hear "We don't know when we will deliver X because we're working on Y this sprint".
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.
If you have a large project, you break it down into smaller parts. If you know what needs to be done, throw it in the backlog, give it a broad estimate, sort it, and you have an estimate for about how long it will take. If you have unknowns, make resolving them a task. If you need things from the business, give them tasks.
> 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.
> you have a large project, you break it down into smaller parts. If you know what needs to be done, throw it in the backlog, give it a broad estimate, sort it, and you have an estimate for about how long it will take. If you have unknowns, make resolving them a task. If you need things from the business, give them tasks.
What’s the difference between this and “waterfall” then?
> 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.)
It’s a vague todo list instead of a project plan. There are no dates or resources assigned to tasks. And you’re not committed to doing any of it yet. You might change items, add items, or remove items.
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.
Your first point is exactly true. We design concepts with certain goals in mind, then that gets cut down into something that takes one or two sprints of work "to see the results", which never come because it does not even cover mvp use cases. Then the rest never gets built.
Absolutely lack in long-term thinking, goals and vision.
Yeah, in theory you’re technically correct, but in my experience, because “scrum masters are on the team” they’re usually a developer with little political or managerial power. I prefer having the scrum master and the PM on the team. As a pair they can navigate technical challenges and business politics effectively.
There's nothing wrong with a full backlog. And also not with a deadline defining when something should be available. Sometimes such deadlines come from third parties (e.g. retirement of an already deprecated API version), a larger corporate program that requires multiple projects to deliver in sync, or opportunities based on external factors where marketing is already concentrating on a specific date, ...
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.
This has been my experience as someone who has worked at a variety of large and small companies. Do you have a (generally B2B) product to market, with fixed release increments, and features set by some external marketing / sales team? Your agile is probably going to be "that agile." Are you a small company developing a new product that you don't fully understand yet as you're still developing it? Your agile will probably be closer to the experience people are seeking.
I’ve worked on three teams which have to some degree been agile in spirit. The first didn’t really have a planning philosophy at all, and was mostly agile in spirit by virtue of that other than when crunch time got really chaotic and stressful. The next took a minor opportunitistic rebellion to achieve, in the midst of a significant culling of management and a sympathetic view from one of the remaining leadership. My current job is thematically between the two and surprisingly adaptable even while being conscious of pressures.
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).
