I don’t believe in sprints(robinrendle.com) |
I don’t believe in sprints(robinrendle.com) |
I absolutely hate useless opinion posts like this. They're incredibly vain. There is zero substance to the authors argument beyond "sprints are inconvenient".
I can only assume the person who wrote this lacks much real world development experience, because anyone who has worked at multiple companies will tell you there is no one size fits all way of doing development. Post like this are pure Dunning-Kruger effect.
This blog post is my love language.
If I personally have to check with someone, each day, to get good work from them, then my preference is to fire that person and hire someone else who I can trust. If I need to check in with a person every day, then I'm micro-managing this person, and I have to wonder why they need to be micro-managed.
This is different from me being available, every day, to help them, when they need some specific help. If they are being blocked by something, they should feel free to reach out to me and ask for my help. But a daily standup assumes that they won't ask for my help when they need it, and therefore I need to force a moment of conversation each day. Again, it is easier to fire such people and hire someone else who I can trust. I'm working in the USA where it is easy to fire people. If I was working in Europe, where it can be difficult to fire someone, then I would instead seek to get people traded away from my team, and I'd see if there were others in the organization that I could get to move to my team.
With senior level software developers I find it is often enough to meet with them on Monday and ask "What will you accomplish this week?" and then chat with them as needed during the week, and then on Friday check in with them and ask "What did you accomplish this week?" If they didn't accomplish what they thought they would during the week, then we can talk about why. With junior level software developers, I usually have to check in with them more often, which is fine. Usually, with each person, I figure out what is the ideal level of support that is needed. Every human being is a unique individual with unique needs, which is why the daily standup is a bad idea. It's important to figure out who is working for you and tailor your support to the needs of that individual.
Direct, honest communication cuts down on the need for rituals and ceremonies such as a daily standup meeting, or grouping work in two week batches.
Often, when I speak to managers of tech teams, they say the main point of two week sprints is to offer transparency to the leadership above them about what progress can be made during those two week sprints. But again, direct, honest communication with the top leadership typically does a better job of explaining what to expect, as well as to explain why something is delayed, if something is delayed.
To the extent that two week sprints serve a mostly political goal, I'd rather address the politics directly. I expect people below to reach out directly when they have something to say, and I do the same to the folks above me.
None of this precludes tracking how much work is being done every week, or every two weeks. If the work is being tracked in a tool such as Jira, it is still possible to add up the number of points that are being done each week. Nothing that I say here suggests that I'm against gathering metrics and trying to improve those metrics. But many of the rituals that are currently advocated for Agile development processes waste time on meetings that could more easily be worked out informally in a series of quick one-on-one conversations -- a style that is actually agile, rather than burdensome and officially Agile.
In general, meetings that waste time should be reduced to a minimum. Conversations that have specific purposes should be encouraged. Large group meetings should be reduced, and one on one meetings should be favored. This style has worked well me over the last 20 years that I've been doing this. As to the details, and nuances, of getting the most from one on one conversations, I develop this theme in my book "One on one meetings are underrated, group meetings waste time."
I’ve worked in sprints. I’ve been a facilitator and an IC and now manager (aside from sprints).
A bad team won’t improve with sprints.
Similarly a good team might not always benefit from sprints.
Almost every team I’ve worked with has improved with iterations and interactions.
The best team I’ve worked with used sprints and communicated with stakeholders well… which in turn spoke true to the agile manifesto.
I want to see the code produced by this non-system; and to learn its longevity, particularly beyond when key early contributors have left. I want to see the applications produced by that code and to learn the size of the teams, departments and companies around the products. This article carries little weight without some of that context.
There's no meat to this article, just a rant about some management style the author doesn't like. The author goes so far as to say that only the managers can fail in software. This sounds unbelievable to me because we're all humans.
Sprints, and points, are not JIRA. Points are not Sprints. Jira is not Scrum. These are all orthogonal tools that can work well together, in my experience. They don't always work well together. If you're doing Scrum well, you'll inspect what's working and what isn't, and change it. It's possible to change so far from Scrum you've moved on from it... but I haven't seen that happen and yet still found it useful in most places I've worked.
People who dislike Scrum often complain that the defenders regularly say "well, you're not doing Scrum if you define it like that". They throw away the whole argument. Scrum that isn't Scrum, isn't scrum. You can't not-do a thing and then claim that thing doesn't work.
< / rant >
I've literally had people say "you're doing agile even if you don't know it!".
You can't nail them down, it's always "oh that works? yeah, that's agile. Oh, that doesn't work? you're not really doing agile".
---
And now let me say, I don't like scrum because it's a shitty way to write software.
There's really only 2 ideas in agile that are useful.
1. iterative development, and
2. evaluate and change
That's it. The rest don't matter and are often actively harmful.
You don't need scrum masters, PO's, sprints, story points, ad nauseum.
Can they be useful? Maybe, it really depends on the scale and needs of what you're building, but I'm going to argue that outside of business analyst, these roles should be developers that take responsibilities. yeah yeah, inb4 "scrum master should be a developer!". Ask yourself this. What is the difference between a tech lead and a scrum master? answer: scrum master is considered a career, tech lead is considered a skilled developer.
The problem is creating these roles puts barriers between people. It prevents developers from developing an understanding of what they're actually doing. None of these roles are useful outside of QA and business analyst, and even the BA role can be done by developers if they have communication skills. All a BA is going to do is ask questions of the business.
Oh, ok. It's a terminology thing. We're actually in agreement. It was very hard to see that from the article because it's only negative.
> The problem is creating these roles puts barriers between people. It prevents developers from developing an understanding of what they're actually doing. None of these roles are useful outside of QA and business analyst, and even the BA role can be done by developers if they have communication skills. All a BA is going to do is ask questions of the business.
Small-a agile prescribes no roles at all, so I can't say whether a BA would be useful or not. Scrum (which is the Big-A Agile I have most experience with) also doesn't define a BA role and broadly agrees with you: get the devs doing that work. It also doesn't make any distinction between "designer", "architect", "copywriter" or "engineer". They're all "developers" in Scrum, as far as I understand it from the course I did, and repeatedly re-reading the guide. Neither agile, nor Scrum talk about story points, JIRA, user stories. Scrum recommends you estimate, so that you can fit things into a sprint (so it can be released), and so you can measure your team's own sense of sizing. Those tools (story points, etc) are extras, often prescribed by businesses that aren't as agile as they'd like to to believe... but can still be useful so long as they're used well. Use them as guides, signals for internal team use, not to share outside the team, not to be held accountable. That's what the planning + review are for. Those are your accountability points.
Honestly, I think the bigger problem with trying to use Scrum is continuous integration. If you're releasing often, faster than your sprint cadence, you're bound to come unstuck with your sprints and they'll feel like a hinderance. I'm not saying "avoid CI", I'm saying "if you use CI, and you should, modify your definitions a bit, find a way of working with the accountability system; share that organisational burden with the wider company".
One problem with agile I've seen is that business priorities often change before work can be completed. You _should_ respond to the changing environment (e.g. new compliance, new customers etc), but it can be very very distracting when you have longer-form projects to complete.
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?
All the ceremonies in the world aren't going to change either of those things.
It's just a rant from someone that thinks they're too good to be managed, probably that kind of engineer that has 10 conflicts a week with everyone in the company because they won't budge on their unfounded personal opinions.
If not, then chances are the team will need some guardrails, that’s what agile and scrum offers. It’s a place to start.
Just because you don’t believe in having a system to break down work doesn’t mean it isn’t useful.
Personally, I’ve seen the alternative in action and it always leads to burnout.
And if the work gets too much then I guess we just work harder to the bone —- because woe us if we should possibly have to grow and delegate, let alone in a scalable, organised and structured way?
You’re the lead of an 8-person team. How do you get everyone rowing in the right direction and shipping software? It sounds like you’d just leave everyone to sort it out themselves and believe they will build the right thing and ship it on time.
I don’t think sprints are a required practice. I’ve used them with teams simply to help shield them from micromanagement and get them used to iteration cycles. They were held up on releasing anything until a huge batch of features was perfect. Only every deploy into production was met with a week or so of overtime fire fighting because the amount of change they were introducing to the production environment was too large and their staging environments were always under provisioned and didn’t have the same load. Sprints helped them break down work instead of crunching for months at a time.
After a while they didn’t need it anymore. So you change things up.
Where it goes wrong I think is when people start copying the practice hoping that following the rituals will grant them good software.
You still need something though. A little planning goes a long way.
His ideal world works for a team of engineers that have no manager, no deadline, no collaboration with other teams, etc.
Basically it works for a personal project. That's it.
Use their crappy tools against them and make sure your projects fail. You’ll be getting another job next year anyway.
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.
"Spirits don’t help organize things, they’re not a useful organizing tool"
"Good teams don’t need spirits to get good work done."
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 discussing what you think that should be done next indeed can create an overhead (even more when the frameworks is abused or done wrong), but epics, stories, sprints and demos provide a more detailed way of communicating and demonstrating progress to whoever it is relevant.
That’s not an optimal way to get work done. It’s metrics.
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.
There are some general guidelines, there is some amount of this that can be taught (not enough to sell a course or certificate), but mostly project management outcomes are dominated by the terms of understanding the domain in detail and the people involved as holistic human beings.
Paul Graham said that the management of hackers for someone who isn’t a hacker can be summed up as “give up”.
Don’t shoot the messenger please, but I agree with pg.
Unpopular? On the contrary, I'd think that position would be popular with us hackers because it's saying what we want to hear, about how special we are. For that reason alone, I'm not sure I buy it.
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".
If you work at a product shop, you might well be able to do without them.
If you build software for clients, the planning is VERY important in order keep the client happy. Knowing ASAP that the project is going to miss a deadline/budget/feature is key to whomever manages the relation with the client.
This is why we do sprints and estimations: to know how the project is going so we can update the client ASAP (or find another solution) when things are off.
There's other ways to show progress and impact. Does it matter how productivity is shown if you can prove the former?
1. Maintain a To Do list for the project.
2. When a developer is available, he/she/it will pick the highest priority task to work on.
3. Use the To Do list when negotiating new features with stake holders. They have to decide where in the priority list the new task is added.
4. Break very large tasks into smaller step by step tasks that can be developed independently.
It’s simple. It works. I have delivered successful projects most of my career using that method. As a single developer and when managing large teams of developers.
> PESSIMISM SOUNDS SMART. Optimism sounds dumb. It’s no wonder, then, that pessimistic messages hit the headlines, and optimistic ones hardly get a middle-page snippet.
If you want a well-reasoned discussion of where the waste is and isn't, I highly recommend Allen Holub's talk #NoEstimates [0].
If your retros are super-negative, then try limiting everyone to one positive and one negative comment/post-it each per retro, and when you discuss the retro comments, talk through the negative ones first and the positive ones last so the retro ends on a positive note. Limiting people to a small number of comments forces people to consider the things that really got in the way rather than raising every little moan they have.
There are lots of different ways of doing retros, and as PM you are ultimately in charge of facilitating a useful retro. If the retro is overly negative then it becomes less useful.
Sprints and standups are degrading tools to enable extremely subpar management to maintain their role.
Tell me why a properly functioning agile shop even needs a manager.
I've worked with two-week and one-week sprints, and generally found them very helpful, but more helpful with better PMs.
But they are not the problem you are trying to solve, just a tool.
I like the concept of false idols in christianity: you must orient yourself toward truth and love (building something good and truthful).
That must be your highest value. Money, prestige, UML charts, Sprints, those are all false idols, they will lead you astray if you worship them.
Only worship truth and love.
like religion, I've seen Agile done poorly (extremely damaging and counter-productive) and done satisfactorily (not harming anyone with some mild benefit). theory is only half the equation, a big part of the equation is methodology and execution.
I agree. Most teams are mediocre though. A lot of processes have the goal to limit risks due to bad teams.
Looks like this Edsger Dijkstra's phrase never gets old :)
It boils down to needing a form of alignment, you can't have team members running around making it up by themselves as they go.
How you achieve alignment and shipping things customers love is irrelevant, just fucking achieve it.
Also helps that companies love to employ clueless people to organize the sprints and those tend to care more for jira to look good, than actual work.
Nevertheless, such small teams (in my experience) use Scrum as well and it is indeed overkill.
FWIW, Scrumban wasn't bad either, and it was way better for us than full Scrum would have been. The reason we switched was because we were basically operating like a Kanban team already, and the sprints were just arbitrary lines in the sand. We regularly had either a) tickets crossing over into multiple sprints or b) sprints we cleared out so fast that we had to start pulling tickets from the next one into the current one. And even after the switch to full Kanban we've kept the few Scrummy stuff that we like, such as biweekly retros.
I rank them as 1) Agile 2) Waterfall 3) Whatever it is this guy wants.
But to be fair, I've worked like this mostly in places that have also enjoyed a continuous deployment way of working, with possibly multiple releases per day. In other places I can kinda see the point for "this is the stuff that needs to go into the next release" kind of sprints, but even then I'm not sure it's an improvement over straight up kanban.
I kinda feel like Ockham's razor would cut the sprint from the ideal work method tbh.
You can’t talk about sprints unless you talk about the sprint demo: It’s the proof that the closed tickets actually represent completed work.
> … they’re designed for mangares who don’t trust their employees (if your manager needs to look at Jira to figure out what work you’ve done for your review or what’s shipped lately then they’re not paying enough attention to the team).
That’s one take, but managers are just as likely as anyone else to B.S. their way through the tickets: “oh yeah that’s pretty much done”. The sprint demo clarifies what “pretty much” means.
> … When you’re on [an efficient team]… then it’s easy to see how everyone else mistakes the bureaucracy around the work for the work itself.
This is extremely true, and probably the main failing of any project management method.
> … the backlogs, the sprints, the points—is pure bureaucracy. It gets in the way of productive folks…
Again, we can’t talk about the sprint unless we talk about the sprint retrospective: It’s there to help the team identify tools and processes that are inefficient, and adjust incrementally through automation, elimination, or modification. One of the things that might get eliminated is the fixed interval sprint. Or replacing relative-size estimation techniques (“story points”) with something more rigorous.
That “sprints” are used mindlessly is frequently true, but we should not dismiss them mindlessly either.
This is the fundamental reason why sprints exist.
If you exist in an environment where all team members are highly motivated, consistent, diligent, and pulling in the same direction then yes, sprints are a distraction, but it is my experience that teams that are genuinely like that are rare as hen's teeth.
For myself, I'm the most productive when I
- Am able to influence what I work on, and choose how I solve a task
- Have tasks lined up in a front of me that I can choose to work on
- Am in a state of flow, where the tasks in front of me roughly corresponds to my skills.
In other words - to me - a good project manager makes sure that there are plans for what to work on next and that the tasks roughly corresponds with the teams strengths.
Now, that roughly corresponds with good "backlog grooming", but not sprints.
Basically, I think Kanban works much better.
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 testing, this is done. It's expected that almost everything spans more sprints.
There is an argument that you can always add features to the sprint, so you start small and then extend sprint with additional task. But it does not work, because tasks seem to take all the time that was planned for them.
However, the rituals of SCRUM like retros and groomings taking place every 2-3 weeks is a good thing. It's like hygiene.
If your QA specialists aren't essentially developers specialising in writing test code then they probably don't belong in a modern development team.
Dedicated QA folk are redundant! The devs write automated tests for all the code they submit. It's 20 years since I spotted a dedicated QA person in the wild.
Anyway, the same happens for any multi-phase cycle. Like with code review. When there are dependencies between people, you are going to need extra items to work on while waiting, and this fights with the requirement that everything should be done at the end of the SCRUM sprint.
shift-left (aka put all of the work on the developer)
Each tool should be evaluated (and periodically re-evaluated) to see what its 'leverage factor' is for your situation. For every unit you put into it (time, effort, money) how much do you get out of it? The best tools give you a 10x or better leverage factor. If a tool gets in the way (i.e. it has a 1x or lower leverage factor) then it should be ignored.
Some tools are just bad (they take more time and effort to learn and to use than they save you) and are generally weeded out. Some are great for certain situations but bad for others.
If sprints (or any other tool) are not helping you and your team, then try to figure out why. Is the tool just not a great fit for our situation (e.g. using a hammer to try and fix a car engine)? Are we using it wrong? Is there something better?
Too many companies and managers go for the 'one size fits all' approach. "This worked at my last company so it must work here too!"
Related to this is that sprints and their associated concepts mechanize and formalize something that may or may not need such. Applying something like Scrum almost always has one engaged in motions that are disconnected or even counter-productive to the local environment. That said, it sure is a lot easier to pick a methodology off the shelf than it is to engage in sober, thoughtful, and rational assessment of your situation's organizational needs. There's also risk inherent in that too, but one effective counter to that is to incrementally add/subtract process as needed.
Given the above, I consider process-heavy management to be a signal for prospective employment -- on the very much negative side. It tells me a few things, mainly about the way management's group mind works and also about what my future role in such a group would be (i.e., more part of organizational machinery than a creative agent).
The last point I'll make is that I just find the experience needlessly draining. A job typically lasts years. It's more of a marathon than a sprint. If it was a marathon with a few necessary sprinting periods, that might be bearable. If you really are sprinting constantly (the next sprint starting immediately after one concludes), that's a good way to generate burnout.
But a bad management style would still trump this.
I see them like CPU cycles, but for a team. They are a heartbeat keeping team members in sync. It's all about answering what's my next task when I'm done with the current one. If you I work alone, or in a very small team, with no external stakeholder, then I can answer that "just in time" and don't need cycles.
But if I work in a larger team and/or with external stakeholders, then it's not practical to do this "just in time", gathering everyone to decide what should be the next task, every time a team member completes a task. In that case, we need to batch the planning work. That's what cycles are for.
I agree with the author that too often the process feels unnecessarily bureaucratic, and I really dislike the "sprint" terminology, but I wouldn't throw the baby out with the bathwater. Cycles still have a purpose.
Agree. Actually, my first experience with Agile used the term "iteration" instead of "sprint" which I thought made much more sense. Everywhere else I've been has used the word "sprint". I suppose a "sprint" does includes three parts: start, run, stop; parallel to an iteration of the development cycle: branch, develop, reintegrate.
My paranoid, anti-management brain still thinks the fact that sprint for most people is associated primarily with speed rather than starting/stopping is a feature, not a bug. In this case idea of always being in a "sprint" is inherently stupid and insulting.
Anyway, another word to file alongside "grooming" for Agile words with unpleasant associations.
There are some great, as in large, problems with software development, as a result of having multiple parts developed by different groups, or even by one person at different times. The parts have to work together.
It is easy, and I have seen this happen in multi-million dollars companies (plural) for groups to go off, develop their parts and for the parts not to work together. Boom. A sprint is designed to ensure that detecting this failure happens early rather than late.
Can you have a sprint that does not help this situation? Yes. And if you do then the sprint is just foofaraw.
The other problem is that it is easy and somewhat natural to write 90% of the code. Which does nothing. 90% of the code is meaningless. What works is the issue. No one needs or wants code. They need or want functionality. I have written some really really cool code that does nothing. It was 90% of something, but unfortunately had to be rewritten in order to be functional.
The second use of a sprint is to show functionality. A sprint to have 92% code completed is nothing. Can you show (to me or yourself) that 90% of the functionality is there? The difference between 90% of the backend API's being functional (and being able to prove it) and 90% of the backend code being written is monumental.
There is a final use of sprints. As a manager you can appear to know what you are doing by organizing sprints, when in reality you have no clue whatsoever as to what you are doing.
If you want to be a good programmer, you will use sprints with yourself. I'm a sole developer and when I use sprints by myself I am much more productive. Much. [updated for spelling and clarity]
In an even earlier job, I saw an overzealous 'scrum master' certified engineering director trying to ticketify everything with Kanban boards and burndown charts etc. Engineering teams under them hated it. It was the least productive period for a division of 100+ engineers I ever saw.
Moral of the story: methodology matters a lot less than culture and talent.
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 a representation of ongoing work as you could get and facilitate the interactions with the teams. Unfortunately, tools like Jira change this to be an over-engineered process and tool (which violates point one of the manifesto). Remote work has not made this better.
Sprints and pairing become tools to keep devs on a hamster wheel. Always productive, in theory at least.
Leaving this to the side, I've seen sprints done well and badly. More often than not teams can't manage to point cards effectively. I've had a couple of teams where things just end up in a middle ground constantly (everything is a 3). The exercise of comparing this card to some previous representative card is too hard (and is itself prone to problems).
Retrospectives, can be a useful tool, or they can be a back patting exercise. Showcases without a customer in sight (put your hand up if you're the "customer proxy").
Having said that, some of the behaviours can be really useful. Breaking down overly complex cards as a part of planning helps define the work. There are other opportunities to do this, but backlog grooming / planning sessions are one place.
Having the team discuss cards and talk about complexity often reveals unknowns. I've seen a bunch of examples where things will be caught because of a dev/designer/product manager can see something that wouldn't have been identified if someone just started working on it.
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.]
It gets abused though far too often not just as a tool to upskill team members but also as a way to 'keep them honest'. The always on, always teaching/learning is exhausting. The constant social interaction is grueling, and I'm an ambivert (ENTP-A E=51%). I pity the actual introverts.
I've discovered, years later, that I much prefer to be alone with my thoughts when programming. Not sure I'll ever go back to an open plan office either.
I would argue the word phrase 'software development' should replace 'agile' in that sentence.
I liken it to boiling water. It's messy and chaotic. You'll eventually reach the goal, but until that happens you must be comfortable with a bit of chaos. Attempting to remove the chaos from software dev is like trying to tell mozart not to practice. You'll never get out of it what you think you will.
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.
Basecamp’s “shape up” method is a nice way to coordinate work when everyone has their own todo list.
I think the biggest game changer is the notion of using the "appetite" (number of weeks per cycle) to drive the design of the solution. This is opposed to the usual approach of coming up with a solution and then estimating the points/time it will take to do each part of the project. SE's are bad estimators and the product manager rarely uses time as a design constraint. This is why most projects run past their deadlines IMO.
Most of the time with the articles, the answer to "X done poorly" is to switch to "Y done well" but doing X well would have likely worked too.
Personally, my most enjoyable job as an engineer was when I worked on a project by myself in 1 week sprints. I spoke to my manager twice a week: 15-30 minutes Monday morning for "sprint kickoff" and 15-30 minutes Friday afternoon for "sprint wrap up" and how I spend the rest of the week was up to me. When a second more senior engineer joined the project it was even more enjoyable to work on it together in the same sprint format.
Having a great manager also helps a lot!
Sprints ARE a tool used for planning, but not just by managers. A team can use their historic sprint data to PUSH BACK against their managers and say "No, we won't get this done in time. Now go away and fix your plans.".
Other people mentioned this is a bad strawman...that's an understatement. But I think that's what the author wanted.
It's easy if there are only maybe 2-5 people involved, objectives are clear and not conflicting.
Usually though, you can't afford to implement every idea you have, you need to maintain old stuff while also making new stuff, teams have non trivial dependencies on each other's work, and time predictions are nebulous at best. Also software managers are generally software engineers first, not managers.
Is sprint good at these things? I don't think so (though I never managed a team with sprints, only saw other teams do it badly). But is there a better blueprint? I'm not sure either. It's a hard problem, and hearing about what doesn't work isn't so insightful.
Sprint.
I do not want to rush through the work and squeeze into arbitrary time period but do it properly in the timeframe necessary (and not more). The hastle and rush atmosphere surrounding this word is repelling to me. As well as the 'stand-up'. Are we on exam in the school or what? Not being adult coworkers but people in entertainment or support group to present to each other?
In other hand a flexible communication and progress tracking system - especially in a fairly unpredictible business like making a novelty product - is essential in teamwork and I know no better than something like this. But this childish naming makes me suspicious about the intention and goal of those coined it...
That said, they aren’t magical. They are often misused. Not every team and every project needs them or is faced with any of the problems sprints set out to solve. And there are lots of ways to build good software.
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 that is the tradeoff. Plus: people actually seldomly take the optimum routes in the first place.
Nobody has to like it, this is probably not the best method and maybe it's not even good. But the author misses the point completely.
Run into a blocker? Too bad, should have seen it coming during our scrum meetings and follow-up refinements.
We engineers had two business analysts, a scrum master, and two managers that resided "above" us in rank all working to keep the "flow" of the sprints alive to help ensure we meet our deadlines.
It was the most stressful tech job/environment I've ever been part of and everything was micro-managed by said 5 people to the point that they were blockers to our progress - scheduling multiple meetings everyday that would easily consume 3-4 hours.
Our backlog would grow everyday as everyone scrambled to finish tasks and our architecture was a patch-work of systems that only one person truly understood because he had been with the company since it's inception.
I was hired as a senior engineer along with three other mid-level engineers - all three quit within four months. I left after six.
Sprints/agile/scrums are generally a good thing IF and ONLY IF you have a capable manager/scrum master leading and organizing the team who truly understands time management and finnicky nature of software development. Otherwise, it quickly falls off the rails and leads to churn and burn.
One of the things that usually happen when they push and push and push for some feature to get rolled out in the next quarter is that it often turns out to be a gigantic flop. Engineers are forced to spend hours they can't get back at the whim of management for something that was a complete and utter failure. I could imagine few things more demoralizing than this.
Agile is really meant to be about self organizing teams that take ownership of their own work and deliveries. The scrum master and product owner are just there to facilitate that.
When a team hits a blocker on a tight schedule -- particularly across third party teams, it's up to the management to figure out a solution -- even if it means gasp delaying the release by one sprint.
To avoid this scenario, it takes really dedicated project managers, product owners and lead developers, and not everyone has those...
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?
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.
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.
I guess, I'm asking, is there something specific about agile that makes a subpar team worse?
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.
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.
It is true though that springs bring in their own problems. For instance I worked on one project with two week sprints where it took a 2-3 day batch job to generate a database/a.i. model. This had a bit of Gannt chart character in that it had to be managed in terms of calendar time instead of punchclock time. If you didn't start the database build early enough you would predictably blow the sprint.
At the same place there were a few different teams with their own sprint schedules and the system was able to turn a 1 day delay into a 4 week delay as one blown sprint caused another blown sprint.
Another problem is how you organize work that has a pipeline structure. Is a tester expected to test work in the same sprint it is being developed in? What does a developer do when a feature is under test?
What really kills teams is a lack of trust. With the six month build cycle you can put off conflicts that a sprint cycle forces you to confront every two weeks. I think sprints are popular with some because it gives developers some space to be inflexible, but it is harmful for the business. Sometimes there is a feature the business needs right now and it could have it right now if you add 2 days to the sprint.
Unwillingness to modulate the length of a sprint is one of the strongest "cargo cult" indicators in my exposure to Agile/Scrum.
You can just ship 2 days into the next sprint if you need to. You don't have to only ship at the end.
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.
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.
Scrum even has a ceremony for fixing this: backlog refinement.
I have yet to find a startup that successfully launched using agile. I am sure there are examples, but most seem to be focused on the true goal of software development: releasing features to production.
Tell management every project will take a month, and meet that expectation, then management will be happy.
While someone else who takes the same work and says it’ll take one week then is consistently 2 days late will be viewed as less effective.
So, by squeezing people into a guaranteed timeframe, in a mini death march aka sprint, you are forcing people to make [very] conservative estimates.
For larger companies this might be preferred, but I would argue, smaller companies should try to move faster.
My experience is that once developers make conservative estimates they are ignored because business side of things would rather prefer to imagine they'll get the system completed this decade, not when estimates show. So instead of working according to estimates everybody is crunching and cutting corners and project gets delivered in some useful form in less than a year.
"Oh, yeah, the rewrite will be done in 1yr, no worries"
One year passes, and you haven't started!
Let’s boil this down to first principles. Nothing about building software, especially innovative software is predictable.
I mean, think about the software you use. Of all the shops that produce that software, which ones do you trust more than others? I'd be willing to be it's the ones that delivery predictably. At the very least the ones that deliver updates reliably - as in they do what they say.
Granted, every industry is different and some rely on trust and predictability more than others. Building an organization that is good at that is very difficult - and that cost has to come from somewhere doesn't it? In my experience it's at the cost of time spent building the product. A tradeoff between reliability and quality, if you will.
This is basically exactly the point. It's incredibly difficult to predict building 'large software'. So, lets try a few things to help make it a little bit more predictable by trying to predict smaller increments.
> Why do we need predictable deliveries?
Say I'm building a piece of software - maybe an app the audience would use - for the Superbowl. It's very handy to be able to estimate our progress to see if we'll actually land that date. The Superbowl isn't going to move because of our app, and our app isn't very useful the month after the Superbowl.
Who will hold their breath? Who would invest in this? Software needs to be used by people. Software deliveries that cannot be estimated cannot be relied upon for planning. It may as well never be announced!
Why do we need predictable deliveries? Because if Bobby from accounting doesn't have your piece of software ready by the 31st of November the company will be slapped by a fine from the IRS so large that you'll need to update your CV alongside all your colleagues from the now bankrupt company you used to work for.
Because your organisation answers to shareholders on a quarterly basis.
Good quality planing, good quality execution will make a delivery predictable regadless of the projecy management style and how we break down a big task into smaller bits. If the breakdow is carried out badly or the big picture is formed carelessly then the chain of sprint breakdowns will also deliver rubish!
If one lives on and focuses on atomic deliveries only and cares no other then I agree.
But that is rarely a product, sometimes not even a feature.
Also complexity (symphony of small tasks) has to live somewhere and unpredictability of the big project will not go away with week based planning cycles.
But I too know better actually. : ) Except probably all the others if everything is done with suitable care and attention.
From some hard-won experience working with a variety of different teams, I have unfortunately found that good quality planning and execution are far harder to attain than you perhaps imagine. Some of these articles seem to paint software developers as magically perfect beings, with managers being pulled straight from Dilbert. The reality is far more complex. Sometimes one of the people on the team is being an asshat and hoarding knowledge. Sometimes they have overly-strong opinions on languages and frameworks that they're super familiar with, or go to the other extreme and work on only bleeding edge ones that were posted on Hacker News.
I strongly suspect that Agile is used at companies because it's a mildly effective way of curbing these dysfunctions in a team. If you spend time and money hiring the perfect team, then you probably won't need Agile. Think of a situation you do find somewhat commonly where you often have hackers smoothly churning out work with a team they selected perfectly for – early-stage startups. Good early-stage startups are often very picky about who they bring onboard, because an unproductive hire can literally cost you the company. It's possible to reproduce that on a team, but imagine telling your next boss at a run-of-the-mill that you're going to hire slowly over 18 months and very selectively.
[1] - https://theanarchistlibrary.org/library/david-graeber-on-the...
[2] - https://bullshit.ist/bullshit-jobs-how-our-modern-bureaucrac...
Sure, if you have a team that can do all the above without sprints, that's great. But I bet they have some other method or social structure that makes team management effective. Most software teams do not have that without some type of formalized structure, especially when new devs rotate into the team.
So, I say stop criticizing the concept of a sprint and start holding your manager accountable for proper communication, effective knowledge sharing and realistic issue tracking. You wouldn't accept crap code, don't accept crap management. Do this and your sprints will add value (and the meeting will be shorter too!).
The real problem, of course, is the word "sprint", which (whether you like it or not) implies something.
A sprint, be definition, is unsustainable.
It's Pythonic levels of hilarity that we adopted this word to describe software development. It's Shakepearean in the tragedy that so many defend it.
Choose another word, like, "jog", "amble" or similar, and you won't see the same level of backlash against it.
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.
Many folks may be unproductive with one management style yet thrive in another.
We don't do sprints. We don't do Scrum. We don't do story points. We have predictable, reliable software delivery on multiple products with an ever growing product development team of 65 people. It's all about measurement and mindful planning.
We are strict about structuring epics vs. stories vs. tasks, and make the largest deliverable an epic. Epics set the scope of what we want to achieve. Then we describe user behaviors / experience we want to enable in terms of stories. The engineering, deployment, and design activities needed to enable those behaviors / UX are structured as tasks.
We say when we want to be done with the epic and try to determine if the scope we have outlined for the epic is reasonable given the self-imposed deadline. Then we measure the growth of tasks in epics week to week. Tasks are expected to grow fast in the first 20% of a project and then start to taper off as more and more of the engineering takes shape.
If we're not following that curve, we hold a retro. If we add stories or change the scope of the epic, we hold a retro. We adjust scope downwards or we change the estimate. We communicate the changes to estimates out to customer-facing teams early in these cases.
The last large-scope new feature we built on our product was scheduled to take 4 months. They were behind by less than 2 weeks, and half the team were rookies. Oh, and no-one was asked to burn the candle at both ends to get us there. No saturdays. No 10pm conference calls between engineering managers and the dev team.
There are better ways to do reliable, predictable software planning than sprints.
For me the biggest problem with sprints is that they force a continuous flow into discrete boxes. An extreme example I've seen was when as a mid-level developer I was told not to pick up any new tasks, because everything we start needs to be finished by the end of the sprint, and if I start a new task now, testers won't be able to complete it before the end of the sprint.
Of course it was an abuse of the concept, but I hope you see the point - we shouldn't try to start every sprint with an empty board, because software development is continuous, and the fear of tasks "spilling" to next sprint, which I've seen multiple times, is just ridiculous.
To the author:
You don't like sprints or backlogs? Okay. So what's the alternative?
Take step back, think about the problem that agile tries to provide solutions for. Now start thinking about new solutions .. spend some time; then write an essay that makes a difference.
Scrum has sprints. And Scrum is all about solving management problems not developer problems.
You can just drop sprints without replacing them with anything.
Developers aren't the only part of a product team.
You can't just drop sprints without failing to meet other objectives.
1. Part of the charm of Agile is that the devs set their own workload. That sounds empowering, but they can become like their own hyper-tyrannical manager, setting themselves unachievable workloads; that is, they become a proxy for bad management.
2. Managers can easily screw it up. For example, by wedging all projects into the same daily scrum, which then drags on for an hour; by participating in the scrum AT ALL, if they aren't doing dev work (they're supposed to be observers); by changing tasks mid-sprint, etc.
TBH I think the term 'agile' should be shunned. It's become a marketing buzzword, and has almost completely detached itself from the Agile Manifesto. If I were farming-out some dev work, and the proposal included something like "We use agile methodologies", that would raise a red flag for me.
Apparently it's a team who can remember everything they discuss and plan between themselves.
What is important however is some type of shared vision or general plan. Not all teams are lucky enough to even have that. Some people treat their job as a job. Some people treat their job as their life's mission. Much of this definition gets lost in translation in the middle.
In theory a team full of product-minded engineers / self-managing individuals don't need much to be impactful because they will know where to add value and make progress while being looped into the industry/customers.
As an engineer and an engineering manager I have worked in strictly controlled water fall, "no process", well structured sprints, kanban, and scrumban. They all have their pros and their cons, their costs and their benefits. It's a question of what works for the team.
Personally, I developed a preference for scrum style sprints as both an engineer and as a manager, because I prefer to work collaboratively where everyone knows what everyone else is working on and everyone gets a chance to have a say. Sprints with a heavy planning component work very well for that. But that's just my preference.
Teams should decide what method they're going to use and commit to making it work. They should also be open to recognizing when it isn't working for one reason or another and be willing to try something different occasionally.
The only piece of process I will always insist on is some sort of regular check in where we can introspect about the process and determine what aspects of it are and aren't working.
But the backlog is useful. I find it amazing how what seems like a great idea when I think of it looks utterly pointless when I see it still on the backlog 3 months later. It's a useful tool to deal with our tendency to fall in love with our ideas.
They're a holding pen for ideas. The good ideas get implemented immediately, the bad ones get deleted. And there's a huge middle ground of "yeah, I guess we could do that, but it's not urgent and there's other stuff to do first" that lasts forever.
Without agile ceremonies, the quality of tickets can really vary depending on who is writing them. I think there's something to be said for a group of devs looking at a task and deciding if there is a clear AC and discussing how difficult that task is. Without these sorts of ceremonies you can get into situations where you work at a task for days, put the PR up and then get told "Oh we probably shouldn't do this". This has happened to me multiple times at my current and last job.
I also think that for certain types of people, the model of committing to a certain number of tickets for a certain block of time makes it easier to structure and plan that time. Certainly it does for me.
Assuming the originator of the concept of a sprint is Scrum (and it's a big assumption; normally I'd check, but I am lazy and somebody is clearly wrong on the internet), then the purposes of sprints are:
- to set a regular cadence/rhythm to work, and to set up periodic checkpoints for inspection of the done product and adaptation of the work that follows
- within a sprint, to produce a done increment that brings the team closer to the product
- by the end of the sprint, to allow stakeholders to inspect the done increment, to observe if anything is being done wrong or in the wrong order, to collect the feedback, and adjust, if necessary, the plans against the reality
- and then to repeat the same over the next iteration, and the next, and the nextThis is all hard to do IMO if there's one running backlog.
The benefits of sprints I see is they're a useful time container for planning purposes. Eg:
- we can allocate larger pieces of work to upcoming sprints. This is done very loosely just to get some idea of what we can take on, and when
- we can allocate a fraction of each sprint to tech debt or platform improvements etc
- set a goal for each sprint which is some observable step forward. This has taken practice to break down the work into appropriate chunks which can be verified done
- record velocity across sprints just so we have a rough idea of what we can get done in a sprint (it will vary of course)
Yes, there is overhead from the planning meetings. But this helps all of us get involved with incoming work, which I think is better than tasks coming from nowhere without context.
I think the right methodology depends on the context of the business. If product teams need to work together towards something, or if there are competing project priorities, then sprints can help protect focus and provide finer structure than just "Q4".
Anyway, with a QA function, you need some kind of release cycle. I don't believe in prescriptive sprints where either developers are stressed to hit an arbitrary end of cycle deadline or developers sit on their hands because the phase of the sprint dictates no new work (which I've heard of happening in some particularly agile-diseased companies). I think a reasonably regular cycle that aims to ship what's ready fairly often is a good middle ground that keeps quality high, keeps the product evolving, and maximizes developer keyboard time (and of course you also need the ability to hotfix production occasionally.)
The only thing that comes close is "every efficient and productive team I’ve worked on has ignored the concept of sprints altogether".
Okay, but why don't do scrum meetings, pointing, retros, or keeping Jira up to date, work. There's nothing in the article to address that.
Great teams do not need additional processes to deliver value and they usually are more of an obstacle. Clear goals and a vision are much more important, as well as having an environment where the decision makers are the one implementing the solution.
The best class was a beginner's C class, and I was eminently suitable to teach it, because I was a beginner C programmer myself /s. By week 3, they were well ahead of me.
It's evidently possible to deliberately build a great team; but I have no idea how that's done. I don't know much about recruitment, and I certainly don't know how you can bring together a team like that C class.
My solution to this is waterfall, and charging for a rigorous requirements analysis process up front, which I, in turn, estimate the cost of by having the client submit their requirements (as they know them so far) in detail in writing up front.
I've been surprised in (the practical version of) agile how often time is wasted revising the same feature 5x that could have been done once if a modicum of time and thought was put into business and technical requirements.
I am however a believer that people do things for a reason, it does probably have advantages for R&D or inside technical product companies.
Note it's not useful in all (most?) scenarios or in all stages of a product's development.
When you are in support mode for a product that's stable, standing up something from scratch, working on a POC or experimenting with frameworks or libraries - it's not useful, use kanban or something else.
But when you are working on a/b tests or adding features to an existing product it's extremely useful.
When done correctly: You get a two-way promise between leadership and a dev team. The dev team commits to getting stuff done within that <sprint-length> time - therefore they must carefully decompose work where that makes sense. Leadership commits to LEAVING THE DEV TEAM ALONE for that <sprint-length> time - no priority changes, no "Product Manager Chad had a dream if we implement X we get 1000% more revenue!", none of that nonsense. This means for bigger efforts, you get <sprint-length> chunks of working code "done" at time. This in practice means the devs drive how much they can get done in a certain amount of time - if a PM wants an earlier date out the door, that's <x> fewer sprints of decomposed work that gets done.
The tricky thing here is the use of the term "correctly" above. Sprint-based methodology isn't a tool for management to dictate or predict performance and it's not a tool to micromanage tasking. If leadership DOES have this distorted view of it, then it is useless overhead to no benefit for anybody.
It's also not useful at all if only the dev teams practice it - everybody has to respect the commitments required to do sprint correctly - if they don't, use kanban or something else.
I disagree. There are, in fact, crappy teams. You might argue that it's a crappy manager that either allows that team to continue in its current form, or simply doesn't recognize that the team is crappy, and does nothing, but... there are crappy teams. There are combinations of personalities and skills that are simply not suited to solving the problem at hand, and nothing short of removing actual people and replacing them with different people will 'fix' anything. Again, you can say that's down to management, but it feels like a word game. The team itself is 'crappy' for the goals at hand - management/owners (crappy or not) need to recognize and fix that.
For instance:
> (...) they’re designed for managers who don’t trust their employees (if your manager needs to look at Jira to figure out what work you’ve done for your review or what’s shipped lately then they’re not paying enough attention to the team).
I disagree. Visibility and documentation of work are important for having everyone working in a project on the same page in an efficient manner, and definitely not a sign of lack of trust on the team.
From checking the author's information I found that he's a "writer and web designer". So maybe he comes from a different background that led him to develop this pessimistic views on scrum.
I'm personally more attracted to Kanban than to Scrum, even so I can see value in Scrum when run in a disciplined manner.
Sprints et al have been a mixbag for me, but the last 7 yrs (current team) have been plain utter BS. All the ceremonies too, retros are nothing but waste, because they only serve to praise undeserved credit with no product to show for most of that time period.
I credit the OP for his courage to raise his voice to shame those/any bullshitters behind the Agile movement.
That big new product is still going to take three months to deliver, regardless of sprints, but you don't get to pull the team off working on it for some new idea until next sprint.
No, they're a tool to get the illusion of more predictable deliveries. As always, comforting lies are more welcome than harsh truths.
> ...probably not the best method and maybe it's not even good
It doesn't sound like you believe in sprints either, but can't imagine something better.
Other than that, I fully agree that Kanban is a great middle ground, as it’s low overhead and focuses on prioritization and flexibility rather than planning and burndown charts and whatnot.
I’ve felt the opposite. My team switched from “Scrum” to “Kamban”. Then after a few months the sensation of having an endless pile of cards, without a time frame, felt overwhelming.
In the other hand, having a short lived cycle used to help me manage my time. If for any reason one day I was not able to accomplish much, I knew I still had a few more days to compensate. The same was true for the opposite, I could be really productive a few days and then I could relax for the rest of the sprint.
That workflow really worked for me. With Kanaban I feel the pressure to always be “productive”, because I don’t have a clear reference on how “relaxed” I’m (or not), during the week or month.
Maybe I just need to find a different reference. I guess my point is that sprints don’t necessarily mean pressure for everyone.
It doesn't matter if you have sprints of kanban, if there is a deadline is project managers need to do the same work to verify things are progressing fast enough for the release. This work is estimating how much time remains, and if there isn't plenty take action. The plenty part is where most management goes wrong: they want everything done on time, but the only way to get that is have everything done early. That in turns means you need to have at least 20% (the higher the better) of the things planned for your deadline things that you are willing do allow to slip to the next release. Of course working against that is the human tendency to polish things until the last minute, but that shouldn't be managed by the deadline (even though it often is)
I'm against the web release early and often model - don't make your users your beta testers. I'm in favor of spending several months of test after the branch to ensure everything is stable even though this is a lot more expensive. I do agree with the web have automated tests for everything model, I just don't think automated tests alone are enough quality control - automated tests ensure that everything you can think of didn't go wrong, manual testing is about noticing things you didn't think of. (you will note I work in an area where my code can kill people)
It worked really well for a team that served a lot of different stakeholders and also had to field requests from customers since the priority of the work was always changing even if the deadlines for the work didn't.
Also all the sprint planning and retrospective took basically 30% of our time.
Managers are pushed to produce reports to prove they're managing. Reports require metrics, and that's a lot of where all this rubbish starts. The solution in my experience is to keep teams small enough that you don't need those sorts of layers of management (though the opposite is inevitable in larger companies).
My team lead spends more time prepping tasks with the PM prior to sprint planning, but even then it's about 5%.
My last company, we had one-week sprints, but we didn't do official retros, so it was still 2.5%, one hour of planning for 40 hours of work.
"Oh, you can do it like THAT?! I was not aware. I'll take a shot at implementing the feature using that approach."
Producing effort estimates is one of the many approaches to start talking about a task, and not doing it may mean that somebody else's better idea on how to tackle it gets ignored.
Having sprints is a good way to coax people in fully finishing things, it is often needed as many developers tend to jump to the next shiny.
If any of these three things gets used by a bad manager to get fake importance, to put pressure, push people down instead of pulling them up... then get rid of that manager.
So sprints are also good way to coax people into cutting scope instead of working till it is "perfect". Then pushing back on management to have breathing space and accepting changes only after sprint ends and not when they have a brilliant idea.
Sprints and ceremonies create touch points for business people to interact with dev team instead of constantly breathing on their neck or coming up with ideas. Business using JIRA and writing stories/tickets should make sure there is enough context in these so your tickets are living documentation "who,why,where".
It's just a 5 letter word, it's not that difficult.
Additionally, despite the attempt at predictability, wider project management was lacking, which lead to cross-team long running projects running over by 100-200%.
Often this was failure to capture actual requirements, making generous assumptions that a vendor would provide a magic bullet, allocating little to know time for integration / cross team work, etc.
Each team worked on the tickets in their sprint, from their backlog, according to what product management wanted. The fact that none of it tied together at the end was not devs fault if you want to institute such a tunnel vision process on them.
Teach the developers who estimate them to treat the process as the circle circumvent instead of the diameter and multiple by Pi. There you go - done.
*most of the times we use a lot less
So we have 2h of meetings in the first weeks, 2.5h of meetings in the second week if you do a two-week sprint as we do. the rest of the meetings is rather "working together" than having "meetings". If you have much more hours in meetings than this (which can be attributed to scrum) you're simply doing it wrong.
Productive teams are primarily hackers solving larger problems. This stuff gets in the way, causing the team to morph into developers instead.
This is a weird take.
Problems arise when those leaders are unaccountable to the people that they represent, you need to have very strong customs and procedures in place that allow you to immediately recall the leader and replace them if they start acting in their own interest rather than the group's. This also requires the group to have good knowledge of what the leader is doing, transparency and a public record of the actions taken by the leader.
The only solution I see is to set up systems that make power accumulation more difficult coupled with a constant struggle to rebalance when it inevitably lopsided.
My long term pet theory (like, next 10-30 years) is: we have this cohort of "kids" growing up now in an environment where there's plenty of money to be made in non-traditional independent ventures; think YouTube, Etsy, Fiverr, or even professional consulting. Not millions for everyone, but a stable living. The internet unlocked this; it just took a couple decades for it to really blossom. Synthesize that trend with the growing "r/antiwork" "end stage capitalism" "quiet quitting" mindset that many people millennial and younger hold. Then you consider declining western populations. I think there's real potential that traditionally structured top-down companies will face challenges competing for talent in the coming decades; and we'll see an increasing trend of peer-driven organizations (you can think of this like worker owned or highly unionized shops, but its less about the ownership structure and more about the power structure and incentive/responsibility culture).
Taxis and food delivery are two domains that are worse for workers now than they were before.
It works for tech workers because they can just go somewhere else in a desperate market.
I believe most content creators are by and large submitted to the market, just a different one.
On top of this mall the jobs you mentioned are not for the crowd.
Yeah, so maybe it would be better if "hackers" simply start working alongside the rest of society, and give up trying to force misplaced and awkward hippie ideals into their planning meeting, that makes their work completely incompatible with the rest of the organisation, and society?
The most boring choice would be "section", and boring might be good here.
We could borrow from military strategy, not for the first time, and call it a "maneuver". More sporty, and pointing to the repeating nature, would be "round".
I wish the word "sprint" could be used for "this will call for an unsustainable amount of effort. we will be calling in dinner a few times. this isn't normal, and can't be normal, and everyone gets to rest after, but it's something we have to do".
Instead it's just a way of saying two weeks.
Orienteering, perhaps: https://en.wikipedia.org/wiki/Orienteering
I like the idea of thinking of software development more as orienteering, if anything, it doesn't go far enough.
To deliver full-featured software in time (note I didn't say on time, but there is certainly such a thing as delivering too late) is 10% velocity and 90% dependency resolution.
I'm still looking for a tool which thinks primarily in terms of dependencies, and treats time as it is: fixed in the past and speculative in the future. I don't care if the person who put the information into the computer thinks something will take three weeks, I care very much if there are three projects which need completing before the main track can get past the third step.
(Sorry, I'm a bit grumpy.)
From what I have experienced, I think that is perfectly reflected in a lot of software too.
Assuming you don't stop there and keep doing those things, I don't see why you don't like agile.
The problem with "Requirements, prototype, feedback, iterate, qa, qa, qa, release" is that most large shops turn that into a 3 year process. As in, a group sits in a room for 6 months and writes some insane "Requirements Doc". Then six months of prototyping against it before any customer has seen anything. Etc etc down the line until you're a programmer looking at a 3 year old requirements doc with a thousand questions that arise during implementation but the designers who wrote the doc left the company two years ago, etc etc
Waterfall was to me inarguably worse than agile.
At least with agile people try to do requirements, prototyping and iterating in a very short period of time, so the feedback loop with customers actually works, and you actually release something on a regular basis.
That is agile for me. What is agile for you then?
Anyway, Agile has that one principle that is focusing on people, not process... You can make any process agile.
Honestly we need about 20% more screen real estate and 1/2 more columns for staging/prod qa.
I would say Steve Yegge's classic Good Agile, Bad Agile gives the answer - Kanban (or, more informally, a work queue).
Because someone's paying you to do stuff, and they might like to know what's happening. The incredible rush of money into tech in the 2010s might have given the impression that that isn't a thing, but it is, and teams that can't self-manage (including giving visibility and predictability) are going to become encumbered with more and more people managers to compensate.
What they should be doing is understanding their role, making sure it's fulfilled, and then taking that cash that would be spent on managers and spending it on engineers instead. But that won't happen if they can't communicate, or can't even see a need for communication.
You need predictability, so that people who depend on your work can make future plans (and I'm not talking about promising the day of delivery, but simple "this week / this quarter / this year / probably never")
And yeah, Kanban is a good alternative, but the article does'nt mention it at all
Are sprints necessary for knowing what other people are working on, and for having a say? I thought sprints are only tangential there.
In the case of the teams I've been on and lead, the sprint is structured with a planning meeting at the beginning of the sprint in which everyone goes over each story. Stories with enough complexity to warrant it have an execution plan attached (written during a SPIKE in a previous sprint) that allow the whole team to collaborate on the execution - everyone can go over the plan together, agree on the approach, poke any holes in it, etc. And this gives everyone a much clearer picture of what's being worked on.
In my experience with Kanban, it's much easier for developers to lose track of the work of the whole team. They focus on their current task, and the task they plan to pick up next. Being able to see the work on the board isn't the same thing as actually knowing and understanding it. Sprint planning lends itself much more to that.
That isn't to say you couldn't run an equally collaborative Kanban process with some work. My experience was just that it was much harder to achieve that level of collaboration with Kanban. That's through several iterations on different teams. Not impossible, just harder. And when there's a ton going on and you're going fast, you generally want your process to make it easier to work the way you want to work. IE. You don't want to have to work extra hard to make your process collaborative, you want your process to make it so that it's hard not to be collaborative.
But again, this was just my experience on a few teams and what works for those teams.
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 visibility of progress. Because you are delivering something tangible that stakeholders can see and feel all the way through the development process, you get better feedback from your stakeholders, better buy-in from your sponsors, and fewer canceled projects.
3. Where projects are canceled, they tend to be canceled early where they are clearly not working, before millions has been spent.
The need for requirements doesn't go away with agile. If you start a project with no requirements, it will almost certainly fail. However the iterative process allows you to refine the requirements as you go, and the early and frequent feedback from your stakeholders makes the requirements better. It's easier to add or remove a requirement if you can see the software doing something wrong or not doing something it should do, rather than trying to figure it out on paper ahead of time.
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.
I believe some people within certain organizations are aware of the waste at some point or another, but it's the price said certain organizations chooses to pay in order to implement a great micromanagement system.
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.
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?
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.
The Retro yesterday was 30. So that's less than 1.25% of my time spent.
Of course, if your project management listens to you and trusts you, you don't have this problem, so I understand your take.
Because you'll get fired if you don't...?
Tools and methodologies are guardrails, use them at the beginning as you learn the craft, get ride of them as you grow and always put meaningful conversation above all
Next performance review, your manager goes: It seems like you're not really aware of a lot of techniques of how to solve problems efficiently. Maybe you should do more pairing with the other seemingly much better developers to strengthen your skills. And now you've cornered yourself as a junior for the next 2 years, who was "hired on the wrong level".
All of this is assuming that the team members will prioritise the performance of the team higher than their own performance, of which there are no incentives. The incentives is to make yourself look as good as possible (don't admit your idea is inferior), and skew the playing field to your advantage (insist on using the tools you know best) etc.
People simply don't spontaneously cooperate and simply don't "just get along" in a situation like this.
Even in hippie communities where everything is voluntary and there is no personal gain to be had, it still falls apart because some people just don't cooperate.
So how do you expect that to happen in a situation with money involved, and competition between people?
Why do the software industry and scrum think they have spontaneously discovered how people always just get along, inside a basic weekly planning schedule? That would literally be a nobel peace prize right there.
Is Scrum a solution that really works, or merely a great concept?
I agree with and swear by the agile manifesto (it's really amazing) but IMHO, all of its byproduct methodologies fall short in the real world, with no exception.
Both have manifestos.
I think there are certain systems that make sense and can be executed properly but human nature eventually mucks it up.
All engineers are equal, but some are more equal than others!
Philosophically, agile is more like democracy/capitalism: it decentralises control to teams, where the information and expertise are. Failures in agile are things like "I didn't like using story points".
Waterfall is more like communism: it centralises control away from the people doing the work. Failures in waterfall are things like "we spent millions and got nothing out of it".
I think this sort of thing - where what you're building has external hard-to-move dependencies - comes up more often than you think. Those election visualisations on NYT didn't build themselves. There's often a bunch of less-hard-but-still-inconvenient dependencies as well - you're building software for hardware, or there's advertising campaigns in planning/motion.
Of the software I use (slack, cloud infra, vim, Jira) exactly none of them tell me precisely when a feature will be delivered. They work hard on it and release it when it's ready.
A deadline like "in a few weeks" is acceptable. A deadline like "in 17 days" is asking to be missed.
Internally, though, Slack et al have targets and expect to deliver feature X by the end of sprint Y. They just don't tell you in case it slides by a sprint, and to avoid laying out a product roadmap for fast-moving competitors.
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.
Same with "ceremonies", that one bugs me too, though not as much.
I still don't know WTF a scrum is however (not even sure that's an agile-specific term).
> The fundamental unit of scrum is a small team of people, consisting of a product owner, a scrum master, and developers. The team is self-managing, cross-functional and focuses on one objective at a time: the product goal. [1]
Like, what? I feel like I know less after reading that. That just sounds like...a development team with a team lead and a manager.
1 - https://en.m.wikipedia.org/wiki/Scrum_(software_development)
Baffling.
I’m making a pithy statement about the difference hackers and developers
Beware the careless pedant!
I rate my comment a perfect 7/5.
Yep, at the end of the day, the whole world can't run if everyone is a professor emeritus just freely exploring random possibilities, even if it would be hundred times more efficient to just "get out of the way".
You just have to sign a standard contract for building a project in 24 months, and wait 23 and a half to be in that situation.
Managers need a tool to avoid reaching that situation and renegotiating the terms in advance.
Now you understand sprints
And software that can't be estimated is still useful, even if you can't plan releases around it yet. "Apple has been unable to accurately estimate any release window for the Apple Car or Apple VR. Therefore no one should invest in it." would be a pretty silly statement, right?
That's exactly how it works though. Imagine Apple's stock price if they announce the Apple Car, without a release window. Now imagine that they come back the next day and say "oh by the way, we're aiming to release it in 2086." What happens to the price? It goes down. There was an implicit estimate used to judge the value of Apple.
Likewise, all software has an implicit estimate. There has to be! Without one, it's worthless.
If testing in "real time" is not possible for some reason, the following sprint should have testing support baked in as an explicit task.
And, IME, sprints work well for mature products where there's a steady flow of defects and enhancements that are relatively easily articulated. Sprints work less well for greenfield development with new tech - you just end up with long strings of spikes/analysis/PoC work (it can still work, but you tend not to have concrete deliverables each sprint).
That’s how it works in an industry where product bugs can kill people. The devs do their own testing but there are large testing teams that take a deep look at at everything the system does.
If you overestimate everything then you end up idle at end of sprint & picking backlog items to bring in, so then product wants to put more points/stories into next sprint.
The system is seemingly designed to produce this outcome.
The system is to teach everyone how to lie and juke the system. It feels awful working in most sprint-based environments. Because even when you're highly productive it still feels like you failed in multiple places, and it always feels like you're being dishonest and have no real choice about it.
So instead of "ticket: make pasta for dinner" it was like "ticket 1: purchase prego & pasta from instacart" , "ticket 2: boil water & get out the jar opener", "ticket 3: cook the pasta and sauce", "ticket 4: place the meal and serve".
Zero chance all 4 finished in the sprint, in fact they were rarely even all planned for same sprint.
It became impossible to express to users what they were getting at the end of each sprint. "OK, so you've.. purchased ingredients, when do I get to eat?"
This happened with multiple product managers, agile coaches and tech leads so it wasn't just a single person forcing stupidity on the process..
This is what scrum (done well) helps with. Unless the software was horribly written, it’s usually easy to estimate effort for very modest, well-defined changes.
Take a large enhancement or overhaul, however, and estimates will be wildly off and it’s because of the iceberg effect of unknowns.
What scrum forces the inexperienced teams to do is start breaking down, plan and incrementally chip away at a ill-defined, large request by turning it into many smaller and better understood deliverables.
It’s what very good teams do, though they do it without the need for formality.
I’ve grown increasingly skeptical of whether adopting agile even prevents the waterfall model rather than making it less legible when it happens.
For instance, I think the kanban concept is more basic than estimation. That is, teams that keep starting new work without finishing the old work are working very hard but get very little ‘done’. Thus you have some limit on how many tickets can be open. I know a very well run cafe where that’s the main management practice they use, only taking orders when they are running low on work in progress.
My beef with estimation is that the model that ‘task A has N subtasks and you can estimate the individual subtasks and add them up’ (which works well in a certain sense) is often less correct with the model that ‘the developer sends a work unit to the tester which may or not be sent back to the developer’… in which case the most important factor for how long it takes to do work is how many times you send it off to the tester.
Sometimes I dream about working with a ‘tester’ in a much more closely coupled way than I do. I always have to ‘test’ something myself to convince myself it works to avoid the embarrassment of sending something to the tester that is 100% busted. I frequently spend a huge amount of time setting up tools and environments for testing. That includes the traditional unit testing (which runs quickly) but also processes like building a full text search index for a system with a few million records, testing to see that a machine learning model builds automatically and works properly, that a full text search engine gives relevant results, or spending four hours building a database so I can run interactive queries against it.
If somebody was helping out on that kind of stuff and could test stuff I do with a turnaround of minutes instead of ‘fill out a lot of paperwork and wait 2 days to 2 weeks’ I’d spend more time thinking and coding. (W/ the caveat that thinking about testing can lead to a better design more often than it leads to Test Driven Design Deformation.)
I've seen open sprints named after a pair of calendar weeks multiple months in the past. And for some reason those were still called "sprint". I'd call unwillingness to modulate rather low on the cargo cult scale.
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.
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.
I've dropped sprints on 2 teams now, and improved our cadence both times.
If you need to demo to gain stakeholder approval, and provide ceremonies like retros to disseminate knowledge to a wider team .. these events need scheduling.
Randomly springing these on people without any regularity just won't work in most orgs.
and, ofc, estimating the time to deliver is impossible, so you end up scheduling a sprint demo that might or might not happen depending on how well the project is going.
Or, as I found, people are perfectly OK with scheduling demos in at short notice and being flexible about their expectations.
When I started SW development in 2005, we had one meeting a week (Friday) with our boss, where we summarized what progress we made during the week. It was exactly what he and his superiors needed to know, not anything more.
Not reporting. Reporting is an internal function. People would like to know what's happening and what's going to happen, so that they know roughly what to expect for planning purposes elsewhere in the business, e.g. marketing. Not just reporting for its own sake.
I'm seeing a lot of processes and tools over people and interaction in more recent iterations of Scrum implementations.
Sprint commitments were originally the opposite of imposed deadlines.
I'd suggest thinking this over, and revisiting.
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)
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.
Again in my experience, in some environments kanban is an excuse for having the team on a constant death march to burnout.
If you give 2 software developers the same software spec they will give you 2 completely different pieces of software.
The code is the blueprints.
If you’re building a new innovative house that is different than what currently exists, the design phase is very similar to software development, and is likely to take an amount of time that is unknown at the beginning.
I like kanban, a stack of tasks with predefined dependencies determining if a card can be picked up, and sorted in priority order once they can be picked up. When something critical goes wrong, the entire team stops and works the problem individually, competitively , until the problem is solved, and the team then resumes their prior work. CI/CD delivers to production, features are enabled when they are ready and the customer is ready. Feedback goes immediately back into the stack and delivery leads constantly manage the feature flags, the stack priority, and inter team communication. The devs just dev and stop the line. The team tech lead, product lead, delivery lead, architect, and program/product lead do all the negotiations and priority setting. There are no estimates. You deliver constantly. You need strong leads and architects to run this way, and you should probably coach your client to expect slow change at first, and rapid change after the first release.
Done this at several clients, for several different domains, with lots of interdependent teams as a consultant, and it is highly productive. The one time it failed, we didn't get buy-in on feature flags in production and the client insisted on batched release branches and long-term maintenance branches for those cut releases.
The other, minor failure, is that it is very prone to momentum. That's when teams get overconfident that they can fix problems in-band with tasks (because they've been successful for so long), and are resistant to stopping the line. This can be spotted by a person not delivering a pr for more than two weeks, or not transitioning a card to done for more than two weeks. Tech lead calls a meeting, determines the issue, decides on stop the line or not.
It works. It's iterative. It keeps the number of communications channels and decision stakeholders low. It cross-polinates through linked dependencies. It ensures product cohesion thru feature flags. It evades critical missteps and bugs via stop the line. And it works well with our modern SSO dev/platform ops and integrated toolsets (Atlassian/clickup + ci pipeline of choice where docs, features, delivery can all talk to each other and reports can be generated for leads that pull from the integrated tools). It doesn't fix Conway's law, but I am not sure that actually needs fixing in truly large development houses.
Software is arbitrary logic which many stakeholders expect to be magic. It's not the same as any kind of construction project.
Thats like asking 'how does naming my local variable X instead of Y have any dependency on code in other functions? and assuming that summarizes the complexity of writing code.
I take it you have never built a large custom house from scratch.
Yes, I have been privy to the pain of custom home builds and remodels. The difference is, when someone says "oh damn the plumbing isn't working as well as we would like", when the contractor says that's not feasible to fix without gutting the house back to studs at the cost of hundreds of thousands, people understand that intuitively. They don't say "can't you just drill some holes and run some new pipes diagonally through the living space".
Software is malleable, opaque, and ever-changing. Construction and maintenance costs of physical infrastructure can be explained in a way that a reasonable lay person can understand. That is not true of software at scale.
I have my criticisms for sure, but sprints give more discretion to the teams to carve out space for multiple types of priorities held in balance, and lock that ratio in for a period of time.
Prior to that, I worked (as did most people) on waterfall-style projects, and the success rate was only about 50%.
Waterfall cannot identify those risks without huge experience. Scrum tends to exacerbate some of them. Kanban with sufficient number of phases tends to expose the problem, but not necessarily fix it.
The ones that didn’t were easily attributable to outside factors or specific problems like an exceptionally bad PM.
https://newsletter.pragmaticengineer.com/p/project-managemen...
Two-week sprints seem to be the default in tech, although I've worked at a company that very successfully used one-week sprints. That's completely separate from how strictly companies try to follow "scrum," if at all. I've run into kanban more often than scrum, personally.
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.
Scrum/sprints are kind if like the bureaucratized and ritualized version of that. The Catholic Church to Agile's Christian cult.
when they do. i was part of an 'agile' team in 2019 (6 mo contract). I wasn't there long enough to have strong views on work items or priorities, but did watch the interactions between others. It was a decently organized team inside a (fast) growing org - lots of challenges there. But overall, there was a decent balance.
Worked on another smaller team longer - 2 years. As the company grew, it got far more process heavy. The 'sprint' stuff was "as tech lead, you get 5 points to use however you want per sprint!" (yay?). that got taken over by the CTO getting involved and using those '5 points' for constant infrastructure stuff. I was reviewing code I delivered, and it was full of cut corners to continually hit deadlines. I begged on a few occasions for more 'cleanup' time. It was always denied (except for 3 days over xmas, because... literally no one else was working, so they couldn't say no).
The project transformed in to "here's our strategic goals for 2022" with every quarter mapped and filled to the brim with work. 0 time for anything but bare minimum MVP. The thinking was "well... you've been able to work at that pace before, and we added someone new, so we can increase that". In 2019, it was MVP - test the idea. Speed to market makes some sense. In 2022, millions of dollars and hundreds of lives affected each month... we need to take a bit more time to clean up existing code, retire legacy code, adopt a slower pace to focus on clarity, testability, even performance concerns etc. This seemed to fall on deaf ears.
"discretion to the teams" tends to ring hollow to me based on recent experiences, and ideally I'll work with another group in the future with a healthier balance.
Though your point is correct - you rarely are given time to fix tech debt. If you switch to a long term employee, then you should intentionally slow your velocity a little to fix tech debt. By the time management catches on you will have fixed enough that an improvement is visible and so you have proven yourself, and thus will be allowed to do more of it.
Also note that a story isn't done until refactoring is done. Sure it works, but if the code is a mess your story isn't done and you don't move onto the next one. Many developers fail to force this, but as a professional this should be part of your code of conduct and thus not optional no matter what the deadline.
In any case the point is you will never be officially given those 5 points - but you can take them by force.
As an aside, one thing just came to mind. Even if you're bringing tech debt tickets into each sprint, there's a possibility they'll get picked up last - fine, unless they keep getting pushed back!
Part of me thinks this could be mitigated by reducing the velocity expectation. But there tends to be an overarching sprint goal relating to product work, and this often invites extra scope due to unforeseen impediments. So 'background' work like tech debt is easily pushed back.
I don't know of a better way. Perhaps it comes down to human factors such as limited focus.
Either do 2 of this, 1 of that, or have separated time slots, or whatever. But separate them.
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.
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.
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.
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...)
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.
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")
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.
At some point though, many of the original assumptions about problems are understood to have been fundamentally wrong/misaligned, and need some revisiting. You need to touch old code, whether to delete it, or to have it align with new standards or new ... whatever. Touching anything that didn't relate to an explicit 'agreed on' jira ticket was seen as wrong/bad. I ended up bundling in 'fixes' of unrelated stuff when working on 'new' stuff because... it had to get done, but was ignored or rejected during any sort of planning.
I've heard it said that "to go fast, do it alone. to go far, you need a team". I can get on board with that, but you need a team in agreement and competent. I have a colleague working on a small team and... they're mostly just completely inexperience and bad, but there's no self-awareness. Taking direction from the guy who was in high school last year, while ignoring the person who's lead multiple teams and has delivered high value software for 20 years... that's a bizarre imbalance that can't be fixed with 'sprints' or process alone.
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.
Not really.. The PP asked how to do visibility and predictability without sprints. I asked, what do you need it for? You said, they are imposed externally. I said, well, if they are imposed externally, figure out the minimal requirements and do that. No need to do any extra bureacracy, they are not required for SW development process.
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.
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.
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.
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
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.
However that's not really what I'm talking about. Assuming some minimum level of quality, 2 houses built from the same blueprints with the same materials and finishes, in similar locations, and by similarly skilled craftsman will be pretty much indistinguishable from each other to the end user.
That's not the case with software.
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.
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.
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.