Hacker News Reader

Comment by rob74 | Hacker News Reader

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...

View on HN

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?

A more fluid "here's what we're prioritizing next" approach. is that 'kanban'? (I think so?)

Worked on a small group (2-3 people?) and .. 'agile-2-week-sprint-estimate-tickets-with-points' wasn't working well. This is 'startup/mvp' area, and we migrated to just a simpler task board. Owner moves tickets up and down in a "to do" queue, and someone (usually me) takes current 'to do' tickets, and does them and releases. The '2 week' time box wasn't really helping anything - we can 'release' multiple times per week.

For larger teams working on established product, there's more value to the '2-week-sprint-give-points-to-tickets' approach that's more popular. Worked in a group a few years ago like that, and... while there were some issues, they weren't specific to sprints or agile, more just growing pains of that company.

Kanban is also fine, for the reasons you mentioned. I wonder if TFA favors this methodology?

Do note Kanban can devolve into "do everything, all at once, and we need right now. Stop doing what you're doing, do this thing instead!". It happened to my team, and we had to ditch it because the stakeholders weren't onboard with no fixed cadence of deliveries.

> "do everything, all at once, and we need right now. Stop doing what you're doing, do this thing instead!"

Hum... Since the single main stated goal of kanban is to minimize WIP, it's safe to say that this is not kanban.

Of course, it won't stop bad managers from implementing it. But nothing will stop bad managers from implementing it anyway. Anything can devolve into that, trying to implement something different won't save you.

> it's safe to say that this is not kanban

But that's the problem with agile.

Nobody can or wants to pin it down. When it fails, "you are not doing it properly". The stated goals are iterations, early feedback, people over processes... except when they aren't.

Hum, no. If you go calling some infinite WIP generating process by the name that has as the one most important principle "no matter what you do, keep WIP down", it's you that are bastardizing the language.

> Hum, no

Um, yes.

I'm sorry, but the "Agile works, it's just that you are doing it wrong" line of argument is weak and unconvincing. The theory of a methodology means little when there is no buy-in from stakeholders, as is often the case. They reinterpret it to mean whatever they want it to mean. If you haven't struck this wall, then congrats! Most of us in software have to deal with it, though.

> WIP

Do you mind defining this?

Work In Progress, I think they're referring to.

Yep, work in progress.

"Work in Progress".

"Strict" Kanban is about minimizing in flight stuff that you don't have bandwidth for. (Strict "traffic limits" based on team size in any specific column.)

Thank you for the clarification, but I am afraid you lost me at this part:

> "Strict" Kanban is about minimizing in flight stuff that you don't have bandwidth for. (Strict "traffic limits" based on team size in any specific column.)

What is "in flight stuff" and "traffic limits?" Are you saying strict Kanban minimizes the number of tasks that are in progress in order to prevent overloading the team i.e., there is an upper limit set to curtail the amount of simultaneous tasks?

If you're interested learning more about Kanban, I thing Eric Brechner does a great job of describing it - https://www.youtube.com/watch?v=CD0y-aU1sXo

Right, Kanban comes from "just in time" factory needs where you've got scarce supplies that feed scarce resources (particular stations). It started on physical index cards representing "parts" that needed to flow through stations. Each station would pull cards representing the parts they need, but weren't allowed to pull more than they could work with at a time. When "parts" run out new ones need to be ordered. Putting it on a central board was all about finding: what parts are needed where, visualizing which ones run out first, and visualizing where the bottlenecks are. (A lot the parts are stuck waiting on a particular station to pull them and maybe that station is blocked for some reason.) At any point if there is too much in any single column "something is wrong". You are missing a column or work isn't flowing right.

Not all the factory needs apply to Software Kanban, but it's still a useful analogy in various ways. Plus not all software for working with Kanban style boards is great at some of things "Physical Kanban" is better at. (Some of the best times I've worked in Kanban board software was eschewed altogether and it was done in index cards on a whiteboard. There is something to be said about physically moving cards around that the software boards don't quite capture.) While the "raw parts" in Software Kanban are generally considered to "backlog items" (features/stories) and are plentiful rather than scarce (and this is one place where the analogy to factory operations kind of breaks down a little bit), in "strict" Kanban each column or "station" is expected to have somewhat strict limits to keep from overloading the team. Only so many tasks in progress in development at once (often capped at one per developer), only so many tasks in progress in QA testing at once (often capped at one per QA person), etc. You can visualize bottlenecks: if there are too many tasks in Development and not enough for QA, maybe the stories are too big for a steady cadence (Development is your bottleneck); if there are too many tasks in QA instead maybe QA is your bottleneck and you need more QA resources. If you need to scroll a column there's probably a bottleneck to fix (or a column/"station" you are missing).

Setting bandwidth limits, finding your "stations" in your column designs to help find and visualize your bottlenecks, is a lot of the art of Kanban. That and Kanban's focus on "pull" rather than "push" are big differences between Kanban done right and Scrum.

Yes, WIP (work on progress) limits are a key feature of Kanban.

>stakeholders weren't onboard with no fixed cadence of deliveries.

Can the fixed cadence of deliveries be weekly or semi weekly status update of cards on the board? (Note: the view of the board should always be available to stakeholders, they may need to hold their breath for a week until a more in-depth status meeting of current cards on the board...)

Yep.

Also I've never seen a Kanban operation deliver everything to Production as soon as it hits a "Done" column and there's no reason not to "time gate" (once every fortnite, just like Sprints are supposed to be, for instance) a Production column "pull".

I think that's easily missed in Kanban versus Scrum discussions: every Kanban column is supposed to be "pull" rather than "push". Production "pulls" finished UAT stories when it is ready (which maybe is a biweekly schedule that keeps ops happy and gives marketing time to prepare materials, etc). (I also think that's why a lot of micro-managers dislike Kanban versus Scrum, because they want to "push" everything and dislike people making their own "pull" judgments based on their current bandwidth and ability.) The failure case of "Production pulls finished work" is that Production sometimes wants to cherry-pick finished work ("I want these three but not this fourth one") after they've been already merged for UAT testing. I've not seen a good Kanban software that visualizes that "state change" of stacking cards together as they become bundled together/releasable units.

Ah yes! I forgot about the "pull" mechanism of kanban. This also helps identity bottlenecks and discover where more "resources" (::barf::) are needed or where re-allocation of "resources" should occur.

I need to reread the following books:

Kanban: Successful Evolutionary Change for Your Technology Business

Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency

The Goal: A Process of Ongoing Improvement.

The Deadline: A Novel About Project Management

But again, sprints can also devolve into that. Structure becomes valueless when people subvert it; there's nothing particular about kanban which makes it more susceptible to this than scrum.

Totally agreed.

From the outside, though, kanban looks more like "no methodology". If people who aren't on board look at both 2-week sprints and kanban, kanban looks a lot closer to "we can ask you to do whatever, whenever". It's wrong, of course, but in my experience they understand better that it's discouraged to insert new requirements in the middle of a sprint.

People will subvert whatever they want, though. Probably the biggest shortcoming with agile methodologies: "you are not doing it right" -- yeah, well, real people in the real world never do it right.

This is what we've been using for some years now, despite the general Scrum-y pressure in the organization I work in. (It is not a mandate, note we get no blowback for what we do as it is under our control, I'm just saying most of the rest of the teams definitely do something more Scrum-y.)

I am a big believer in "true agile", since "Agile" (note capital letter) has become heavily corrupted. "True agile" can really be summed up as "try some different things, keep what works for you". My team has a large number of independent projects, more than one per person. Because of that we tend to have one person working on a given project at a time, as that is a cheap way to avoid coordination overhead if you are able to get away with it.

What we found for "sprints" is that we couldn't plan anything with them, because the variance in how much time we were actually going to have to work on a project was too high. We might have the full two weeks to work on what we said we were going to work on. We might have a fire on another system that pulled that person away for literally 3/4ths of that "sprint". We might have an emergency feature request that could do the same thing. We found this variance to dominate the rest of our time planning, which resulted in our "sprint planning" being a bad joke. Nor could we just "git gud" at sprint planning, because the variance in the amount of time we had to spend on it was far, far too pathological.

I do not present this as evidence that "Sprints" are bad for everyone, only that there are cases where they really don't based on my experience as well. This has been my personal working mode for most of the last 10 years, and they've never worked for me. We've switched to a much more Kanban style of planning, which gives us the flexibility to deal with our issues without wrecking all our plans. I personally take the brunt of a lot of the highest frequency switching in our team, and my primary goal is that on a given day, I am working on one project, with a secondary goal of trying to keep it chunked up by week. That latter often fails, but I definitely try to avoid switching projects mid-day. (Which also fails, sometimes due to fires, but I've noticeably improved on this metric in the past couple of years.)

We've tried at least twice to switch to a more Sprint-y method of organization to better match the rest of the organization, but failed both times. I'm fine with the attempt, I'm just very glad we've also retained the flexibility to admit it was a failure, and that it isn't mandated from above that we must do the Sprint approach.

The vast bulk of teams in the rest of the organization I work in does have 3-7 person teams all working on one particular system, and while nobody ever escapes from the possibility of fires, they have a lower variance on the impact on that for all sorts of reasons. (Most notable being that 3/4ths of a week for one person out of 3-7 is a lower impact than 3/4ths of a week out of what was effectively zero people, which means it was actively drawing against what was nominally another project's time. That's a really big difference.) Sprints work much better for them. I'm sure they fail them sometimes but they generally seem to work for them.

> "True agile" can really be summed up as "try some different things, keep what works for you".

I would argue that is more common sense than "True Agile." ;)

However, I think you hit the nail on the head with Sprints. I understand why organizations want estimates, planning, etc.. However, if I could predict the future, I would be working on Wall Street and not doing Agile. In my jaded experience, few things ever go to plan. I do think one should still plan, but I do not think plans should be immutable nor estimates turned into deadlines.

Sprints, to me, seem to be the antithesis of Agile. I find sprints turn Agile into a series of mini-Waterfalls.

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.

Plan enough is sometimes 3 months of work. "Here's all the stuff we need to do to create a MVP." After 3 months, its not done and you are trying to do the last 90% on a task you thought was already 90% done. The hard things were put off till the end and now the optimistic "it should be done in 3 months" is getting up to directors that you don't have anything that runs at all.

The sprint forces a "this is what we're doing in these 2 weeks" with a deliverable at the end. If, at the end of the first sprint, you only got half the things done because of challenges, ok that's what it is. Next sprint you pick up only half as much work and you get that done.

Now, the PM can look at all the work that needs to be done and the rate of work that needs to be done and the amount of work and realizes that instead of the initial "yea, we can do this MVP in 3 months" that you're closer to having it out in 8 months if everything remains the same rate.

That is something actionable for project management to say "nope, can't have the MVP in 3 months with this scope" after only 4 weeks and the project can get canceled earlier.

Sprints try to make management realize overly optimistic estimates and timelines and either have things get adjusted (staff, scope, or time) or have it canceled sooner. Having a sprint based project canceled after 4 weeks rather than embarrassed and dragging out at 12 weeks is good for the organization to not spend resources on things that won't get done in the required timeframe.

The goal of the short framed boundaries is to force this decision sooner.

Hot take: If you take three months planning, either it's incredibly complex or you're holding it wrong. If your directors aren't able to recognize either case well before the 3 months mark, get yourself new directors. (Source: I am one of those pointy-haired monsters. The sinking feeling in your gut starts at the end of month one, the latest)

And the third paragraph kind of lays bare the problem with sprints: The PM can only look at all the work that needs to be done if, well, there was a discovery phase to list all the work that needs to be done. That discovery looks suspiciously like planning.

That's why agile focuses on continuous delivery of value. It's excellent for projects where it's hard to estimate the full scope, but there are many intermediate targets that are valuable to the customer. You go along until enough value is delivered, and then move on. Not all projects work like that. Some things only generate any value at the end of a long slog. Some things can be delivered incrementally but require a predictable end date. (Hello, Black Friday!)

And so, you get to adopt methodology to the problem at hand. Sometimes, you really need to spend the planning up front. Sometimes it's enough to sketch it out on a napkin. Sometimes you can do things sprint-by-sprint. Sometimes, you have larger checkpoints and sprints in between. The idea that any single methodology works for every problem is an idea favored by the consulting industry, but not a reality. And it predates agile, by a lot - I've been a process consulting victim way back in the early 80s. (And the mass of miracle methodologies directly led to "No Silver Bullet")

Exactly this. That is why the Agile Manifesto said to favor "Individuals and interactions over processes and tools". The problem is that approach only works when you have a team of experts with clear goals and enough space to address them. It doesn't necessarily lend itself to being quantifiable or standardized across multiple teams (depending on the problem), so the bean counters and middle managers get nervous. This is an environment ripe for agile consultants to swoop in with the siren song of the silver bullet process du jour.

I believe you misread my "Plan enough is sometimes 3 months of work." which was referring to the wording of the parent comment "How bout, plan enough then just build the thing until we agree its usable and correct."

Plan it out - be it a napkin or post it notes or whatever. That isn't three months of planning.

My point is one of that if you do a "just then just build the thing until we agree its usable and correct" often doesn't get a first milestone until a month or two down the road.

Sprints, being frequent, are there to help people identify issues with planning sooner so that issues with timelines earlier.

Often the "then just build the thing" gets down a month and the customer or business realizes that you're not building the right thing... or that you're doing a demo of what was built and get a "oh, I thought you'd be further along by now - there's no budget left for this work."

Sprints are designed to make projects that fall into those situations fail sooner. The fail fast part of agile is often a hard pill for people to swallow. https://www.agile-academy.com/en/agile-dictionary/fail-fast/ and https://www.ibm.com/garage/method/practices/culture/failing-...

Planning up front or as you go or how much isn't at issue with sprints. It's making sure that the project doesn't go too far off the intended goal or is too far behind what the budget allows for - and making those issues visible sooner so that the appropriate changes (less scope, more budget, more timeline, or just canceling it all together) can be done sooner in the process.

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.

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.

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.

The work is to read and synthesize a 10k+ smorgasbord, how do you break that into 2 week sprints?

Agile 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.

Bingo! 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 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.

It 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.

Oh, 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.

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.

> 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.

> 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?

> 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.

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?

It can make them believe they're good.

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).

> 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.

> 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)

> 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.

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.

And... in my experience, 'sprints-point-cards-planning-estimating' can also be a recipe for having the team on a constant death march to burnout. Doesn't mean it always is, but... find what works for the team. Let the team decide. I'd go further and say "let the people doing the bulk of the code work make these decisions first". Make process adjustments after some baselines are established to see if those adjustments are worth it or not.

Death marches can happen regardless of the methodologies used to get there. I've seen death marches up close before the word 'agile' was even a thing in the software world (and have seen it well after, in 'agile' organizations). If the team decides to not do any work for a day because. they're exhausted.... let them have it.

Agreed, but is anyone arguing that the team shouldn't decide?

Being the person to say "let's stop doing X and do something different" has generally not served me well in team settings. Whether or not others on the team agree or even care, they often don't want to be vocal about stuff, and would rather just punch in and do some work and go home.

The psychology around "team decisions" is a weird one, and I don't think there's always as much 'group buy in' or consensus as people might think.

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?

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

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

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

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.

> 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.

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.

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.

architecture has to be done first

Reply on news.ycombinator.com