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?
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?
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.
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.
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.
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.
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...)
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.
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
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.
Do you mind defining this?
"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.)
> "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?
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.
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.
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.
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.
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.
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.
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.
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.
And sometimes you do hit a brick wall or bite something you cannot chew yet must digest.
It still makes sense to have intermediate deliverables for internal milestones though.
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.
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")
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.