I think this is unnecessarily reductive. When your day job is programming and you have strict sprint deadlines you don't have the hour or two it might take to leisurely stroll through manpages. Quickness is a result of industry demand not because it's correct. But that also doesn't make the programmers "hate reading". I have never had a PM/manager/TL/etc budget "documentation reading" into sprint points. I will hazard a guess and say you haven't either. So if you're not reading manpages in your free time Google/ChatGPT/SO/whatever is usually the best option.
Isn't the idea of the sprint there to protect developers from having the priorities shift under their feet every two minutes? It's easier to get work done if you know you can focus on a task for a few weeks and not be forced to context-switch suddenly.
It's all about perception. If I had 2 less story points per sprint then I would get more tasks to fill up those 2 story points. PMs don't like it when the whole day isn't accounted for.
Absolutely anything is better than sprint pointing. This garbage process was adopted from what I can only assume is some cabal of "agile consultants". I have over 10 years in the industry. I cannot estimate something with less than a 20% margin. An estimate requires you to know everything up front, at that moment, for it to be accurate. Anyone who has made software knows this is never the case. The only thing it allows, and what I can assume is the only reason it continues, is because it's a job creation program for "agile certified" project managers and it produces a nice burn down/up chart you can show the manager. Sure, you can call points deadlines, but they are not. It's an arbitrary measurement of a unit of work that in total makes up a two week "deadline". Two weeks isn't enough to produce good code on anything more complicated than a boilerplate application.
Deadlines are far better. Tell me something needs to be done by next month it will be done. I can negotiate inside these bounds to prevent scope creep because a deadline is far more flexible than points. If you find yourself done with deadline work, you can refine and add touch ups. If you find yourself done with pointed work the PM will just assign you more work to "keep your points up" instead of allowing you to do the same.
The tyranny of the agile PM hinges on convoluted point systems. Even the one the writer prescribes. Force the management to actually agree on a deadline that is reasonable (not ship me facebook next week) and watch how productive and accurate developers can actually be. Read the comments here. Agile has been butchered to the point it's unrecognizable. Give me deadlines.
In my experience when people focus too much on sprint deadlines, they miss the purpose of sprints.
Timed sprints exist not for the benefits of managers, but for the benefit of developers. They exist so that the development team has a shield against managers making last-minute decisions and changing priorities without notice.
If the focus and discussion is regularly on short term deadlines, then the developers are not driving the process, the managers are. It means that sprints are seen as a management methodology and not a development methodology. And then everyone has a hard time.
Managers who think this way know they’re not “allowed” to make mid-sprint changes so instead they focus on the end/deadline.
The managers should be spending their energy supporting the team and figuring out what the priorities are for the next sprint(s). If they’re spending their mental energy on deadlines then they’re doing everyone involved a disservice.
When I first started coding professionally, I thought sprints were stupid. We've got a backlog that will easily take us a year to complete. Why bother with organizing them into 2-week sections? Why not just finish a ticket, take the next one off the pile, and start working?
Over time, I learned that time-boxing your work creates short-term goals, a slight sense of urgency, and some accountability. Otherwise, it's easy to just look at the huge lists of tasks and think "Well, I'm expected to take a year to complete all these, and during that time, more work will be added to the pile, so I can just take my time" and become complacent.
That all said, sprint planning is impossible to get perfect, especially with an incompetent manager that fails to recognize patterns in point assignments. Consistent underestimations on the number of points the tasks are can look like people are underperforming. Consistent overestimations look like you have a team of rock stars.
Sprints do give faster feedback, early value and autonomy, but only in contrast with planning the complete project upfront in utter detail and committing to a deadline. It's a compromise. Instead of planning a whole project we just do two weeks and go from there.
Its a nice idea but it often doesn't pan out in practice. The sprint is way too detailed, the team gives too much time and attention to planning the next two weeks and too little to what comes after, often people don't really know what to do when they finish early or don't make the sprint, etc. But most of all, everything becomes this game of predicting the sprint and finishing it rather than solving the most important business problems right now. It becomes a bureaucratic thing (in a bad sense).
For me, two weeks is usually too small of a timeframe to get something really meaningful done, so the sprint goals feels like a collection of random things we stuffed in two weeks. Most people also adhere religiously to the goal of 'achieving the sprint', which pushes the team to planning together in way too much detail. Not achieving the sprint feels like failure and you will get 'punished' if only by disapproval. We should take it as feedback and rejoice in the opportunity to hone our estimation skills, but in reality it functions as a reverse gamification mechanism making devs conservative and risk avoidant.
In an ideal situation, what sprints give you is control over delivery schedules. But this control always comes with a price, and two weeks into the future isn't far enough by far. It's never free to set a hard deadline. So you pay with lower productivity in order to get higher control over schedule.
I think its better to set looser goals, have a course roadmap of things you will be working on, problems you want to solve, but don't fret over 'velocity' and 'story points', just like you are not counting lines of code produced per day. Story points are meaningless, what matters is if you have solved some problem. That is what gives you autonomy, value and feedback, not 'achieving the sprint'. Nobody cares about that.
They're the open office plan of project management. Tech workers have open offices, other professionals don't. I think we're just treated more poorly in some regards. Sprints tend to create lots of of tech debt and they're used for micromanagement. You want to work in 3-6 month projects, not 2 week arbitrary deadlines.
Not sure your average PhD at Microsoft Research or Jane Street would put up with them. Linux Kernel developers don't use them. Mathematicians don't story point conjectures.
But creating CRUD apps for a non-tech enterprise, you might have lots of "sprints" but no software is delivered reliably or high in quality.
You can value planning and deadlines and still not do sprints. The key is that whoever is managing the project, whether it's a dedicated PM or just the lead dev, needs to be fully engaged with the team and understand the work that is being done. Cards (beyond a basic todo list and record of who's doing what), points, sprints, standups, backlogs all of these are symptoms of bad communication and a lack of an overall understanding of the project. Unfortunately, or fortunately if you can put it in to practice, this means that the person leading/managing the team needs to understand software development as well as the current tech and tools being used. There is a place for non-technical managers but it is outside of the software development team where they act as an interface between dev and the other departments or interests in the company.
The bit explaining velocity and sprints is really just a sentence... It may deserve a bit more emphasis. It makes sense to me, but to someone who isn't familiar with it, it is easy to gloss over that part.
And you also don't mention that if a manager wants to know when something is done more frequently than once a week, there's probably something else wrong there. Nobody should really be managing developers hour by hour, you're just going to kill productivity. Are you building a product in the long term, or are you micromanaging every paragraph of text on the web site, etc.
The entire concept of a sprint to me always felt wrong. Development work can't be split up into time slices. And trying to divvy up tasks based on an estimate of how long it'll take to complete each one is just a waste of time.
I remember being in a standup, being told to bump a high-priority task into the next sprint and complete a couple low-priority tasks instead because I already had too many points assigned to me for that sprint and just thinking...really? If I don't complete the second high-priority task before the end of the sprint, so what? I still made progress on it.
It just felt like so much time was being wasted. We estimated the amount of time each task would take, assigned it points based on that, and we'd fill our task list in such a way to try to make the estimation close 40 hours of work. If you had 30 hours worth of tasks assigned to you already, and there was a 20-hour high-priority task in the queue, it'd get bumped to the next sprint with 10 points of low-priority tasks assigned instead. It was more important to them to get precisely an estimated 40 hours of tasks completed, rather than getting supposedly high-priority tasks done.
Obviously, this frequently resulted in priority inversion, not to mention the problems from poor estimations of task time.
Management was often clueless. You only earned the points when you completed the task. So if you took on two 20-hour tasks, and just barely didn't finish the second one before the end of the week, but then completed that plus 40 hours the next week, they'd question why your productivity swings so much because you only got 20 hours done one week, but 60 hours the next!
And of course, as mentioned, these "hours" were all estimated hours, not the actual hours done. People started overestimating the hours needed for tasks, but management was apparently smart enough to catch on to that when they noticed everyone was getting 50-60 hours worth of work done, despite everyone only working about 40 hours per week.
I've rambled a bit, but you get the idea. I think the author is spot on. Just use your task tracker.
the writer assumes that sprints are adopted to help the developers, while in fact its a tool so that product owners track progress in a way to have a shorter feedback cycle than in months.
Of course its more convenient not to worry about sprints and time/points and "just work", and that is usually the case in startups or backend teams where the stakeholders are all always present in the same room, but once you add more layers to the organisation chart it becomes harder to track what everyone is focused on right now and that they are planning to do next without sprints or something similar.
Yes, sprints on paper are what you describe, but in reality, they rarely ensure deliveries or predictability, they even tend to hinder productivity as they narrow the body of work of a whole team. Think about it, after a week, what is usually the distribution of work of your team? For me, it was always very unbalanced, where people where working overtime and others (best case scenario) would be looking for some work to do.
I understand the author's heated post, because I've been there so many times, and I think THIS IS THE POINT of this article, the point that you are missing. Good manager shouldn't rely as much on a set tools that are broken or unfit for their team.
I my opinion, not enough people question Sprints and their viability and benefits. And he's right, backlogs are by far just a list of the things you wont do.
If your tool cannot fix your issues, the manager should. Use post-its, emails, spreadsheet, large whiteboards, hang a TV screen in the room, pdf, discussions... There is endless possibilities, be creative.
> Bob Martin put it best: "Software projects are marathons, and in a marathon you don't want to sprint."
As a both a runner and a developer, I find this quite funny and a bit wrong. The fact that we call them sprints can be a bit wrong or confusing if you put them in a different context, but what I can say is that almost every serious runner will constantly check their laps, be it miles, be it km, you will always look at your watch to see how you performed in your last km and if you are on track.
That's what I see useful in sprints, the fact that you stop for a bit and see where you are, you have the time to discuss things that might have gone wrong and try to fix them before it gets out of hand. But in the end I can understand people who dislike the system, because I've worked with a lot of managers with no technical knowledge trying to manage technical projects.
I feel like the use of metrics is often just a crutch to avoid real management/leadership decisions. Sprints are meaningless overhead unless they are coupled to important deliveries. Often they aren't.
In my real world experience software doesn't get delivered within sprints, it gets delivered when it's ready. And decisions about what to deliver aren't made by the sprint team.
Anyone can pad story points enough to look like a sprint super-hero. The key focus should be what are you building, are you building it the right way, and what can we do to deliver it faster/better. Sometimes the right answer is stop holding meetings, and just get out of the way and let the team focus on the problem without interruption for a while.
The idea referenced in the blog post that sprints are "rushing" developers is just nonsense. At least in every sprint process I've been a part of, the developers are the ones assigning effort (points/hours) to each task. The dev team is free to decide how much padding any task deserves to get the job done right -- and some padding is totally legit and expected.
If you have a large task, one that's either too complex to estimate accurately or with too many unknowns or outside dependencies, you should be breaking it up into smaller tasks.
Developers decide how many points they can do in a sprint, AND they decide how many points each task gets. There's no rushing involved here.
IMO sprints are a barely-adequate substitute for a coherent vision with priorities. In a chaotic (dysfunctional) business environment where things change on a whim, sprints serve as a firewall to provide a few days/weeks of focus.
If everyone on the team is aligned and knows what the priorities are, sprints are rarely needed. When you do sprint, it's reserved for real emergencies. You don't need to play games to carve out time for X because everyone agrees that X needs to get done. Then when X is done, you move onto Y. Serialize. I won't say it's the only way to build software, but this method almost always produces a superior quality product compared to arbitrarily carving up tasks and trying to bin-pack them into sprints.
Sprints are for middle management to keep projects from getting out of hand, they aren't for programmers or programmer freedom. When you understand this simple principal it all makes a lot more sense. It's really no deeper than that. All the stuff grafted on top of that as "support for" is pretty much all feel good fluff and unproven social theory.
I think, if sprints are used to beat dev's into submission, then they suck. But if they are used for the dev's to be able to plan things, they are awesome.
I am not a code monkey. I am not a cog. I like having things I'm going to be working on laid out. I like a road map. If I'm part of the planning, then I love sprints. I get to estimate what I can finish, and work to it (pass or fail)
reply