391–400 of 459 posts
But how do you truly know WHAT you should on focus and deliver without having a clear understanding of the broader picture and without breaking apart work for the week, especially with a team where everyone is at completely different steps and working on completely different things?
Earlier quoted context omitted.
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…
> 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.
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.
Earlier quoted context omitted.
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.…
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 b…
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.
Earlier quoted context omitted.
I think sprints (I've almost never used this in work and am not anti) are lacking something, limiting scope is one thing but do they ensure framing the problem / solution / design well too ? The few times we've used sprints it was just issue dispatch and see you later, not really a guarantee of anything, but maybe I'm missing some information.
> do they ensure framing the problem / solution / design well too ? In my experience with a complex product, they do not. You need an earlier, separate layer of preparation for defining and refining implementation tasks until they are ready to be scheduled in a sprint. Although in the ideal workflow, you should be able to split those definition processes (user research, writing requirements, etc) as tasks for the tea…
Earlier quoted context omitted.
I’d go further, sprints are defensive for devs. Don’t bother me or tell me to do something new during a sprint. I’m doing the work I said I’d do, leave me alone until the sprint is overs.
Love it. Lots of agile benefits for devs. Less hand-wavy requirements. You get to say how long your work is going to take
Earlier quoted context omitted.
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.…
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.
I've been bemused watching the rise of agile over the last (10?) years since my background is in building software for large/multinational non-tech companies. They have VPs and accounting departments with budgets and they want to know exactly how much they're spending before they spend the first dollar. Whether or not they should, they don't see the uncertainties in estimating software development as their problem. M…
I have worked on agile projects inside large non-technical corporates and there are several big advantages to agile in such an environment. For example: 1. Much less time spent trying to chase requirements that are technically infeasible within the budget and rough timescales. This on its own normally more than makes up for iterating and throwing away proof of concept implementations of features. 2. Much better visib…
The same dynamic happens with large residential/commercial construction projects FYI. They're expensive, complex, and hard to estimate. Overruns are common, but commitments on time and price are still made up front. In that industry they often remediate, if not solve, the problem by paying third-parties who are experts at estimation and of course everything that can possibly be spec'ed up front, is.
Earlier quoted context omitted.
One of these days we might even hear of an example where following "agile" actually panned out. The question is - before year of the Linux desktop or after?
I've worked at 3 different companies now where the system worked well and teams moved quickly and created great software. Unfortunately, that story is incredibly boring and goes against the tech blog hivemind.
I am a firm believer that one, "does not get chicken salad out of chicken shit." Thus, well ran and well organized companies would produce similar quality of products regardless of methodology, and in the same vein, poorly ran and disorganized companies will produce garbage regardless of the methodology.
Rich Hickey has a great joke about sprints, paraphrasing: So how do we run a marathon? That's right, we run a 200m wind sprint! Then another sprint, and another, and pretty soon... Of course no one does this, you'd die! We don't do this in software either, for the same reason. But when we talk about 'sprints' this is what we tell ourselves we're doing.
I liked the joke when I heard it. Reading it now, I'm realizing that "marathon" doesn't fit as a metaphor because we don't know the destination. Orienteering, perhaps: https://en.wikipedia.org/wiki/Orienteering
From what I have experienced, I think that is perfectly reflected in a lot of software too.
Rich Hickey has a great joke about sprints, paraphrasing: So how do we run a marathon? That's right, we run a 200m wind sprint! Then another sprint, and another, and pretty soon... Of course no one does this, you'd die! We don't do this in software either, for the same reason. But when we talk about 'sprints' this is what we tell ourselves we're doing.