7 ms·

And because you have sprints, you create lots and lots of small tasks, then focus on them, and then team members forget the "big picture" of how everything shou

by rob74 4y ago

And because you have sprints, you create lots and lots of small tasks, then focus on them, and then team members forget the "big picture" of how everything should fit together in the end (if they were ever aware of it). And when all of those small tasks are done, you notice that the sum of all those parts is not what you set out to build initially, and you need more time to shape it into something that resembles what you wanted to have. To avoid this scenario, it takes really dedicated project managers, product owners and lead developers, and not everyone has those...

astura 4y ago
If you have subpar project managers, product owners, and lead developers on your team would you really be better off without structured sprints? I guess, I'm asking, is there something specific about agile that makes a subpar team worse?
- ethanwillis 4y ago
  It can make them believe they're good.
  - the_af 4y ago
    In what sense? If they keep missing the planned sprint so that they must take less and less work each following sprint, isn't this telling the company there's something wrong somewhere? (Not necessarily the developers, mind you).
    - mgkimsal 4y ago
      > In what sense? In the sense that they're 'doing' the 'industry standard' practice. "There's gonna be problems with anything". If you missed estimates without agile/sprints, and now miss estimates with agile/sprints, you may think "well, at least we're doing industry standard practices now - estimates are always gonna be missed anyway, but now we're more agile". But now you have the attendant overhead of planning/meetings which is using up time that could be better spent somewhere else. Something not necessarily mentioned too much that I see, is that if you actually have all those people (PM, PO, tech/dev lead, etc), is that they all have to be good/skilled and generally on the same page. If two are good and one is bad, it's all bad. The system is only as good as the weakest participant.
      - the_af 4y ago
        > In the sense that they're 'doing' the 'industry standard' practice. "There's gonna be problems with anything". This is true regardless of whether they use sprints or not. Such a project is doomed regardless. I don't think any methodology will fix a project where most of the team is coasting, don't want to do the real work, or do not believe in the end goal. > The system is only as good as the weakest participant. I agree about this weakness! I think this is a reality of any software development endeavor. How would it be better without sprints, though? One thing agile proponents claim, which I think has at least a measure of truth, is that agile doesn't make projects succeed, but it does make problems visible earlier. I think we can all agree visibility is a good thing? So let's take the perfect project: all devs and stakeholders are stars, they never make mistakes, their customers understand their own needs perfectly, the budget is just right, no errors at all anywhere. This idyllic project needs no "methodology": no sprints, no managers, no nothing. The problem is that the above project doesn't exist. Back in the real world, where people are fallible, mistakes are made and misunderstandings abound, how can we surface those problems as early as possible, when they are less costly to fix? (when possible, of course -- some projects are doomed regardless)
        mgkimsal 4y ago
        > How would it be better without sprints, though? kanban, deliver something when it's done (even incremental when possible), fast feedback... The notion of "here's what we'll do in the next X weeks" takes a certain amount of planning which (imo) is often better spent just doing first. As/when issues/questions come up, they need to be addressed then, not waiting. You surface the problems early by some planning, then some work, then some feedback. "Sprint boundaries" don't seem to help in any of that. They help other people who want to know when something might be 'done', but it doesn't help me get feedback or clarify misunderstandings any faster.
        the_af 4y ago
        Kanban is good for some situations, but in my experience the problems of a weak team (or lack of vision of the big picture) only get exacerbated with this methodology. Again in my experience, in some environments kanban is an excuse for having the team on a constant death march to burnout.
hebrox 4y ago
I understand the feeling, but isn't everything eventually broken down into small tasks?
- TuringTest 4y ago
  Yes, and sprints are a tool to prioritize between them and create predictable schedules for the part that has been broken down already.
the_af 4y ago
What would be the alternative without sprints? What specifically about not using sprints would help the team if they lack good planners and people capable of seeing the big picture? Isn't such a team screwed regardless of how they allot work?
- peteradio 4y ago
  How bout, plan enough then just build the thing until we agree its usable and correct. What the hell is the point of the short time framed boundaries? I'm not a fucking horse I don't need cadence OR blinders.
  - 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 ago
      If 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 ago
        With 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.
specialp 4y ago
Well yes it does require some dedicated PMs, owners and leads. If you are a smaller operation that does not have this, sprints might not be as beneficial. But if you are working for anything at scale as a developer, sprints aren't necessarily to track every hour of your day, it is to give you a structured path of things to do without having to know every detail about the bigger picture/compromises with product/prioritization. Also as a developer it gives you leverage because you were given certain tasks for the week so when someone comes along and tries to inject "high" priority item X, something else has to give. I found before I was on the planning/lead side, it was hard when you did not have this structure. People would still shove in "small" tasks without a sprint structure and then months later it is hard to explain why a big project did not ship on time. So if done right and not abusively by oversubscribing devs, it is a great too for both sides.
hurril 4y ago
My experience from my previous $work was that things never quite got completed. I really tried arguing for a more sprint-based approach but they didn't like what they expected to be undue overhead. I disagreed since ... well, you can't have a conversation about overhead if $thing is not even done, can you?
- polynomial 4y ago
  But what if it takes even longer to not do what we're already not doing?
jayd16 4y ago
You're supposed to be integrating everything and evaluating the big picture every sprint. You run into the mindless sub tasks if you don't look at the big picture, sprints or not.
nathias 4y ago
architecture has to be done first
commandlinefan 4y ago
> forget the "big picture" Even if they remember the big picture, the tyranny of the sprint deadlines make it impossible to take the big picture into account - whatever gets the task done faster, no matter whether or not it creates problems down the line.
- Volundr 4y ago
  If your regularly running against sprint deadlines something is broken in either your planning or estimates. Either your trying to cram too much into a sprint or for some reason your regularly estimating tasks as significantly easier than they are. I'll also note if the response to an underestimated task is "well either pull some extra hours or rush it to get it in anyway" an important step of scrum is being missed.
hirvi74 4y ago
> if they were ever aware of it This is my biggest pet-peeve on my current project. I am a solo dev on my current project at work, and for some reason, we are still choosing to use agile/scrum with sprints and all that jazz (seriously, your guess as to why is good as mine). Regardless, one of the more difficult issues I have encountered through out my current project is the usage of proper abstraction and avoiding redundency. I seriously have little idea of anything I build will for the project will ever be used again in a different part. Since, everything is given to me in sprints, I literally have no idea what is coming down the pipes. Any feature I implement becomes an internal debate of how much abstraction is necessary vs. YAGNI. I've since given up on even trying. Once the project is more or less finished, I'll properly just run back through it and then properly abstract, refactor, etc.. You know -- spend more time doing something twice than properly the first time, but whatever.
- DougBTX 4y ago
  > Since, everything is given to me in sprints, I literally have no idea what is coming down the pipes. So you literally don’t know what the end goal of your project is? I would say then definitely not a “self organised” team, or in a sense, you’re not in the team?
  - hirvi74 4y ago
    > So you literally don’t know what the end goal of your project is? I know the end goal of the project in a general sense (like any other CRUD app), but I do not know what is takes to get to the end nor when the project will be considered finished. I'm also the solo dev, and I've been working on this for almost a year now. I'm so stressed and burned out because of this bastardized process (not real agile, but my org's "agile"). I know the only way things will get better is to find a new job, but I seriously cannot muster up the willpower to improve my situation.
jevyjevjevs 4y ago
There are a number of fundamental pieces of Scrum that are needed so all the pieces fit together. In the Sprint, one of the fundamental elements is having a "Sprint Goal". This allows the team to see the big picture and add/remove work during the sprint to get to that goal. Without a clear sprint goal, then of course it's easy to loose the essence or "big picture" of what the team is trying to achieve during the sprint.

by rob74 4y ago

astura 4y ago

If you have subpar project managers, product owners, and lead developers on your team would you really be better off without structured sprints? I guess, I'm asking, is there something specific about agile that makes a subpar team worse?

ethanwillis 4y ago
It can make them believe they're good.
- the_af 4y ago
  In what sense? If they keep missing the planned sprint so that they must take less and less work each following sprint, isn't this telling the company there's something wrong somewhere? (Not necessarily the developers, mind you).
  - mgkimsal 4y ago
    > In what sense? In the sense that they're 'doing' the 'industry standard' practice. "There's gonna be problems with anything". If you missed estimates without agile/sprints, and now miss estimates with agile/sprints, you may think "well, at least we're doing industry standard practices now - estimates are always gonna be missed anyway, but now we're more agile". But now you have the attendant overhead of planning/meetings which is using up time that could be better spent somewhere else. Something not necessarily mentioned too much that I see, is that if you actually have all those people (PM, PO, tech/dev lead, etc), is that they all have to be good/skilled and generally on the same page. If two are good and one is bad, it's all bad. The system is only as good as the weakest participant.
    - the_af 4y ago
      > In the sense that they're 'doing' the 'industry standard' practice. "There's gonna be problems with anything". This is true regardless of whether they use sprints or not. Such a project is doomed regardless. I don't think any methodology will fix a project where most of the team is coasting, don't want to do the real work, or do not believe in the end goal. > The system is only as good as the weakest participant. I agree about this weakness! I think this is a reality of any software development endeavor. How would it be better without sprints, though? One thing agile proponents claim, which I think has at least a measure of truth, is that agile doesn't make projects succeed, but it does make problems visible earlier. I think we can all agree visibility is a good thing? So let's take the perfect project: all devs and stakeholders are stars, they never make mistakes, their customers understand their own needs perfectly, the budget is just right, no errors at all anywhere. This idyllic project needs no "methodology": no sprints, no managers, no nothing. The problem is that the above project doesn't exist. Back in the real world, where people are fallible, mistakes are made and misunderstandings abound, how can we surface those problems as early as possible, when they are less costly to fix? (when possible, of course -- some projects are doomed regardless)
      - mgkimsal 4y ago
        > How would it be better without sprints, though? kanban, deliver something when it's done (even incremental when possible), fast feedback... The notion of "here's what we'll do in the next X weeks" takes a certain amount of planning which (imo) is often better spent just doing first. As/when issues/questions come up, they need to be addressed then, not waiting. You surface the problems early by some planning, then some work, then some feedback. "Sprint boundaries" don't seem to help in any of that. They help other people who want to know when something might be 'done', but it doesn't help me get feedback or clarify misunderstandings any faster.
        the_af 4y ago
        Kanban is good for some situations, but in my experience the problems of a weak team (or lack of vision of the big picture) only get exacerbated with this methodology. Again in my experience, in some environments kanban is an excuse for having the team on a constant death march to burnout.

hebrox 4y ago

I understand the feeling, but isn't everything eventually broken down into small tasks?

TuringTest 4y ago
Yes, and sprints are a tool to prioritize between them and create predictable schedules for the part that has been broken down already.

the_af 4y ago

What would be the alternative without sprints? What specifically about not using sprints would help the team if they lack good planners and people capable of seeing the big picture? Isn't such a team screwed regardless of how they allot work?

peteradio 4y ago
How bout, plan enough then just build the thing until we agree its usable and correct. What the hell is the point of the short time framed boundaries? I'm not a fucking horse I don't need cadence OR blinders.
- 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 ago
    If 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 ago
      With 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.

specialp 4y ago

Well yes it does require some dedicated PMs, owners and leads. If you are a smaller operation that does not have this, sprints might not be as beneficial. But if you are working for anything at scale as a developer, sprints aren't necessarily to track every hour of your day, it is to give you a structured path of things to do without having to know every detail about the bigger picture/compromises with product/prioritization. Also as a developer it gives you leverage because you were given certain tasks for the week so when someone comes along and tries to inject "high" priority item X, something else has to give. I found before I was on the planning/lead side, it was hard when you did not have this structure. People would still shove in "small" tasks without a sprint structure and then months later it is hard to explain why a big project did not ship on time. So if done right and not abusively by oversubscribing devs, it is a great too for both sides.

hurril 4y ago

My experience from my previous $work was that things never quite got completed. I really tried arguing for a more sprint-based approach but they didn't like what they expected to be undue overhead. I disagreed since ... well, you can't have a conversation about overhead if $thing is not even done, can you?

polynomial 4y ago
But what if it takes even longer to not do what we're already not doing?

jayd16 4y ago

You're supposed to be integrating everything and evaluating the big picture every sprint. You run into the mindless sub tasks if you don't look at the big picture, sprints or not.

nathias 4y ago

architecture has to be done first

commandlinefan 4y ago

> forget the "big picture" Even if they remember the big picture, the tyranny of the sprint deadlines make it impossible to take the big picture into account - whatever gets the task done faster, no matter whether or not it creates problems down the line.

Volundr 4y ago
If your regularly running against sprint deadlines something is broken in either your planning or estimates. Either your trying to cram too much into a sprint or for some reason your regularly estimating tasks as significantly easier than they are. I'll also note if the response to an underestimated task is "well either pull some extra hours or rush it to get it in anyway" an important step of scrum is being missed.

hirvi74 4y ago

> if they were ever aware of it This is my biggest pet-peeve on my current project. I am a solo dev on my current project at work, and for some reason, we are still choosing to use agile/scrum with sprints and all that jazz (seriously, your guess as to why is good as mine). Regardless, one of the more difficult issues I have encountered through out my current project is the usage of proper abstraction and avoiding redundency. I seriously have little idea of anything I build will for the project will ever be used again in a different part. Since, everything is given to me in sprints, I literally have no idea what is coming down the pipes. Any feature I implement becomes an internal debate of how much abstraction is necessary vs. YAGNI. I've since given up on even trying. Once the project is more or less finished, I'll properly just run back through it and then properly abstract, refactor, etc.. You know -- spend more time doing something twice than properly the first time, but whatever.

DougBTX 4y ago
> Since, everything is given to me in sprints, I literally have no idea what is coming down the pipes. So you literally don’t know what the end goal of your project is? I would say then definitely not a “self organised” team, or in a sense, you’re not in the team?
- hirvi74 4y ago
  > So you literally don’t know what the end goal of your project is? I know the end goal of the project in a general sense (like any other CRUD app), but I do not know what is takes to get to the end nor when the project will be considered finished. I'm also the solo dev, and I've been working on this for almost a year now. I'm so stressed and burned out because of this bastardized process (not real agile, but my org's "agile"). I know the only way things will get better is to find a new job, but I seriously cannot muster up the willpower to improve my situation.

jevyjevjevs 4y ago

There are a number of fundamental pieces of Scrum that are needed so all the pieces fit together. In the Sprint, one of the fundamental elements is having a "Sprint Goal". This allows the team to see the big picture and add/remove work during the sprint to get to that goal. Without a clear sprint goal, then of course it's easy to loose the essence or "big picture" of what the team is trying to achieve during the sprint.