The Reasons Not to Use Scrum(amazingcto.com)
amazingcto.com
The Reasons Not to Use Scrum
https://www.amazingcto.com/the-5-reasons-not-to-use-scrum/
66 comments
Fuck Scrum. How many devs are saying this privately how much they hate scrum but have a work persona where they have to love it? It's so fucking toxic. It's just focus on doing a good job and get back to basics. Hire the right people, give them a lot of trust, some incentives to do a good job, and see what happens. Stop making out a methodology out of a freaking todo list.
I'm getting the impression that it's like Monopoly -- an overall solid idea that some people glue their own pet ideas to, or where they tack on pointless add-ons until it becomes unrecognizable.
I don't really see what's hateable in scrum, when done sensibly. Like what do you have?
1. Daily short, standup meetings just to make sure everyone is on the same page, nobody is terminally stuck, and everything is moving forward. Most of the time these are done in a few minutes and go by completely uneventfully.
2. Weekly plannings where the team figures out what to do next. That allows replying to real-world changes, or to adapt to team composition. Eg, if Bob, who knows everything there is about Postgres is on vacation, maybe we'll delay database related work until he returns.
3. Retrospective to see if everything is on track or things are getting badly bogged down somewhere. This is a good time to think about whether some feature will not make it at this rate, or such.
I don't think there's anything wrong with the core idea, and there's a lot you can adjust to your needs. If doing two week sprints is too much planning for you because all the tickets are long running, do it once a month instead.
I don't really see what's hateable in scrum, when done sensibly. Like what do you have?
1. Daily short, standup meetings just to make sure everyone is on the same page, nobody is terminally stuck, and everything is moving forward. Most of the time these are done in a few minutes and go by completely uneventfully.
2. Weekly plannings where the team figures out what to do next. That allows replying to real-world changes, or to adapt to team composition. Eg, if Bob, who knows everything there is about Postgres is on vacation, maybe we'll delay database related work until he returns.
3. Retrospective to see if everything is on track or things are getting badly bogged down somewhere. This is a good time to think about whether some feature will not make it at this rate, or such.
I don't think there's anything wrong with the core idea, and there's a lot you can adjust to your needs. If doing two week sprints is too much planning for you because all the tickets are long running, do it once a month instead.
I would suggest all this stuff will arise organically if you just hire the right people and give them some good principles of what good looks like. Like actually train people in leadership and other skills instead of just having a 'process'? I mean it when I say see what happens if you actually trust people and give them some freedom.
Who are these people excited about scrum? Most of the scrum masters I know dislike it and would rather build ad-hoc from the agile toolbox. Scrum is popular because it's an easy-to-implement general process that enough people know.
Scrum is the duplo block of agile. That said, it doesn't have to be that heavy. A retrospective every other week, A sprint review every other week, a sprint planning every other week, and 15 minutes a day for standup.
So that's a half day block every other week and 15 minutes a day otherwise. It doesn't even need to be a half day block - our sprint plannings usually end up being 15 minutes because we work on refining tickets through the week.
My teams have 3-4 hours of standing meetings a week. We try to group them as much as possible to avoid dumb blocks of time. The vast majority of that time is going through the work together.
The vast majority of our meetings are making sure we are building the right thing. Reviewing the specification for gaps happens with development. You could say that that could be done asynchronously, and it does. But I think so much of the issue here is that people add more.
Scrum is the duplo block of agile. That said, it doesn't have to be that heavy. A retrospective every other week, A sprint review every other week, a sprint planning every other week, and 15 minutes a day for standup.
So that's a half day block every other week and 15 minutes a day otherwise. It doesn't even need to be a half day block - our sprint plannings usually end up being 15 minutes because we work on refining tickets through the week.
My teams have 3-4 hours of standing meetings a week. We try to group them as much as possible to avoid dumb blocks of time. The vast majority of that time is going through the work together.
The vast majority of our meetings are making sure we are building the right thing. Reviewing the specification for gaps happens with development. You could say that that could be done asynchronously, and it does. But I think so much of the issue here is that people add more.
I'm a UX Designer and I despise scrum. It's a useless bunch of practices pushed by failed project managers to justify their salary. It does orders of magnitude more harm than good in software development.
I used to work at Rally, who's product is literally to facilitate Scrum. We did not use Scrum. At one point we thought we needed to dog food better and tried using Scrum, and that lasted a few weeks. We used Kanban instead, and it worked pretty well. I think it's more realistic, doesn't get in the way as much and allows coordination and prioritization to more naturally happen. The downside is Kanban takes skill and experience to pull off well, which could be said about Scrum too.
Kanban requires either a team who is mature enough to know what is important to work on, or a leader who is able to translate business requirements to tickets, and to gently guide the team in that direction.
My current company's SREs switched from Kanban to Scrum shortly before I was hired, allegedly because they were working on things that were fun instead of things that were necessary.
Conversely, at my first SRE job, we did Kanban and it worked great. We met once a week, where my manager would discuss in broad strokes what needed to get done. Sometimes our Principal Eng would write a ticket to explicitly do something, but mostly we'd just figure it out on our own. Never once did anyone accuse us of being slow, missing work, etc.
I love Kanban. It's the only tracking system where you get treated like an adult.
My current company's SREs switched from Kanban to Scrum shortly before I was hired, allegedly because they were working on things that were fun instead of things that were necessary.
Conversely, at my first SRE job, we did Kanban and it worked great. We met once a week, where my manager would discuss in broad strokes what needed to get done. Sometimes our Principal Eng would write a ticket to explicitly do something, but mostly we'd just figure it out on our own. Never once did anyone accuse us of being slow, missing work, etc.
I love Kanban. It's the only tracking system where you get treated like an adult.
Prioritizing what to work on is the same problem in Kanban or Scrum. This isn’t a differentiator between the two.
In Scrum, I have to argue during a meeting why something in the backlog is important, and if I can successfully convince others, I then have to apply an abstract, unitless measure of complexity to that task, keeping in mind that not everyone has the same skillset. Worse, if the team completes all of their tasks ahead of time, we have to revisit Step 0 to decide what to pull into the sprint, and then discuss during the retro why we underestimated the length.
In Kanban, I get shit done, and when it's done, I get more shit done.
In Kanban, I get shit done, and when it's done, I get more shit done.
The only difference between Scrum and Kanban in terms of work priority is that with Kanban you prioritize the backlog and take the next thing off the top.
With Scrum you prioritize the backlog and try to forecast the volume of items from the top of that backlog that you'll be able to work into the sprint based on past velocity.
You're not wrong about the arbitrary estimate. Prioritization is a function of the company and/or product team. If you need to do something in the sprint that you didn't know at the start of the plan, yes there are definitely scrum teams that would try to stop you because they are too strict with their process.
Don't get me wrong here, this perception is a standard antipattern that you see in scrum shops. I've only seen a scrum team once in my career that was actually effective and I'm a huge Kanban advocate because of it.
https://news.ycombinator.com/item?id=17154355
But prioritization still happens at a higher level than the team itself. It has to because it defines the direction of the company. Most importantly, deciding what you're NOT working on so you can focus on what matters.
With Scrum you prioritize the backlog and try to forecast the volume of items from the top of that backlog that you'll be able to work into the sprint based on past velocity.
You're not wrong about the arbitrary estimate. Prioritization is a function of the company and/or product team. If you need to do something in the sprint that you didn't know at the start of the plan, yes there are definitely scrum teams that would try to stop you because they are too strict with their process.
Don't get me wrong here, this perception is a standard antipattern that you see in scrum shops. I've only seen a scrum team once in my career that was actually effective and I'm a huge Kanban advocate because of it.
https://news.ycombinator.com/item?id=17154355
But prioritization still happens at a higher level than the team itself. It has to because it defines the direction of the company. Most importantly, deciding what you're NOT working on so you can focus on what matters.
This is by one the dudes who invented story points, and is really worth a read: https://ronjeffries.com/articles/019-01ff/story-points/Index...
It explains what they were aimed to solve, and acknowledges their modern day abuse. If you read Extreme Programming Explained ed 2, you see Kent Beck acknowledging them as an early experiment that they decided wasn’t useful.
It explains what they were aimed to solve, and acknowledges their modern day abuse. If you read Extreme Programming Explained ed 2, you see Kent Beck acknowledging them as an early experiment that they decided wasn’t useful.
Sometimes I think of Scrum as the thing that teaches you why (and how) you actually want Kanban.
The biggest problem that I have experienced with Scrum are the Scrum Masters. They play such a central role in Scrum. I have twice experienced that the role of Scrum Master was given to a 'junior' software developer who had ambitions for becoming a manager. In both case, I left the company. In my opinion, Scrum can only work when you have a Scrum Master that is there 100% for the team. A person who has a sixth sense for friction within the team, either with developers struggling with themselves, among eachother or with people outside the team, and someone that knows what to do about the cause of the friction. And these Scrum Masters should be given enough power to also change things in the organisation. I think that organisation that want to embrace Scrum, often do this for the wrong reasons and do not assign the right persons for the roles of Scrum Master and/or limit their authorithy rendering them ineffective.
I see "scrum master" as similar to "president" in the sense that anyone who wants the position should be kept as far away as possible.
It's a position very similar to "engineering architect" where you're given a huge amount of leeway to impose rules and process, but you have almost zero accountability.
The absolute worst are the "certified scrum masters" who are utterly bought in on whatever bogus "one true scrum process!" bullshit they've paid money to be certified in from a scummy for-profit company. I avoid these people like the plague - they kill companies.
In general - you can do quite a bit of "scrum" without any scrum master at all. Share early and often, adjust based on what else you're seeing shared and customer feedback, treat the people around you with respect, be accountable for the respect others are giving you. No scrum master needed.
It's a position very similar to "engineering architect" where you're given a huge amount of leeway to impose rules and process, but you have almost zero accountability.
The absolute worst are the "certified scrum masters" who are utterly bought in on whatever bogus "one true scrum process!" bullshit they've paid money to be certified in from a scummy for-profit company. I avoid these people like the plague - they kill companies.
In general - you can do quite a bit of "scrum" without any scrum master at all. Share early and often, adjust based on what else you're seeing shared and customer feedback, treat the people around you with respect, be accountable for the respect others are giving you. No scrum master needed.
My biggest issue with it is how easy it is to derail 'agile' with process and ceremonies. One project I went from 5-10 mins to make a story and maybe another 5-10 mins to manage it over the next few weeks. To each story taking 3-4 days of management and fiddling each required field in Jira then another 1-2 planning sessions to get the thing moved across the lanes.
> It’s not an engineering process. I once argued Scrum is so good; you can manage everything with it.
This is a pretty absurd reason to not use Scrum. It's a method of organizing and tracking work, why do you need something specific to engineering?
This is a pretty absurd reason to not use Scrum. It's a method of organizing and tracking work, why do you need something specific to engineering?
The problem is that the author did not define what engineering is. Given that, your conclusion is valid.
Regardless I do agree with the author. In fact, in my opinion, the fact that scrum is not an engineering process is its largest shortcoming.
My opinion is that the difference between engineering and programming is that engineers support non-functional requirements. In other words they are responsible for satisfying technical constraints on a system. These are things like can my system fit within a certain size, weight, can it run at a certain speed, etc. This means that many people who are doing programming are actually doing engineering. Anyone who has tried to optimize a program is trying to meet a non-functional requirement on speed or memory usage.
Scrum does well if you want to bolt things onto your system. As a user I want to do x. Do you want to add a button? Make a user story, estimate it. Do you want to add a payment system? Make a user story, estimate it. It's simple and that makes it seductive. This sometimes works for non-functional requirements. System running too slow? Do a spike story. It was because we're using bubble sort under the hood. Make a story to swap it out with quick sort. But what if I want to change my response time of my system from 2s to 1s? Well we need to re-architect our system and launch a new satellite into orbit. Alright, so you can do that in a sprint, right?
For me, Scrum is a toy process of what business people think engineering is. It fails as a process because it doesn't account for non-functional requirements and it doesn't admit its shortcomings.
Regardless I do agree with the author. In fact, in my opinion, the fact that scrum is not an engineering process is its largest shortcoming.
My opinion is that the difference between engineering and programming is that engineers support non-functional requirements. In other words they are responsible for satisfying technical constraints on a system. These are things like can my system fit within a certain size, weight, can it run at a certain speed, etc. This means that many people who are doing programming are actually doing engineering. Anyone who has tried to optimize a program is trying to meet a non-functional requirement on speed or memory usage.
Scrum does well if you want to bolt things onto your system. As a user I want to do x. Do you want to add a button? Make a user story, estimate it. Do you want to add a payment system? Make a user story, estimate it. It's simple and that makes it seductive. This sometimes works for non-functional requirements. System running too slow? Do a spike story. It was because we're using bubble sort under the hood. Make a story to swap it out with quick sort. But what if I want to change my response time of my system from 2s to 1s? Well we need to re-architect our system and launch a new satellite into orbit. Alright, so you can do that in a sprint, right?
For me, Scrum is a toy process of what business people think engineering is. It fails as a process because it doesn't account for non-functional requirements and it doesn't admit its shortcomings.
Also having some iterative improvement instead of a large project (waterfall) seems to fit quite well for certain (software) engineering projects.
Error 42. Scrums are not about what to work on.
I have witnessed the incredible effectiveness of what are now called scrums. Maybe we call this "A tale of Two Teams".
Team A built a product and the manager held these annoying meetings once a week where people talked about what they worked on. It was stupid. Or so I thought at the time. Ultimately, this team shipped products, time after time.
Team two was at a database company which did a rewrite of its product. Each team went off for months and worked on the rewrite. At the end each team brought its contribution to the table and lo and behold, none of parts worked with the other parts. These teams never had meetings with the other teams, so of course the pieces did not work together. The assumptions that each team made, and the decisions they made, ensured that no two pieces would or could interact. The whole process was a fiasco and months of time were wasted. This company did not exist for much longer.
So no matter what you call it, no matter what you think it is supposed to do, the simple fact is
* Meetings of the entities working on a single project to share what they are doing is effective. *
Very effective. Complex Adaptive Systems.
I have witnessed the incredible effectiveness of what are now called scrums. Maybe we call this "A tale of Two Teams".
Team A built a product and the manager held these annoying meetings once a week where people talked about what they worked on. It was stupid. Or so I thought at the time. Ultimately, this team shipped products, time after time.
Team two was at a database company which did a rewrite of its product. Each team went off for months and worked on the rewrite. At the end each team brought its contribution to the table and lo and behold, none of parts worked with the other parts. These teams never had meetings with the other teams, so of course the pieces did not work together. The assumptions that each team made, and the decisions they made, ensured that no two pieces would or could interact. The whole process was a fiasco and months of time were wasted. This company did not exist for much longer.
So no matter what you call it, no matter what you think it is supposed to do, the simple fact is
* Meetings of the entities working on a single project to share what they are doing is effective. *
Very effective. Complex Adaptive Systems.
Nothing stops you from talking to other teams under any other system. And frankly if an adult on Team A needs to be told "you should find out what Team B is doing so your products work together," you have larger problems.
I call this the "group project" problem (there's probably a catchier term kicking around out there), mainly from watching it happen time after time in group projects as a TA in school, but it plays out mostly the same in companies. Stated simply:
If you split up a task and assign parts to team members, you are only 30% done when all members have completed their part of the task. 70% of the work is in combining the parts back into a coherent whole.
So the teams that fail horribly are the ones that work in isolation and believe that combining the output of that work is easy.
The teams that actually get a product out the door focus on the majority of the work (making a coherent whole out of disparate parts) as SOON as possible.
That means sharing back with the group at the earliest possible moment, and then as often as possible as you update and change your part.
Now... scrum is hardly the only way to make that happen, but I think the processes it encourages follow the same trend: Work alone for very short periods, share often, adapt as needed in response to what else is shared.
The problem with scrum is just all the rest of it (especially scrum masters... those certifications are a black mark on your resume in my opinion).
If you split up a task and assign parts to team members, you are only 30% done when all members have completed their part of the task. 70% of the work is in combining the parts back into a coherent whole.
So the teams that fail horribly are the ones that work in isolation and believe that combining the output of that work is easy.
The teams that actually get a product out the door focus on the majority of the work (making a coherent whole out of disparate parts) as SOON as possible.
That means sharing back with the group at the earliest possible moment, and then as often as possible as you update and change your part.
Now... scrum is hardly the only way to make that happen, but I think the processes it encourages follow the same trend: Work alone for very short periods, share often, adapt as needed in response to what else is shared.
The problem with scrum is just all the rest of it (especially scrum masters... those certifications are a black mark on your resume in my opinion).
Meetings are a poor indicator of continuous integration.
Instead, build a steel thread. Make the simplest thing that can go through every team first. Every team working on the project goes to build that initial slice of functionality. When done, you have the infrastructure and tests necessary to make sure each next slice is functioning. It means that you have a low level friction through the project, but it is much smaller than the overall friction at an integration phase.
Then, use meetings to discuss the clarification of the specification and the technical design. Any status meetings can be at the EM/PM/Lead level as necessary but you will have the feedback to know how things are progressing quickly.
Instead, build a steel thread. Make the simplest thing that can go through every team first. Every team working on the project goes to build that initial slice of functionality. When done, you have the infrastructure and tests necessary to make sure each next slice is functioning. It means that you have a low level friction through the project, but it is much smaller than the overall friction at an integration phase.
Then, use meetings to discuss the clarification of the specification and the technical design. Any status meetings can be at the EM/PM/Lead level as necessary but you will have the feedback to know how things are progressing quickly.
A third approach (not endorsing it, merely adding it here for the sake of completeness) is to have a software architecture role which defines how the components interact. Each time is free to do whatever they want within their component, but they have to meet their interface spec. When the components are put together, there'll be small problems/bugs for sure, but if they've followed the architecture (and the architecture team/person has been making sure of that) then they should basically fit together.
That doesn’t have to be a silo, you can have the capability rather than a role and agree on specs / contracts as to how your tools/apis will interact and work with the bigger picture or the product.
> * Meetings of the entities working on a single project to share what they are doing is effective. *
In other words, these things are very valuable: Individuals and interactions, Working software, collaboration, Responding to change.
https://agilemanifesto.org/
In other words, these things are very valuable: Individuals and interactions, Working software, collaboration, Responding to change.
https://agilemanifesto.org/
Highly efficient teams arrive at ~scrum naturally, without having to label it.
You start with a highly efficient team, and scrum follows. Not the other way around.
If you've got a team of individuals that do not naturally want to meet every once in a while to discuss progress and potential efficiency wins, you've got an incompatible team and should rebuild, not force them to have those meetings.
You start with a highly efficient team, and scrum follows. Not the other way around.
If you've got a team of individuals that do not naturally want to meet every once in a while to discuss progress and potential efficiency wins, you've got an incompatible team and should rebuild, not force them to have those meetings.
My unfortunate personal experience with various teams is that Scrum is too often an excellent way to close tickets if you don't care very much about quality.
The whole dynamic of fixed-length iterations and "commitment ceremonies" puts heavy social pressure on developers to hit lots of tiny deadlines. And when minor estimation errors occur, there's a risk of developers shipping code that technically meets requirements, but which subtly compromises quality or maintainability. But hey, they kept their promises!
And then you hold retrospectives where you try to find out why production is a dumpster fire and the clients are unhappy.
Even skilled software estimators may be off by 50% on individual features. Over time, this mostly averages out. But chopping time up too finely and applying social pressure to consistently hit lots of micro-deadlines has to be paid for somewhere.
I am personally a fan of Kanban: Keep a priority queue of features. Estimate them as best you can. Allow decision makers to reorder the queue as they learn about customers. This still gives you rough estimates, and the ability to track estimation accuracy. But it doesn't back team members into a corner where they feel pressured to ship two days to soon just because it's the end of the iteration.
The whole dynamic of fixed-length iterations and "commitment ceremonies" puts heavy social pressure on developers to hit lots of tiny deadlines. And when minor estimation errors occur, there's a risk of developers shipping code that technically meets requirements, but which subtly compromises quality or maintainability. But hey, they kept their promises!
And then you hold retrospectives where you try to find out why production is a dumpster fire and the clients are unhappy.
Even skilled software estimators may be off by 50% on individual features. Over time, this mostly averages out. But chopping time up too finely and applying social pressure to consistently hit lots of micro-deadlines has to be paid for somewhere.
I am personally a fan of Kanban: Keep a priority queue of features. Estimate them as best you can. Allow decision makers to reorder the queue as they learn about customers. This still gives you rough estimates, and the ability to track estimation accuracy. But it doesn't back team members into a corner where they feel pressured to ship two days to soon just because it's the end of the iteration.
Formal and/or scheduled meetings are not the only and often not the most effective way of communication between team members. Highly effective teams often have a lot of informal interactions between team members by various means of communication not restricted to one-on-one talks or small group meetings before white boards. I know many introvert developers that rather write a detailed comment on an issue raising some discussion points than have a discussion on the subject. In a highly effective team, the team members know the strong and weaknesses of fellow team member and are often able to arrange things without having to rely on regular scheduled meetings and/or stand-ups.
Before you ask anyone about Scrum, read the https://agilemanifesto.org/
> Individuals and interactions over processes and tools
> Working software over comprehensive documentation
> Customer collaboration over contract negotiation
> Responding to change over following a plan
Then look at every suggestion through that lens.
> Individuals and interactions over processes and tools
> Working software over comprehensive documentation
> Customer collaboration over contract negotiation
> Responding to change over following a plan
Then look at every suggestion through that lens.
The truth of the matter is that most organizations are fundamentally incompatible with agile.
Organizations obsess over details. They want detailed plans and cost estimates months ahead. They have a low or zero tolerance for failure. They think in hard promises/contracts and punishment for those that don't deliver. All of this is entirely opposite to the core of agile, which "discovers" reality as it progresses.
Organizations obsess over details. They want detailed plans and cost estimates months ahead. They have a low or zero tolerance for failure. They think in hard promises/contracts and punishment for those that don't deliver. All of this is entirely opposite to the core of agile, which "discovers" reality as it progresses.
Scrum was a (failed) attempt to get companies to think outside the box. For a variety of reasons, it doesn't really work and you can't fix bad management process with it.
You can't save a company with scrum.
What you might be able to do is study it as an open minded organization and pick out the best parts. And also make sure you have an appropriate engineering (non-functional requirements) process.
You can't save a company with scrum.
What you might be able to do is study it as an open minded organization and pick out the best parts. And also make sure you have an appropriate engineering (non-functional requirements) process.
The blog post mentions too many meetings. Its the 15m daily everyday, then a retro and a planning once per sprint. I understand it is too much for a one-week sprint (as stated in the post) but how is that too much otherwise? Seems exaggerated to have a four week sprint because of those two moments. In fact, I would argue that having longer sprints means longer meetings (if you're having a productive retro you'll have a lot more to talk about during four weeks than two)
And how is having meetings a negative thing for remote work? Remote shouldn't mean "no interaction". Remote should adapt for collaboration.
And how is having meetings a negative thing for remote work? Remote shouldn't mean "no interaction". Remote should adapt for collaboration.
>but how is that too much otherwise?
Because people lack discipline, will powder Scrum meetings on top of existing meetings, create more meetings from stand-ups because Scrum doesn't teach individuals to be disciplined, drag out the meetings, etc. Scrum's entire premise of "get everyone together and talk" is the very thing which encourages people to talk. A lot. Without providing any suggestions to counteract it beyond "draw the head of the owl, now draw the rest"-type of advice.
>And how is having meetings a negative thing for remote work?
Meetings imply synchronous communication. Author is conflating remote with asynchronous, but nothing about the story implies collaboration needs to be synchronous / meeting-heavy either.
Because people lack discipline, will powder Scrum meetings on top of existing meetings, create more meetings from stand-ups because Scrum doesn't teach individuals to be disciplined, drag out the meetings, etc. Scrum's entire premise of "get everyone together and talk" is the very thing which encourages people to talk. A lot. Without providing any suggestions to counteract it beyond "draw the head of the owl, now draw the rest"-type of advice.
>And how is having meetings a negative thing for remote work?
Meetings imply synchronous communication. Author is conflating remote with asynchronous, but nothing about the story implies collaboration needs to be synchronous / meeting-heavy either.
I’ve rarely see stand ups end in 15 minutes. I’ve had stand ups that drag out for two and a half hours. When I say I need to go to get work done, I’m told this is work and you need to stay. So… many… meetings. And then I’m asked why I didn’t get my things done this sprint. Gee? I wonder why?
I've also seen these awful interminable standups. But i've also seen quick and effective standups, even on a big team. The difference is simply discipline.
If you ask a developer to talk about what they did yesterday, their instinct will be to waffle on, go into all sorts of interesting details, reflect on decisions they made, voice various concerns, etc. If you ask a whole team what they did, and they follow their instincts, you will have a long, boring, low-value meeting.
If the developers have a discipline of reporting only the most important things they can fit into two minutes - whether through self-discipline, or discipline imposed by a strict and heartless overlord - then you will have a short and effective meeting.
Discipline does not appear out of thin air! It has to be intentionally cultivated or imposed. Many teams don't do either. I think some just don't understand that this discipline is required; it simply doesn't occur to them that they should avoid waffling, because every standup they've ever seen is full of waffling. Others intellectually understand that they should follow that discipline, but their brain hasn't connected to their glands, so they don't actually do it, and they don't have a leader cruel enough to impose it.
The best example i have seen was at my first full-time programming job. We ended up with a team of about twenty developers, mostly senior. There was a tendency to waffling. Luckily, our team lead was an absolute bastard, who had no problem controlling it. First rule, stand in a circle. Second rule, stand next to the person you paired with yesterday. Third rule, if you are the first in your pair to speak, you have two minutes to say what you did and anything that others should know. The boss will have a timer running, and will cut you off without ceremony at the two minute mark. Fourth rule, if you are the second in your pair to speak, say "nothing to add", unless you do, in which case do it quickly. Fifth rule, if you have something you desperately want to say that will take you over two minutes, tell people you will send an email about it. Twenty people, ten pairs, twenty-minute standup, like clockwork.
So, if you are suffering from long and waffling standups, and if you also have retros, raise it at the retro. Ask people "do you think standups are too long?". Await the chorus of agreement. Tell them that the only solution is to strictly limit the amount of time people speak for. Some will complain that they have too many important things to say to be limited. Remind them that a limit is the only solution. Some will still complain. Bully them into submission or have them fired. Go on to enjoy fast and satisfying standups.
If you ask a developer to talk about what they did yesterday, their instinct will be to waffle on, go into all sorts of interesting details, reflect on decisions they made, voice various concerns, etc. If you ask a whole team what they did, and they follow their instincts, you will have a long, boring, low-value meeting.
If the developers have a discipline of reporting only the most important things they can fit into two minutes - whether through self-discipline, or discipline imposed by a strict and heartless overlord - then you will have a short and effective meeting.
Discipline does not appear out of thin air! It has to be intentionally cultivated or imposed. Many teams don't do either. I think some just don't understand that this discipline is required; it simply doesn't occur to them that they should avoid waffling, because every standup they've ever seen is full of waffling. Others intellectually understand that they should follow that discipline, but their brain hasn't connected to their glands, so they don't actually do it, and they don't have a leader cruel enough to impose it.
The best example i have seen was at my first full-time programming job. We ended up with a team of about twenty developers, mostly senior. There was a tendency to waffling. Luckily, our team lead was an absolute bastard, who had no problem controlling it. First rule, stand in a circle. Second rule, stand next to the person you paired with yesterday. Third rule, if you are the first in your pair to speak, you have two minutes to say what you did and anything that others should know. The boss will have a timer running, and will cut you off without ceremony at the two minute mark. Fourth rule, if you are the second in your pair to speak, say "nothing to add", unless you do, in which case do it quickly. Fifth rule, if you have something you desperately want to say that will take you over two minutes, tell people you will send an email about it. Twenty people, ten pairs, twenty-minute standup, like clockwork.
So, if you are suffering from long and waffling standups, and if you also have retros, raise it at the retro. Ask people "do you think standups are too long?". Await the chorus of agreement. Tell them that the only solution is to strictly limit the amount of time people speak for. Some will complain that they have too many important things to say to be limited. Remind them that a limit is the only solution. Some will still complain. Bully them into submission or have them fired. Go on to enjoy fast and satisfying standups.
Yeah, and not every scrum implementation needs to have a ton of meetings. We do 1 week sprints with no 15m daily stand-ups and a monthly or so retrospective. If someone is blocked I don't need them to wait to the next day to bring it up in standup. That's why we have group chat collaborarion tools after all right??
> Its the 15m daily everyday, then a retro and a planning once per sprint. I understand it is too much for a one-week sprint (as stated in the post) but how is that too much otherwise?
One place I worked at had two week sprints. The entirety of one day every sprint was spent on demo, retro, planning, commitment. But because the scrum master had to "build" a sprint and couldn't do that without knowing the size of tickets, there were two morning meetings every week to "analyse" tickets.
So you had: Week 1, 1 full day Scrum day, 2 half days. Week 2: 2 half days. So 3 days out of the 10 day sprint, so 30% time spent on Scrum.
Plus standups, so the hour before the standup nobody did anything (as judged by the number of PRs and comments and Slack activity) so that's an hour plus the time for standup every single day.
Maybe that's insanity, I mean I certainly thought so, but these things do happen.
One place I worked at had two week sprints. The entirety of one day every sprint was spent on demo, retro, planning, commitment. But because the scrum master had to "build" a sprint and couldn't do that without knowing the size of tickets, there were two morning meetings every week to "analyse" tickets.
So you had: Week 1, 1 full day Scrum day, 2 half days. Week 2: 2 half days. So 3 days out of the 10 day sprint, so 30% time spent on Scrum.
Plus standups, so the hour before the standup nobody did anything (as judged by the number of PRs and comments and Slack activity) so that's an hour plus the time for standup every single day.
Maybe that's insanity, I mean I certainly thought so, but these things do happen.
It's not so much time, it's more cognitive load. In scrum teams, it feels like you're always talking about the future. I think it just builds on the anxiety many people have frankly. It's just another attempt to unrealistically control the future.
The theory of a meeting is that the team will gather, go through a list of problems, solve those problems, which will keep the work moving forward.
Standup/scrum meetings should be about identifying the work that has stopped moving forward or is progressing slower than we’d like it to. The team might find a solution on the spot or a new ticket is created and assigned to someone to dig deeper for a solution. Probably that ticket is assigned to the Product Owner.
Most standups/scrum meetings are not about unsticking work. What they are about will vary depending on the particular dysfunction of the company, e.g. managers trying to make sure everyone is working.
Standup/scrum meetings should be about identifying the work that has stopped moving forward or is progressing slower than we’d like it to. The team might find a solution on the spot or a new ticket is created and assigned to someone to dig deeper for a solution. Probably that ticket is assigned to the Product Owner.
Most standups/scrum meetings are not about unsticking work. What they are about will vary depending on the particular dysfunction of the company, e.g. managers trying to make sure everyone is working.
it's because the 15 minute daily becomes a 30 minute daily
I typically get our 15 minute daily done in 3-5 minutes. About once a week someone has a more complex problem and just those people who can help with that problem stay after for 10 more minutes while the rest of the team goes back to work. As the team lead I get regular (3x/week) checkins to make sure people are doing work and not stuck, but it doesn't take a lot of time while people talk about projects the rest of the team isn't on.
Glad your team is not ridiculous. My team treats the daily as a report up to our boss, and our boss treats the daily as a time to go on a long monologue
I haven't ever seen an organization focused on "doing Scrum" that gets good results. However, some teams trying to deliver working software iteratively for their customers do find Scrum lets them deliver better than what they were doing before. But when Scrum becomes the goal and takes precedence over delivering software, it becomes a liability.
Getting everyone together for 15 minutes each day to ask, "How can we coordinate our work to make sure we are all doing our best to deliver the next piece the customer wants?" is valuable. Showing the customer what you built over the last week and asking if it needs any changes is also really valuable. Occasionally taking time as a team to discuss ways you can improve? Again, very valuable.
But the value comes from the collaboration each activity enables. Just because you have a 15-minute meeting you call a standup, a demo, or a retrospective doesn't mean people are actually collaborating in a valuable way.
Getting everyone together for 15 minutes each day to ask, "How can we coordinate our work to make sure we are all doing our best to deliver the next piece the customer wants?" is valuable. Showing the customer what you built over the last week and asking if it needs any changes is also really valuable. Occasionally taking time as a team to discuss ways you can improve? Again, very valuable.
But the value comes from the collaboration each activity enables. Just because you have a 15-minute meeting you call a standup, a demo, or a retrospective doesn't mean people are actually collaborating in a valuable way.
> Getting everyone together for 15 minutes each day to ask, "How can we coordinate our work to make sure we are all doing our best to deliver the next piece the customer wants?" is valuable.
But is it more valuable than the work that would have been produced by the e.g. 10 people, working for that hour in the flow every single day, if they hadn't been interrupted by that meeting? (Before/after the 15 minute meeting people are going to go for coffee, read emails, read the news etc., so you're probably losing about an hour of "flow" work by having the meeting.)
But is it more valuable than the work that would have been produced by the e.g. 10 people, working for that hour in the flow every single day, if they hadn't been interrupted by that meeting? (Before/after the 15 minute meeting people are going to go for coffee, read emails, read the news etc., so you're probably losing about an hour of "flow" work by having the meeting.)
That is an excellent point. If everyone knows exactly what the next most important thing is for the customer, and they are already working collaboratively to deliver it, maybe the meeting only takes 5 minutes. Or maybe the coordination happens informally just in the way they are working.
If you are trying to "do Scrum" it doesn't matter. You have a formal standup meeting because Scrum says to. That is how you end up with teams going around answering three questions that have absolutely no impact on anyone's work for the day. If you are trying to deliver the software, then you should be free to mix things up to better deliver.
Now in practice, most teams do benefit by spending a few minutes making sure everyone is on the same page for how they are going to work together efficiently for the day even if it is very short. I've seen some teams where most of their standups take 90 to 300 seconds...but the team felt it was a valuable way to collaborate. If the people in the daily standup don't feel it is a valuable use of their time, then it probably needs to change.
If you are trying to "do Scrum" it doesn't matter. You have a formal standup meeting because Scrum says to. That is how you end up with teams going around answering three questions that have absolutely no impact on anyone's work for the day. If you are trying to deliver the software, then you should be free to mix things up to better deliver.
Now in practice, most teams do benefit by spending a few minutes making sure everyone is on the same page for how they are going to work together efficiently for the day even if it is very short. I've seen some teams where most of their standups take 90 to 300 seconds...but the team felt it was a valuable way to collaborate. If the people in the daily standup don't feel it is a valuable use of their time, then it probably needs to change.
It is not only that, but I have known a lot of developers who simply hate the daily stand-ups, either because they were lead in the wrong way or because it did not match with their introvert personality, and that this added a lot of anxiety that it had a negative effect on their performance. Anxiety is an important factor in procrastination.
Too often a daily standup is really just a way to try to make sure everyone is busy. Asking everyone what they did yesterday, what they are going to today, and if they have any blockers, doesn't usually help the team coordinate their work. As you point out, it just puts people on the spot to try to say something that makes them sound important.
But if you ask the team, "What can we do today to make the most progress delivering this next tiny slice of functionality for the customer?" the discussion is centered around the work. Usually introverted people can participate in that conversation without being uncomfortable.
But if you ask the team, "What can we do today to make the most progress delivering this next tiny slice of functionality for the customer?" the discussion is centered around the work. Usually introverted people can participate in that conversation without being uncomfortable.
I have to say I’m pretty sick of scrum meetings and regular formal sprints. 80%+ of the meetings feel like a waste of time only adding context switching.
You could argue that such teams / enterprises just aren’t doing it right and that may well be true - but it’s what’s we’ve ended up with.
I long for the days of a (small!) daily standup coupled with simple Kanban and an issue backlog.
You could argue that such teams / enterprises just aren’t doing it right and that may well be true - but it’s what’s we’ve ended up with.
I long for the days of a (small!) daily standup coupled with simple Kanban and an issue backlog.
> I long for the days of a (small!) daily standup coupled with simple Kanban and an issue backlog.
Scrum is just that plus these things:
- showing the client or their in-house rep what you've done and getting their input on it
- checking in with yourself + your team that the systems are working or working out how to improve them
- some recommendations for how often to do those, and for how long
- definitions of two other roles: one to own shaping the backlog and one to work as "manager" - does soft-skills people stuff, liases around the company to solve blockages, trains the developers who need it how to do this last bit themselves.
Scrum is informal, and the only strict parts are designed to monkey about with traditional business structures (business analysts, project management, line managers). When I say "monkey about with" I mean this: change the roles and lines of communication to reduce silo-ing.
Scrum is just that plus these things:
- showing the client or their in-house rep what you've done and getting their input on it
- checking in with yourself + your team that the systems are working or working out how to improve them
- some recommendations for how often to do those, and for how long
- definitions of two other roles: one to own shaping the backlog and one to work as "manager" - does soft-skills people stuff, liases around the company to solve blockages, trains the developers who need it how to do this last bit themselves.
Scrum is informal, and the only strict parts are designed to monkey about with traditional business structures (business analysts, project management, line managers). When I say "monkey about with" I mean this: change the roles and lines of communication to reduce silo-ing.
> I long for the days of a (small!) daily standup coupled with simple Kanban and an issue backlog.
That's what we do at my company and it works pretty well. No process is perfect, but we really try to keep meetings to a minimum for devs. Daily standup is literally 5 minutes.
That's what we do at my company and it works pretty well. No process is perfect, but we really try to keep meetings to a minimum for devs. Daily standup is literally 5 minutes.
You’re making me envious. Before I went consulting that is all I knew, now there is only darkness.
Well-written item.
I disagree with some of it. Scrum does a pretty good job keeping things flowing when it isn't hijacked for political reasons. Unfortunately, it is usually hijacked for political reasons.
I'd worked one contract project almost 3 years under Scrum and it went great as a B2B setup. But I've seen internal projects fail miserably because Scrum got hijacked.
I disagree with some of it. Scrum does a pretty good job keeping things flowing when it isn't hijacked for political reasons. Unfortunately, it is usually hijacked for political reasons.
I'd worked one contract project almost 3 years under Scrum and it went great as a B2B setup. But I've seen internal projects fail miserably because Scrum got hijacked.
Scrum is fine. The problem is making it too formal and having the wrong people involved in it. It is a way for engineers to get things done. That is all.
I feel like Scrum was one of the biggest, long-running slow motion mistakes I've ever seen. It was well intentioned, but retrospectively pretty garbage. The best faint praise you can give it I think was that it was better than planning who was working on what for each step of a project for a year out, but agile on its own was sufficient to convince everyone to fix that problem.
Scrum kind of ended up a local maxima that a lot of good people seem to get stuck in for a very long time.
Scrum kind of ended up a local maxima that a lot of good people seem to get stuck in for a very long time.
I have had good experience with Scrum when all the participants had a common grounding in it, and worked together toward its goal of frequent delivery of valuable software. But I’ve also had bad experiences, in which the company claimed or pretended to do scrum but left out one or more key parts. The main thing you need, and that we don’t have at my current company, is someone to act as the product owner, the person who says what they want built. The key relationship is between Product (who wants a thing built) and Engineering (who build the thing). Without that, we have a lot of performative number-watching and busy-keeping.
Scrum, Kamban, Agile, manifestos ... to h*l with all of them. I just want to get things done and go home.
That is why I like Kanban: it gives me the next thing to work on and then I get to go home knowing I worked on something important. Scrum puts in those arbitrary sprint deadlines, but work never lines up to be finished in 2 weeks so either I'm scrambling to get work done anyway, or I'm out of work that can be done before the end (the process never really accounts for work crossing boundaries even though it always does)
progomofo's save us!
Scrum is an industry. Its primary goal is to make scrum your focus. It transforms your team to a process oriented shitshow that squashes innovators and elevates morons who cling to process.
Similar discussion last couple of days:
https://news.ycombinator.com/item?id=37289151
https://news.ycombinator.com/item?id=37289151
Big brain programmers, “Well actually, the most important part of our job isn’t writing code.”
Big brain programmers when using scrum, “Not like that!”
Big brain programmers when using scrum, “Not like that!”
Scrum might not be the right fit for every situation. It depends on stuff like project size, complexity, how your organization rolls, flexibility needs, team size and distribution, and whether your project is stable or unpredictable. If your project is huge, has lots of moving parts, or your organization isn't keen on change, scrum definitely is not the right one.
Guess I’ll yell into the void too haha. Never was a huge fan of scrum, but I get why it’s there. Not every team is blessed with very senior and, frankly, trustworthy engineers. I was once one, so were you. Lacking that, you need guardrails for your developing engineers. Scrum is ONE such guardrail, a micro-management process where one is needed. The better guardrail is actually pairing up your developing engineers with helpful senior engineers indefinitely, but the less functional orgs out there don’t use senior engineers like this.
The ideal team just gets work done. They communicate status and progress. They deliver. At the end of the day, the powers that be just want the results that they are paying for. They don’t care about scrum or Kanban or whatever (if they do, I’m sorry, that sounds bad— they shouldn’t). All they care about is results. It’s when results don’t happen that management freaks out, and the snake oil of scrum sounds appetizing. My $0.02.
The ideal team just gets work done. They communicate status and progress. They deliver. At the end of the day, the powers that be just want the results that they are paying for. They don’t care about scrum or Kanban or whatever (if they do, I’m sorry, that sounds bad— they shouldn’t). All they care about is results. It’s when results don’t happen that management freaks out, and the snake oil of scrum sounds appetizing. My $0.02.
it's primarily a communication framework. you need to pair it with something like OKRs.
Then you have two problems.
Throw in a mandatory return to an open office plan and you've got a deal.