I think the author got the right answer, but checking their work, I'm not sure they got it the right way. Sprints are actually really simple. You know how you work on something for a year, and then Google I/O is coming up where you're going to show it off to 3 billion people, and it's not done, so you just say "ya know what, I don't even CARE about these features we said we'd have" and you launch whatever you happen to have checked in on launch day? That's sprints! Except with sprints you do this every two weeks instead of every year.
I don’t believe in sprints
271–280 of 459 posts
Re: I don’t believe in sprints
#272I feel most of the criticism towards Agile coming from devs misses an important point: how it’s used to show the progress of a project to the people outside of the team. Unless you are part of a completely autonomous team, you need to communicate progress in a way that’s more informative than saying “trust me and leave us alone, it will be delivered in X months”. Spending time in meetings or writing down and discussi…
It’s horse before the cart though. It’s definitionally organizing work so it’s easy to understand and measure, rather than easy to actually work on. That’s not an optimal way to get work done. It’s metrics.
True, but metrics shouldn’t be downplayed given they are what boards/owners will be looking into when deciding to keep investing in a project or abort it - then both carts and horses become irrelevant.
It is somewhat utopian to think that companies paying for the development of whatever will patiently wait for (and fund) a team for months without any evidence of progress stronger than the promise of devs/managers that one day it will be delivered.
Re: I don’t believe in sprints
#273This is nothing but a bad strawman from start to finish. Sprints are not made to help organize things, they're a tool to get more predictable deliveries. Their very short nature forces participants to construct tasks that are easier to estimate and therefore complete on time with a higher probability. This certainly adds overhead to an idealised scenario where people take the shortest reasonble route often enough and…
Pretty much every rant like this is a straw man rant overfitted to the writer's worst experience of what someone called "agile" in one of their companies once.
In the same way that few ReST implementations are truly ReSTful, few agile implementations are truly agile.
The Agile Manifesto came into style, then predictably a cottage industry of small companies grew up around it, with the business model of charging Fortune 500s huge amounts of money to train their Engineering departments. I've sat through such training before, and I can say without doubt that the day our company took "agile training" was the day we stopped being agile.
We overlaid an efficient process with a ton of bureaucratic busy work. We came out the other side of it with an army of PMs (read: Jira configuration experts). Engineers had less time to engineer, with constant flow-interrupting meetings where they became trapped in a morass of Gantt Charts, "deliverables" spreadsheets, etc.
We had many employees for whom English was a second language, and interestingly none of those I talked to realized that "agile" was an actual word, meaning "nimble, quick, dexterous." Nothing about the new process conveyed any of those qualities. It was basically classic waterfall, with stand-up meetings thrown in. Rigid project management methodology is definitionally opposed to agility.
Re: I don’t believe in sprints
#274My view as a customer: a simple change, could be changing ine character in one script will be delayed for two weeks or however long the sprint is. I would usually do all the troubleshooting and testing and basically handover the dev team a solution so that they won't keep delaying simple things for months.
I like the concept but dislike the rigidity. Perhaps it might help if sprints were retroactive, that is you get shit done, create jira,etc... and it will be reviewed as things done in the sprint, instead od micro-managing tasks, set goals like "complete feature X and bugfixes".
Re: I don’t believe in sprints
#275I think the author completely misses the point or never worked in a proper agile team. Imagine running a marathon without mile markers. Sprints are like mile markers they help you know and adjust your velocity and capacity to reach the end goal. Without these sorts of tools you are just running without any sense of achievement or tuning to your teams performance.
Runners don't stop at every marker. Kanban can provide exactly the same information.
Re: I don’t believe in sprints
#276Earlier quoted context omitted.
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/me…
> 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)
Re: I don’t believe in sprints
#277Earlier 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.
As a senior dev I hate this. Of course I'm going to drop everything, if what I do stops making sense on an org level. Why would I do anything else.
Maybe you've never had a project manager whose whims change with the wind, and interrupts the sprint to add yet another high priority bug in the middle that absolutely-needs-attention-right-fing-now... every sprint. Scrum tries to stop that.
Of course, if your project management listens to you and trusts you, you don't have this problem, so I understand your take.
Re: I don’t believe in sprints
#278I'm frankly puzzled how SCRUM sprints are even expected to work with a development + QA cycle. When a sprint starts, what QAs people are expected to do ? When the developers finish, and QAs start testing, what developers are expected to do ? It seems to me that this forced synchronization is just pointless and harmful. Where I work, we handle "sprints" just like checkpoints. This is in developing stage, this is in te…
Your QA specialists work on tickets with developers and write feature tests alongside the feature. If you're doing TDD then QA can work on turning feature requirements and designs into tests for the next iteration. Integration and performance test development and automation happens alongside, often as separate sprint tasks done by QA specialists.
If your QA specialists aren't essentially developers specialising in writing test code then they probably don't belong in a modern development team.
Re: I don’t believe in sprints
#279Earlier quoted context omitted.
That's a good reason why sprints work well so often. They limit the amount of inflation that is possible.
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 team members involved, so their output can be included themselves as deliverables in previous sprints, so that later ones use those completed definition tasks as input.
Re: I don’t believe in sprints
#280The problem that a lot of people get to with Agile/Lean is that the actual practices deviate from the original goals. The powers that be can't actually handle agile in it's truest chaotic form. So it gets bastardised from the top down (and at times from the bottom up as well). Worse still some of the things that are advertised as 'agile' actually violate the principles. The card wall was supposed to be about as light…
> Sprints and pairing become tools to keep devs on a hamster wheel. Always productive, in theory at least.
SCRUM and sprints lend themselves to "hamster-wheel management". That's an abuse, but it stilll gets labeled agile.
Pair programming is amazing. Provided no pair has a total dullard (or worst: two dullards!), pairing with rotation quickly results in every member of the team knowing the whole project, so that any team member can pick up the work of any other team member. It also levels-up the skills of the whole team. Even mediocre devs can become good devs by working side-by-side with someone really good.
On a per-task basis, I'm willing to grant that a pair might have lower velocity than two devs working alone. But the benefits of pairing with rotation for raising the standard of the whole team are striking.
[I'm not saying that all work should be done as pairs; as in everything you have to use common sense.]