3 ms·
That can be seen as a large enough sprint that encompasses "the thing". If, like in the scenario I was describing, the team lacks good planners, lead devs and p
by the_af 4y ago
That can be seen as a large enough sprint that encompasses "the thing". If, like in the scenario I was describing, the team lacks good planners, lead devs and people with the "big picture", what you are describing is a recipe for disaster. What will happen is that at the end of the long stretch, they won't have achieved much or worse, built the wrong thing.
When done well, any iterative method is meant to provide early stakeholder feedback at each stage, provide some measure of progress, and have earlier warning signs that the wrong thing is being built.
> What the hell is the point of the short time framed boundaries?
It's easier to estimate a simpler and smaller thing than a larger and more complex thing. If you cannot achieve the small thing, you absolutely won't be able to do the larger one.
- peteradio 4y agoIf developers x, y are developing UI and API endpoints and developer z is developing backend to a 10k+ page spec, 2 week sprints need not apply to developer z.
- the_af 4y agoWith sprints, the work of developer z would get broken up in more manageable chunks. The backend project would be very high risk otherwise. More in general, coordinating between related but separate projects is a hard problem in software engineering, and it's orthogonal to whether you use sprints, kanban, waterfall or whatever methodology.
- peteradio 4y agoThe work is to read and synthesize a 10k+ smorgasbord, how do you break that into 2 week sprints?
- Volundr 4y agoAgile means everything is up for being changed as makes the most sense, so in the (rare) event that you really have a task with 0 sensible deliverables you would indeed likely do longer sprints or no sprints. If that's not mutable because of some management mandate your not really doing Scrum, your doing "process inspired by Scrum" and saying you are doing Scrum. That said your description of "read and synthesize a 10k+ smorgasbord" is nowhere near descriptive enough to answer your question or have any kind of estimate on how easy/hard this work is. It could be anything from I'll have it done in a couple hours this afternoon to a year long effort by multiple devs. The best I can say is in the real world it's pretty rare to have a huge task that doesn't have sensible subtasks. In the case of ingesting a large mess of data like you are describing this could mean identifying and ingesting the data from system X, or processing event Y. These are steps the developers is going to go through anyway, and in many cases are even going to be deployable and useful on their own! Even if they aren't individually deployable they represent useful landmarks allowing for the understanding how work is progressing, readjusting estimates as necessary, and determining if the entire design needs to be reconsidered due to violated assumptions.
- peteradio 4y agoBingo! It's nuanced and process shouldn't rule people. Unfortunately process often rules people and those shops will insist to their dying day that they are agile.
- the_af 4y ago> The work is to read and synthesize a 10k+ smorgasbord, how do you break that into 2 week sprints? I don't know, your problem statement doesn't allow me to formulate an answer. I suspect whatever the project, it can be split into a series of more manageable chunks.
- AstralStorm 4y agoIt does not work if none of the chunks produces value for the customer, yet is necessary from engineering or bureaucratic point of view. And sometimes you do hit a brick wall or bite something you cannot chew yet must digest.
- the_af 4y agoOh, to clarify: I don't believe in Scrum's "you must be able to release to the customer at the end of each iteration". That's a piece of fiction that I think almost nobody believes in anymore. It still makes sense to have intermediate deliverables for internal milestones though.