You don’t need standups(medium.com)
medium.com
You don’t need standups
https://medium.com/@jsonpify/you-dont-need-standup-9a74782517c1
340 comments
"working on bugs" is not a great update, it's opaque and doesn't help your team or your leader get a picture of what you're struggling with.
"I tried this and this and measured this latency from the application and suspect it's a race condition, I checked this code and feel like I'm on the right track, and if someone wants to take a second set of eyes on my bug I would appreciate it" is a much much better update. Stand ups are about communication with your peers. Having to hunt down tasks you're working on and reading through each task can create an unnecessary mental load that can be solved with a single 1 minute "ESPN sportscenter edition" summary of your current issues.
However, blockers do create a sense of ineffectiveness. Especially on small workload teams where task swarming doesn't net too much benefit. "Hey I am still waiting on $vendor to configure their service" or "Still waiting on netops to tag $port for vlan blah" or "Procurement put in a PO for $hardware, still waiting on it", there are times when we are waiting for something, and there's nothing able to be done currently. Especially when the immediate tasks are already doled out and your leader doesn't want to pull more work into the current sprint. Subsequent tasks could be too large or complex to be pulled in. Current tasks could be unable to be broken up any further, to which I have to say, pair program until your blockers dissipate. We do this at my current job, and it really creates tangible benefit.
As for TFA's bulletpoints on why sprints can be bad, most of their arguments are bunk except for this one:
> 4. Extroverts thrive at stand-ups, planning, and retros.
Not everyone is great at self-selling, and people who move up in the company are the ones who hype their personal brand, not necessarily those who are the best at their roles. I don't know how to solve this as it's a personality issue, but I do think it can be a problem for a lot of businesses and teams.
"I tried this and this and measured this latency from the application and suspect it's a race condition, I checked this code and feel like I'm on the right track, and if someone wants to take a second set of eyes on my bug I would appreciate it" is a much much better update. Stand ups are about communication with your peers. Having to hunt down tasks you're working on and reading through each task can create an unnecessary mental load that can be solved with a single 1 minute "ESPN sportscenter edition" summary of your current issues.
However, blockers do create a sense of ineffectiveness. Especially on small workload teams where task swarming doesn't net too much benefit. "Hey I am still waiting on $vendor to configure their service" or "Still waiting on netops to tag $port for vlan blah" or "Procurement put in a PO for $hardware, still waiting on it", there are times when we are waiting for something, and there's nothing able to be done currently. Especially when the immediate tasks are already doled out and your leader doesn't want to pull more work into the current sprint. Subsequent tasks could be too large or complex to be pulled in. Current tasks could be unable to be broken up any further, to which I have to say, pair program until your blockers dissipate. We do this at my current job, and it really creates tangible benefit.
As for TFA's bulletpoints on why sprints can be bad, most of their arguments are bunk except for this one:
> 4. Extroverts thrive at stand-ups, planning, and retros.
Not everyone is great at self-selling, and people who move up in the company are the ones who hype their personal brand, not necessarily those who are the best at their roles. I don't know how to solve this as it's a personality issue, but I do think it can be a problem for a lot of businesses and teams.
That's useless because everybody else tunes out. Nobody cares what debugging methods you tried on some project they've never touched. If you need help you can just ask somebody.
I think your team is too big then. Don't have company wide standups, have a standup per team and possibly role. If you're working on a web stack have a standup where the backend devs talk, one for the DBAs (if that's a thing you have) one for the front-end people... If there's someone in a product manager role they might want to attend all the meetings but likely not.
If a clear majority of the audience isn't interested in your status then you're just burning hours.
Also a standup with 40 or 50 people is just plain silly. I worked in gaming a few years ago and our standup was a full game team, the artists, designers, QA, server-devs, client-devs and our stats guy all spoke. It was a bit interesting to see what artists were doing but totally unnecessary for me to hear anything anyone said except the two other people I worked with, and we communicated well outside of the standup anyways.
If a clear majority of the audience isn't interested in your status then you're just burning hours.
Also a standup with 40 or 50 people is just plain silly. I worked in gaming a few years ago and our standup was a full game team, the artists, designers, QA, server-devs, client-devs and our stats guy all spoke. It was a bit interesting to see what artists were doing but totally unnecessary for me to hear anything anyone said except the two other people I worked with, and we communicated well outside of the standup anyways.
>If a clear majority of the audience isn't interested in your status then you're just burning hours.
From my understanding stand ups are not supposed to be status reports. They tend to turn into them though as it seems the most common format is 1) what did you work on yesterday, 2) what are you working on today, 3) what's blocking you?
I prefer daily stand ups (near the onset of the day) for small teams to be 1) what's our goal for today? 2) what might block us or slow us down? 3) how are we going to tackle our goal?
When stand ups start feeling like justifying your existence then morale drops, [looking] busy work increases, and too much time is spent on CYA. Focus on solving problems not explaining them.
From my understanding stand ups are not supposed to be status reports. They tend to turn into them though as it seems the most common format is 1) what did you work on yesterday, 2) what are you working on today, 3) what's blocking you?
I prefer daily stand ups (near the onset of the day) for small teams to be 1) what's our goal for today? 2) what might block us or slow us down? 3) how are we going to tackle our goal?
When stand ups start feeling like justifying your existence then morale drops, [looking] busy work increases, and too much time is spent on CYA. Focus on solving problems not explaining them.
> what's our goal for today?
The same as it was yesterday or whenever the last planning session happened.
Like TFA said, the team, as a whole, shouldn’t be changing priorities like socks.
The same as it was yesterday or whenever the last planning session happened.
Like TFA said, the team, as a whole, shouldn’t be changing priorities like socks.
If your goal for the sprint is "build widget" then your goal for the day should be "build part 3". You don't change priorities each day, you change how far along you are and where you expect to get to.
The term "Sprint" makes me cringe, it's meaningless in my experience. It doesn't effectively identify goals or deadlines. It's a stupid techie/hipster term that no one apparently pays attention to.
> The term "Sprint" makes me cringe,
Tried that once as a team. Then it became a derogatory joke word, haven't sprinted since. Well only in real life when playing tag with my kids.
Estimating, delivering on time, working together, can be hard. Someone deciding to rename it with a new label, doesn't usually solve the problem, though now everyone has a new label to make fun of.
Tried that once as a team. Then it became a derogatory joke word, haven't sprinted since. Well only in real life when playing tag with my kids.
Estimating, delivering on time, working together, can be hard. Someone deciding to rename it with a new label, doesn't usually solve the problem, though now everyone has a new label to make fun of.
If you're doing kanban and work in an environment where product direction changes quickly, then definitely this.
If your standup can be replaced with everyone posting on a slack channel, then it's just a status update as there's no discussion and alignment happening, which are the valuable parts.
Most teams should experiment with their process more.
If your standup can be replaced with everyone posting on a slack channel, then it's just a status update as there's no discussion and alignment happening, which are the valuable parts.
Most teams should experiment with their process more.
The standup should be with the people on the current sprint. Alignment should have happened in earlier planning stages. "Discussion" is (should be) highly structured in a daily standup and any discussion that is like a dialog should be placed in the parking lot until the meeting ends, when only those interested in that discussion need to attend.
Goal for today - get stuff done. finish up things we planned for the week.
Blockers - hopefully blockers are identified and communicated right away vs waiting for standups.
How to get stuff done - less unnecessary meetings and processes. Async communication.
Blockers - hopefully blockers are identified and communicated right away vs waiting for standups.
How to get stuff done - less unnecessary meetings and processes. Async communication.
Though what you are doing today is a direct result of what happened yesterday.
My team is about 8 people, but we work on about 15 projects, some with about 3 FTE, some take up a few hours per week of one person on average. It happens that someone works on a project on his own for months at a time. There is some shared tech between them, but also a lot of specific stuff.
I thought that was the kind of situation he meant, where people zone out because they don't work on that project, but who knows.
You shouldn't assume too much about the environment other people work in.
I thought that was the kind of situation he meant, where people zone out because they don't work on that project, but who knows.
You shouldn't assume too much about the environment other people work in.
>
I think your team is too big then. Don't have company wide standups, have a standup per team and possibly role. If you're working on a web stack have a standup where the backend devs talk, one for the DBAs (if that's a thing you have) one for the front-end people... If there's someone in a product manager role they might want to attend all the meetings but likely not.
This would be better solved by hosting specific IRC channels for those roles and having occasional role-specific meets/lunches to introduce new people.
This would be better solved by hosting specific IRC channels for those roles and having occasional role-specific meets/lunches to introduce new people.
I think that's either a team culture issue, a management issue, or a business culture issue. Teams I've worked on have had no issue brainstorming ideas for a person who's stumped.
Now, I'm not totally defending standups here, I've been on teams where daily standups are a stuffy formality, and they are miserable. I've also had the pleasure of being on teams where weekly standups were implemented, and they were an absolute delight and completely useful.
I will qualify all of my opinions with the fact that the best teams I've worked with implement Kanban, so there is no sprint planning. We just pull off backlog and work with weekly standups. There's way way less overhead, with some tradeoffs.
I also definitely think that certain team cultures are completely incompatible with standups, to the point that you receive negative benefit from implementing them. If you have a lot of people who are of the type "my responsibility ends where my story points end", I am pretty sure you will end up have a bad time doing standups.
Now, I'm not totally defending standups here, I've been on teams where daily standups are a stuffy formality, and they are miserable. I've also had the pleasure of being on teams where weekly standups were implemented, and they were an absolute delight and completely useful.
I will qualify all of my opinions with the fact that the best teams I've worked with implement Kanban, so there is no sprint planning. We just pull off backlog and work with weekly standups. There's way way less overhead, with some tradeoffs.
I also definitely think that certain team cultures are completely incompatible with standups, to the point that you receive negative benefit from implementing them. If you have a lot of people who are of the type "my responsibility ends where my story points end", I am pretty sure you will end up have a bad time doing standups.
In some previous team, I realized that some people working on very long tasks just gave bullshit updates. What they explained was interesting, it gave a sense of progress, and they communicated well.
Too well perhaps, their small talk was on super minor or even unrelated stuff that they saw the previous day.
They were doing mainly exploratory work, and it made no sense to bring on board other people before they settled on a direction themselves.
I think ultimately a one size fits them all approach only “works” when the people on the fringe also play the game and bullshit (in a good light) their way around.
Too well perhaps, their small talk was on super minor or even unrelated stuff that they saw the previous day.
They were doing mainly exploratory work, and it made no sense to bring on board other people before they settled on a direction themselves.
I think ultimately a one size fits them all approach only “works” when the people on the fringe also play the game and bullshit (in a good light) their way around.
It's a good idea to waste valuable engineering time with "bullshit" (in a good light) small talk? OK…
I likely will never understand the great minds behind management.
I likely will never understand the great minds behind management.
It's a trade off. Some of the communication is very valuable, and needs to happen for coordination, knowledge sharing, etc. The potential harm of that communication not happening is great, the risk of having a meeting go 15 minutes longer is worth trying to avoid (hence the article) but much smaller.
However, if only some people speak that can create divisions in the team, or make it look like the speakers are the leading members when that may or may not be true. So to prevent that dynamic everyone says something, and people can help the team function better by coming up with a nifty one minute oration.
Ultimately making software is a human endeavor. Sometimes a little small talk prevents the humans from feeling bad and not making software. Sometimes it has the opposite effect.
The best managers figure out which case is true at a specific time and place and adapt. Good managers just have to pick what risks to take and live with the outcome.
However, if only some people speak that can create divisions in the team, or make it look like the speakers are the leading members when that may or may not be true. So to prevent that dynamic everyone says something, and people can help the team function better by coming up with a nifty one minute oration.
Ultimately making software is a human endeavor. Sometimes a little small talk prevents the humans from feeling bad and not making software. Sometimes it has the opposite effect.
The best managers figure out which case is true at a specific time and place and adapt. Good managers just have to pick what risks to take and live with the outcome.
Are stand up meetings the correct venue for brainstorming?
No, but they can spur an interested subset of people to brainstorm after the standup ends.
Maybe not, but if your peer said "hey can someone help me with this task" in a standup, wouldn't you want to help them once the meeting is over?
Replace that with asking for help in slack or whatever, and you don't need a standup. And you also get help as soon as people's time is available, not the next day.
No, those are things you want to take "offline" or "to the parking lot".
1. Isn't the standup usually the place you're told to initially ask for that help?
2. Aren't most people, at least the developers/designers in the same standup, supposed to be working on the same project?
2. Aren't most people, at least the developers/designers in the same standup, supposed to be working on the same project?
Don't wait until the standup to ask for help if you don't have to.
I'm also confused why OP is having standup eith people who havent even heard of the project he's working on. Doesn't sound like he's working on the same product as the other developers.
I'm also confused why OP is having standup eith people who havent even heard of the project he's working on. Doesn't sound like he's working on the same product as the other developers.
+1
The standup should be the place of last resort for bringing up barriers impeding a task. The more resourceful you can be at solving a problem/brainstorming outside of the standup the better ime
The standup should be the place of last resort for bringing up barriers impeding a task. The more resourceful you can be at solving a problem/brainstorming outside of the standup the better ime
"Don't wait until the standup to ask for help if you don't have to."
I didn't mean to imply that, but one of the purposes of stand-up is to give a place for that to happen.
I didn't mean to imply that, but one of the purposes of stand-up is to give a place for that to happen.
#2 never happened at any job I've had. It was always the entire team and we all had different projects. Sometimes entirely different applications.
That sounds like you were all on different teams, in the sense being used here, and probably shouldn't have all been in the same standup together apart from maybe a once-a-week catchup.
A friend worked in a startup where 20-30 people of the tech dept. had a hour long standup. QA, sysadmins, developers - all had their 2 minutes to essentially do a daily status update.
I'm glad I haven't lived through that hell.
I'm glad I haven't lived through that hell.
Wow that sounds like a nightmare. My standups have almost always been limited to just one team, usually 5-8 people.
But you are in the same team in all the other senses, mostly that these are the people you work with in the long term. Some projects you do alone, some with Bob, others with almost everyone, but the team members want to feel like a team and have an idea of what everyone's working on.
That reminds me of a job that wanted detailed reports every day. So I ended them with "and I spent the last hour of my work time writing this report".
They eventually saw the light. I was one of the two people charged with firing the incompetents.
They eventually saw the light. I was one of the two people charged with firing the incompetents.
> Not everyone is great at self-selling, and people who move up in the company are the ones who hype their personal brand, not necessarily those who are the best at their roles. I don't know how to solve this as it's a personality issue, but I do think it can be a problem for a lot of businesses and teams.
Oh! Just don't give the show people a stage.
You know a stage — like daily standups or so…
Oh! Just don't give the show people a stage.
You know a stage — like daily standups or so…
[deleted]
> ...there are times when we are waiting for something, and there's nothing able to be done currently. Especially when the immediate tasks are already doled out and your leader doesn't want to pull more work into the current sprint. Subsequent tasks could be too large or complex to be pulled in. Current tasks could be unable to be broken up any further...
I find this concept very strange. Maybe it's just me, but aside from one time where the agency I worked for briefly had no ongoing client work, I don't think I've ever felt like there was no work for me to do. At all my past jobs we have always had a large list of small, low-priority tickets that people can pull from if they are blocked on their larger tasks. Is this not the case at some companies?
I find this concept very strange. Maybe it's just me, but aside from one time where the agency I worked for briefly had no ongoing client work, I don't think I've ever felt like there was no work for me to do. At all my past jobs we have always had a large list of small, low-priority tickets that people can pull from if they are blocked on their larger tasks. Is this not the case at some companies?
I have no direct experience, so take this with a grain of salt, but I think this type of thing only really tends to pop up in large multinationals that literally just end up with too many moving parts at certain points to be able to keep every gear spinning at once. The business process dependency tree is just plain old _too complex_ to get 100% utilization of every piece at every point in time. It's more profitable for the business at that scale to have a certain role just "idle" for a period of time rather than fundamentally change business processes to maximize individual resource utilization.
> "working on bugs" is not a great update, it's opaque and doesn't help your team or your leader get a picture of what you're struggling with.
Don't take people so literally.
Don't take people so literally.
> Having to hunt down tasks you're working on and reading through each task can create an unnecessary mental load that can be solved with a single 1 minute "ESPN sportscenter edition" summary of your current issues.
Some people indeed need spoon feeding. That above statement only strengthens my view.
Or how do we interpret "unnecessary mental load" out of the mouth of someone likely in management when it comes to simply reading a task board?
Sometimes I really wonder what most of the management is good for… Really.
Running around, having a lot of meetings, but nevertheless not knowing what is happening all around them, so they have to ask every day anew…
But now I understand: It's only a unnecessary (too height?)^^ mental load to read the task board. :-)
Some people indeed need spoon feeding. That above statement only strengthens my view.
Or how do we interpret "unnecessary mental load" out of the mouth of someone likely in management when it comes to simply reading a task board?
Sometimes I really wonder what most of the management is good for… Really.
Running around, having a lot of meetings, but nevertheless not knowing what is happening all around them, so they have to ask every day anew…
But now I understand: It's only a unnecessary (too height?)^^ mental load to read the task board. :-)
That was my thought too.
If it's an unnecessary mental load (for developers or managers) to find out about the tasks currently being worked on and what they are, then the problem is with your work/task tracking system, not with your developers.
If it's an unnecessary mental load (for developers or managers) to find out about the tasks currently being worked on and what they are, then the problem is with your work/task tracking system, not with your developers.
>Not everyone is great at self-selling, and people who move up in the company are the ones who hype their personal brand, not necessarily those who are the best at their roles. I don't know how to solve this as it's a personality issue
You need a strong manager or leader willing and able to reign individuals in. This person needs to open the discussion space to others and prevent the loudest (and it sure seems often like the most opinionated) from interrupting.
You need a strong manager or leader willing and able to reign individuals in. This person needs to open the discussion space to others and prevent the loudest (and it sure seems often like the most opinionated) from interrupting.
It feels like the article is trying to sell a _different paradigm_ and you are arguing why the individual steps won't work under the current paradigm...
I agree, what you describe provides an opportunity to solve problems - far from useless! Certainly there's judgement needed in terms of where something becomes too detailed or digresses too far but that comes down to practice and intuition and feedback to get a consensus.
I agree with you. But I think the problem is that most people don't approach a problem like you explained in your first sentence. It's more, "I'll be googling and reading Stack Overflow for the answer and guessing until I find it". I think it's partially due to a lack of rigor that has crept into coding.
You can learn coping strategies to get better at it though.
What if I don't want a team mate to look at something I'm working on? What if I just want to focus on building, not explaining and sharing?
The current trend of "agile" is just another form of micro management. It's not good for the programmers at all, it's only good for product owners and team leads who are coordinating resources. Because it's micro management. We just call it something else now.
It forces developers to share every mistake they make, it makes them share if they are thinking incorrectly about something, it makes them easily replaceable.
Let's just stop pretending it's good for the programmers, alright?
The current trend of "agile" is just another form of micro management. It's not good for the programmers at all, it's only good for product owners and team leads who are coordinating resources. Because it's micro management. We just call it something else now.
It forces developers to share every mistake they make, it makes them share if they are thinking incorrectly about something, it makes them easily replaceable.
Let's just stop pretending it's good for the programmers, alright?
Screw these other commenters saying you're a stubborn introvert. If I had a company, I would hire you. I have the same view.
Micro management erodes trust, which deskills programmers. If you know the exact bounds of what a programmer that you hired can do, then they can never do anything exceptional. I understand large companies need reliable workers because they are working on cornering their market, but for startups, or just for anyone going after something that's never been done, you need to take a risk, and that risk includes your programmers as well.
What's more, there's a small but important difference between being told to go to a meeting and converse with other employees, or CEOs, or clients to get some external validation on your work, and choosing to seek out those people of your own free will. I agree that no programmer can silo themselves off and "do work", but that doesn't mean we have to infantilize them and spoonfeed them their feedback.
A fisherman knows how to catch fish, so why are you telling him what lure to use and how to cast his line rather than just letting natural competition takes it's course and allowing him to become jealous of the better fisherman and having him improve. "Didn't catch a fish today" "well you should've used the red lures like Bob does". Do you want a better fisherman? or do you want the same fisherman?
Micro management erodes trust, which deskills programmers. If you know the exact bounds of what a programmer that you hired can do, then they can never do anything exceptional. I understand large companies need reliable workers because they are working on cornering their market, but for startups, or just for anyone going after something that's never been done, you need to take a risk, and that risk includes your programmers as well.
What's more, there's a small but important difference between being told to go to a meeting and converse with other employees, or CEOs, or clients to get some external validation on your work, and choosing to seek out those people of your own free will. I agree that no programmer can silo themselves off and "do work", but that doesn't mean we have to infantilize them and spoonfeed them their feedback.
A fisherman knows how to catch fish, so why are you telling him what lure to use and how to cast his line rather than just letting natural competition takes it's course and allowing him to become jealous of the better fisherman and having him improve. "Didn't catch a fish today" "well you should've used the red lures like Bob does". Do you want a better fisherman? or do you want the same fisherman?
It's not micromanagement. It's working as a team. I don't really understand what you're saying. Sometimes programmers are proud and don't want to seek out help. They'd rather spin their wheels trying to debug something than stoop to asking someone else for help. It's dumb but it happens.
I'm not GP, but let me try to explain.
The key is to treat people as responsible adult professionals with the best intentions. This way communication will happen organically and proactively. For organic proactive communication async channels are ideal. When you bump into a problem you need help with you message someone you think can help. They will eventually see your message and find the time to reply (seeing and replying won't always happen at the same time). This type of communication is extremely efficient and sustainable. Sync communication also has its benefits and they're trivial to set up using async comms if/when the need arises. This does not mean that recurring synchronous communications aka. standups are bad per se but their value is highly context dependent and oftentimes they are not the best solution.
On the other hand if you treat people as irresponsible children that needs constant supervision then, in my humble opinion, nothing will save you on the long run and implementing mandatory protocols like a daily standup are just surface treatments.
The key is to treat people as responsible adult professionals with the best intentions. This way communication will happen organically and proactively. For organic proactive communication async channels are ideal. When you bump into a problem you need help with you message someone you think can help. They will eventually see your message and find the time to reply (seeing and replying won't always happen at the same time). This type of communication is extremely efficient and sustainable. Sync communication also has its benefits and they're trivial to set up using async comms if/when the need arises. This does not mean that recurring synchronous communications aka. standups are bad per se but their value is highly context dependent and oftentimes they are not the best solution.
On the other hand if you treat people as irresponsible children that needs constant supervision then, in my humble opinion, nothing will save you on the long run and implementing mandatory protocols like a daily standup are just surface treatments.
Developers come in all shapes and sizes. Some barely use Slack and are laconic on standups.
The whole Agile (tm) is a surface treatment for having a grasp on complexity. It's more of a ritual thing than an exact science.
The introvert developers are sometimes so introvert and protective that they deliver at the last possible moment stuff that doesn't follow any conventions set by the team and in some cases makes stuff explode after merging.
I would rather have them forced to give me an update and subsequently a pretext to get a peek at their work under the guise of helping than have them fail the whole team. Eventually they shed their impostor syndrome, or at least I hope they do.
Personally, I've been on both sides of this pattern and I would rather still have standups.
As for supervision, I've seen teams selling bullshit with glitter on standups if there were transitional people or stakeholders. Then it's nothing more than the usual status update dance.
The whole Agile (tm) is a surface treatment for having a grasp on complexity. It's more of a ritual thing than an exact science.
The introvert developers are sometimes so introvert and protective that they deliver at the last possible moment stuff that doesn't follow any conventions set by the team and in some cases makes stuff explode after merging.
I would rather have them forced to give me an update and subsequently a pretext to get a peek at their work under the guise of helping than have them fail the whole team. Eventually they shed their impostor syndrome, or at least I hope they do.
Personally, I've been on both sides of this pattern and I would rather still have standups.
As for supervision, I've seen teams selling bullshit with glitter on standups if there were transitional people or stakeholders. Then it's nothing more than the usual status update dance.
If the team is truly a team, that kind of goal-oriented facilitation really isn't necessary. While it's good to have some sort of institutions within a team, good quality teams tend to be self-organizing. If employers focused more on creating quality teams, they wouldn't need tools like Scrum to mitigate problems that might not even exist (the fact of which can easily be swept under the rug by rigid adherence to such systems).
Sometimes I run into a really tough problem, and good team members don't need to have a system to force this behavior. In fact, I'd say it's within the prerogative of a developer to withhold problems they believe they can work through so that other cooks don't jump in to crowd the kitchen, and so that managers don't make a counterproductive decision to dislodge a perceived roadblock.
As you say, some programmers are proud and don't want to seek out help. Does this reflect in their work? If it doesn't, then who cares? And if it does, then management should resolve the issue by whatever means necessary. Trying to force "I'm facing a tough bug" out of people is not the way. Creating a culture that fosters collaboration, on the other hand, seems more effective in getting people to seek genuine help.
Just make standups about the people. Hire good engineers or engineers with potential and invest in them, and allow their team to function naturally. Remove the goal-orientation from standups and just give teams 10 to 15 minutes out of the day to just shoot the shit. Having to make it about going person-by-person and saying "Yesterday, I did X...", "Today, I'm doing Y...", or "I ran into some issues with X-thing", is really just like being back in elementary school where the teacher picks on students. I know some people don't seem to feel this way, but I'm really not that interested in going back to the 3rd grade.
Sometimes I run into a really tough problem, and good team members don't need to have a system to force this behavior. In fact, I'd say it's within the prerogative of a developer to withhold problems they believe they can work through so that other cooks don't jump in to crowd the kitchen, and so that managers don't make a counterproductive decision to dislodge a perceived roadblock.
As you say, some programmers are proud and don't want to seek out help. Does this reflect in their work? If it doesn't, then who cares? And if it does, then management should resolve the issue by whatever means necessary. Trying to force "I'm facing a tough bug" out of people is not the way. Creating a culture that fosters collaboration, on the other hand, seems more effective in getting people to seek genuine help.
Just make standups about the people. Hire good engineers or engineers with potential and invest in them, and allow their team to function naturally. Remove the goal-orientation from standups and just give teams 10 to 15 minutes out of the day to just shoot the shit. Having to make it about going person-by-person and saying "Yesterday, I did X...", "Today, I'm doing Y...", or "I ran into some issues with X-thing", is really just like being back in elementary school where the teacher picks on students. I know some people don't seem to feel this way, but I'm really not that interested in going back to the 3rd grade.
>What if I don't want a team mate to look at something I'm working on?
>What if I just want to focus on building, not explaining and sharing?
>it makes them share if they are thinking incorrectly about something
>it makes them easily replaceable
I think the thing that makes you easily replaceable is if you constantly are thinking incorrectly about something and are unwilling to be corrected by teammates because you aren't able to explain what you're doing and share your thought process. Writing buggy code and refusing to work with your team is a primo way to get canned. Owning the fact that there's time constraints and imperfect code and minimizing the risks taken and assumptions made by understanding the architecture is valuable.
Stand ups might not be the way to do it, but if even the prospect of sharing your thought process and explaining what you did strikes you as being 'micro managed', well.......
>What if I just want to focus on building, not explaining and sharing?
>it makes them share if they are thinking incorrectly about something
>it makes them easily replaceable
I think the thing that makes you easily replaceable is if you constantly are thinking incorrectly about something and are unwilling to be corrected by teammates because you aren't able to explain what you're doing and share your thought process. Writing buggy code and refusing to work with your team is a primo way to get canned. Owning the fact that there's time constraints and imperfect code and minimizing the risks taken and assumptions made by understanding the architecture is valuable.
Stand ups might not be the way to do it, but if even the prospect of sharing your thought process and explaining what you did strikes you as being 'micro managed', well.......
This mentality is the root of the problem (from the dev perspective). The GP commenter is saying "these processes don't help me to feel that I've done my job better."
And you respond with "Well, this sounds like you aren't good at proving you're not a _complete idiot_."
And you respond with "Well, this sounds like you aren't good at proving you're not a _complete idiot_."
> it makes them easily replaceable
I don't think a developer is ever "easily replacable" (discounting obviously incompetent people which shouldn't have been hired in the first place). As soon as we join a team we start accumulating all kinds of knowledge about the codebase, the domain, the history, company politics, etc. Replacing with a new hire is back to square one. It's expensive, disturbing, and generally undesirable from a company perspective.
Yet you can't blame companies for trying to make each developer "as replacable as possible". There is always an employee churn -- people leaving for all kinds of reasons, some after a short while, some after decades -- and new people being hired. It's in the company's best interest to minimize the cost of this entirely predictable churn.
Actually, I think it's in the best interest of the developer as well. The more replacable we can make ourselves, the easier it is to leave to work on new, exciting projects. The more irreplacable, the more likely we are to be the dude who spent the past ten years maintaining the module written in $OBSOLETE_LANGUAGE_OR_FRAMEWORK because everyone else left and nothing was really documented.
I don't think daily stand-ups is really the tool for making yourself replacable since the information transmitted tends to be very short lived. Good code structure, well maintained tests, rock solid build env, good documentation of purpose, requirements, design considerations ... we never quite arrive at that nirvana but it would be the goal to aim for.
I don't think a developer is ever "easily replacable" (discounting obviously incompetent people which shouldn't have been hired in the first place). As soon as we join a team we start accumulating all kinds of knowledge about the codebase, the domain, the history, company politics, etc. Replacing with a new hire is back to square one. It's expensive, disturbing, and generally undesirable from a company perspective.
Yet you can't blame companies for trying to make each developer "as replacable as possible". There is always an employee churn -- people leaving for all kinds of reasons, some after a short while, some after decades -- and new people being hired. It's in the company's best interest to minimize the cost of this entirely predictable churn.
Actually, I think it's in the best interest of the developer as well. The more replacable we can make ourselves, the easier it is to leave to work on new, exciting projects. The more irreplacable, the more likely we are to be the dude who spent the past ten years maintaining the module written in $OBSOLETE_LANGUAGE_OR_FRAMEWORK because everyone else left and nothing was really documented.
I don't think daily stand-ups is really the tool for making yourself replacable since the information transmitted tends to be very short lived. Good code structure, well maintained tests, rock solid build env, good documentation of purpose, requirements, design considerations ... we never quite arrive at that nirvana but it would be the goal to aim for.
Do you care how useful the thing you're building is for the people you're building it for? How well it fits in with what other people on the team are building? If any of your teammates have ideas that could be helpful, or have learned things that might be of interest to you?
I've often been the guy who comes in to help untangle a messy code base, and an entrenched "just let me build shit" attitude appears to be a chief predictor of unextensible and inflexible design. Even when not in a managerial role, I don't like to see people working in silos because experience has taught me that I'm gonna have to deal - as a fellow dev - with repercussions of poor design sooner or later.
I've often been the guy who comes in to help untangle a messy code base, and an entrenched "just let me build shit" attitude appears to be a chief predictor of unextensible and inflexible design. Even when not in a managerial role, I don't like to see people working in silos because experience has taught me that I'm gonna have to deal - as a fellow dev - with repercussions of poor design sooner or later.
If daily standup has any role whatsoever in those questions, your process is horrifically broken.
I'm not sure how much that micro-managing aspect is peculiar to agile and how much is just inherent to working on a team.
> It forces developers to share every mistake they make, it makes them share if they are thinking incorrectly about something, it makes them easily replaceable.
That's absolutely the point of a team. Contrary to popular belief, a team is not a meritocracy[1], it's a mediocracy. The beautiful thing about a mediocracy is that it means that you can take vacation or quit and someone else can pick up your work. We have a pretty good gig that we can just chew through tickets, imbibing coffee and excreting code and poo.
Not everyone has that luxury. For many actors, their face needs to be in every episode, so they sign a contract with stiff penalties if they quit.
[1]: Engineering is meritocratic in the larger market; if you are better or worse than your team's medium, you find a better team where the medium is closer to your skill level.
> It forces developers to share every mistake they make, it makes them share if they are thinking incorrectly about something, it makes them easily replaceable.
That's absolutely the point of a team. Contrary to popular belief, a team is not a meritocracy[1], it's a mediocracy. The beautiful thing about a mediocracy is that it means that you can take vacation or quit and someone else can pick up your work. We have a pretty good gig that we can just chew through tickets, imbibing coffee and excreting code and poo.
Not everyone has that luxury. For many actors, their face needs to be in every episode, so they sign a contract with stiff penalties if they quit.
[1]: Engineering is meritocratic in the larger market; if you are better or worse than your team's medium, you find a better team where the medium is closer to your skill level.
That sounds like hell. The sense of ownership, achievement, and subject matter expertise when driving projects from ideation to completion is everything I like about my job. Working on scattershot, atomized tickets from an assembly line would be awful.
Unfortunately, we do not live in Utopia. In reality, politics, competition and self-interest play huge role in the workplace. In some companies, admitting a mistake or showing vulnerability in front of the wrong crowd can be very damaging for your career there.
1. Agile is not personally great for programmers.
2. Agile is good for managers.
3. Managers run the business and make sure it exists.
4. Programmers need the business in order to have a job.
5. Agile is therefore good for the business,
6. And therefore Agile is good for Programmers, though not personally.
2. Agile is good for managers.
3. Managers run the business and make sure it exists.
4. Programmers need the business in order to have a job.
5. Agile is therefore good for the business,
6. And therefore Agile is good for Programmers, though not personally.
Unfortunately, you have been taught and are executing Agile in the completely wrong fashion. My first guess would be, you are actually working in Waterfall, but your managers have labeled it Agile and cherry-picked the parts they liked.
Agile has a remarkable resemblance to both communism and faith healing: Every time I say it doesn't work, a true believer replies and says I wasn't doing it right or I didn't believe in it enough.
I would disagree with almost every claim on this list.
I don't really have that strong of an attachment to any specific one of these claims. I was just pointing out the logic of the parent comment is very narcissistic (without saying as much).
The logic falls apart when you look at different individuals and different companies. For example, if your company is very political then what is good for managers very likely is not good for programmers. If your company focuses on teamwork and has a strong one-for-all;all-for-one culture, then whats good for managers probably is good for programmers.
The logic falls apart when you look at different individuals and different companies. For example, if your company is very political then what is good for managers very likely is not good for programmers. If your company focuses on teamwork and has a strong one-for-all;all-for-one culture, then whats good for managers probably is good for programmers.
Agile is good for managers who are unable to evaluate their programmers otherwise.
4. Managers need the Programmers, to make sure the business exists.
5. Agile may or may not be good for Programmers.
6. Agile may or may not be good for the business.
5. Agile may or may not be good for Programmers.
6. Agile may or may not be good for the business.
Agile is good for managers in that it gives them a feeling of being in control.
Agile is not actually for managers, in that productivity suffers a lot, less software with real value is produced.
But software productivity is notoriously hard to measure, so it is ignored.
Agile is not actually for managers, in that productivity suffers a lot, less software with real value is produced.
But software productivity is notoriously hard to measure, so it is ignored.
My, how very Douglas Adams of you =)
It's a crime that Scrum is allowed to call itself "Agile". Look at the Agile Manifesto again, then look at Scrum. Almost complete opposties.
Yes, it's a little disappointing that the term "Agile" pretty much now refers to Scrum.
If you don’t want to explain or share, I don’t want you on my team.
I’m confident I can identify some interval at which you don’t want to explain or share, either. For example, every 30 seconds.
Explaining and sharing are important. The difference between micromanagement and management is, IMO, somewhere between daily and quarterly.
Explaining and sharing are important. The difference between micromanagement and management is, IMO, somewhere between daily and quarterly.
Because you work in the team.
A boss used to say to us, you haven't proven you know how to do it until you've done it twice. This is, as I recall, also the guy who would pigeonhole people who built things that they couldn't hand off to others. He fed us some bullshit line about being 'too important' to work on the new cool stuff. It was a hard lesson but I learned pretty quick to put extra time in to make my code obvious to others instead of just me. Boost your truck number if you ever want new scenery.
(Most of my coworkers thought he was being sincere in his flattery rather than being ironic. For all I know they are still being 'too important' to work on new subsystems.)
(Most of my coworkers thought he was being sincere in his flattery rather than being ironic. For all I know they are still being 'too important' to work on new subsystems.)
There's still code review right? And if you're off building something more involved, then hopefully that code review is happening on a weekly basis with at least 2 people reviewing it so that there's input and ideas and corrections happening. It's brutal to see someone waste time on building out unnecessary parts, etc. Plus it's also useful to reduce bus factor, have other people in the loop to pick up the work if necessary.
ah the black hole programming movement! We've been there with "waterfall", which was a disaster. Not explaining and sharing is counter to working on a team. If you are a one man army, and no one knows what your code does, or if it can be compiled or deployed without errors, then that is bad for your company.
are you really on a team then?
A manager usually has several distinct projects in the air, with ICs working on them in groups of 1-3. Someone's work isn't relevant to you just because you report to the same manager. The "team" for standup, sprint planing, etc. is really several teams, each tuning out while the others speak. And because small groups can communicate fine informally, the relevant-seeming part of the team-level ritual is always a rehash of what the project staff already know.
That sounds like a bad structure then. Standups ought to be for the teams of small groups, not the convenience of the manager.
Whether standups are useless or not depends on the dynamics of the team. With the team I'm currently working in there are no standups, all communication is async and everyone knows what everyone else is working on. If there's a problem, holler in chat, or discuss IRL. There's also the project board where anyone can just hop in to see progress. There is a trust in each other in my team, which is not something I can say for other teams I've been with.
The whole agile methodology shouldn't be taken as is. Standups, sprint planning, retro etc all can be ala-carted with modifications depending on what type of team you're in and the people in it. The ideal scenario is that the team is a well-oiled machine, much like a precision, well built watch. No standups or meetings that force context switches and interruptions.
Adapt to the team. Do away with unnecessary processes. Just because standups are done everywhere doesn't mean you have to do it just for the sake of 'following the process'. It also doesn't mean you should do away with it, if you have a team that's new, or if there's a lack of communication or trust in each other. Isn't the point of agile, to be agile in everything that we do, including the agile processes themselves?
The whole agile methodology shouldn't be taken as is. Standups, sprint planning, retro etc all can be ala-carted with modifications depending on what type of team you're in and the people in it. The ideal scenario is that the team is a well-oiled machine, much like a precision, well built watch. No standups or meetings that force context switches and interruptions.
Adapt to the team. Do away with unnecessary processes. Just because standups are done everywhere doesn't mean you have to do it just for the sake of 'following the process'. It also doesn't mean you should do away with it, if you have a team that's new, or if there's a lack of communication or trust in each other. Isn't the point of agile, to be agile in everything that we do, including the agile processes themselves?
Besides that, I hate that they took me out of rhytm of work. If a standup is at 10am, and I arrive at 9am to do dev work, there is very little I can do before being interrupted - I need at least 2-4h of interrupted time to do some good work.
My team just does "asynchronous stand-ups" - share your status once day in a dedicated Slack channel, whenever you want.
We do this on top of a good culture of asking for help and posting regular updates on our internal Sprint tracker, it works quite well.
We do this on top of a good culture of asking for help and posting regular updates on our internal Sprint tracker, it works quite well.
For technical or non-technical teams, this is usually all that's needed. If there are any questions, they can be addressed below in a reply thread or via a call or face-to-face.
It's amazing how much of a time saver and efficiency builder that can be. It's equally amazing how many managers prefer time wasting group meetings where people essentially read written reports...
It's amazing how much of a time saver and efficiency builder that can be. It's equally amazing how many managers prefer time wasting group meetings where people essentially read written reports...
I think this is the correct way to do standups for most teams. It's asynchronous and non-intrusive, and there generally isn't any benefit from doing the standup in person anyway (aside from seeing people's faces if your team is remote).
Been advocating this for months at my company with no success. Our standup is of the worst kind: conference call.
Standup just before lunch might work better. That’s my experience.
It works very poorly in practice, in my experience.
You interrupt people 2-4 hours into their work, which is highly disruptive for those who get the most done in the morning.
Often discussions run on past many peoples' lunch time, which can make people cranky and occasionally leads to tense exchanges which might have been more amicable if people weren't hangry.
You wind up with people melding the work they did during the previous day and the current day. It gets difficult to keep track of what you did between two days' midpoints compared to what you did during a day.
And things get worse as more items are inevitably added to the standup meetings (now we need to check on tests, now we need to add a review of open tickets, now we need to involve people from other teams, etc).
In my experience, pre-lunch scrums result in heavy disruption and a bunch of people who feel like they could be doing other things to much greater effect.
You interrupt people 2-4 hours into their work, which is highly disruptive for those who get the most done in the morning.
Often discussions run on past many peoples' lunch time, which can make people cranky and occasionally leads to tense exchanges which might have been more amicable if people weren't hangry.
You wind up with people melding the work they did during the previous day and the current day. It gets difficult to keep track of what you did between two days' midpoints compared to what you did during a day.
And things get worse as more items are inevitably added to the standup meetings (now we need to check on tests, now we need to add a review of open tickets, now we need to involve people from other teams, etc).
In my experience, pre-lunch scrums result in heavy disruption and a bunch of people who feel like they could be doing other things to much greater effect.
If you're not keeping the daily scrum shorter than 15 minutes then that's in and of itself a problem that will make people annoyed and disrupted.
The problem probably isn't the time the meeting takes, it's the subsequent discussions about various things brought up during the meeting.
In my team, we have it early in the morning, so we can overlap with India. Folks in US have rest of their day for work, whereas folks in India do the standup at the end of the day just before going home.
Must be terrible for those in your team who aren't predisposed to waking early
That's why you should do them at the end of the day as we did of my first very successful Agile project - presented at the IIIE I believe after we finished.
Though that was the full on clean room high level sponsor route, collocated with the customer.
Though that was the full on clean room high level sponsor route, collocated with the customer.
I did that (4pm standups) for a while on a team that was just me and another guy plus our team's dev manager, qe manager, and product manager. All the managers were in HQ, my teammate and I were in separate remote offices, so it was done over Hangouts. We loved it being late and got a lot done for just two of us over the few months, but the managers didn't like it (very few times they'd all show up, and dev manager always showed up while on a bart train) and killed it (back to 10am meetings) a few weeks before the team dissolved.
I've been on 11am standups lately and they're not too bad, but it incentivizes me to either come in at 8 or come in at 10-10:30. The latter is what usually happens.
I've been on 11am standups lately and they're not too bad, but it incentivizes me to either come in at 8 or come in at 10-10:30. The latter is what usually happens.
We have it right before lunch
The one thing that I like about standups is that they make real blockage or ineffectiveness more visible.
It is true in theory that you can get the same thing from just scanning the project board every day. But people don't actually do it. Furthermore if you're stuck on X, standups are a perfect time for someone who was about to look for a ticket to take one off of you that they are better suited to handling.
Are they perfect? No. There are definitely false positives. But the ratio of real positive to false one is good enough that they provide real value overall.
It is true in theory that you can get the same thing from just scanning the project board every day. But people don't actually do it. Furthermore if you're stuck on X, standups are a perfect time for someone who was about to look for a ticket to take one off of you that they are better suited to handling.
Are they perfect? No. There are definitely false positives. But the ratio of real positive to false one is good enough that they provide real value overall.
The best meeting updates are just the surpises.
Sometimes I’d start meetings with, “first, let’s go around the table and report any surprises this week”, and then adjourn the meeting.
Sometimes I’d start meetings with, “first, let’s go around the table and report any surprises this week”, and then adjourn the meeting.
> there have been many times where I've worked on a task or a set or related tasks for weeks or months, simply because the tasks required a lot of forethought and careful planning.
The idea of standups and breaking down work into chunks that fit in a short sprint is to avoid this sort of situation where somebody is off on their own and not getting feedback.
I find that people are overly optimistic about their chances of getting a task completed in the promised time frame. If something is expected to take five days, I'll hear every day that it's going well, right up to the last day, then all of a sudden it's not going to be done. The more granular the task is, the easier it is to deal with slippage because you get to know about that slippage sooner.
The idea of standups and breaking down work into chunks that fit in a short sprint is to avoid this sort of situation where somebody is off on their own and not getting feedback.
I find that people are overly optimistic about their chances of getting a task completed in the promised time frame. If something is expected to take five days, I'll hear every day that it's going well, right up to the last day, then all of a sudden it's not going to be done. The more granular the task is, the easier it is to deal with slippage because you get to know about that slippage sooner.
A task should be something that can be done independently by one person. Sometimes you have a big chunk of work that's tightly coupled and can take months to implement, how do you best track that?
In my experience what happens is one of three things:
(a) You try and bring multiple people into that feature and it turns into a clusterfuck of awful merge conflicts and hours upon hours wasted on co-ordination instead of building
(b) You track it as a lot of tasks (~30-50), and whoever is working on it spends half their day fielding questions like "Can I pick up that task for you?" or "why are all the highest priority tasks assigned to the same person?"
(c) You track it as one or a small number of tasks (~2-5), and whoever is working on it has the problem GP mentioned with stand-ups, where they don't have anything granular enough to report and end up looking like an incompetent tool.
I've experienced all 3 and they all suck. I'm not convinced that option (c) isn't the furthest down the right track. Option (a) can be a horror show and probably one of the quickest ways to lose a good dev, option (b) can work but it's dependent on a manager that understands the work and isn't going to lambast the dev for blocking up the backlog with self-assigned tasks. Option (c) just relies on adjusting or removing stand-ups to not focus so heavy on day-to-day progress.
In my experience what happens is one of three things:
(a) You try and bring multiple people into that feature and it turns into a clusterfuck of awful merge conflicts and hours upon hours wasted on co-ordination instead of building
(b) You track it as a lot of tasks (~30-50), and whoever is working on it spends half their day fielding questions like "Can I pick up that task for you?" or "why are all the highest priority tasks assigned to the same person?"
(c) You track it as one or a small number of tasks (~2-5), and whoever is working on it has the problem GP mentioned with stand-ups, where they don't have anything granular enough to report and end up looking like an incompetent tool.
I've experienced all 3 and they all suck. I'm not convinced that option (c) isn't the furthest down the right track. Option (a) can be a horror show and probably one of the quickest ways to lose a good dev, option (b) can work but it's dependent on a manager that understands the work and isn't going to lambast the dev for blocking up the backlog with self-assigned tasks. Option (c) just relies on adjusting or removing stand-ups to not focus so heavy on day-to-day progress.
My 5 cents on this:
- Usually, for large chunks of work, you want to bring in more people. Both because they tend to involve several modules or several layers of the stack, and very few people are equally skilled in every part of the codebase. But also because there will most probably be design decisions and tradeoffs along the way to discuss. Coordinate who is working on which parts of the codebase at any given time.
- I'd avoid excessive preplanning. But I'd make tasks to make explicit the general plan and the interdependencies. E.g. create new server API, then refactor client, then remove old server API.
- Don't be too concerned with showing progress in stand-ups. Feeling like you need to do this to justify yourself is a team process smell. Abandon them if they bring no value, e.g. if you have a de facto three people subteam who is coordinating all the time anyway.
- Usually, for large chunks of work, you want to bring in more people. Both because they tend to involve several modules or several layers of the stack, and very few people are equally skilled in every part of the codebase. But also because there will most probably be design decisions and tradeoffs along the way to discuss. Coordinate who is working on which parts of the codebase at any given time.
- I'd avoid excessive preplanning. But I'd make tasks to make explicit the general plan and the interdependencies. E.g. create new server API, then refactor client, then remove old server API.
- Don't be too concerned with showing progress in stand-ups. Feeling like you need to do this to justify yourself is a team process smell. Abandon them if they bring no value, e.g. if you have a de facto three people subteam who is coordinating all the time anyway.
Oh for sure, I'm not saying not to involve other people, just that the actual implementation for some things is most efficient if it falls to one person.
I struggle to think of an example where I'd ever let somebody go off and work on something for months. I can't think of how they would be successful, let alone take on the risk that they quit or get hit by a bus and nobody can continue the work.
It really depends on what kind of software you're building. A large new CRUD feature (which is what most of us are building 95% of the time) can easily be split among many people. But a complex data visualisation, or a novel algorithm, can easily take a month or two and isn't easily split amongst the team, even if you have multiple members with the expertise to implement it.
EDIT: Also, just because someone is working on a siloed task doesn't mean that nobody else can pick up where they left off. For that to be true you have to assume they document nothing and code like an idiot (which is unfortunately probably pretty common).
EDIT: Also, just because someone is working on a siloed task doesn't mean that nobody else can pick up where they left off. For that to be true you have to assume they document nothing and code like an idiot (which is unfortunately probably pretty common).
This type of work is highly atypical. All the scrum ceremonies were designed around fast feedback, if you can't fit it into the work you do then using anything agile-related is not going to work.
I hate it because every approaching standing meeting feels like an approaching "rejustify your existence" checkin.
Even if I'm not going to be judged out loud in this meeting, I'm going to have to explain myself. I have a problem in front of me that I'm working to solve. Maybe I decided to do some reading about possible ways to solve it. Maybe I decided to learn one of the tools that I'll probably use in the course of solving it. Maybe I'll try a particular approach.
Whatever I decided to do yesterday, I have to decide how to frame it and describe it today. I can practically hear another engineer or manager thinking "why didn't you just X" where X is some simple thing involving less time and thought than what I did. And I don't want to have that conversation with them right now. I am still in the middle of it.
I want to be able to say in a few days, "Here's a solution! It meets the requirements and in a really elegant way if I do say so!" I live for that. I want the freedom and flexibility to get to that point without being probed every day about how I'm getting there. I used to do that, before scrums and standups took over the programming world, and it was great. Having a daily checkin robs me of that latitude.
I'll gladly pick someone's brain if I want their input or feel stuck. But if I want to think outside the box a bit, a daily checkin can feel like a pretty short leash.
Even if I'm not going to be judged out loud in this meeting, I'm going to have to explain myself. I have a problem in front of me that I'm working to solve. Maybe I decided to do some reading about possible ways to solve it. Maybe I decided to learn one of the tools that I'll probably use in the course of solving it. Maybe I'll try a particular approach.
Whatever I decided to do yesterday, I have to decide how to frame it and describe it today. I can practically hear another engineer or manager thinking "why didn't you just X" where X is some simple thing involving less time and thought than what I did. And I don't want to have that conversation with them right now. I am still in the middle of it.
I want to be able to say in a few days, "Here's a solution! It meets the requirements and in a really elegant way if I do say so!" I live for that. I want the freedom and flexibility to get to that point without being probed every day about how I'm getting there. I used to do that, before scrums and standups took over the programming world, and it was great. Having a daily checkin robs me of that latitude.
I'll gladly pick someone's brain if I want their input or feel stuck. But if I want to think outside the box a bit, a daily checkin can feel like a pretty short leash.
Sounds like your project is scoped too broadly for daily standup then, though sometimes model just doesn't fit the task and you get the above.
> In fact, all I like about standups is seeing my team mates once a day
This may sound a little funny, but at my work we do daily morning prayer from 9-9:30am (company-wide, 20-25 people). We sing a few songs with guitar, then talk about our weekend or personal life, or whatever. Some days it's more work related than others. Maybe we'll share a little about what we're working on, or bigger updates from managers, but it's definitely not a planning meeting.
It's awesome.
This may sound a little funny, but at my work we do daily morning prayer from 9-9:30am (company-wide, 20-25 people). We sing a few songs with guitar, then talk about our weekend or personal life, or whatever. Some days it's more work related than others. Maybe we'll share a little about what we're working on, or bigger updates from managers, but it's definitely not a planning meeting.
It's awesome.
I have other issues with standups, but if your concern is "I don't look productive and I don't want to talk about what I'm doing" not having standups isn't going to make you look more productive.
If you're working heads-down for weeks or months without standups, people are still likely to wonder if you're stuck/ineffective/blocked if you're not communicating in more detail than "it's still in progress."
If you're working heads-down for weeks or months without standups, people are still likely to wonder if you're stuck/ineffective/blocked if you're not communicating in more detail than "it's still in progress."
I think the desire is more to have goals and work towards those. If you don't have daily goals, then having a daily standup is going to be pointless.
That is, if I am working for weeks or months without making visible progress, but I have successfully delivered the last X things on time, why are you worried about what I look like?
So, yes, people should grow into longer timelines that they can appear to be slacking off. I expect the tasks we've given the newest intern, as an example, to be something that can show daily progress. In large, because it will likely need daily coaching. As you get on the larger projects, though, asking me to break everything down to daily chunks is itself a chore that may add significantly to effort.
Worse, it encourages people to fall for the sunken costs fallacy. If you burned down all of that effort, many folks are hesitant to take any of it back. If I haven't let you know about the small progress I made on the last experiment I did, then I am as likely to abandon the path and try something else if I am confident it will be better.
That is, if I am working for weeks or months without making visible progress, but I have successfully delivered the last X things on time, why are you worried about what I look like?
So, yes, people should grow into longer timelines that they can appear to be slacking off. I expect the tasks we've given the newest intern, as an example, to be something that can show daily progress. In large, because it will likely need daily coaching. As you get on the larger projects, though, asking me to break everything down to daily chunks is itself a chore that may add significantly to effort.
Worse, it encourages people to fall for the sunken costs fallacy. If you burned down all of that effort, many folks are hesitant to take any of it back. If I haven't let you know about the small progress I made on the last experiment I did, then I am as likely to abandon the path and try something else if I am confident it will be better.
> That is, if I am working for weeks or months without making visible progress, but I have successfully delivered the last X things on time, why are you worried about what I look like?
I'm not worried what the OP looks like, or generally what I look like for that matter, but they were worried what they look like. I just dispute the claim that standups are the root of their anxiety about that.
I'm not worried what the OP looks like, or generally what I look like for that matter, but they were worried what they look like. I just dispute the claim that standups are the root of their anxiety about that.
I think it is fair to think you will be measured with the same general yardsticks that your peers are measured by. So, if you are in a standup where others are giving daily task reports, it is natural to expect you should. And that if you are not, it is natural to feel something is amiss.
This is especially true if you're working on a research task, or the research portion prior to really driving in and implementing the feature. Every day you're basically saying the same thing and it looks like you're struggling, but you're mostly just learning.
>>In fact, all I like about standups is seeing my team mates once a day.
Yeah, I think a better way to do standups is a couple minutes of social time, and "anybody finish anything? any blockers?" rather than going person-by-person.
Yeah, I think a better way to do standups is a couple minutes of social time, and "anybody finish anything? any blockers?" rather than going person-by-person.
I've run my team's stand-ups for several years now. I find without going person by person there is less communication. I still restrict each person's comments to blockers and their agenda for the time until the next standup (not daily). It's not uncommon for "no blockers, tickets X, Y, Z for next day or two" to be it for a report. It's not common but occasionally this will remind someone else of a blocker they have which they can chime in with during their update or else at the end if they've already gone.
Agreed with this. I'm actually curious what level of engineers Jason is leading. If it's a group of senior engineers, I'd imagine everyone already knows what's expected of them, but a group of junior engineers might be a different story.
rather than going person-by-person.
Better still for us has been going task-by-task rather than person-by-person. Look at everything which is in progress, get a quick update on it, move on. Five minutes tops, everybody is up-to-date, issues flagged.
Better still for us has been going task-by-task rather than person-by-person. Look at everything which is in progress, get a quick update on it, move on. Five minutes tops, everybody is up-to-date, issues flagged.
Yes! At my last workplace we switched from person-to-person to task-to-task and it worked great.
[deleted]
> I don't want to have to say "Yup, still workin' on those bugs" every morning.
Then don't. Give specifics about what you did, what you accomplished or didn't accomplish, and what your next steps are. Provide evidence of forward velocity, or ask for help if you're stuck. The key here is accountability. Don't be "the guy in a room" who doesn't apprise the team of what's going on in his world. That guy is first in line to be fired.
Then don't. Give specifics about what you did, what you accomplished or didn't accomplish, and what your next steps are. Provide evidence of forward velocity, or ask for help if you're stuck. The key here is accountability. Don't be "the guy in a room" who doesn't apprise the team of what's going on in his world. That guy is first in line to be fired.
I find it interesting how literal people took that.
Must I have provided a lengthy, detailed example of what I would say at a standup? I'm the guy who pushed for people to provide more detail at standup. I thought I'd communicated my point and didn't think it a particularly good use of my time or anyone else's to spend more time on that sentence. Now I regret writing that it at all.
If anyone manages to read this, keep in mind that I was not suggesting that a professional update along the lines of "d'uhhh... i did a thing" is particularly valid.
Must I have provided a lengthy, detailed example of what I would say at a standup? I'm the guy who pushed for people to provide more detail at standup. I thought I'd communicated my point and didn't think it a particularly good use of my time or anyone else's to spend more time on that sentence. Now I regret writing that it at all.
If anyone manages to read this, keep in mind that I was not suggesting that a professional update along the lines of "d'uhhh... i did a thing" is particularly valid.
As a n00b just getting into software development this might be a dumb question but does saying "Yup, still workin' on those bugs" really create a sense of blockage or such?
I gotta think that's kinda a common thing to be said and other devs would understand that that happens...
I gotta think that's kinda a common thing to be said and other devs would understand that that happens...
If working on the same ones, then after a few days, yes. By then you should have explored some debugging techniques, options for solution, etc., and either can't figure out how to replicate or debug it or have found a tricky bug and 1-3 ideas for a solution, but all the potential solutions seem bad. That's when you can say you're blocked, ask the team for ideas on how else to replicate/debug, or try to get consensus for the least-worst hacky fix that you've come up with, or any other ideas based on what you've found. We all spin our wheels or get stuck sometimes, so of course we understand, and that's exactly what it's for. But you have to give that context and say where you're stuck.
The problem is that product managers and management in general want features and don't care about technical debt.
So if you are working on a bug (fixing technical debt) then you are not working on a feature.
Also, working on features is often (but not always) more predictable in time estimation than working on bugs, which can be a completely exploratory task with the only endpoint being "it works now"...
So if you are working on a bug (fixing technical debt) then you are not working on a feature.
Also, working on features is often (but not always) more predictable in time estimation than working on bugs, which can be a completely exploratory task with the only endpoint being "it works now"...
"still workin' on those bugs" is really pretty useless. I'm not suggesting you're not a disciplined person but at some point, debugging something for days on end is a sign you may need some help, a fresh set of eyes, or come up for air and re-group. Same goes for feature development. If a single user story representing a whole feature (or part of a larger one) goes on and on and on, that's either a sign you perhaps rabbit-holed it too deeply, need some help from another team member, or need to raise a flag and split the story into another piece, possibly even one someone else can rally around to help close it.
I wish everything was so simple.
At a past job a very technically strong coworker spent months on a problem and eventually threw the towel and handed it to me. It took me another couple months to find a reasonable solution to it.
Some problems are _really_ hard and no amount of help will get a dev to solve it faster.
At a past job a very technically strong coworker spent months on a problem and eventually threw the towel and handed it to me. It took me another couple months to find a reasonable solution to it.
Some problems are _really_ hard and no amount of help will get a dev to solve it faster.
But if I hire nine women, I can get a baby in a month right?
Then that is a project that should not use Agile in my opinion.
I first read your comment as the inevitable "that's not true agile" response. Haha
Perhaps companies should just pick and choose what parts of Agile methodology suits the situation. I don't really buy the idea that Agile only works if there's an ensemble effect from every workflow aspect made Agile.
Perhaps companies should just pick and choose what parts of Agile methodology suits the situation. I don't really buy the idea that Agile only works if there's an ensemble effect from every workflow aspect made Agile.
Some standups the boss gives off an unpleasant vibe than nothing should ever take more than a day.
Get stuck on something for a few days, and it feels like it's time for a new job.
Get stuck on something for a few days, and it feels like it's time for a new job.
For instance, there have been many times where I've worked on a task or a set or related tasks for weeks or months, simply because the tasks required a lot of forethought and careful planning.
That would raise immediate, massive, flashing red alarm bells in my teams!
I understand that different environments have different requirements, and different teams have different needs though.
That would raise immediate, massive, flashing red alarm bells in my teams!
I understand that different environments have different requirements, and different teams have different needs though.
Maybe other teams work radically differently, but everywhere I worked it was inevitable that team members would occasionally get "meaty" projects to work on where they would take primary ownership. Under the repetitiousness and time constraint of stand-ups, it still outwardly appear that the smaller tasks broken out of a large project can all sound the same to others on the team who are only mildly interested in the details of other people's tasks.
If I was working on a very functional team where we had the employees and resources to work very collaboratively across projects, I'd certainly agree that (groups of) tasks that take that long should raise alarm bells. But most companies, in my experience thusfar, minimally value their developers and only hire X amount of them, so the developers they did hire are naturally forced to take on large projects to the point of taking sole ownership of them.
Disregarding that, I don't see it as unreasonable that tasks shared between multiple people would take weeks to figure out. If I were hiring developers, I wouldn't want them to race to make a bunch of horseshit that's going to fail, but instead they should take their time to figure out the right approach. In conjunction, they should be able and allowed to communicate when long-running tasks aren't going anywhere, without any shame. As long as they document the steps they took along the way, there's no reason that standup needs to play a role; with documentation, a manager should be able to tell if an employee is incompetent or merely trying to do their job right.
I don't think that stand-ups are really a big deal, but if I were running a team, I probably wouldn't use stand-ups in a traditional sense. Rather, I'd keep stand-ups but not make them goal-oriented or strictly related to work in any sense. As I said earlier, I think it's positive for people on a team to interact at least once throughout the day if they are in the office, and a quick and optional stand-up in the morning would be a great way to facilitate this. If someone wants to bring up an issue or asks if another team member knows how to do X thing, then awesome. In fact, I suspect people would be more comfortable in doing so if they aren't wasting time thinking up how to summarize their work for stand-up, and if stand-up was kept casual and didn't devolve into employees reporting to their manager.
If I was working on a very functional team where we had the employees and resources to work very collaboratively across projects, I'd certainly agree that (groups of) tasks that take that long should raise alarm bells. But most companies, in my experience thusfar, minimally value their developers and only hire X amount of them, so the developers they did hire are naturally forced to take on large projects to the point of taking sole ownership of them.
Disregarding that, I don't see it as unreasonable that tasks shared between multiple people would take weeks to figure out. If I were hiring developers, I wouldn't want them to race to make a bunch of horseshit that's going to fail, but instead they should take their time to figure out the right approach. In conjunction, they should be able and allowed to communicate when long-running tasks aren't going anywhere, without any shame. As long as they document the steps they took along the way, there's no reason that standup needs to play a role; with documentation, a manager should be able to tell if an employee is incompetent or merely trying to do their job right.
I don't think that stand-ups are really a big deal, but if I were running a team, I probably wouldn't use stand-ups in a traditional sense. Rather, I'd keep stand-ups but not make them goal-oriented or strictly related to work in any sense. As I said earlier, I think it's positive for people on a team to interact at least once throughout the day if they are in the office, and a quick and optional stand-up in the morning would be a great way to facilitate this. If someone wants to bring up an issue or asks if another team member knows how to do X thing, then awesome. In fact, I suspect people would be more comfortable in doing so if they aren't wasting time thinking up how to summarize their work for stand-up, and if stand-up was kept casual and didn't devolve into employees reporting to their manager.
I always upvote these things, not because they're right. Because they show common misunderstandings about Agile. Agile is so simple and easy that the development community continues to screw it up. It's important to understand how.
According to the author, standups are something companies require developers to do to report about what they're doing. Many times they can take more than a half hour.
That may be true, but the purpose of standups is that the team requires one another to get together and talk about how to move the project forward. It's not about what you did. That's a status report. It's about how you can help one another.
If you can self-organize, effectively communicate, and help one another as-needed without standups? Don't do them. Easy. There's no magic requirement that you have to. What we've found over the years is that if you give it a name and a time, at least you have a way to talk about whether it's working or not. Other people can drop by to help out. But if that's too formal for you and you don't need it? Stop!
Standups remind me of brushing your teeth. When they're working well, it looks like nothing of value is happening. Five minutes and people tell jokes and leave. It's when they're misunderstood as something else that they become useless and painful. Had to throw a SM out of his own team room once because he kept using standups as an opportunity to play "What's your status?". Nobody cares about your status. We care about how the entire team is working. Have some down time? Tell us you're free and then go play tennis the rest of the day or something. It's not a management, outside-in meeting. Just the opposite, in fact.
I love these articles because they remind us that the goal is what's important, not the ritual. Unfortunately, people get the two conflated, usually due to a lack of multiple-team/org experiences.
According to the author, standups are something companies require developers to do to report about what they're doing. Many times they can take more than a half hour.
That may be true, but the purpose of standups is that the team requires one another to get together and talk about how to move the project forward. It's not about what you did. That's a status report. It's about how you can help one another.
If you can self-organize, effectively communicate, and help one another as-needed without standups? Don't do them. Easy. There's no magic requirement that you have to. What we've found over the years is that if you give it a name and a time, at least you have a way to talk about whether it's working or not. Other people can drop by to help out. But if that's too formal for you and you don't need it? Stop!
Standups remind me of brushing your teeth. When they're working well, it looks like nothing of value is happening. Five minutes and people tell jokes and leave. It's when they're misunderstood as something else that they become useless and painful. Had to throw a SM out of his own team room once because he kept using standups as an opportunity to play "What's your status?". Nobody cares about your status. We care about how the entire team is working. Have some down time? Tell us you're free and then go play tennis the rest of the day or something. It's not a management, outside-in meeting. Just the opposite, in fact.
I love these articles because they remind us that the goal is what's important, not the ritual. Unfortunately, people get the two conflated, usually due to a lack of multiple-team/org experiences.
That is just bullshit though. I don't find value in anything that agile offers, can I just throw it out entirely by your argument?
Standups - You can simply claim that, hey you don't want to do standups, don't do standups but if you take a concrete implementation of Agile, say scrum for instance, it specifically asks each person in the team to answer:
"What did I do yesterday that helped the development team meet the sprint goal? What will I do today to help the development team meet the sprint goal? Do I see any impediment that prevents me or the development team from meeting the sprint goal?"
These questions are effectively a way lay out a very clear path for management to basically micro-manage developers and they add pressure on developers to come up with some contrived explanation to make it sound like their day was productive. Hardly builds any trust when your work is being supervised and judged by a team every single day even if the goal of the meeting is not to do so specifically.
I can go deeper into each individual process that agile variants impose and take each of them apart. I have nothing but spite for this godforsaken process, the only thing it's good for is to give management an illusion of control on software development process.
Standups - You can simply claim that, hey you don't want to do standups, don't do standups but if you take a concrete implementation of Agile, say scrum for instance, it specifically asks each person in the team to answer:
"What did I do yesterday that helped the development team meet the sprint goal? What will I do today to help the development team meet the sprint goal? Do I see any impediment that prevents me or the development team from meeting the sprint goal?"
These questions are effectively a way lay out a very clear path for management to basically micro-manage developers and they add pressure on developers to come up with some contrived explanation to make it sound like their day was productive. Hardly builds any trust when your work is being supervised and judged by a team every single day even if the goal of the meeting is not to do so specifically.
I can go deeper into each individual process that agile variants impose and take each of them apart. I have nothing but spite for this godforsaken process, the only thing it's good for is to give management an illusion of control on software development process.
If you read the agile manifesto and then you look at scrum, it feels as if scrum has nothing to do with agile. It seems to breaks every rule.
Scrum is processes and tools over individuals and interactions, by its very nature.
Scrum is comprehensive documentation over working software, because you have to map everything out.
Scrum is contract negotiation over customer collaboration, by allowing management to effectively rule scrum, scrum masters are always management or reporting to management, so devolve into contract negotiation by proxy.
Scrum is following a plan over responding to change, again, by its very nature.
It's the most odd thing I've ever seen, that somehow scrum came out of agile and literally got it all backwards. There's even certifications on how to do scrum, which is utterly stupid when you read the 12 principles, some choice scrum oxymorons:
trust them to get the job done - nope, we don't trust you, follow these scrum rules you oiks
simplicity is essential - but we've got all these formal rules for you to follow
working software is the primary measure of progress - no, actually, how many sprints have been successfully completed?
the best architectures, requirements, and designs emerge from self-organizing teams - but we're not going to let you self organize, you must follow these scrum rules
Scrum is processes and tools over individuals and interactions, by its very nature.
Scrum is comprehensive documentation over working software, because you have to map everything out.
Scrum is contract negotiation over customer collaboration, by allowing management to effectively rule scrum, scrum masters are always management or reporting to management, so devolve into contract negotiation by proxy.
Scrum is following a plan over responding to change, again, by its very nature.
It's the most odd thing I've ever seen, that somehow scrum came out of agile and literally got it all backwards. There's even certifications on how to do scrum, which is utterly stupid when you read the 12 principles, some choice scrum oxymorons:
trust them to get the job done - nope, we don't trust you, follow these scrum rules you oiks
simplicity is essential - but we've got all these formal rules for you to follow
working software is the primary measure of progress - no, actually, how many sprints have been successfully completed?
the best architectures, requirements, and designs emerge from self-organizing teams - but we're not going to let you self organize, you must follow these scrum rules
Scrum is all about implementing a system and then adapting it over time to fit your needs. It's all about having the team figure out for itself how to organize. It's not a rigid set of requirements. It's a set of suggestions about how to begin implementing the system, and then trusting the team to figure out what to adapt and what to cut.
That's not how it's presented in real life.
Read something like this:
https://www.mountaingoatsoftware.com/agile/scrum
All about what has to be done, with a formal role of scrum master.
Phrases like these brook no adaptability:
On each day of the sprint, all team members should attend a daily Scrum meeting, including the ScrumMaster and the product owner
on the first day of a sprint and during the planning meeting
Another activity in Scrum project management is the sprint retrospective at the end of each sprint. The whole team participates in this meeting
Management take Scrum as a set of rules to follow and then use it to micro-manage everyone. Scrum masters end up as middle managers. Daily stand-ups turn in to daily justify your worth.
Read something like this:
https://www.mountaingoatsoftware.com/agile/scrum
All about what has to be done, with a formal role of scrum master.
Phrases like these brook no adaptability:
On each day of the sprint, all team members should attend a daily Scrum meeting, including the ScrumMaster and the product owner
on the first day of a sprint and during the planning meeting
Another activity in Scrum project management is the sprint retrospective at the end of each sprint. The whole team participates in this meeting
Management take Scrum as a set of rules to follow and then use it to micro-manage everyone. Scrum masters end up as middle managers. Daily stand-ups turn in to daily justify your worth.
> These questions are effectively a way lay out a very clear path for management to basically micro-manage developers
Well, they would if there was manager in the daily scrum.
Which is why there isn't.
(Not that I think the scrum formula here is ideal; if you've got a shared status display—kanban-like—the only question you should really need in the standup is the barriers one; the standup shouldn't be a status/progress check, it should be a venue for shared progress on breaking barriers.)
Well, they would if there was manager in the daily scrum.
Which is why there isn't.
(Not that I think the scrum formula here is ideal; if you've got a shared status display—kanban-like—the only question you should really need in the standup is the barriers one; the standup shouldn't be a status/progress check, it should be a venue for shared progress on breaking barriers.)
If it's not a dev manager, it can be a product manager / owner / scrum master / whomever is in charge of roadmap and high-level backlog items.
They take control because they've made promises to other people, higher up in the org and possibly outside the company, and they need to find out if scope is expanding too much, if something is taking too long to implement and scope needs to shrink as a result, or people who've been promised something need to be let down.
As a developer, this interaction feels a lot like micro-management.
They take control because they've made promises to other people, higher up in the org and possibly outside the company, and they need to find out if scope is expanding too much, if something is taking too long to implement and scope needs to shrink as a result, or people who've been promised something need to be let down.
As a developer, this interaction feels a lot like micro-management.
> If it's not a dev manager, it can be a product manager / owner / scrum master / whomever is in charge of roadmap and high-level backlog items.
In by-the-book Scrum, that's the Product Owner, who isn't a participant in the daily scrum. Neither is the Scrum Master, whose only roles with regard to the daily scrum are: (1) teaching the Dev Team to keep it within a 15-minute time box, and (2) ensuring that it occurs, (3) ensuring that if people other than the Dev team are present, they do not disrupt the scrum.
(I do think that both having the status questions and leaving the door open for the P.O. to be present even if not supposedly participating is a thing that creates the temptation to turn the scrum into a managing meeting, which is very explicitly not the intent.)
In by-the-book Scrum, that's the Product Owner, who isn't a participant in the daily scrum. Neither is the Scrum Master, whose only roles with regard to the daily scrum are: (1) teaching the Dev Team to keep it within a 15-minute time box, and (2) ensuring that it occurs, (3) ensuring that if people other than the Dev team are present, they do not disrupt the scrum.
(I do think that both having the status questions and leaving the door open for the P.O. to be present even if not supposedly participating is a thing that creates the temptation to turn the scrum into a managing meeting, which is very explicitly not the intent.)
Sure, present but not participating.
I really don't get this "management can micro-manage developers". Sounds like you work at a very shitty company / unhealthy environment. Dailies are for the actual working team, so they work better together and not a tool for team externals to shit all over the process.
I really can imagine your scenario - do you really have your CEO standing there on your daily meeting? Or are you bothered by your Team Lead?
I'm a CTO and I've never been on a daily. I don't care about daily tasks. I care about shit breaking. It can be our tech, our infra, our people, etc.. That's what I need to solve. I don't get it why in the god's name I would attend a daily. What value would I get out of that?
If on the other hand, I see shit going down, I dig in right away and talk with the Lead and/or Team if shit got real.
I really can imagine your scenario - do you really have your CEO standing there on your daily meeting? Or are you bothered by your Team Lead?
I'm a CTO and I've never been on a daily. I don't care about daily tasks. I care about shit breaking. It can be our tech, our infra, our people, etc.. That's what I need to solve. I don't get it why in the god's name I would attend a daily. What value would I get out of that?
If on the other hand, I see shit going down, I dig in right away and talk with the Lead and/or Team if shit got real.
Without scrum, if a CTO wanted to ask how an individual developer is doing, they could ask their line manager. With scrum, a CTO could just dig in to some of the many dubious reports that scrum generates. They could look at an individuals burn-down on tasks, and compare them across developers/teams. No matter how stupid this sounds, I've seen this exact thing being done by company Directors.
Decisions are made. Developers are moved to different projects, or given shitty bonuses, or constantly hassled to make their scrum metrics look better.
Just because you don't go to a stand up doesn't mean your not micromanaging, or enabling micromanagement as it is usually the line manager using scrum as an excuse to account for every hour in the day. Sometimes that is due to pressure from up high for various metrics to improve, etc. Other times they are just douchebag managers that don't know what they are doing...
Decisions are made. Developers are moved to different projects, or given shitty bonuses, or constantly hassled to make their scrum metrics look better.
Just because you don't go to a stand up doesn't mean your not micromanaging, or enabling micromanagement as it is usually the line manager using scrum as an excuse to account for every hour in the day. Sometimes that is due to pressure from up high for various metrics to improve, etc. Other times they are just douchebag managers that don't know what they are doing...
You're basically arguing that CTOs mostly cause damage and it's better to hide various vanity metrics from them with the purpose of them not meddling in the process.
My view is that looking at scrum metrics will provide you with additional insight into the development process. I understand that shitty managers will simply take those and decide on top of that. Proper managers would look at the numbers and go ask the line manager what is going on.
I can give you a very practical example - before we had scrum and burndown charts our team leads had limited tooling to detect problems and even quantify problems in the development process. Now we can use that to improve our process with the purpose of us being more efficient and making the development process less stressful.
I never look at burndown charts - I'm the CTO and my purpose is strategic. VP of Eng might look at them, but only if issues are detected, while team leads need to use them daily to help them improve how they work.
My view is that looking at scrum metrics will provide you with additional insight into the development process. I understand that shitty managers will simply take those and decide on top of that. Proper managers would look at the numbers and go ask the line manager what is going on.
I can give you a very practical example - before we had scrum and burndown charts our team leads had limited tooling to detect problems and even quantify problems in the development process. Now we can use that to improve our process with the purpose of us being more efficient and making the development process less stressful.
I never look at burndown charts - I'm the CTO and my purpose is strategic. VP of Eng might look at them, but only if issues are detected, while team leads need to use them daily to help them improve how they work.
> I don't find value in anything that agile offers, can I just throw it out entirely by your argument?
Yes, of course?
But I think you might be confused about what agile is, going by your remark about processes that agile imposes. There are none. Agile is about certain values, and people have come up with various processes that try to incorporate those values. This fails sometimes, mostly because different teams require different things in their process.
But ultimately, since it is about values, if those values are not shared by a company (or at least your division) and management it's going to turn into process for process sake. You're screwed, but it's not agile that screwed you.
Yes, of course?
But I think you might be confused about what agile is, going by your remark about processes that agile imposes. There are none. Agile is about certain values, and people have come up with various processes that try to incorporate those values. This fails sometimes, mostly because different teams require different things in their process.
But ultimately, since it is about values, if those values are not shared by a company (or at least your division) and management it's going to turn into process for process sake. You're screwed, but it's not agile that screwed you.
Then it becomes completely meaningless - It's the equivalent to saying to someone - "Be good" without defining anything about what good-ness involves.
Once you start defining specifically what you mean by good, if your initial premise falls apart and there's no practical way to be good, then what's the point of saying be good?
Once you start defining specifically what you mean by good, if your initial premise falls apart and there's no practical way to be good, then what's the point of saying be good?
>Because they show common misunderstandings about Agile
I agree with most of what you're saying. I've found this to be the biggest barrier to the process actually working. People don't understand the purpose of what is being achieved with X meeting/process and so will actively try to subvert it. Sometimes as engineers we're too smart for our own good, and sometimes we don't listen to what we're being told.
I went through the SM training and really brought into it, however, it's a difficult job to do well. Sometimes being the bad guy and telling your product owner no, or yes but here are the consequences can make you hated (literally a former co-worker and Po/PM of mine won't say more than Hi to me)
>If you can self-organize, effectively communicate, and help one another as-needed without standups
Another anecdote I have is this happening only to find out over approximately a 4 month period that we weren't good communicators, that we did need frequent structured communication to get things done right (right being the keyword). Even though this was the `smartest`, highest paid, most experienced team I've ever worked with, there was still re-work and production outages because of a lack of good coms. This probably could've been avoided if planning meetings were being attended.
Bottom line, agile processes are written in blood that you don't need to shed. Convincing a team of engineers this is the hard part.
I agree with most of what you're saying. I've found this to be the biggest barrier to the process actually working. People don't understand the purpose of what is being achieved with X meeting/process and so will actively try to subvert it. Sometimes as engineers we're too smart for our own good, and sometimes we don't listen to what we're being told.
I went through the SM training and really brought into it, however, it's a difficult job to do well. Sometimes being the bad guy and telling your product owner no, or yes but here are the consequences can make you hated (literally a former co-worker and Po/PM of mine won't say more than Hi to me)
>If you can self-organize, effectively communicate, and help one another as-needed without standups
Another anecdote I have is this happening only to find out over approximately a 4 month period that we weren't good communicators, that we did need frequent structured communication to get things done right (right being the keyword). Even though this was the `smartest`, highest paid, most experienced team I've ever worked with, there was still re-work and production outages because of a lack of good coms. This probably could've been avoided if planning meetings were being attended.
Bottom line, agile processes are written in blood that you don't need to shed. Convincing a team of engineers this is the hard part.
I'm Old Expert Programmer Dude now, so I get to tell stories.
1. Worked with a team of outside experts once. We were brought in to stand up an internal team of coaches. The first week there, the four of us got together. I asked "Do we want to do standups?"
Another coach said nope, we're professionals! What do we need standups for?
The rest of us met every morning for breakfast. No standing up, no meeting. But we knew what we had to cover in between shooting the crap.
We did well. He did not.
2. Worked with another team once who were doing some gnarly embedded work. The lead, a super-smart C++ guy, announced that he wasn't going to do standups because he was a professional (see a pattern here?) and could communicate just fine without tossing a football around.
He finally came. Every morning the team would have fun with the nerf ball (which is just something fun to toss around. Who cares if you have one or not?) When it was his turn, everybody stopped smiling and somebody put the little football on the ground at his feet. Then he spoke. He never did touch the nerf ball.
I was trying to help them do mocks and rapid hardware prototyping, but he wasn't getting it. Finally one day, just after the standup, somebody said something like "You know John, if we did this thing like this, we could work a lot faster"
He said he hadn't thought of that (even though multiple people had suggested it. It just wasn't phrased the right way for some reason) and agreed to start right away.
I smiled as he left and asked him "Wasn't that a great standup!"
"Nope. Could've had that conversation just the same without the stupid meeting"
Yes, you could have. But you didn't. Communication is weird. There are no big, flashing red lights when you fuck it up. And when it works, it doesn't feel like anything has happened.
So when people want to do things differently, I always encourage it. If they focus on the goal, they'll come back to these lessons. If they focus on the ritual, however, it'll never ever make any sense to them. (And they very well may end up making life miserable on everybody around them)
1. Worked with a team of outside experts once. We were brought in to stand up an internal team of coaches. The first week there, the four of us got together. I asked "Do we want to do standups?"
Another coach said nope, we're professionals! What do we need standups for?
The rest of us met every morning for breakfast. No standing up, no meeting. But we knew what we had to cover in between shooting the crap.
We did well. He did not.
2. Worked with another team once who were doing some gnarly embedded work. The lead, a super-smart C++ guy, announced that he wasn't going to do standups because he was a professional (see a pattern here?) and could communicate just fine without tossing a football around.
He finally came. Every morning the team would have fun with the nerf ball (which is just something fun to toss around. Who cares if you have one or not?) When it was his turn, everybody stopped smiling and somebody put the little football on the ground at his feet. Then he spoke. He never did touch the nerf ball.
I was trying to help them do mocks and rapid hardware prototyping, but he wasn't getting it. Finally one day, just after the standup, somebody said something like "You know John, if we did this thing like this, we could work a lot faster"
He said he hadn't thought of that (even though multiple people had suggested it. It just wasn't phrased the right way for some reason) and agreed to start right away.
I smiled as he left and asked him "Wasn't that a great standup!"
"Nope. Could've had that conversation just the same without the stupid meeting"
Yes, you could have. But you didn't. Communication is weird. There are no big, flashing red lights when you fuck it up. And when it works, it doesn't feel like anything has happened.
So when people want to do things differently, I always encourage it. If they focus on the goal, they'll come back to these lessons. If they focus on the ritual, however, it'll never ever make any sense to them. (And they very well may end up making life miserable on everybody around them)
> The rest of us met every morning for breakfast. No standing up, no meeting. But we knew what we had to cover in between shooting the crap. We did well. He did not.
Basically, since the other guy did not wanted standup you intentionally left him out of loop and communicated only among yourself during breakfast. If there was ever ugly politics, it is this one.
> He finally came. Every morning the team would have fun with the nerf ball (which is just something fun to toss around. Who cares if you have one or not?) When it was his turn, everybody stopped smiling and somebody put the little football on the ground at his feet. Then he spoke. He never did touch the nerf ball.
Frankly, I really don't want to work in environment you and your friends are creating. Regardless of whether I enjoy the process you are pushing for, I don't want to work with people who intentionally sabotage people they disagree with - and then brag about it. If there is something called inability to work with different people, this right here is it.
The pattern I see here is that your colleges are intentionally toxic to those who don't share their preferences and then blame victims. You refused to communicate like adults resorting to passive aggression, not your opposition.
Basically, since the other guy did not wanted standup you intentionally left him out of loop and communicated only among yourself during breakfast. If there was ever ugly politics, it is this one.
> He finally came. Every morning the team would have fun with the nerf ball (which is just something fun to toss around. Who cares if you have one or not?) When it was his turn, everybody stopped smiling and somebody put the little football on the ground at his feet. Then he spoke. He never did touch the nerf ball.
Frankly, I really don't want to work in environment you and your friends are creating. Regardless of whether I enjoy the process you are pushing for, I don't want to work with people who intentionally sabotage people they disagree with - and then brag about it. If there is something called inability to work with different people, this right here is it.
The pattern I see here is that your colleges are intentionally toxic to those who don't share their preferences and then blame victims. You refused to communicate like adults resorting to passive aggression, not your opposition.
Maybe they were being toxic, but it simply seems like they took a little time in the morning to go over things and he chose not to join them. So what should they have done, each staged separate little talks with him to go over everything that was discussed in their morning meetings? Compile meeting notes and send them to him?
It doesn't sound so much like sabotage as it does that he chose to put his head down and eschew the meeting and struggled because of it.
It doesn't sound so much like sabotage as it does that he chose to put his head down and eschew the meeting and struggled because of it.
No, of course not. "We are having coordination meeting at <insert reasinable time and place>" announcement is already fine. Just starting standup when everyone is in office even if he disagree is fine too.
The time and place here seem juuuuust coincide with time and place he is least likely to be at. Standups are not supposed to be passive aggresive way to enforce early coming to work either (most coders have flexible time, your process should honor that) nor are they supposed to prevent you to have breakfast with familly or alone in home.
And yes, if collegue does nor know info he needs for work, I would tell it to him even if he clearly missed it by his own mistake. I would also tell him that he don't know info because he ignores meetings he should be at. Transparency and open discussion, basically.
Otherwise said, you solve it like any other disagreement over something that requires coordination.
The time and place here seem juuuuust coincide with time and place he is least likely to be at. Standups are not supposed to be passive aggresive way to enforce early coming to work either (most coders have flexible time, your process should honor that) nor are they supposed to prevent you to have breakfast with familly or alone in home.
And yes, if collegue does nor know info he needs for work, I would tell it to him even if he clearly missed it by his own mistake. I would also tell him that he don't know info because he ignores meetings he should be at. Transparency and open discussion, basically.
Otherwise said, you solve it like any other disagreement over something that requires coordination.
>see a pattern here?
Yes, the pattern is arrogance.
>And when it works, it doesn't feel like anything has happened
Exactly, which is why it's so hard to keep people on board when all is going well. The meetings start seeming like a waste of time and then you end up falling into cyclic relearning traps.
Good chat though, I'm sure most people who have been SMs will have similar stories.
Yes, the pattern is arrogance.
>And when it works, it doesn't feel like anything has happened
Exactly, which is why it's so hard to keep people on board when all is going well. The meetings start seeming like a waste of time and then you end up falling into cyclic relearning traps.
Good chat though, I'm sure most people who have been SMs will have similar stories.
"agile" is great. "Agile" has been fucked to death by consultants and execs who just heard "wait you can make developers completely fungible and i can get something in 2 weeks rather than waiting for 2 years?" and never bothered to listen to anything else.
That is how I view it:
- "big A" Agile has books and approved tools and coaches from outside the company holding week-long all-day workshops.
- "little a" agile has devs/QA/etc. suggesting ways to make the process of building and shipping software smoother.
I'm currently working on a "little a" agile team. Upper management doesn't really care what our process is, as long as they get their quarterly release with (most) of their priorities.
I'm currently working on a "little a" agile team. Upper management doesn't really care what our process is, as long as they get their quarterly release with (most) of their priorities.
I'm becoming increasingly convinced that, to be successful, a team's agile practice needs to largely fly under the radar of upper management.
As soon as upper management catches wind, you'll need to justify every little process flow change to them, or they'll start demanding regular reports with burndown charts and plots of velocity over time and crap like that. At which point, you're done. Things officially suck forever.
That isn't to say that I think Scrum coaches and whatever have no value to offer. I've done a 1-week Agile training course, and I thought it presented some really great ideas. But their potential value is severely undercut by the fact that there's no way to bring one in without attracting the attention of the mothership.
As soon as upper management catches wind, you'll need to justify every little process flow change to them, or they'll start demanding regular reports with burndown charts and plots of velocity over time and crap like that. At which point, you're done. Things officially suck forever.
That isn't to say that I think Scrum coaches and whatever have no value to offer. I've done a 1-week Agile training course, and I thought it presented some really great ideas. But their potential value is severely undercut by the fact that there's no way to bring one in without attracting the attention of the mothership.
I had that once, the bit where management wanted to see the burndowns and velocity, then fixated over same. The only way to move past it was to stop producing them. I did, as the Lead/SM/Dev Manager, have the clout to say no, so that was lucky. I explained it's the working software you need but I don't think they were happy.
> As soon as upper management catches wind, you'll need to justify every little process flow change to them, or they'll start demanding regular reports with burndown charts and plots of velocity over time and crap like that.
I think that's a management problem you'll run into with any development methodology you use. There are a lot of management types that slavishly focus on metrics whether or not they make any sense, and they can do tremendous damage to any organization.
Give those people a tool and they'll find a way to misapply it, whether it's velocity, or performance reviews, or LOC, or whatever.
Prime example of this was stack ranking at Microsoft. How much productivity was lost due to the political maneuvering and backbiting caused by their misunderstanding of bell curves?
I think that's a management problem you'll run into with any development methodology you use. There are a lot of management types that slavishly focus on metrics whether or not they make any sense, and they can do tremendous damage to any organization.
Give those people a tool and they'll find a way to misapply it, whether it's velocity, or performance reviews, or LOC, or whatever.
Prime example of this was stack ranking at Microsoft. How much productivity was lost due to the political maneuvering and backbiting caused by their misunderstanding of bell curves?
That's a strange reading of Agile to me. Agile is not about making developers fungible, it's about building high performing teams of people. That takes time, and it is set back any time you have to replace someone. There's plenty of Agile literature that points out the hit to velocity when there's turnover.
As for 'i can get something in 2 weeks rather than waiting for 2 years', that's about not waiting 2 years to find out that you've been building the wrong thing or that the software sucks. Maybe as you deliver features you'll find out that the application is good enough in 18 months. Maybe you'll find out after several months of sprints that the product owner is bad at getting requirements and you need to do something different. Or maybe you'll find out that it is taking longer than original estimated to deliver functionality so important dates need to be adjusted accordingly.
In the old waterfall model, all that bad news may not come out until 2 years later when the software is released. And in the old model the customer is not getting useful software until 2 years out, rather than much sooner with a minimally viable product.
Agile is not a panacea and any methodology will fail if attempted by dysfunctional/incompetent groups of people. But if there's one benefit of Agile, is that everyone should find out much sooner that things are going awry.
As for 'i can get something in 2 weeks rather than waiting for 2 years', that's about not waiting 2 years to find out that you've been building the wrong thing or that the software sucks. Maybe as you deliver features you'll find out that the application is good enough in 18 months. Maybe you'll find out after several months of sprints that the product owner is bad at getting requirements and you need to do something different. Or maybe you'll find out that it is taking longer than original estimated to deliver functionality so important dates need to be adjusted accordingly.
In the old waterfall model, all that bad news may not come out until 2 years later when the software is released. And in the old model the customer is not getting useful software until 2 years out, rather than much sooner with a minimally viable product.
Agile is not a panacea and any methodology will fail if attempted by dysfunctional/incompetent groups of people. But if there's one benefit of Agile, is that everyone should find out much sooner that things are going awry.
I've worked in waterfall and agile for 15 years, and the key lesson from Scrum is that it effectively exposes bad news early on. The scrum ceremonies do just that and nothing more. Once you get the bad news open and dealt with a lot of other work is made more worthwhile.
The moment someone says they're a certified scrum master you know you're fucked.
It's so true. So many people think "Agile is bad because my company does ineffective standups". That's not what Agile is! Agile is about continuous improvement.
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
It's pretty simple but somehow people confuse this and Scrum (with bad scrummasters) and blame Agile for what's actually ineffective leadership
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
It's pretty simple but somehow people confuse this and Scrum (with bad scrummasters) and blame Agile for what's actually ineffective leadership
In my experience, at least at bigger companies, standups are there to justify the project manager’s job. It’s for them to tally that everyone is doing their work. Simply, they see that the team wishes to meet for development purposes and it gets co-opted into a status meeting.
I find that small business gets it right more often because there is simply less bureaucracy and developers are much more trusted.
I find that small business gets it right more often because there is simply less bureaucracy and developers are much more trusted.
Feel free to send them this way. I’m currently working at a startup where the CEO is the product owner/manager, as well as doing all the CEO duties. A good PM would be a dream come true right now.
PMs have a role, no doubt. They should help facilitate discussion and help protect the team and communicate upward, and provide guidance where necessary. I have worked with some that did this well. I have also worked with some who cared so much about status that it negatively affected the team because they wanted five or more meetings a week (even stand-ups took an hour each). This type of disruption isn't limited to PMs, of course, it's just something I've found in my experience -- more-so than any other role.
Can you articulate an example of a good versus a bad standup? Because your response is pretty vague. I've been on a lot of teams, read a lot about Agile and SCRUM, and just about every single one communicates stand-ups as a status update, not what you are indicating at all. If this was an isolated thing, I would agree with you, but when almost everyone is doing it this "wrong" way, as you say, I think the problem is with "agile," as loaded as that term is these days.
I don't even understand how you can get together to "move the project forward" and it be under 5 or even 15 minutes. What does that even mean in practical terms? That kind of open-ended question usually devolves into many different unfocused discussions and then pretty soon everyone clearly wants to leave.
I don't even understand how you can get together to "move the project forward" and it be under 5 or even 15 minutes. What does that even mean in practical terms? That kind of open-ended question usually devolves into many different unfocused discussions and then pretty soon everyone clearly wants to leave.
Yes! This is right on the money. So many people forget that "being Agile" is an active undertaking, something that takes reflection and iterative improvement of not just the things you're building, but also the process you're using (in search of a way that works specifically for you and your team). One easy step is rethinking the classic standup questions, in a way to address the overall question "what do you need?".
The only useful result of standups that I ever saw consistently was when people spoke up about tasks they were blocked on, and cross-team collaboration allowed a pathway towards a solution to be established more quickly and smoothly than if the exchange had occurred over email or Slack.
Aside from that, the only purpose of a stand up that I experienced was to posture ones self and otherwise waste company time.
Aside from that, the only purpose of a stand up that I experienced was to posture ones self and otherwise waste company time.
I think most times, the individual developers are not the ones that choose to do Agile (or which flavor of Agile), and in many cases, they have no agency to change anything. So when you're in a situation with "hour long standups," you're not really able to do anything about it, due to the business people who are really in charge not wanting to change.
> they have no agency to change anything
If this is the case, than that's a sad state of affairs for the team. Instead the Team should have retrospectives to freely talk about, what processes/ceremonies work and add to the teams efficiency at getting things done and which do not or are even detrimental.
With each iteration of a retro the Team should slowly but surely progress towards a local optimum, where they shaped their work environment such that they can work best.
> due to the business people who are really in charge not wanting to change.
Stand-ups should be only for the team and SM. Sometimes a domain expert/PO can be added to the mix, if issues need clarification. But never should managers or stake holders bother the team during internal coordination of the work (as others said, standups are no status-report).
If this is the case, than that's a sad state of affairs for the team. Instead the Team should have retrospectives to freely talk about, what processes/ceremonies work and add to the teams efficiency at getting things done and which do not or are even detrimental.
With each iteration of a retro the Team should slowly but surely progress towards a local optimum, where they shaped their work environment such that they can work best.
> due to the business people who are really in charge not wanting to change.
Stand-ups should be only for the team and SM. Sometimes a domain expert/PO can be added to the mix, if issues need clarification. But never should managers or stake holders bother the team during internal coordination of the work (as others said, standups are no status-report).
"If this is the case, than that's a sad state of affairs for the team. Instead the Team should have retrospectives to freely talk about, what processes/ceremonies work and add to the teams efficiency at getting things done and which do not or are even detrimental."
I mean, that sounds great, but in many of these situations, which are quite sad, the biggest problems they face are management that doesn't completely buy in, but still wants to tout that they're "Agile". So no getting rid of any ceremonies.
"With each iteration of a retro the Team should slowly but surely progress towards a local optimum, where they shaped their work environment such that they can work best."
Again, not all the issues are ones that the Team directly can address.
"Stand-ups should be only for the team and SM."
Should. Should is the operative word there. And I understand what you're trying to say in your comment, but it just completely ignores what reality is like at some places.
I mean, that sounds great, but in many of these situations, which are quite sad, the biggest problems they face are management that doesn't completely buy in, but still wants to tout that they're "Agile". So no getting rid of any ceremonies.
"With each iteration of a retro the Team should slowly but surely progress towards a local optimum, where they shaped their work environment such that they can work best."
Again, not all the issues are ones that the Team directly can address.
"Stand-ups should be only for the team and SM."
Should. Should is the operative word there. And I understand what you're trying to say in your comment, but it just completely ignores what reality is like at some places.
I famously got outraged at my team the day after our planning meetings + interviews the whole team was on.
"Yesterday we had meetings"
because while that's helpful in retro finding out where time went; it doesn't update or encourage more thought on the current work. I pushed my team to think about things that others would ask questions about and how it affected their work.
"Yesterday we had meetings"
because while that's helpful in retro finding out where time went; it doesn't update or encourage more thought on the current work. I pushed my team to think about things that others would ask questions about and how it affected their work.
But they likely haven't actually started anything. I think that's the worst part about standups is they require everyone to get up and say something. If you've got nothing to say, then you end up saying idiotic stuff like "yesterday was meetings". (I do also think that having everyone take a turn at speaking is one of the good things about them, because otherwise it's really easy for one or two people to take the whole time talking about their thing, and a shyer person might not be able to get in a word that they otherwise really would have wanted/needed to.)
[deleted]
[deleted]
You are right, of course, in an abstract sense. But in the real world, this reminds me of the "we never had communism!" argument (because somehow, all those who implemented it, got it "wrong" and failed the principles). I mean, the principles behind communism might be noble and great, but if they ignore the human nature and the realities of the world, then, what good are they? If communism always seems to lead to murderous regimes, maybe it's better to avoid it than to attempt to "implement it right, this time"?
Of course, the parallels between "communism" and "agile" are imperfect. But the same way that various forms of "real communism" might work in small communities but fail spectacularly in large organizations, maybe "agile" is in fact actively harmful in corporations? Just a thought.... because I've never seen it implemented right. OTOH, I can't say I've seem good software practices in any large corporations (small pockets of excellence, yes, but they often work "against the system", not because of it).
Of course, the parallels between "communism" and "agile" are imperfect. But the same way that various forms of "real communism" might work in small communities but fail spectacularly in large organizations, maybe "agile" is in fact actively harmful in corporations? Just a thought.... because I've never seen it implemented right. OTOH, I can't say I've seem good software practices in any large corporations (small pockets of excellence, yes, but they often work "against the system", not because of it).
This seems like some application of "no true scottsman" combined with complex human interactions in a theoretically "simple" system. I guess the perfectly rational consumer fits in somehow too.
[deleted]
[deleted]
Let the developers alone.
This means the tech lead must find something else to do.
Good.
However, all the tech leads I've met think their job is to get up in my hair.
Stop doing it, is what I want to say.
However, we need to show the tech leads what we really need from them.
So they don't displace their activity getting up in my hair.
This means the tech lead must find something else to do.
Good.
However, all the tech leads I've met think their job is to get up in my hair.
Stop doing it, is what I want to say.
However, we need to show the tech leads what we really need from them.
So they don't displace their activity getting up in my hair.
You describe a better way of doing standups than simply status reports, but I'm finding it hard to distil into a couple of sentences. Could you help me understand what a better standup would look like?
Talking about team communication in the abstract is difficult. I wrote a book about it. [1]
The problem is that you are looking for the maximum amount of valuable communication with the minimum amount of overhead. That is almost impossible to reliably quantify, however, because each team develops their own communication and language style. This is the tension we face: outside folks who mean well want to standardize things so that teams have a better chance of succeeding. But the only thing they accomplish by doing this is creating a lot of friction, waste, and overhead. It does not matter if your TPS report has a cover sheet or whether your standup is at noon or not. Nor does it matter whether you're using Trello or crayons. You're focusing on the wrong thing.
If we limit our discussion to teams located in one place using a physical board, I have noticed that standups that focus on the board, the work, happen with better teams. (They don't make teams better. Good teams tend to do it that way). A few useful tokens of testable work on the wall that people can point at and talk about how those goals are going tends to focus the conversation around value.
On the other end of the spectrum, large spreadsheets or online tools where each person reports on what they're doing usually show a completely waste of time and a death march. I worked with a VP once of a major corporation that kept a 100-300 line spreadsheet with "promises" he received from all his teams. We spent every Monday morning for hours reviewing each promise and talking about how we had failed the clan and dishonored ourselves. Oof. It was horrible.
1. https://leanpub.com/info-ops
The problem is that you are looking for the maximum amount of valuable communication with the minimum amount of overhead. That is almost impossible to reliably quantify, however, because each team develops their own communication and language style. This is the tension we face: outside folks who mean well want to standardize things so that teams have a better chance of succeeding. But the only thing they accomplish by doing this is creating a lot of friction, waste, and overhead. It does not matter if your TPS report has a cover sheet or whether your standup is at noon or not. Nor does it matter whether you're using Trello or crayons. You're focusing on the wrong thing.
If we limit our discussion to teams located in one place using a physical board, I have noticed that standups that focus on the board, the work, happen with better teams. (They don't make teams better. Good teams tend to do it that way). A few useful tokens of testable work on the wall that people can point at and talk about how those goals are going tends to focus the conversation around value.
On the other end of the spectrum, large spreadsheets or online tools where each person reports on what they're doing usually show a completely waste of time and a death march. I worked with a VP once of a major corporation that kept a 100-300 line spreadsheet with "promises" he received from all his teams. We spent every Monday morning for hours reviewing each promise and talking about how we had failed the clan and dishonored ourselves. Oof. It was horrible.
1. https://leanpub.com/info-ops
Do you have any advice for someone in a senior IC role to actually get people setting the processes to shift their thinking from optimizing general metrics and making everything more homogenous, into a model where everything is contextualized (like your examples) and then we draw out higher-level patterns by analyzing the common traits that organically arise as a result of contextual solutions?
Ping me. I'm happy to provide any free advice I can over the phone as long as it has a chance of helping developers. HN isn't the place for this, however, as whatever I say is just going to open up a religious war. (Disclaimer: I am currently looking for new clients)
You hire a guy like me because they have a broad and long record of seeing various things work and fail. The first thing you learn is that it takes a lot of examples to start seeing patterns. The worse folks you can deal with are the enthusiasts who have only seen things rock-and-roll a few times. Skeptics are great. Let's go see what works or not. True believers are another thing entirely. Humility is critical here.
There are some things I've seen that work. There are also some things I've read from others that I trust. I've always been a huge believer in success by failure avoidance: it might not matter what you do as much as it matters that you're actively trying to avoid screwing up.
No matter what your mix of strategies, it's a personal call that involves risk and not a kind of conversation you want to have in a room with ten thousand people in it. It's something to think about for a while.
You hire a guy like me because they have a broad and long record of seeing various things work and fail. The first thing you learn is that it takes a lot of examples to start seeing patterns. The worse folks you can deal with are the enthusiasts who have only seen things rock-and-roll a few times. Skeptics are great. Let's go see what works or not. True believers are another thing entirely. Humility is critical here.
There are some things I've seen that work. There are also some things I've read from others that I trust. I've always been a huge believer in success by failure avoidance: it might not matter what you do as much as it matters that you're actively trying to avoid screwing up.
No matter what your mix of strategies, it's a personal call that involves risk and not a kind of conversation you want to have in a room with ten thousand people in it. It's something to think about for a while.
Standups always felt to me that they had a core negative message to developers.
It's not about communication at all. Its about control, its about saying:
We don't trust you.
We are going to check on you to see what you are doing, every single day, because you are not a responsible adult and need constant surveillance.
Its also about putting constant psychological pressure on developers, to make sure they complete the tasks as soon as possible, and move on to the next task in the list.
Even if developers know that some refactoring is absolutely needed or this production issue needs a closer look because something strange is going on, developers don't have the autonomy to just do what they know needs to be done.
Everything needs to be pre-approved by a non technical manager and assigned a JIRA or equivalent.
Looking back, to me its clear that I resented standups, they made me feel like I was being treated as an assembly line worker.
It's not about communication at all. Its about control, its about saying:
We don't trust you.
We are going to check on you to see what you are doing, every single day, because you are not a responsible adult and need constant surveillance.
Its also about putting constant psychological pressure on developers, to make sure they complete the tasks as soon as possible, and move on to the next task in the list.
Even if developers know that some refactoring is absolutely needed or this production issue needs a closer look because something strange is going on, developers don't have the autonomy to just do what they know needs to be done.
Everything needs to be pre-approved by a non technical manager and assigned a JIRA or equivalent.
Looking back, to me its clear that I resented standups, they made me feel like I was being treated as an assembly line worker.
It's worse than "assembly line worker." For that, a hyper-specific set of actions is created, and then commoditized workers are inserted into this rigid process. The spec/actions rarely change over time.
In "what did you do yesterday?" stand-ups, the worker is expected to establish their own personal direct actions in order to meet outside expectations and goals set by their manager/team. And then every morning someone is analyzing those actions for "blockers." A "blocker" is either a case where the manager didn't communicate effectively and/or didn't set effective scope/milestones, or else it's a code word for "you're doing it wrong" and gives the manager a change to micro-manage the specific actions the worker is taking day-to-day.
In any case, I firmly agree with you that the core message is "I don't fucking trust you even an inch."
If you want to see a bad engineering manager's brain misfire on cue (if they are of this micro-manager type), ask them why the product manager or designer on your team isn't expected to time-box and pre-estimate his/her spec. writing tasks.
In "what did you do yesterday?" stand-ups, the worker is expected to establish their own personal direct actions in order to meet outside expectations and goals set by their manager/team. And then every morning someone is analyzing those actions for "blockers." A "blocker" is either a case where the manager didn't communicate effectively and/or didn't set effective scope/milestones, or else it's a code word for "you're doing it wrong" and gives the manager a change to micro-manage the specific actions the worker is taking day-to-day.
In any case, I firmly agree with you that the core message is "I don't fucking trust you even an inch."
If you want to see a bad engineering manager's brain misfire on cue (if they are of this micro-manager type), ask them why the product manager or designer on your team isn't expected to time-box and pre-estimate his/her spec. writing tasks.
In orgs I've been in the daily standup was clearly intended to help people get a heads up on who can help them with blockers or may be working on a similar part of the codebase that day. It also helps PMs know what kind of support they'll need to give their dev team that day since they often get pulled into meetings by other parts of the company.
As far as timeboxing, the PM is timeboxed by having stuff in good enough state of definition that their devs feel they can work on them. So if you don't have your specs there by the time sprint planning happens, your projects don't get done and you risk your job. Of course, we have an issue if the PM is writing shitty specs and not around to help answer edge case questions.
As far as timeboxing, the PM is timeboxed by having stuff in good enough state of definition that their devs feel they can work on them. So if you don't have your specs there by the time sprint planning happens, your projects don't get done and you risk your job. Of course, we have an issue if the PM is writing shitty specs and not around to help answer edge case questions.
Standups are one possible solution to a variety of common problems when managing engineers:
- Many engineers prefer to solve issues themselves rather than ask others for help. Often newer engineers don't know when to ask others for help. Standups help to foster this communication.
- Reading code is generally harder than writing code, especially when written using a framework that the engineer is unfamiliar with. This leads to a tendency to declare existing code tech debt and want to re-write it, especially by less experienced engineers. Sometimes this is warranted but often it is not. Standups help guard against this by allowing more senior engineers or managers to catch this early-on.
- There can be valid business reasons to get an unscalable feature out in ~2 weeks rather than scalable feature in ~2 months. Standups provide a quick way to explain the underlying business reasons to the team.
- Business and contracts do require dates & deadlines. Even though it is not perfect, there needs to be some attempt at predicting when a certain feature can be delivered. Jira, and ticket tracking is important for this.
- Many engineers prefer to solve issues themselves rather than ask others for help. Often newer engineers don't know when to ask others for help. Standups help to foster this communication.
- Reading code is generally harder than writing code, especially when written using a framework that the engineer is unfamiliar with. This leads to a tendency to declare existing code tech debt and want to re-write it, especially by less experienced engineers. Sometimes this is warranted but often it is not. Standups help guard against this by allowing more senior engineers or managers to catch this early-on.
- There can be valid business reasons to get an unscalable feature out in ~2 weeks rather than scalable feature in ~2 months. Standups provide a quick way to explain the underlying business reasons to the team.
- Business and contracts do require dates & deadlines. Even though it is not perfect, there needs to be some attempt at predicting when a certain feature can be delivered. Jira, and ticket tracking is important for this.
Not really a fan of standups either, but I want to express a counter point: developers consistently over-estimate their understanding of the problem domain they are working in and the wider context it sits in. That is yes, managers don't "trust" developers - but not in quite as negative a sense as you think. There is a positive aspect of supporting the person, ensuring they are connected to the right resources to succeed and stopping them getting stuck on things that don't matter.
I have a small team of devs and I consistently find that given task X they will get stuck and end up spending a lot of time on small subpart Y. And they really want to solve Y, because they are engineers and doing the "hard" stuff is what often drives them. So without some kind of input, what they will do is spend a week on Y and then report back that X was much harder than expected. When told at that point "Oh, we really actually don't need the Y part, we could just to Z instead" they will be quite disappointed, and wonder why they weren't informed that Y wasn't that important to begin with. So more regular communication of some kind is really important to avoid this. As I mentioned, I don't really like daily standups as the optimal way to achieve it ... but I don't quite accept the "leave your developers alone for weeks at a time" strategy either.
I have a small team of devs and I consistently find that given task X they will get stuck and end up spending a lot of time on small subpart Y. And they really want to solve Y, because they are engineers and doing the "hard" stuff is what often drives them. So without some kind of input, what they will do is spend a week on Y and then report back that X was much harder than expected. When told at that point "Oh, we really actually don't need the Y part, we could just to Z instead" they will be quite disappointed, and wonder why they weren't informed that Y wasn't that important to begin with. So more regular communication of some kind is really important to avoid this. As I mentioned, I don't really like daily standups as the optimal way to achieve it ... but I don't quite accept the "leave your developers alone for weeks at a time" strategy either.
I wish more devs understood what you said instead of taking it as being micro managed. In short, what good managers distrust is the ability to communicate. We are all pretty bad at it. These meetings just give us an opportunity to continually refine what it is we are actually working towards. Agile to me doesn't mean daily standups. It does mean sharing with each other what we've learned about the problem which almost always means reprioritizing. If that communication isn't happening at least a few times a week, there's something off or unusual.
I understand that avoiding spending a week on Y is important for business value, but constantly prioritizing shipping features in the cheapest manner possible also means not investing in the long-term growth of your developers. You don't learn much of value by gluing together a handful of framework functions. You become a better engineer by really struggling with and digging into Y for an entire week. If engineers are never given the freedom to do that, they stagnate as framework glue monkeys. "Deep work" is a rare thing in scrum shops.
That's a really good point. I know my career has nearly entirely been steered from "non-core" activities that I undertook which never would have been justified on a week to week schedule. Businesses also are actually very poor at understanding technical opportunities which developers at the coalface can see (that is, things that are technically easy or at least feasible, possibly due to the specific skill of the engineer(s) in question, but have very high value).
Standups are about developers updating eachother. Basically no one outside the development team should be in the standup. I don't get what's negative about this.
You might be right, but I think you shouldn't be focusing your resentment at standups themselves, you should be focusing on the managerial or corporate culture.
I've worked in places that did standups and places that didn't, and found that the lack of trust / constant surveillance / psychological pressure can be there regardless of whether standups are used.
What does change, though, is that with standups, a manager has the reassurance that they are checking up on their developers every day, and the developers in return get the reassurance that their boss is only going to interrupt them once per day at a fixed time (or at least there's a better chance this is how it works out).
I see "agile" as being a set of compromises and helpful cultural patterns which were designed by taking into account all the weird cognitive biases that brains get forced into by the group dynamics of working in a team on a project.
I've worked in places that did standups and places that didn't, and found that the lack of trust / constant surveillance / psychological pressure can be there regardless of whether standups are used.
What does change, though, is that with standups, a manager has the reassurance that they are checking up on their developers every day, and the developers in return get the reassurance that their boss is only going to interrupt them once per day at a fixed time (or at least there's a better chance this is how it works out).
I see "agile" as being a set of compromises and helpful cultural patterns which were designed by taking into account all the weird cognitive biases that brains get forced into by the group dynamics of working in a team on a project.
I think it's easy for teams to feel this way depending on the mechanics of who's running standup. One of the biggest values I see for standup is talking through what you're working on. This opens communication with other engineers, especially if they default to working in isolation on their projects (even more so for remote engineers). I can't count the number of times we've had actionable changes to direction from just 5 minutes of standup that result in code reuse, uncovering unknown unknowns, etc.
Best description of standup I've ever seen. One of the many reasons I left corporate tech.
Yep this is the exactly right and obvious interpretation.
The entire concept of a sprint to me always felt wrong. Development work can't be split up into time slices. And trying to divvy up tasks based on an estimate of how long it'll take to complete each one is just a waste of time.
I remember being in a standup, being told to bump a high-priority task into the next sprint and complete a couple low-priority tasks instead because I already had too many points assigned to me for that sprint and just thinking...really? If I don't complete the second high-priority task before the end of the sprint, so what? I still made progress on it.
It just felt like so much time was being wasted. We estimated the amount of time each task would take, assigned it points based on that, and we'd fill our task list in such a way to try to make the estimation close 40 hours of work. If you had 30 hours worth of tasks assigned to you already, and there was a 20-hour high-priority task in the queue, it'd get bumped to the next sprint with 10 points of low-priority tasks assigned instead. It was more important to them to get precisely an estimated 40 hours of tasks completed, rather than getting supposedly high-priority tasks done.
Obviously, this frequently resulted in priority inversion, not to mention the problems from poor estimations of task time.
Management was often clueless. You only earned the points when you completed the task. So if you took on two 20-hour tasks, and just barely didn't finish the second one before the end of the week, but then completed that plus 40 hours the next week, they'd question why your productivity swings so much because you only got 20 hours done one week, but 60 hours the next!
And of course, as mentioned, these "hours" were all estimated hours, not the actual hours done. People started overestimating the hours needed for tasks, but management was apparently smart enough to catch on to that when they noticed everyone was getting 50-60 hours worth of work done, despite everyone only working about 40 hours per week.
I've rambled a bit, but you get the idea. I think the author is spot on. Just use your task tracker.
I remember being in a standup, being told to bump a high-priority task into the next sprint and complete a couple low-priority tasks instead because I already had too many points assigned to me for that sprint and just thinking...really? If I don't complete the second high-priority task before the end of the sprint, so what? I still made progress on it.
It just felt like so much time was being wasted. We estimated the amount of time each task would take, assigned it points based on that, and we'd fill our task list in such a way to try to make the estimation close 40 hours of work. If you had 30 hours worth of tasks assigned to you already, and there was a 20-hour high-priority task in the queue, it'd get bumped to the next sprint with 10 points of low-priority tasks assigned instead. It was more important to them to get precisely an estimated 40 hours of tasks completed, rather than getting supposedly high-priority tasks done.
Obviously, this frequently resulted in priority inversion, not to mention the problems from poor estimations of task time.
Management was often clueless. You only earned the points when you completed the task. So if you took on two 20-hour tasks, and just barely didn't finish the second one before the end of the week, but then completed that plus 40 hours the next week, they'd question why your productivity swings so much because you only got 20 hours done one week, but 60 hours the next!
And of course, as mentioned, these "hours" were all estimated hours, not the actual hours done. People started overestimating the hours needed for tasks, but management was apparently smart enough to catch on to that when they noticed everyone was getting 50-60 hours worth of work done, despite everyone only working about 40 hours per week.
I've rambled a bit, but you get the idea. I think the author is spot on. Just use your task tracker.
>The entire concept of a sprint to me always felt wrong. Development work can't be split up into time slices. And trying to divvy up tasks based on an estimate of how long it'll take to complete each one is just a waste of time.
That's because sprints weren't designed for us. They're designed for management. Product managers and VPs need to be able to think of their "resources" in manageable, discrete chunks. Vagaries are an absolute antithesis to their world view. Small boutique firms can avoid this, but mass production means the need for mass conformity.
That's because sprints weren't designed for us. They're designed for management. Product managers and VPs need to be able to think of their "resources" in manageable, discrete chunks. Vagaries are an absolute antithesis to their world view. Small boutique firms can avoid this, but mass production means the need for mass conformity.
They should be designed for us. The idea is supposed to be that there are limited times that developers are negotiating with the outside world about what exactly they are working on. The rest of the time, nobody gets to interrupt and demand that they drop everything and jump on to their latest crazy idea.
But yeah. I currently have to wear both the PO and dev hats, and, when I'm wearing the PO hat, I also see advantages: It means that I get to have a rhythmic schedule that I can set my calendar to. That makes all the orchestration crap so much easier.
Which, incidentally, I also like from a developer perspective. The less time I have to spend on that stuff, or get randomly interrupted by that stuff, or randomly interrupt people with that stuff, the more time I get to spend on actually building stuff.
But yeah. I currently have to wear both the PO and dev hats, and, when I'm wearing the PO hat, I also see advantages: It means that I get to have a rhythmic schedule that I can set my calendar to. That makes all the orchestration crap so much easier.
Which, incidentally, I also like from a developer perspective. The less time I have to spend on that stuff, or get randomly interrupted by that stuff, or randomly interrupt people with that stuff, the more time I get to spend on actually building stuff.
[deleted]
I've noticed similar things. One of the things that bugs me the most in my organization is that managers (product owners, non-very-technical VPs) there's a push to split larger items into bite-sized chunks which can be neatly distributed amongst developers and neatly tracked by PMs. These smaller items are now inter-dependent, which result in a lot of context switches and cache misses, even on an individual scale, not to mention they are often misestimated, and sometimes flat out wrong since they come out of planning meetings rather than thoughtful, careful research.
Why are you estimating things in hours? Why is management tracking the amount of story points every developer completes in a sprint? Why are you not working on the highest prio stuff in the sprint?
Of course sprints look useless if you're doing them like that. Do you even have a clear sprint goal you're working towards?
Of course sprints look useless if you're doing them like that. Do you even have a clear sprint goal you're working towards?
People always say not to estimate in hours and instead to estimate in "points", but at the same time teams tend to plan around how many points they're taking into a sprint. If you have 40 points but usually take only 30, you'll be asked to bump something out.
And once you agree on a number of points to do in 2 weeks, it's not rocket science to figure out an estimated number of hours per point.
And once you agree on a number of points to do in 2 weeks, it's not rocket science to figure out an estimated number of hours per point.
The point (heh) is not that there is no mapping between story points and time, the point is that it helps us acknowledge that these are estimates, not promises that signify failure if broken. No individual estimate is expected to be exact, but we hope that deviations from the estimate average out across the stories in a sprint.
And most importantly, story points make it easy to base our sprint commitment on the available evidence from previous sprints. We say that we can do 40 story points in a sprint, because we know that is roughly what we managed to do in the last few sprints. The conversion factor can change over time as the team gains experience, or the team changes, or the nature of the work changes. It's much harder to do such adjustments when you directly estimate hours.
And most importantly, story points make it easy to base our sprint commitment on the available evidence from previous sprints. We say that we can do 40 story points in a sprint, because we know that is roughly what we managed to do in the last few sprints. The conversion factor can change over time as the team gains experience, or the team changes, or the nature of the work changes. It's much harder to do such adjustments when you directly estimate hours.
> Why are you estimating things in hours?
Because anything else is completely arbitrary. I mean, we ARE measuring things in "points", but with the understanding that 1 point ~ 1 hour of work.
> Why is management tracking the amount of story points every developer completes in a sprint?
Because they want metrics on productivity. I don't entirely blame them.
> Why are you not working on the highest prio stuff in the sprint?
As mentioned, because management really wanted to see us complete 40 hours of work every week, and getting close to 40 hours done per week was more important than priorities. If something couldn't be finished before the end of the sprint, they thought it was better to push it to the next sprint, rather than leave something incomplete at the end of a sprint.
> Of course sprints look useless if you're doing them like that. Do you even have a clear sprint goal you're working towards?
I was on a QA team writing test code. I specifically was writing security tests, while others wrote functionality or stability tests. Each sprint goal was effectively just "Write these tests".
Because anything else is completely arbitrary. I mean, we ARE measuring things in "points", but with the understanding that 1 point ~ 1 hour of work.
> Why is management tracking the amount of story points every developer completes in a sprint?
Because they want metrics on productivity. I don't entirely blame them.
> Why are you not working on the highest prio stuff in the sprint?
As mentioned, because management really wanted to see us complete 40 hours of work every week, and getting close to 40 hours done per week was more important than priorities. If something couldn't be finished before the end of the sprint, they thought it was better to push it to the next sprint, rather than leave something incomplete at the end of a sprint.
> Of course sprints look useless if you're doing them like that. Do you even have a clear sprint goal you're working towards?
I was on a QA team writing test code. I specifically was writing security tests, while others wrote functionality or stability tests. Each sprint goal was effectively just "Write these tests".
I am upvoting because that is totally pathological example of how it should not be. If I end up in place like this I just quit as soon as possible. Maybe they heard something about "Responding to change instead of following plan" and implemented it...
Could not agree more. This coupled with the feeling of being "defeated" when you need to move cards from this sprint to the next sprint just because you didn't get it completed is why my team went away from sprints.
> We estimated the amount of time each task would take, assigned it points based on that, and we'd fill our task list in such a way to try to make the estimation close 40 hours of work.
The concept of story points was invented as an attempt to solve the problem of developers reliably estimating the amount of time a given task will take.
If you're directly equating story points to time then you're doing it wrong.
The concept of story points was invented as an attempt to solve the problem of developers reliably estimating the amount of time a given task will take.
If you're directly equating story points to time then you're doing it wrong.
And yet, story points are used to estimate how much work a team can get done in a sprint, which is a time measurement... and they are used to track velocity, which is used by management to figure out when a project might be completed (also a measurement of time).
"Oh, story points are just about the complexity" Oh really? Why does complexity matter, if not to function as an indicator of how long something might take to finish?
Anyone who is telling you that story points aren't directly related to time estimation is either confused, or lying.
"Oh, story points are just about the complexity" Oh really? Why does complexity matter, if not to function as an indicator of how long something might take to finish?
Anyone who is telling you that story points aren't directly related to time estimation is either confused, or lying.
Absolutely, story points are used as a component in the estimation of time.
Story points on their own are useless though; they are an abstract thing that only means anything to the team and it’s velocity.
A good analogy is that they are an estimate of distance. Knowing roughly how far something is away does not tell you how soon you will get there. You can only do this by working with an average of how fast the team can go.
If the team is terrible at estimating distance, then the velocity will reflect that and gradually self-correct.
Story points on their own are useless though; they are an abstract thing that only means anything to the team and it’s velocity.
A good analogy is that they are an estimate of distance. Knowing roughly how far something is away does not tell you how soon you will get there. You can only do this by working with an average of how fast the team can go.
If the team is terrible at estimating distance, then the velocity will reflect that and gradually self-correct.
Just because you swapped the word "time" with "distance" doesn't mean you aren't still talking about time.
Distance from what? How far it is from now until when the work will be done. You are still talking about time.
I feel that swapping out the term with one that is more vague is, at worst, disingenuous, and at best, counter-productive.
Distance from what? How far it is from now until when the work will be done. You are still talking about time.
I feel that swapping out the term with one that is more vague is, at worst, disingenuous, and at best, counter-productive.
Story points are like BMI: They're meant to be accurate enough that, when you aggregate them over a whole bunch of items, you end up with a reasonably reliable time estimate. But they're a terrible measure of time to complete an individual task. They were never meant to be such a thing in the first place.
That's why the canonical Scrum books always say that the PO can use story points to (roughly) estimate completion dates, but the development team should never use them to figure out how many items to accept into the next sprint.
That's why the canonical Scrum books always say that the PO can use story points to (roughly) estimate completion dates, but the development team should never use them to figure out how many items to accept into the next sprint.
> If you're directly equating story points to time then you're doing it wrong.
But it's not us, the developers, doing this conflation. It's management. No matter how many times we say "story points are useless without a consistent measurement of velocity", they still say "okay, but 2 + 5 + 3 + 2 = 12 dev days, so you and Jane can have ${FEATURE} done on Tuesday, right?"
But it's not us, the developers, doing this conflation. It's management. No matter how many times we say "story points are useless without a consistent measurement of velocity", they still say "okay, but 2 + 5 + 3 + 2 = 12 dev days, so you and Jane can have ${FEATURE} done on Tuesday, right?"
I'm the scrum master on a team where most members are very geographically spread out, and the standup is great. It's time for everyone to have that direct social connection.
But I don't ask about ticket status. We just ask about what they did yesterday, and what they're up to today. And I mostly ask that if they aren't doing something already captured in a ticket, make another one, so we have a record of issues taking up our time. You want to do some tech debt reduction? OK, but keep it unambiguous - "tech debt" is too generic.
The standup typically exposes important issues, like how team members are siloing off from each other. And then we can easily sit down and notice "hey we need to sync up". A lot of ad hoc conversations appear right after standups, that wouldn't have just happened, because people don't often spend their time reading through the comment section on open tickets.
It's really a gut check that yes, the team is indeed working together. If your team's standup is just some regular robotic process of repeating status already captured in tickets... WTF; I'd say you've got serious leadership problems.
But I don't ask about ticket status. We just ask about what they did yesterday, and what they're up to today. And I mostly ask that if they aren't doing something already captured in a ticket, make another one, so we have a record of issues taking up our time. You want to do some tech debt reduction? OK, but keep it unambiguous - "tech debt" is too generic.
The standup typically exposes important issues, like how team members are siloing off from each other. And then we can easily sit down and notice "hey we need to sync up". A lot of ad hoc conversations appear right after standups, that wouldn't have just happened, because people don't often spend their time reading through the comment section on open tickets.
It's really a gut check that yes, the team is indeed working together. If your team's standup is just some regular robotic process of repeating status already captured in tickets... WTF; I'd say you've got serious leadership problems.
Why doesn't everyone just write what they're up to today in a chat channel and people can reply if they want?
It seems kind of silly to me to have everyone dial in or stand around in a circle, to each have one person speak. I'd much rather see a list of what's going on with everyone today and if anything catches my eye, I can talk to them about it.
It seems kind of silly to me to have everyone dial in or stand around in a circle, to each have one person speak. I'd much rather see a list of what's going on with everyone today and if anything catches my eye, I can talk to them about it.
On a mostly-remote team, it may be the only opportunity in a day for everyone to hear everyone else's voices. Social interaction is important.
It creates silos.
We do this on occasion, sometimes people are out, and there's just a few of us around.
I _never_ see social interaction when people do that via chat. It's the same thing as just updating your ticket.
We do this on occasion, sometimes people are out, and there's just a few of us around.
I _never_ see social interaction when people do that via chat. It's the same thing as just updating your ticket.
This sounds to me like a team that went through the agile rituals until everyone was familiar with the benefits and methodologies and got rid of the formal structure once that happened. That's fine. But having structure in place around these things is helpful to newcomers, especially when the entire larger organization is trying to transition from a waterfall process or no process at all.
The list of rituals the author got rid of shows that the team has already learned the more abstract values and benefits and is doing them real-time instead of scheduling them as standalone meetings and sessions. It doesn't mean these things have no value; it means the team is a well-oiled machine.
Except standups. Standups are, have always been, and always will be a waste of time.
The list of rituals the author got rid of shows that the team has already learned the more abstract values and benefits and is doing them real-time instead of scheduling them as standalone meetings and sessions. It doesn't mean these things have no value; it means the team is a well-oiled machine.
Except standups. Standups are, have always been, and always will be a waste of time.
I've been managing engineering teams for a few jobs now, but I think this article suffers from some logical fallacies.
"You don't need stand-ups"
I've actually tried this multiple times with multiple teams in my career. The truth is, is that sure no stand-ups can work... _sometimes_. Some teams some teams we ended up doing 15 minute enforced with a stopwatch stand-ups, we ended up doing a slack standup, and some teams we skipped them altogether.
I too, when I had my first engineering team skip stand-ups and retros felt like I had unlocked some secret in management, as work was indeed getting done.
But the very next team I tried it on it failed miserably. Tons of conflicts, duplicated work, etc. We also tried to "fix them as they went" but what ended up happening is that bringing up and trying to resolve every issue when it happened got difficult. Naturally we kept "tabling" issues to discuss later and we never did until we create monthly meetings to discuss all the issues together. Funny how a "retro" ended up organically forming.
The truth is, every team is different. What works with one team won't work with another. I've found that as a general rule, a regular check in with engineers help align goals and what they are working on. And a somewhat regular cadence of evaluating _how_ you do work makes sense.
I also think the authors marriage analogy is weak. At work, your team isn't a family. It's a team. You can't fire family members. A team you need to stay consistently plugged in because you are trying to complete specific objectives. Marriage is rarely like that.
"You don't need stand-ups"
I've actually tried this multiple times with multiple teams in my career. The truth is, is that sure no stand-ups can work... _sometimes_. Some teams some teams we ended up doing 15 minute enforced with a stopwatch stand-ups, we ended up doing a slack standup, and some teams we skipped them altogether.
I too, when I had my first engineering team skip stand-ups and retros felt like I had unlocked some secret in management, as work was indeed getting done.
But the very next team I tried it on it failed miserably. Tons of conflicts, duplicated work, etc. We also tried to "fix them as they went" but what ended up happening is that bringing up and trying to resolve every issue when it happened got difficult. Naturally we kept "tabling" issues to discuss later and we never did until we create monthly meetings to discuss all the issues together. Funny how a "retro" ended up organically forming.
The truth is, every team is different. What works with one team won't work with another. I've found that as a general rule, a regular check in with engineers help align goals and what they are working on. And a somewhat regular cadence of evaluating _how_ you do work makes sense.
I also think the authors marriage analogy is weak. At work, your team isn't a family. It's a team. You can't fire family members. A team you need to stay consistently plugged in because you are trying to complete specific objectives. Marriage is rarely like that.
Here's a thought experiment, and a challenge: When was the last time you learned something really important at a standup meeting that you wouldn't have learned otherwise, either by talking to someone directly or in some form of asynchronous communication?
I bet it was a while ago, if you can even think of anything specific.
Standups, in my experience, are a net negative, in that there is a cost, but rarely a benefit. I almost never get anything useful from them. I don't need to know that the product owner is in meetings all day. That's almost every day. I don't need to know what every single other developer is doing every single day. If I have a general idea of what the team is doing that's usually good enough. If I am blocked on something, how is that useful for you to know? If there's anything you can do about it, or need to communicate to somebody else, I've probably already talked to you. And if I haven't talked to you, it's almost certainly irrelevant to you.
Challenge: For the next week, make a note (actually write it down on paper) of something useful and actionable you learned at a standup meeting, and see how many times that happens. Then compare the cost of the time spent in standups to the number of times it was useful.
I bet it was a while ago, if you can even think of anything specific.
Standups, in my experience, are a net negative, in that there is a cost, but rarely a benefit. I almost never get anything useful from them. I don't need to know that the product owner is in meetings all day. That's almost every day. I don't need to know what every single other developer is doing every single day. If I have a general idea of what the team is doing that's usually good enough. If I am blocked on something, how is that useful for you to know? If there's anything you can do about it, or need to communicate to somebody else, I've probably already talked to you. And if I haven't talked to you, it's almost certainly irrelevant to you.
Challenge: For the next week, make a note (actually write it down on paper) of something useful and actionable you learned at a standup meeting, and see how many times that happens. Then compare the cost of the time spent in standups to the number of times it was useful.
> Here's a thought experiment, and a challenge: When was the last time you learned something really important at a standup meeting that you wouldn't have learned otherwise, either by talking to someone directly or in some form of asynchronous communication?
Twice this sprint, a problem I mentioned at standup was addressed at that moment by a comment or suggestion from a teammate. The standup is really the only venue I have to casually, non-directionally vent frustrations I'm facing. They're great.
Twice this sprint, a problem I mentioned at standup was addressed at that moment by a comment or suggestion from a teammate. The standup is really the only venue I have to casually, non-directionally vent frustrations I'm facing. They're great.
I can hardly remember the last time I personally learned something just from attending a standup, but I guarantee I've taught other developers a thing or two regarding their problems and tasks that they otherwise would have floundered about trying to solve on their own. Just because it doesn't benefit you doesn't mean it doesn't benefit the team and project.
A team where the Engineering Lead(or any kind of manager) thinks that you don't need retros because there are no problems is exactly the kind of team that needs retros.
My experience is that most retros result in a list of things that should get addressed but never get addressed. Especially because they must be addressed by larger organizational changes once the low hanging fruit has been addressed, In teams where we actually addressed these issues we ran out of things to say in the retro after a few times.
Things being recognised and never/rarely acted on is better than them going unrecognised entirely. At least in the former scenario, there's a shared awareness of the problem.
There isn't. Raising an issue without ever fixing it is very demotivating and causes a "fuck it" attitude.
Everyone being aware of an issue without it ever being raised or acknowledged is equally demotivating and results in the same attitude.
Same thing. Issues that are known and don't get fixed are demotivating.
You may have missed the part where the author says that problems should be addressed as they come up and not just once at the end of the week.
A retro obligates people to find and/or bring up issues. In my opinion an open door policy would push people to bring up things that actually matter.
A retro obligates people to find and/or bring up issues. In my opinion an open door policy would push people to bring up things that actually matter.
This is a situation that really depends on the team. If your team isn't surfacing issues, then either you're creating an environment where people don't feel comfortable surfacing issues, or your team is mostly just not the type that is proactive about it.
If it's the latter, then "priming the pump" is a useful exercise, and a regular retrospective makes tons of sense.
That's also generally true of processes: every team has its quirks, and you fit the processes to the team's quirks.
If it's the latter, then "priming the pump" is a useful exercise, and a regular retrospective makes tons of sense.
That's also generally true of processes: every team has its quirks, and you fit the processes to the team's quirks.
Retros are also for bringing up what went well, discussing why it went well, and how to do that in the future.
Meh. A team with a leader/manager like that isn't going to get much value out of retros because either the leader/manager isn't going to listen to what's being said, or everyone won't feel safe enough to be able to say what needs to be said.
Posts like this usually have good points, but I feel like they should always come with a massive caveat:
Every team is different, and you should tailor your processes to fit the team.
And because of this, I think posts like this one should spend time answering:
What conditions were needed for your decision to be a good idea? And when would your decision be a bad idea?
The author seems aware of this, because he tries to generalize to just not over-complicating things. But his post is pretty much just arguments for removing meetings entirely without really considering when that might not be a good idea. And there are definitely teams and circumstances where that might not be a good idea.
Every team is different, and you should tailor your processes to fit the team.
And because of this, I think posts like this one should spend time answering:
What conditions were needed for your decision to be a good idea? And when would your decision be a bad idea?
The author seems aware of this, because he tries to generalize to just not over-complicating things. But his post is pretty much just arguments for removing meetings entirely without really considering when that might not be a good idea. And there are definitely teams and circumstances where that might not be a good idea.
Isn't pretty much that caveat right under the title?
"Notice: Below represents my PERSONAL beliefs about agile and team organization. Your results may vary."
"Notice: Below represents my PERSONAL beliefs about agile and team organization. Your results may vary."
Not quite. I think there's an important distinction. That caveat says: "I think you should do things this way, it might work for you." But what I'm asking for is: "I think, under these conditions, you should do things this way."
But you're right to point this out. I think I phrased my post badly. The caveat isn't the important part. The second point is the really important one. The decision framework for when to take any specific piece of advice is more important than the advice itself. In general (and this is definitely true with development process advice), advice is plentiful and often conflicting, and most of it gives you ideas of what to do, but doesn't tell you when it's applicable. The really good books, courses, and blog posts I've found do exactly that.
But you're right to point this out. I think I phrased my post badly. The caveat isn't the important part. The second point is the really important one. The decision framework for when to take any specific piece of advice is more important than the advice itself. In general (and this is definitely true with development process advice), advice is plentiful and often conflicting, and most of it gives you ideas of what to do, but doesn't tell you when it's applicable. The really good books, courses, and blog posts I've found do exactly that.
Is there any reason to believe that a process that interrupts an entire team every day to make everyone listen to non-critical updates would be necessary?
Standups are (in my experience) usually a symptom of a low-trust environment, where there's an underlying belief that engineers will do less work or let things slip without the fear of being behind at the next standup. In some companies, this is actually true - so in some cases, standups are certainly effective - but I can't think of any argument for why they'd be necessary at all companies.
Our team is distributed and has been going ~eight months without standups or work hours, and I'm extremely happy with the quality and pace of our engineering. This requires a high-trust environment where every person is given large feature areas that they are able (and incentivized) to drive autonomously, but I think this ends up being better both for productivity and for quality-of-life.
Standups are (in my experience) usually a symptom of a low-trust environment, where there's an underlying belief that engineers will do less work or let things slip without the fear of being behind at the next standup. In some companies, this is actually true - so in some cases, standups are certainly effective - but I can't think of any argument for why they'd be necessary at all companies.
Our team is distributed and has been going ~eight months without standups or work hours, and I'm extremely happy with the quality and pace of our engineering. This requires a high-trust environment where every person is given large feature areas that they are able (and incentivized) to drive autonomously, but I think this ends up being better both for productivity and for quality-of-life.
> Standups are (in my experience) usually a symptom of a low-trust environment
and or a high volatility process and or poor information flow. All of these things occur at different times throughout any company. Standups mitigate these issues and are not supposed to be these hour marathons that I see everywhere.
and or a high volatility process and or poor information flow. All of these things occur at different times throughout any company. Standups mitigate these issues and are not supposed to be these hour marathons that I see everywhere.
Agreed that those are other common causes.
I think that keeping standups short does very little to mitigate the damage they cause, though. The biggest cost isn't the time they take, it's the act of forcing your entire engineering team out of a flow state (or worse, forcing them to wait until after standup to even start) on a daily basis. That happens regardless of if they're 10 minutes or 30 minutes.
I think that keeping standups short does very little to mitigate the damage they cause, though. The biggest cost isn't the time they take, it's the act of forcing your entire engineering team out of a flow state (or worse, forcing them to wait until after standup to even start) on a daily basis. That happens regardless of if they're 10 minutes or 30 minutes.
I love the fact that none of this exists in open source projects. All communication is done immediately using IRC, mailing lists, and bugs/tickets. Nobody has to follow a development methodology. You volunteer to contribute to the things planned in the roadmap. You get shit done when you get around to it. When it's ready, it's ready.
I hate the fact that if you're not following a bullshit development methodology (and usually poorly) you're treated like there's something wrong with you.
I hate the fact that if you're not following a bullshit development methodology (and usually poorly) you're treated like there's something wrong with you.
It's hard for me to dislike this, because I also find standups and sprint planning meetings to be painful and somewhat less than useful for myself.
On the other hand, when you are with a new team, or a team with a few people that need mentoring, or going in a new direction, I find that it's important to force people to coordinate, because many times people will just run off in random directions you don't want them to. You really have to have the best people, and trust their instincts if you follow what the article suggests. Any weak players on your team will just be lost and potentially set you back (or at best, just waste their time).
On the other hand, when you are with a new team, or a team with a few people that need mentoring, or going in a new direction, I find that it's important to force people to coordinate, because many times people will just run off in random directions you don't want them to. You really have to have the best people, and trust their instincts if you follow what the article suggests. Any weak players on your team will just be lost and potentially set you back (or at best, just waste their time).
Exactly. This could work well in teams where the engineers are all competent and really just need the PM to stay out of their way.
In weak teams, this could easily see an end-of-quarter with unmet deliverables and other management messes. A lot of people would take advantage of the hands-off approach as much as they could.
Either way, Agile is ridiculous so I agree with the author about that.
In weak teams, this could easily see an end-of-quarter with unmet deliverables and other management messes. A lot of people would take advantage of the hands-off approach as much as they could.
Either way, Agile is ridiculous so I agree with the author about that.
> In weak teams,
Agile is largely about managing weaker teams.
Agile is largely about managing weaker teams.
We actually massively profited from implementing standups and agile-ish process and we really do not feel the downsides mentioned in the article.
Standups:
1. The standups are held in very small groups that work on the same thing and where it is important that they are coordinated.
2. Standups are not a place to discuss priorities. Those were set way before. It's for you to tell everybody what you're working.
3. Standups take 5-6 minutes per day. It's less than one foosball game. Some teams actually do their standups while doing a plank, so that they're very short.
4. Standups help us achieve team cohesion. Everybody knows what everybody is doing, so people can help each other when needed + leads can detect issues sooner (especially valid for introverts, since they sometimes lock up and grind away without telling anybody).
5. If you're bored during standup and not getting any value then you should not be part of the standup. Standups are considered optional, but everybody attends.
Agile process:
1. 14-day scrums are to sync priorities and discuss the development process. Generally speaking, we set up quarterly goals (and we have a rolling forecast for the next two quarters) so its clear what people need to do. We do not change the quarterly goal, except if external forces force us (example: things failing).
2. The schedule also gives the leads a clear tool to block any "non-urgent" but important tasks that would meddle in the development process. Instead of caving under the pressure of product teams or high-level management they can clearly state when they will start working on the task. I think the schedule needs to be set so that management can handle the lag between request and start of work on the request. I've heard of 3-day sprints since that was the most effective way of blocking daily priorities changing until management got on board.
Standups:
1. The standups are held in very small groups that work on the same thing and where it is important that they are coordinated.
2. Standups are not a place to discuss priorities. Those were set way before. It's for you to tell everybody what you're working.
3. Standups take 5-6 minutes per day. It's less than one foosball game. Some teams actually do their standups while doing a plank, so that they're very short.
4. Standups help us achieve team cohesion. Everybody knows what everybody is doing, so people can help each other when needed + leads can detect issues sooner (especially valid for introverts, since they sometimes lock up and grind away without telling anybody).
5. If you're bored during standup and not getting any value then you should not be part of the standup. Standups are considered optional, but everybody attends.
Agile process:
1. 14-day scrums are to sync priorities and discuss the development process. Generally speaking, we set up quarterly goals (and we have a rolling forecast for the next two quarters) so its clear what people need to do. We do not change the quarterly goal, except if external forces force us (example: things failing).
2. The schedule also gives the leads a clear tool to block any "non-urgent" but important tasks that would meddle in the development process. Instead of caving under the pressure of product teams or high-level management they can clearly state when they will start working on the task. I think the schedule needs to be set so that management can handle the lag between request and start of work on the request. I've heard of 3-day sprints since that was the most effective way of blocking daily priorities changing until management got on board.
We do stand ups once a week on Monday morning to get everyone on the same page and focussed for new week.
Each time a different dev runs it, chosen by the person who ran it last.
Our stand ups are one of the most mentioned things in my 1:1s as everyone likes to hear what other people are working on.
We then do a retro on Friday afternoon, sit outside and have a beer and chat about what worked and what didn’t.
Not strictly agile, but this works for us and everyone is happy and productive.
Each time a different dev runs it, chosen by the person who ran it last.
Our stand ups are one of the most mentioned things in my 1:1s as everyone likes to hear what other people are working on.
We then do a retro on Friday afternoon, sit outside and have a beer and chat about what worked and what didn’t.
Not strictly agile, but this works for us and everyone is happy and productive.
> Not strictly agile
Sure it is, because agile is precisely supposed to be "whatever works for your team". Awesome that you've been able to find such a good, low-key process!
Sure it is, because agile is precisely supposed to be "whatever works for your team". Awesome that you've been able to find such a good, low-key process!
Not going to lie...I like stand-ups, but I am an extrovert. I also like them as a full time remote because it's the only way I regularly see my team.
As long as it doesn't interrupt people. 10am is to late if the work day starts at 8:30am. About 45 minutes after the "beginning" of the day is about as long as can be tolerated. Give people time to arrive, account for traffic, get coffee, check some email, quick stand-up with the team and then get to it.
At the same time, there's not a point where I think stand-ups encourage prioritizing features over tech debt. Usually, that comes from sprints themselves and the planning around sprints. Stand-up shouldn't be anything more than a quick "how's it going" for the team.
I would have no argument as a developer working under this unless the quarterly goals were out of control.
What you're describing is basically Kanban.
I agree with almost every word.
As long as it doesn't interrupt people. 10am is to late if the work day starts at 8:30am. About 45 minutes after the "beginning" of the day is about as long as can be tolerated. Give people time to arrive, account for traffic, get coffee, check some email, quick stand-up with the team and then get to it.
At the same time, there's not a point where I think stand-ups encourage prioritizing features over tech debt. Usually, that comes from sprints themselves and the planning around sprints. Stand-up shouldn't be anything more than a quick "how's it going" for the team.
I would have no argument as a developer working under this unless the quarterly goals were out of control.
What you're describing is basically Kanban.
I agree with almost every word.
I've worked at 5 different companies that did standups. They always sucked. Agree with what others said here: If you need to talk to someone, just do it, don't wait for the next day.
The team that didn't do standups was by far my best team. We still talked frequently as needed and moved quickly. Actually quicker because we didn't get interrupted by standups, hour long retros and planning meetings.
The team that didn't do standups was by far my best team. We still talked frequently as needed and moved quickly. Actually quicker because we didn't get interrupted by standups, hour long retros and planning meetings.
I've been beating this drum as it's one of the more frequently cargoculted items about agile.
A standup has 3 questions to report on:
1. What did you make progress on yesterday?
2. What are you planning on making progress on today?
3. Do you have any blockers?
Taking this pulse once every 24 hours is artificially constraining. Relevant stakeholders (product people, other engineers, project managers, etc.) should have perfect, frictionless visibility in to what people recently worked on, and what they are planning to work on at any given time, as self-reported by the team. Additionally, if you have a blocker, you should not wait until the next standup. Unless the blocker was discovered immediately preceding the standup, it should be well known to all who need to know with the same perfect, frictionless visibility. At the time of the standup, blockers should be well-known. I've specifically seen standups backfire as individuals use reserve their blockers until the next morning. It's a great reason to call it an early day when you hit a blocker and get the opportunity to report something of substance at the next day's standup.
Perhaps I just described an unattainable utopia, but I think it's important to start with process idealism and make considered compromises rather than acculturating the status quo.
I lead an entirely remote-first development team, and am adamant that standups often are a crutch at best, and inhibit progress at worst.
A standup has 3 questions to report on:
1. What did you make progress on yesterday?
2. What are you planning on making progress on today?
3. Do you have any blockers?
Taking this pulse once every 24 hours is artificially constraining. Relevant stakeholders (product people, other engineers, project managers, etc.) should have perfect, frictionless visibility in to what people recently worked on, and what they are planning to work on at any given time, as self-reported by the team. Additionally, if you have a blocker, you should not wait until the next standup. Unless the blocker was discovered immediately preceding the standup, it should be well known to all who need to know with the same perfect, frictionless visibility. At the time of the standup, blockers should be well-known. I've specifically seen standups backfire as individuals use reserve their blockers until the next morning. It's a great reason to call it an early day when you hit a blocker and get the opportunity to report something of substance at the next day's standup.
Perhaps I just described an unattainable utopia, but I think it's important to start with process idealism and make considered compromises rather than acculturating the status quo.
I lead an entirely remote-first development team, and am adamant that standups often are a crutch at best, and inhibit progress at worst.
> I've been beating this drum as it's one of the more frequently cargoculted items about agile.
When most aspects of something have strong cargo cult features, then maybe the whole thing is a fantasy.
When most aspects of something have strong cargo cult features, then maybe the whole thing is a fantasy.
I really dislike these type of articles. The title is there just to shock you, and so is the content... so much that there's a disclaimer at the end of it. I think I would read it with an open mind if the title was phrased differently... "Maybe you don't need standup" or "how standup slows down our company" something of that sort.
"The natural side effects of not doing standup are:"
"- Developers communicate more - Your team becomes more remote-friendly - Tech debt gets addressed - Developers feel more in control and less stressed - Developers know you trust them and that you have their back"
These bullet points are non-sense. Perhaps developers were not communicating properly, and that's why you started having stand-ups in the first place. Perhaps your developers need more guidance and someone overseeing them. Maybe your business is growing too fast and you need to have more meetings to get things back under control. Some people are goal driven and can take care of things on their schedule other people don't even know how to make a proper schedule.
Here's what you should do:
1. See what works for you 2. Make adjustments 3. Evaluate adjustments 4. Repeat
Meanwhile, read some books on management and learn from more experienced people. There's no reason to drop everything you are doing because a blog post said so.
"The natural side effects of not doing standup are:"
"- Developers communicate more - Your team becomes more remote-friendly - Tech debt gets addressed - Developers feel more in control and less stressed - Developers know you trust them and that you have their back"
These bullet points are non-sense. Perhaps developers were not communicating properly, and that's why you started having stand-ups in the first place. Perhaps your developers need more guidance and someone overseeing them. Maybe your business is growing too fast and you need to have more meetings to get things back under control. Some people are goal driven and can take care of things on their schedule other people don't even know how to make a proper schedule.
Here's what you should do:
1. See what works for you 2. Make adjustments 3. Evaluate adjustments 4. Repeat
Meanwhile, read some books on management and learn from more experienced people. There's no reason to drop everything you are doing because a blog post said so.
Our team of developers is 100% remote and we do a daily standup each morning that lasts anywhere from 15-30 minutes. Each person runs through anything of note from yesterday, our priorities for the coming day, any roadblocks, and anything we feel like discussing with the team.
Coming from a team that did nothing remotely close to a standup, I highly value our current system. It's not perfect, and I have no idea if it fits the Valley's definition of "standup", but it serves its purpose very well and keeps everyone on the same page. I can't tell you how many times a person from my team has reached out in the afternoon about a roadblock I mentioned during standup. Or how many times a team member wanted to help me out on a tough user story simply because I was open about discussing its difficulty.
This is just my opinion.
Coming from a team that did nothing remotely close to a standup, I highly value our current system. It's not perfect, and I have no idea if it fits the Valley's definition of "standup", but it serves its purpose very well and keeps everyone on the same page. I can't tell you how many times a person from my team has reached out in the afternoon about a roadblock I mentioned during standup. Or how many times a team member wanted to help me out on a tough user story simply because I was open about discussing its difficulty.
This is just my opinion.
As someone who hates standups I tend to disagree. I've found that without some kind of forced daily interaction, lines of communication in a team break down very quickly if they aren't already extremely tight knit. Once that happens, your project is toast.
That's funny because we recently started doing standups and our communication has fallen off a cliff. I feel like we had that tight knit group you describe, knowing when to get in touch and when to leave things alone.
Now we don't speak to each other except during standups, and even then it feels more like speaking at each other as it is expected that each member put in their voice, even when they have nothing to useful to add, leading to the team quickly tuning out and then not paying attention when something important is mentioned. Not to mention that now there is up to a 24 hour window before anything is addressed, when the previously used ad-hoc meetings would have got everyone on the right track in a much shorter timeframe. And as a result of all that I feel like there is a lot more animosity between members.
It may be possible to do standups well, but we've failed at it horrifically.
Now we don't speak to each other except during standups, and even then it feels more like speaking at each other as it is expected that each member put in their voice, even when they have nothing to useful to add, leading to the team quickly tuning out and then not paying attention when something important is mentioned. Not to mention that now there is up to a 24 hour window before anything is addressed, when the previously used ad-hoc meetings would have got everyone on the right track in a much shorter timeframe. And as a result of all that I feel like there is a lot more animosity between members.
It may be possible to do standups well, but we've failed at it horrifically.
This approach works really well when you have a great team - like I'd imagine palmerj3 has at Spotify. I've worked in a few of these places and know how well this approach can work. However, I am currently working at a place with people who are very inexperienced and frankly pretty lazy and just generally not very motivated. The manager has to constantly monitor them and make sure everything is being done. In this type of environment you just wouldnt see the end result at the end of the month. But personally I find this approach works super well for me.
People should try to think more long term about standups.
Yes, maybe you could remove them and maintain the same productivity for a year, so they appear wasteful.
But removing accountability, can lead you occasional bad decisions, which lead to more frequent bad decisions and then 5 years later you have some REALLY bad habits in place. Standups feel like babysitting, and they are not necessary if everyone is just ready to work, but I think the accountability from publicly stating goals for the day has a subconscious effect that can lead to people getting into a great routine.
I myself, never needed standups to prevent goofing off. But they really helped me get a handle on how bad I was at predicting the results of my work for a day. My optimize makes me perpetually underestimate the time it will take to do a task by a factor of 3-4. With practice in standups I've got that down to more like 2x.
Yes, maybe you could remove them and maintain the same productivity for a year, so they appear wasteful.
But removing accountability, can lead you occasional bad decisions, which lead to more frequent bad decisions and then 5 years later you have some REALLY bad habits in place. Standups feel like babysitting, and they are not necessary if everyone is just ready to work, but I think the accountability from publicly stating goals for the day has a subconscious effect that can lead to people getting into a great routine.
I myself, never needed standups to prevent goofing off. But they really helped me get a handle on how bad I was at predicting the results of my work for a day. My optimize makes me perpetually underestimate the time it will take to do a task by a factor of 3-4. With practice in standups I've got that down to more like 2x.
I'd really like to hear thoughts on how this applies to remote teams. I find that async standups via slack are pretty damn helpful for keeping everyone appraised of what is going on across 5 timezones.
Process and communication are kind of key, aren't they?
Process and communication are kind of key, aren't they?
Async standups do well only if the engineers have the discipline to actually go through them. My past experiences have shown a couple devs paid attention to the standups to look for issues and everyone else just typed their own up without looking at what other people wrote.
This is what everyone does in person too. The people that go last tune out because they're preoccupied about what they'll say and the people that go first stop listening because the value of the information tends to be very low.
Async standups are great even for on-site teams. First, people only spend half a minute to post it; manager needs half a minute to read it to know whats going on. After it is posted, everyone have something to refer to before the weekly meeting, which does not have to be long if it is well prepared. The set up keeps the communications efficient and consistent.
As for the original post, the outstanding team does not need the manager, so far. It will need one, after the writer deteriorate the culture and communication channels that have been established before him with own "trust" and f-words.
As for the original post, the outstanding team does not need the manager, so far. It will need one, after the writer deteriorate the culture and communication channels that have been established before him with own "trust" and f-words.
There is a good argument to be made that supporting remote work yeilds gains in processes. See e.g. remoteonly.org
I don't think slack standups are a useful way to communicate this. I'd rather have it in the form of trello or pivotal tracker, for example, because those have audit logs and commentary. By all means, have people update those things at the beginning or ending of the day on a routine basis, but doing it in chat is just too ephemeral for me.
I think it's often useful to ping people if you know you're going to need their help, for example, but that's not precisely a standup. It's just scheduling and communication.
I think it's often useful to ping people if you know you're going to need their help, for example, but that's not precisely a standup. It's just scheduling and communication.
I've pushed for this model and I've done this with my team over the past year. It's worked out relatively well, but not as well as I expected. Context: I am the lead developer on the team, I am not a people manager.
Our work involves some research which we've managed to do quite well following this model. We've also evolved our product and managed to deliver complex features more efficiently than we would have done if we did sprints, IMO.
A few team members have complained about lack of frequent deadlines (?!?), lack of status meetings/standups etc. The arguments are weak IMO - 'that's how we did it before', 'we hear what other people are doing' (we are pretty good on transparency), 'it's nice to have a forum to discuss how things are going' (we use chat extensively and we should be able to discuss things there). Our manager is great and he helps people choose which things to work on - he's been handling feature prioritization and he's making sure that people are comfortable with their work during 1:1s.
Also, I think it's really important to have a clear vision and steer the product - we've been missing that and it's caused a lot of friction when deciding how to evolve the product. Sprints wouldn't have fixed that, but maybe a more rigid decision making process would have made us fix the problem (or at least complain more) earlier.
Our work involves some research which we've managed to do quite well following this model. We've also evolved our product and managed to deliver complex features more efficiently than we would have done if we did sprints, IMO.
A few team members have complained about lack of frequent deadlines (?!?), lack of status meetings/standups etc. The arguments are weak IMO - 'that's how we did it before', 'we hear what other people are doing' (we are pretty good on transparency), 'it's nice to have a forum to discuss how things are going' (we use chat extensively and we should be able to discuss things there). Our manager is great and he helps people choose which things to work on - he's been handling feature prioritization and he's making sure that people are comfortable with their work during 1:1s.
Also, I think it's really important to have a clear vision and steer the product - we've been missing that and it's caused a lot of friction when deciding how to evolve the product. Sprints wouldn't have fixed that, but maybe a more rigid decision making process would have made us fix the problem (or at least complain more) earlier.
I work on a team where 3/4 of the team are business people. Yet we have a stand up with the entire team everyday and everyone talks about what they are working on. How is hearing that you are talking to account X about something or just came back from conference Y applicable to the job I've been hired to do? Likewise when it comes to my turn to talk it often turns into "blah blah blah [giggle] I don't know what any of that means! computers!" from the business people. It's so useless.
I think you want a culture were people let others know as soon as they are blocked. And were a manager discusses your progress 1 on 1, not in a group setting. Standups are inefficient because most updates of others don't matter and it is needlessly synchronous.
While I do agree with the sentiment of reducing meetings and time spent planning, I don't believe that removing all scheduled communication and planning is a good answer. This approach is especially problematic for teams that are working more directly on rapidly changing business concerns. Communication, planning and analysis are quite important for teams with members who need regular guidance or teams with lots of distinct roles.
I understand many writers are desperate for views, but I'm looking forward to this nasty spreading imperative title infection to die out (which it will, but not soon enough). "What you need to know about ..." (you have no idea what my knowledge requirements are) "You don't need ..." (you won't know what I need until you find out something about me, dolt). "Why you should ..." (until you've at a minimum skimmed 'Ethics for Dummies', which your 1st-year-uni-essay-think-piece betrays no evidence of, you're not qualified to inform me what I 'should' do).
This rash is particularly prevalent in the prissy modern etiquette columns that dominate so many alleged newspapers (I'm looking at you, Graun), but the tech sector is also succumbing apace.
Now Kant: there was a guy who knew how to construct titles. He did not write "What you need to know about the categorical imperative", nor "Why you must critique pure reason".
This rash is particularly prevalent in the prissy modern etiquette columns that dominate so many alleged newspapers (I'm looking at you, Graun), but the tech sector is also succumbing apace.
Now Kant: there was a guy who knew how to construct titles. He did not write "What you need to know about the categorical imperative", nor "Why you must critique pure reason".
Yes, but Kant was not incentivized to write in a certain way by some performance graph in Google Analytics.
Indeed. Our intellectual history definitely dodged a bullet there.
One of my manager used to say that number of status meetings you must to do is inversely proportional to quality of people you have.
The whole concept of standups and scrum was started to bring highly dysfunctional team back on track. Since then now we have been applying methodology that is required to make highly dysfunctional teams work to all teams.
The whole concept of standups and scrum was started to bring highly dysfunctional team back on track. Since then now we have been applying methodology that is required to make highly dysfunctional teams work to all teams.
Agile is the management equivalent to electron apps, not very efficient but makes your job easier.
I think a lot of the themes in this article I can agree with, but I come away with the overall impression that the author hasn't necessarily worked in a healthy agile environment before. Basically, I agree with many of the conclusions (or solutions) but disagree with a lot of how the author came to them.
Standups aren't inherently bad. Also it sounds like he moved his team to more of a kanban style workflow -- which many people use already. That isn't ground breaking. There is still iterative planning, even if they aren't "sprint planning" sessions.
Standups aren't inherently bad. Also it sounds like he moved his team to more of a kanban style workflow -- which many people use already. That isn't ground breaking. There is still iterative planning, even if they aren't "sprint planning" sessions.
I got the impression that the author of the post had worked in effective agile environments and he came to the conclusion that the cargo-culted trapping of agile were unnecessary.
I was a little bit surprised to see this article with him at Spotify. Their Squads framework is shown as an example for larger-scale agile, I heard about it at a place that had just started doing SAFe. The approach mentioned in the article doesn't really match up with my idea of larger-scale more corporate agile.
FTA: Say you’re in a relationship and it’s going amazing. You should totally start going to couples therapy once a week, right? </sarcasm>
Me: Actually yes - that way it stays amazing...
Me: Actually yes - that way it stays amazing...
I thought the same thing. Not couples therapy, per se - that bit is a blatant straw effigy - but we do have a regularly scheduled chat that is, in effect, a standup meeting.
We've found that it ultimately reduces the amount of time we spend on talking about that stuff. Sit down, take care of business, see what's on Netflix. Without it, we could easily spend the same amount of time per week just figuring out when to talk about XXX thing, let alone actually talking about it.
We've found that it ultimately reduces the amount of time we spend on talking about that stuff. Sit down, take care of business, see what's on Netflix. Without it, we could easily spend the same amount of time per week just figuring out when to talk about XXX thing, let alone actually talking about it.
Probably too late to this thread, but anyway - the key to understanding agile tomfoolery is that processes are most effective if they evolve to meet the needs of the people in the team.
A process will always feel like a burden (and be less effective for it) unless it is co-created by the people right in the middle of it. Most people like doing a good job if they're permitted to, and like supporting their colleagues if it doesn't prevent them doing a good job. Few people want to make their colleagues' job harder or get in fights - much of this is friction caused by bad processes.
Given a chance to talk over problems faced by each team-member and to discover fair solutions, a team that dislikes agile may themselves choose to adopt parts of agile if it is obvious that it solves real problems and makes the team more effective.
The difference between a pointless, painful, morale-destroying standup and a fun, useful, team-building standup is that one is imposed from outside and the other naturally arises from a team allowed to figure out for themselves how best to work together.
A process will always feel like a burden (and be less effective for it) unless it is co-created by the people right in the middle of it. Most people like doing a good job if they're permitted to, and like supporting their colleagues if it doesn't prevent them doing a good job. Few people want to make their colleagues' job harder or get in fights - much of this is friction caused by bad processes.
Given a chance to talk over problems faced by each team-member and to discover fair solutions, a team that dislikes agile may themselves choose to adopt parts of agile if it is obvious that it solves real problems and makes the team more effective.
The difference between a pointless, painful, morale-destroying standup and a fun, useful, team-building standup is that one is imposed from outside and the other naturally arises from a team allowed to figure out for themselves how best to work together.
I think a lot of this depends on the size of the organization and teams involved. Too often I find these kinds of articles (from both sides of the argument) ignore that aspect.
Some aspects of Agile/XP/Scrum etc. obviously have some benefits particularly for larger organizations/teams. On the other hand I've seen smaller companies that are trying to emulate this success really struggle to get real work done, because there are so many standups, retros, kanban and "user stories" etc. In between morning tea and lunchtime, not much breakfix or clearing out tech debt actually gets done, before they are required to pour another bucket of features on top.
I've worked at a company like this that held retros on Friday afternoons and by Monday morning standups, they couldn't remember the things that had been discussed in Friday's retro. It all felt so mindlessly pointless, and playing into the hands of those who make good money selling books about Agile, or talking at conferences about Agile.
IMHO I think the sweet spot is probably somewhere in between.
Some aspects of Agile/XP/Scrum etc. obviously have some benefits particularly for larger organizations/teams. On the other hand I've seen smaller companies that are trying to emulate this success really struggle to get real work done, because there are so many standups, retros, kanban and "user stories" etc. In between morning tea and lunchtime, not much breakfix or clearing out tech debt actually gets done, before they are required to pour another bucket of features on top.
I've worked at a company like this that held retros on Friday afternoons and by Monday morning standups, they couldn't remember the things that had been discussed in Friday's retro. It all felt so mindlessly pointless, and playing into the hands of those who make good money selling books about Agile, or talking at conferences about Agile.
IMHO I think the sweet spot is probably somewhere in between.
I find myself slowing down or doing tasks that I can easily explain because of standups. Instead of pushing ahead and killing it I find I need to translate what I am doing into english conversation speak so I manage my work around this. Normally I would work on multiple items but standups force me to work on something easily explainable/simple so I do less but explain it well.
This should really be taken as an example of a team that got rid of standups and did well. Every team is different and without prior knowledge of the team featured in this article, it's hard to judge if this advice is any useful to me. I would've preferred if the tone was more like "Why we didn't need standups" not "You don't need standups".
Good article. If you have a good team, you don't need agile or other methodologies. These frameworks have always been the crutch of bad managers, or MBA types who want to corral "those developer people." Now, can agile/scrum/ninjitsu/rockstarism transform a bad team into a competent one? I don't know - I don't work with bad teams.
I really like this advice. One thing I've been taking notice of at my job is just how meaningful the tracker is to our workflow. If things are settled down and well-managed, then no meetings are needed, the tracker is a really good representation of the current state of the project, and Shit Gets Done. For awhile when I first joined the team we pounded through sprints and often had a week or more of downtime that we could use to clean up tech debt or play ping pong.
It was Amazing. So amazing I ended up having to speak up at meetings telling our nervous team leadership that nothing was going wrong. We were kicking ass and playing more ping pong than everybody else in the company.
Now we're still kicking ass, but the management has gone into the shitter. We had a product owner, a team lead, and project manager, then the product owner got pushed out and it's been veritable chaos ever since. If anybody is looking for a Rails ninja, drop me a line.
It was Amazing. So amazing I ended up having to speak up at meetings telling our nervous team leadership that nothing was going wrong. We were kicking ass and playing more ping pong than everybody else in the company.
Now we're still kicking ass, but the management has gone into the shitter. We had a product owner, a team lead, and project manager, then the product owner got pushed out and it's been veritable chaos ever since. If anybody is looking for a Rails ninja, drop me a line.
I think standups can be good, but get rid of the mandatory status updates.
Want to talk about something? Knowing you can put it on the agenda for the next standup is great. If the standup isn't the right forum for the topic, then it's still probably the right forum to decide what the right forum is, and let's you include people who are unexpectedly interested.
Talking about incoming tasks and bugs is also helpful, and is an important part of developing a collective understanding of priority and approach.
And of course when there's some specific pressure or deadline, then you'll need to talk status and cover details. The standup is going to change based on needs. It's good to have a well-socialized team that regularly talks and both makes collective decisions and learns how to interpret those decisions when doing their personal work. Daily practice is worth it, and pays off double when something goes wrong.
Want to talk about something? Knowing you can put it on the agenda for the next standup is great. If the standup isn't the right forum for the topic, then it's still probably the right forum to decide what the right forum is, and let's you include people who are unexpectedly interested.
Talking about incoming tasks and bugs is also helpful, and is an important part of developing a collective understanding of priority and approach.
And of course when there's some specific pressure or deadline, then you'll need to talk status and cover details. The standup is going to change based on needs. It's good to have a well-socialized team that regularly talks and both makes collective decisions and learns how to interpret those decisions when doing their personal work. Daily practice is worth it, and pays off double when something goes wrong.
> I wanted the team to know I trusted them.
This can be very powerful. People will often rise (or sink) to the level corresponding to how much you show you believe in them.
Imagine you hand someone the reigns and say, "Here, take over this for me. I know you're going to do a good job." And you sincerely mean it because you've bothered to understand them well enough to know that they can. In a lot of cases, you'll be amazed at what they will accomplish. They may even be amazed too.
Often, forming good, healthy relationships and building people up is what's really effective at getting people to get stuff done. So many of the other things people do (endless status reports, procedures and methodologies du jour, applying pressure or creating fear, etc.) are really just bandaids to attempt to force productivity to happen when it's really not happening because the basics haven't been covered.
This can be very powerful. People will often rise (or sink) to the level corresponding to how much you show you believe in them.
Imagine you hand someone the reigns and say, "Here, take over this for me. I know you're going to do a good job." And you sincerely mean it because you've bothered to understand them well enough to know that they can. In a lot of cases, you'll be amazed at what they will accomplish. They may even be amazed too.
Often, forming good, healthy relationships and building people up is what's really effective at getting people to get stuff done. So many of the other things people do (endless status reports, procedures and methodologies du jour, applying pressure or creating fear, etc.) are really just bandaids to attempt to force productivity to happen when it's really not happening because the basics haven't been covered.
One thing that the standup helped me was getting blocked by a senior developer.He would never answer my questions normally. But once we started with scrum and daily standups, there was that I am blocked because of something that can be answered by another developer within 15 minutes. Standups make a team working.
To me, standups are most useful for 3 things:
1) When working on a new system, making sure that your work aligns with what others are doing, and you have group consensus that your approach is acceptable (or if not, then getting someone to talk through it with after standing).
2) When working on a legacy system, getting group consensus on the hacky stuff you're doing to solve a problem (and in the process letting others know about that hacky stuff).
3) The group's lighthearted banter while we wait for others to join the meeting, and sometimes at the end, or on a particularly fun day, in the middle.
All of that is about group teamwork, consensus, and a little bit of bonding. All the details should already be on the board, and in slack discussions or calls with the relevant people. The meeting should focus on stuff that needs the group interactions.
1) When working on a new system, making sure that your work aligns with what others are doing, and you have group consensus that your approach is acceptable (or if not, then getting someone to talk through it with after standing).
2) When working on a legacy system, getting group consensus on the hacky stuff you're doing to solve a problem (and in the process letting others know about that hacky stuff).
3) The group's lighthearted banter while we wait for others to join the meeting, and sometimes at the end, or on a particularly fun day, in the middle.
All of that is about group teamwork, consensus, and a little bit of bonding. All the details should already be on the board, and in slack discussions or calls with the relevant people. The meeting should focus on stuff that needs the group interactions.
my 2 cents,
I don't think this post will age well.
The team I am on is currently swinging back towards more traditional agile after going too lax on planning, retro, estimation, etc for a while. These "rituals" are effective ways to ensure a good base level of inefficiency. If you're feeling like the agile rituals are becoming a waste of time, I would try out doing longer sprints before dropping them entirely.
Cutting process relies on good habits from the developers/whoever on the team, and habits can degrade over time. Devs can cut corners without formal process, because creating meetings and facilitating process that doesn't formally exist can feel like just another burden/task switch they have to take on.
I don't think this post will age well.
The team I am on is currently swinging back towards more traditional agile after going too lax on planning, retro, estimation, etc for a while. These "rituals" are effective ways to ensure a good base level of inefficiency. If you're feeling like the agile rituals are becoming a waste of time, I would try out doing longer sprints before dropping them entirely.
Cutting process relies on good habits from the developers/whoever on the team, and habits can degrade over time. Devs can cut corners without formal process, because creating meetings and facilitating process that doesn't formally exist can feel like just another burden/task switch they have to take on.
Let's say you have 2 developers:
- developer A wants to get promoted as quickly as possible. developer A will try to "ship" as many features as possible.
- developer B wants features to actually work, not just be "shipped". developer B volunteers to fix the problems developer A created by rushing to close as many tickets as possible.
Now, guess which developer contributes more to the team "velocity"? developer A. But in reality, developer A is just gaming the system and making everyone else slower. This is how agile distorts development.
Using velocity as KPI is the same as evaluating leaflet distributors by amount of leaflets distributed. Some will just throw them away in the garbage and claim their money.
- developer A wants to get promoted as quickly as possible. developer A will try to "ship" as many features as possible.
- developer B wants features to actually work, not just be "shipped". developer B volunteers to fix the problems developer A created by rushing to close as many tickets as possible.
Now, guess which developer contributes more to the team "velocity"? developer A. But in reality, developer A is just gaming the system and making everyone else slower. This is how agile distorts development.
Using velocity as KPI is the same as evaluating leaflet distributors by amount of leaflets distributed. Some will just throw them away in the garbage and claim their money.
Or do developer A and developer B make a good team? Looks like you've got a starter and a closer there to me.
Sometimes that is indeed the case.
In other cases you need a full rewrite, and that is not good.
In other cases you need a full rewrite, and that is not good.
Why the need for all this formalization of process. We're all adults. As long as we hire people who can communicate well, shouldn't just having conversations here and there when the need feels natural be enough?
I'm so in alignment with this. I've always hated standups. As a night owl, it's a morning meeting I have to make every single day and I hate it. I also don't understand how I can't just communicate in Slack to say "hey this is what I'm working on, this is what I worked on. Here are the questions I have." And move on. And if the PM prioritizes the backlog, always pick from the top just makes sense. And yes, retros feel like a place for extroverts to own the conversation (and I know, I'm an extrovert).
We have some teams that do "slack-ins" but I find few people read the updates and even fewer questions are answered or asked.
At best, this gives micromanagers satisfaction while not doing much, and at worst it's a log of "well I told you so"
At best, this gives micromanagers satisfaction while not doing much, and at worst it's a log of "well I told you so"
The fact that everybody tunes out these updates suggests that the things being communicated are of low value.
> Stand-ups ENCOURAGE plans to change daily. Lack of consistency is a great way to ruin developer flow.
Do they ever. Every day I have no idea what I'll actually be working on. It's almost never what I say I'll be working on because shit comes up in a stand-up. I'm not a manager so it doesn't bother me much, but it does slow progress on larger tasks considerably at times. Sometimes I just avoid saying what I think I'll be working on to save time as it's irrelevant and the meeting is already twenty to thirty minutes anyway.
Do they ever. Every day I have no idea what I'll actually be working on. It's almost never what I say I'll be working on because shit comes up in a stand-up. I'm not a manager so it doesn't bother me much, but it does slow progress on larger tasks considerably at times. Sometimes I just avoid saying what I think I'll be working on to save time as it's irrelevant and the meeting is already twenty to thirty minutes anyway.
I have done a lot of standups. From my perspective, no one really cares for them. Most of the time, your coworkers are working on something that either doesn't matter to your task or you have no clue what they are doing even when they explain it. So standups are ultimately for the manager to get a sense of where everything is. But good managers should already have a grasp of the situation so standups become redundant.
All of this is even worse with a distributed team. Don't get me started on what happens when contractors enter the picture.
Edit: and so-called development managers!
Edit: and so-called development managers!
I've had some truly great development managers, and some really mediocre ones. It's helpful to have a technical manager that can shield you from certain issues while still understanding your needs enough to actually meet them.
You said it man. But when development managers enter the picture, and when they're also your people managers, and they come into the scrum and start enforcing top-down patterns it's about as toxic as you can get.
It seems that much of the discussion here can be distilled into not trusting people. Lack of trust that people will work, can do the work, will tell someone when they have a problem or surprise, and mistrust of the effectiveness of the particular Task Management System in use.
Daily standups as largely practiced today, are a means to overcome this lack of trust through micromanagement.
Daily standups as largely practiced today, are a means to overcome this lack of trust through micromanagement.
This makes me suspicious of Spotify. This is bad advice that could maybe apply temporarily to teams where you're not working on mission critical business work (what is left to engineer at Spotify?)
I also don't like that he prefixed bad advice with "PERSONAL beliefs" as a cop-out for responsibility. This is a tactic used by people skirting ownership of ideas.
I also don't like that he prefixed bad advice with "PERSONAL beliefs" as a cop-out for responsibility. This is a tactic used by people skirting ownership of ideas.
This article flies in the face of everything. I love articles that fly in the face of everything.
Standups is just another example of something that someone had to makeup for the Agile methodology in order to be able to say that "people are communicating"...kumbaya.
It was probably invented by the same guy that invented the demented concept of open office.
It was probably invented by the same guy that invented the demented concept of open office.
I'd guess this is probably only possible at a cash flush company where the devs personally use the product and fully understand the cost/benefit trade offs. Also, those sorts of meetings aren't for the sole benefit of the engineers.
This is easy to explain. Main premise of agile is spending a lot of effort on improving the process. These are the standups, demos, retrospectives, etc.
It is no wonder you get more done if you cut the effort. You are coasting on past improvements. This is only going to work for a while until your performance starts to slip because the team stopped correcting and improving.
Spending time on improvements is important for other reasons. If your team spends 100% of the time on project work it is inefficient by definition (though not very intuitively, but see constraint theory). Spending time on improvements creates necessary flexible buffer. This is an alternative task when there is shortage of project work or it can be temporarily cut if there is too much project work.
It is no wonder you get more done if you cut the effort. You are coasting on past improvements. This is only going to work for a while until your performance starts to slip because the team stopped correcting and improving.
Spending time on improvements is important for other reasons. If your team spends 100% of the time on project work it is inefficient by definition (though not very intuitively, but see constraint theory). Spending time on improvements creates necessary flexible buffer. This is an alternative task when there is shortage of project work or it can be temporarily cut if there is too much project work.
I am collecting links to SCRUM-related criticism at https://againstscrum.tumblr.com/ Please contribute!
I'm having a hard time agreeing with a lot of the points being made (I mostly skimmed but also read some parts).
The conclusion is relatively sound though: the default agile approach (sprints, standups, planning, grooming, retro) is only a base to start working on a software development project. The team members should optimize it or even throw it out if it works for them.
- Daily standups are a tool for coordinating teams.
- Weekly planning is a tool for iteratively communicating about the progress being done, steering the team and discussing priorities
- Retrospectives are a tool as well; a quorum regarding what goes well and what should be improved.
In a well functioning team, you will always need coordination/communication, progress visibility, continuous improvements, etc.
I picked 2 red flags in how this junior product manager approaches their work:
- the team did not discuss estimations
- he told his boss the team will deliver after 3 months
Basically he just "winged it" for his first project, picked a waterfall approach, and made it. Congrats! That tells me he either has a kick ass team (thank them) or the deliverable was easily achievable (thank the boss), or more likely a bit of both.
Let's take a few of the points being made throughout the post:
> Trello (or whatever you use) has to be kept in sync with what’s discussed in these meetings. It often isn’t. As the team grows this becomes even more complicated.
This is spot on. Using a tool to keep in sync is only useful if the members keep it up to date. If the tool is not up to date, the team either has a tool problem or a people problem.
> Stand-ups ENCOURAGE plans to change daily. Lack of consistency is a great way to ruin developer flow.
I strongly disagree there. Nothing, in each team member speaking daily, for less than 2 minutes, about what they are working on, encourages change of plans.
When the author mentions standups routinely lasting 30+ minutes... well yeah either fix it the soft way (time limit + a judge making sure everybody stays on point) or the hard way (just stop doing standups & send updates through a different channel).
What I've seen is that there are usually 2 team members that come with the 'authority' to make for a great standup: the product owner (in this case our author) or the tech lead (well, seems it's the author again, as a technical. prod. owner?).
> Standup forces every team member to be productive at a set place and a set time
Yes it can be a problem. That could possibly be reason #1 to get rid of standups. We're lucky in our remote team that everybody is happy starting the day at 9am as standups mid or end of day make not much sense.
> Extroverts thrive at stand-ups, planning, and retros. It’s no wonder that tech debt is such a common problem. Developers shouldn’t have to PUSH for tech debt to be addressed. Teams should operate at a sustainable pace.
Again, it sounds like standups are being used for the wrong thing. The standup is at 90% a 'passive' communication tool. Listen to the others carefully. Wait for the standup to be finished and FREE PEOPLE FROM THE MEETING to catch up with whomever you want on whichever subject you want.
> Why do we encourage problems to be discussed once a week? We should address them immediately, not just at retros.
Absolutely, problems that can and should be addressed on the spot MUST be addressed on the spot or taken ownership of by a lead and then addressed timely.
However that approach does not catch everything. Retrospectives are an excellent way to make sure people can flag issues. It is natural that, in the week, someone will be too busy to immediately flag an issue, but make a note of what could be improved. A regular open quorum dedicated to these things helps share these details.
There are 2 critical elements to successful retrospectives:
- trust that everybody can speak up about the most minute detail. Be open about anything that is being said. Leave the ego out.
- trust that what is said is genuinely acted upon. Track improvement and suggestions and ADDRESS THEM. In software development, if you see a bug, you create a regression test and then fix the bug. Well, tske the same approach!
> Sprints encourage iterative development. This sounds really good to people like me who strongly advocate small, concise, pull requests over long-living feature branches. But it’s not the same thing. Sprints encourage features over tech debt. How often have you had to advocate spending an entire sprint tackling tech debt?
I'm eluded by the fact that sprints encourage features over tech debt. It seems that the source of the friction with sprints is not the sprint itself but how it is being used.
Addressing tech debt is part of any new feature. There should be no 'tech debt' in a sprint. DO NOT address tech debt that does not fix a bug(s) or help new a new feature though. It can be useful to write a list of hot spots, for communication and reminder purposes..
For each new feature, the team has many choices for the implementation: from complete hack to full refactor. A constant balance goes a long way, with the occasional 'that is needed in a week' and 'we need to refactor A to K before we do feature XYZ'. These are healthy events in a team that care a lot about delivering the most business value through solid software.
> That said, I’m not against planning, I’m against planning on an interval.
Fair point. Planning on an interval brings a few things on the table:
- it sets a cadence. Some people love stability. Regular planning can be an anchor to someone's organization of their work.
- it allows measuring velocity and therefore longer term planning through past velocity.
- it allows reprioritization sprint after sprint. Usually the product owner role is to gather clients' needs. These needs evolve both with new features and time. Rather than re-prioritizing on the spot (like it seems it was being done at the author's previous projects), it is a compromise between constantly shuffling around what developers do and being flexible about what is being built.
In my modest experience, all of these are very useful tools :)
The conclusion is relatively sound though: the default agile approach (sprints, standups, planning, grooming, retro) is only a base to start working on a software development project. The team members should optimize it or even throw it out if it works for them.
- Daily standups are a tool for coordinating teams.
- Weekly planning is a tool for iteratively communicating about the progress being done, steering the team and discussing priorities
- Retrospectives are a tool as well; a quorum regarding what goes well and what should be improved.
In a well functioning team, you will always need coordination/communication, progress visibility, continuous improvements, etc.
I picked 2 red flags in how this junior product manager approaches their work:
- the team did not discuss estimations
- he told his boss the team will deliver after 3 months
Basically he just "winged it" for his first project, picked a waterfall approach, and made it. Congrats! That tells me he either has a kick ass team (thank them) or the deliverable was easily achievable (thank the boss), or more likely a bit of both.
Let's take a few of the points being made throughout the post:
> Trello (or whatever you use) has to be kept in sync with what’s discussed in these meetings. It often isn’t. As the team grows this becomes even more complicated.
This is spot on. Using a tool to keep in sync is only useful if the members keep it up to date. If the tool is not up to date, the team either has a tool problem or a people problem.
> Stand-ups ENCOURAGE plans to change daily. Lack of consistency is a great way to ruin developer flow.
I strongly disagree there. Nothing, in each team member speaking daily, for less than 2 minutes, about what they are working on, encourages change of plans.
When the author mentions standups routinely lasting 30+ minutes... well yeah either fix it the soft way (time limit + a judge making sure everybody stays on point) or the hard way (just stop doing standups & send updates through a different channel).
What I've seen is that there are usually 2 team members that come with the 'authority' to make for a great standup: the product owner (in this case our author) or the tech lead (well, seems it's the author again, as a technical. prod. owner?).
> Standup forces every team member to be productive at a set place and a set time
Yes it can be a problem. That could possibly be reason #1 to get rid of standups. We're lucky in our remote team that everybody is happy starting the day at 9am as standups mid or end of day make not much sense.
> Extroverts thrive at stand-ups, planning, and retros. It’s no wonder that tech debt is such a common problem. Developers shouldn’t have to PUSH for tech debt to be addressed. Teams should operate at a sustainable pace.
Again, it sounds like standups are being used for the wrong thing. The standup is at 90% a 'passive' communication tool. Listen to the others carefully. Wait for the standup to be finished and FREE PEOPLE FROM THE MEETING to catch up with whomever you want on whichever subject you want.
> Why do we encourage problems to be discussed once a week? We should address them immediately, not just at retros.
Absolutely, problems that can and should be addressed on the spot MUST be addressed on the spot or taken ownership of by a lead and then addressed timely.
However that approach does not catch everything. Retrospectives are an excellent way to make sure people can flag issues. It is natural that, in the week, someone will be too busy to immediately flag an issue, but make a note of what could be improved. A regular open quorum dedicated to these things helps share these details.
There are 2 critical elements to successful retrospectives:
- trust that everybody can speak up about the most minute detail. Be open about anything that is being said. Leave the ego out.
- trust that what is said is genuinely acted upon. Track improvement and suggestions and ADDRESS THEM. In software development, if you see a bug, you create a regression test and then fix the bug. Well, tske the same approach!
> Sprints encourage iterative development. This sounds really good to people like me who strongly advocate small, concise, pull requests over long-living feature branches. But it’s not the same thing. Sprints encourage features over tech debt. How often have you had to advocate spending an entire sprint tackling tech debt?
I'm eluded by the fact that sprints encourage features over tech debt. It seems that the source of the friction with sprints is not the sprint itself but how it is being used.
Addressing tech debt is part of any new feature. There should be no 'tech debt' in a sprint. DO NOT address tech debt that does not fix a bug(s) or help new a new feature though. It can be useful to write a list of hot spots, for communication and reminder purposes..
For each new feature, the team has many choices for the implementation: from complete hack to full refactor. A constant balance goes a long way, with the occasional 'that is needed in a week' and 'we need to refactor A to K before we do feature XYZ'. These are healthy events in a team that care a lot about delivering the most business value through solid software.
> That said, I’m not against planning, I’m against planning on an interval.
Fair point. Planning on an interval brings a few things on the table:
- it sets a cadence. Some people love stability. Regular planning can be an anchor to someone's organization of their work.
- it allows measuring velocity and therefore longer term planning through past velocity.
- it allows reprioritization sprint after sprint. Usually the product owner role is to gather clients' needs. These needs evolve both with new features and time. Rather than re-prioritizing on the spot (like it seems it was being done at the author's previous projects), it is a compromise between constantly shuffling around what developers do and being flexible about what is being built.
In my modest experience, all of these are very useful tools :)
now we don't need stand-ups. couple of months ago they were the best since sliced bread. in job interviews i still get asked every time how often we do stand-ups - right after whether my team is lean, agile or design thinking. good lord have mercy ...
I read "You don't need startups" and nodded my head in agreement.
Post agile is a thing. Everybody is pretending to be agile these days. So, the word has become utterly meaningless. Every bank, insurerer, etc. is doing agile. And they are just as boring, stupid, and ineffective as 20 years ago. Government IT projects still go spectacularly wrong but they all pray to the church of Agile now.
When the agile manifesto was signed (yes old enough to remember), this was not the case. Agile was a new thing then. People were doing all sorts of stuff at the time and confusing processes and modeling techniques and requirements engineering methodology. Universities taught waterfall then (mostly because academics have no clue how development actually works). Rational Unified Process was something pimped by a company specializing in UML tooling! They ended up in the hands of IBM; probably the least agile company in existence at the time. Blue suits/white shirts were very much still a thing then. RUP was considered modern in the late nineties.
UML itself perpetuated the dogmas of waterfall, which was to first do detailed designs (using UML) after doing requirements specifications and before doing implementation work and before testing would commence. Automated testing was not a thing at the time. With rational unified they added a thin layer of iterative; meaning you got to do waterfall multiple times in a project. Rational's premise was that this required tools, lots of tools. Very complex tools that required lots of consulting. This is why IBM bought them.
Iterative development is of course almost as old as waterfall. The original paper by Royce on waterfall is actually a pretty good read but was soon complemented by papers on spiral and iterative development. Feedback loops are a good thing; every engineer knows this.
What the agile manifesto accomplished was that the UML bubble was burst. Having a lot of design documentation slows you down when iterating and makes it hard to do that. When people figured out that the added value of this typically incomplete and out of date documentation was questionable and that iterating was a good thing the result was that UML became a thing for whiteboards and from there an entirely optional thing. Same with requirements documentation, which was a bit of a black art to begin with. With agile people figured out that it's much easier to specify small deltas of what you want changed then the whole thing up front. Issue trackers empowered this. Bugzilla was the first popular one that got a lot of traction. They turned requirements into a way of working.
In a post agile world, everybody uses similarly capable tools. Typically git, some issue tracker, async commnunication tools like irc or slack, etc. I exclude email here; relative to 20 years ago, I spend a lot less time looking at email. It's rapidly disappearing from my life at least. Async communication is at odds with meetings and empower having distributed teams. The open source world was always distributed and never relied on meetings. They were an early adopted of asynchronous tools.
With post agile people are discovering that the added value of meetings is questionable. Agile initially replaced tools with structured ways to organize teams. An unintended side effect was lots of meetings. Meetings are inherently synchronous in both time and (usually) space. They require heads in a room at a specific moment. Video conferencing sucks and remote attendees are typically at a huge disadvantage in such meetings. So meetings are an obstacle for having remote teams.
With post agile, people are keeping some of the tools but are abandoning meetings. This is similarly liberating as saying goodbye to convoluted out of date UML diagrams, crappy requirements specifications, and the glacial pace of waterfall style development. Other post agile trends are continuous deployment: if it's ready, ship it now, not after the next retrospective in two weeks. And it's key enabler: continuous integration: aka. automatically assess whether you are fit to ship right now and do that after every small change. The former eliminates release management as a role and the latter relieves product managers from having to manually test and approve releases. That cuts down on meetings and eliminates Sprints as a necessity and allows you to iterate in hours instead of weeks. With sprints out of the way, you can delete the associated meetings. Standups are not practical in a distributed team, so those go as well. Post agile is about asynchronous communication and work distribution and getting rid of synchronization bottlenecks in processes (aka meetings).
When the agile manifesto was signed (yes old enough to remember), this was not the case. Agile was a new thing then. People were doing all sorts of stuff at the time and confusing processes and modeling techniques and requirements engineering methodology. Universities taught waterfall then (mostly because academics have no clue how development actually works). Rational Unified Process was something pimped by a company specializing in UML tooling! They ended up in the hands of IBM; probably the least agile company in existence at the time. Blue suits/white shirts were very much still a thing then. RUP was considered modern in the late nineties.
UML itself perpetuated the dogmas of waterfall, which was to first do detailed designs (using UML) after doing requirements specifications and before doing implementation work and before testing would commence. Automated testing was not a thing at the time. With rational unified they added a thin layer of iterative; meaning you got to do waterfall multiple times in a project. Rational's premise was that this required tools, lots of tools. Very complex tools that required lots of consulting. This is why IBM bought them.
Iterative development is of course almost as old as waterfall. The original paper by Royce on waterfall is actually a pretty good read but was soon complemented by papers on spiral and iterative development. Feedback loops are a good thing; every engineer knows this.
What the agile manifesto accomplished was that the UML bubble was burst. Having a lot of design documentation slows you down when iterating and makes it hard to do that. When people figured out that the added value of this typically incomplete and out of date documentation was questionable and that iterating was a good thing the result was that UML became a thing for whiteboards and from there an entirely optional thing. Same with requirements documentation, which was a bit of a black art to begin with. With agile people figured out that it's much easier to specify small deltas of what you want changed then the whole thing up front. Issue trackers empowered this. Bugzilla was the first popular one that got a lot of traction. They turned requirements into a way of working.
In a post agile world, everybody uses similarly capable tools. Typically git, some issue tracker, async commnunication tools like irc or slack, etc. I exclude email here; relative to 20 years ago, I spend a lot less time looking at email. It's rapidly disappearing from my life at least. Async communication is at odds with meetings and empower having distributed teams. The open source world was always distributed and never relied on meetings. They were an early adopted of asynchronous tools.
With post agile people are discovering that the added value of meetings is questionable. Agile initially replaced tools with structured ways to organize teams. An unintended side effect was lots of meetings. Meetings are inherently synchronous in both time and (usually) space. They require heads in a room at a specific moment. Video conferencing sucks and remote attendees are typically at a huge disadvantage in such meetings. So meetings are an obstacle for having remote teams.
With post agile, people are keeping some of the tools but are abandoning meetings. This is similarly liberating as saying goodbye to convoluted out of date UML diagrams, crappy requirements specifications, and the glacial pace of waterfall style development. Other post agile trends are continuous deployment: if it's ready, ship it now, not after the next retrospective in two weeks. And it's key enabler: continuous integration: aka. automatically assess whether you are fit to ship right now and do that after every small change. The former eliminates release management as a role and the latter relieves product managers from having to manually test and approve releases. That cuts down on meetings and eliminates Sprints as a necessity and allows you to iterate in hours instead of weeks. With sprints out of the way, you can delete the associated meetings. Standups are not practical in a distributed team, so those go as well. Post agile is about asynchronous communication and work distribution and getting rid of synchronization bottlenecks in processes (aka meetings).
Line by line:
> Trello (or whatever you use) has to be kept in sync with what’s discussed in these meetings. It often isn’t.
My team offloaded this to the PM.
> Stand-ups ENCOURAGE plans to change daily.
The sprint plan is the plan, stand-ups make sure the execution is coordinated.
> Standup forces every team member to be productive at a set place and a set time
Timing around standups is interesting. 11am and everyone will be there, but it interrupts a lot of people's flow. Earlier and people no show, later and the point of a morning stand up is lost.
> Extroverts thrive at stand-ups, planning, and retros. It’s no wonder that tech debt is such a common problem.
How are extroverts and tech debt related?
> Developers shouldn’t have to PUSH for tech debt to be addressed.
Have a sustainable plan for addressing tech debt. My team had 3 week sprints, 2 weeks code, 1 week on debt. Developers who had just finished a major feature would be cycled on to tech debt for the entirety of the next sprint.
> Why do we encourage problems to be discussed once a week?
You can talk about problems whenever, but having a set place to have larger planning discussions means that you waste less time smaller meetings about them.
> Sprints encourage features over tech debt.
Plan tech debt into your sprints. Put bug fixing onto your task board. Put writing tests onto your task board. If your task board is full of tech debt, then you can't add any more features, because that is how a task board works, it gets filled up eventually and you have to go through it completing stuff.
> It usually serves to interrupt developers, make them feel pressured to prioritize features over tech debt
Tech debt sounds like a cultural problem on team's he has been on. Not surprising, it is a cultural problem on a lot of teams, independent of dev methodology.
> Developers communicate more
Why? Developers are always free to communicate outside of stand-ups.
> Tech debt gets addressed
If promotions are based upon feature completion, as they often are, tech debt being completed isn't a natural outcome of freeing up 10 minutes a day.
One goal of stand-ups is for people to say outloud what they are working on, so if someone else has knowledge in that area, that person can overhear and chip in.
Without a public forum, how is Developer A supposed to know Developer B is knee deep in code that Developer A wrote a year ago? Keep up to date on everyone's assigned tasks?
> It’s my role to “steer the ship” (e.g. decide what we work on).
I find that giving developers input on this is important. In fact, that is how the tech debt gets addressed...
> If I’m changing my mind about this on a daily basis that’s problematic.
Yeah, don't do that. Daily standups are not for PMs to give feedback, or talk much for that matter. They are for devs to coordinate the day's tasks.
> Stop planning every sprint
Sprints are super useful to chunk up work and allocate resources. For companies that have infinite investor money and ship a fancy JS app that can be updated at any time without impacting customers, sure, go sprint less.
Have a hard deadline that you need work done by? Does shipping your product have an actual impact on end users? You need to be able to estimate how long work will take, and figure out what people will be doing.
Historical task completion rate, bug fix rates, and burn down charts let teams accurately estimate how much work they can get done before that real life deadline hits.
IMHO weekly planning is too much. My team experimented with a bunch of different sprint schedules, we settled on 3 weeks as a good balance between time spent planning and time spent getting stuff done.
Sprints had a rhythm, developers assigned to multi-sprint features ignored the rhythm for the most part.
For everyone else, 2 weeks feature work, 1 week tech debt, and coordinating with test for sign off.
> Tasks are added to the backlog as needed,
Stand-ups have no impact on this being possible. The add task button is always available, 24/7.
> Developers are trusted to be working on the correct things
Stand-ups have no impact on this. You can still trust people to pull of the tasks they feel are important.
> Stop doing retros
Retros are how the devs tell everyone else that tech debt needs to be addressed. It is where they can make a solid numerical argument that more time needs to be taken to fix bugs. On multiple occasions I used retros to get the larger org to buy off on my team spending an entire sprint on just bug fixes and tech debt. We were able to show previous burn down charts, show how our productivity had decreased as tech debt went up, and use hard numbers to estimate our improved velocity after taking time off to address out debt.
tl;dr: Stand-ups are a nice way for developers to catch up on what is being worked on by their team mates, and to know if they can help each other out.
If you use them for anything more than that, well, sure, simplify it.
> Trello (or whatever you use) has to be kept in sync with what’s discussed in these meetings. It often isn’t.
My team offloaded this to the PM.
> Stand-ups ENCOURAGE plans to change daily.
The sprint plan is the plan, stand-ups make sure the execution is coordinated.
> Standup forces every team member to be productive at a set place and a set time
Timing around standups is interesting. 11am and everyone will be there, but it interrupts a lot of people's flow. Earlier and people no show, later and the point of a morning stand up is lost.
> Extroverts thrive at stand-ups, planning, and retros. It’s no wonder that tech debt is such a common problem.
How are extroverts and tech debt related?
> Developers shouldn’t have to PUSH for tech debt to be addressed.
Have a sustainable plan for addressing tech debt. My team had 3 week sprints, 2 weeks code, 1 week on debt. Developers who had just finished a major feature would be cycled on to tech debt for the entirety of the next sprint.
> Why do we encourage problems to be discussed once a week?
You can talk about problems whenever, but having a set place to have larger planning discussions means that you waste less time smaller meetings about them.
> Sprints encourage features over tech debt.
Plan tech debt into your sprints. Put bug fixing onto your task board. Put writing tests onto your task board. If your task board is full of tech debt, then you can't add any more features, because that is how a task board works, it gets filled up eventually and you have to go through it completing stuff.
> It usually serves to interrupt developers, make them feel pressured to prioritize features over tech debt
Tech debt sounds like a cultural problem on team's he has been on. Not surprising, it is a cultural problem on a lot of teams, independent of dev methodology.
> Developers communicate more
Why? Developers are always free to communicate outside of stand-ups.
> Tech debt gets addressed
If promotions are based upon feature completion, as they often are, tech debt being completed isn't a natural outcome of freeing up 10 minutes a day.
One goal of stand-ups is for people to say outloud what they are working on, so if someone else has knowledge in that area, that person can overhear and chip in.
Without a public forum, how is Developer A supposed to know Developer B is knee deep in code that Developer A wrote a year ago? Keep up to date on everyone's assigned tasks?
> It’s my role to “steer the ship” (e.g. decide what we work on).
I find that giving developers input on this is important. In fact, that is how the tech debt gets addressed...
> If I’m changing my mind about this on a daily basis that’s problematic.
Yeah, don't do that. Daily standups are not for PMs to give feedback, or talk much for that matter. They are for devs to coordinate the day's tasks.
> Stop planning every sprint
Sprints are super useful to chunk up work and allocate resources. For companies that have infinite investor money and ship a fancy JS app that can be updated at any time without impacting customers, sure, go sprint less.
Have a hard deadline that you need work done by? Does shipping your product have an actual impact on end users? You need to be able to estimate how long work will take, and figure out what people will be doing.
Historical task completion rate, bug fix rates, and burn down charts let teams accurately estimate how much work they can get done before that real life deadline hits.
IMHO weekly planning is too much. My team experimented with a bunch of different sprint schedules, we settled on 3 weeks as a good balance between time spent planning and time spent getting stuff done.
Sprints had a rhythm, developers assigned to multi-sprint features ignored the rhythm for the most part.
For everyone else, 2 weeks feature work, 1 week tech debt, and coordinating with test for sign off.
> Tasks are added to the backlog as needed,
Stand-ups have no impact on this being possible. The add task button is always available, 24/7.
> Developers are trusted to be working on the correct things
Stand-ups have no impact on this. You can still trust people to pull of the tasks they feel are important.
> Stop doing retros
Retros are how the devs tell everyone else that tech debt needs to be addressed. It is where they can make a solid numerical argument that more time needs to be taken to fix bugs. On multiple occasions I used retros to get the larger org to buy off on my team spending an entire sprint on just bug fixes and tech debt. We were able to show previous burn down charts, show how our productivity had decreased as tech debt went up, and use hard numbers to estimate our improved velocity after taking time off to address out debt.
tl;dr: Stand-ups are a nice way for developers to catch up on what is being worked on by their team mates, and to know if they can help each other out.
If you use them for anything more than that, well, sure, simplify it.
> Plan tech debt into your sprints.
Exactly! Nothing about Scrum or Agile discourages tackling tech debt. Managers and Product Owners encourage features—not sprints.
Exactly! Nothing about Scrum or Agile discourages tackling tech debt. Managers and Product Owners encourage features—not sprints.
"Extroverts thrive at stand-ups, planning, and retros."
As if to insinuate that extroverts like to increase technical debt and introverts are the quiet ones that toil away. Nah.
As if to insinuate that extroverts like to increase technical debt and introverts are the quiet ones that toil away. Nah.
Sometimes the goal is to slow down work. For example, if your budget is for a year but the project only takes 6 months, sometimes people add extra hurdles that look good to outsiders but slow down work enough so they get paid for the full time.
If a project ends 6 months early it's entirely possible to not get paid as much.
If a project ends 6 months early it's entirely possible to not get paid as much.
Bull-fucking-shit; you know why Spotify's engineering team does well? Stripe's? Netflix's? Because they have money, they have money so they can buy the best engineers. You ever see a small business development team compete on their level that isn't a bespoke design firm?
In my world, my team isn't an olympic-performing high-end software engineering pack. They don't lead in particular subfields in FOSS in their spare time. So you know what? They need fucking plans.
This article is a glorified, "Well if you're good you don't need process," piece.
In my world, my team isn't an olympic-performing high-end software engineering pack. They don't lead in particular subfields in FOSS in their spare time. So you know what? They need fucking plans.
This article is a glorified, "Well if you're good you don't need process," piece.
This is pretty condescending to your team. They might not be rockstar developers, but they are adults and can probably manage their time themselves. You don't need to be the best programmer to manage your time, you just need some common sense. If I were working somewhere where the manager thought I couldn't plan my own schedule, I'd look elsewhere.
Would you please not rant like this to HN? You may have a substantive point in there but you need to make it more thoughtfully.
Could you please elaborate? I don't feel like "like this" and "thoughtfully" are constructive pieces of feedback for comments.
> Could you please elaborate?
'Bull-fucking-shit' was literally the first word in your comment.
'Bull-fucking-shit' was literally the first word in your comment.
It's basically the online equivalent of spittle flying out of your mouth while berating someone.
If dang asks you to do something politely, there's a good reason for it.
You can find out more about him here: https://blog.ycombinator.com/meet-the-people-taking-over-hac...
You can find out more about him here: https://blog.ycombinator.com/meet-the-people-taking-over-hac...
I didn't see it that way. The article argues for a very clear and curated Backlog of tasks. If engineers can't define tasks well and PM lacks understanding to structure backlog well then no amount of Engineering Olympians will help.
Yeah. A well maintained backlog with a disciplined approach to changes does miracles.
And Uber has lots of money, but their product is still a shit-show, although, granted that their payments platform has excellent uptime and works very smoothly given the n-to-n model of the system.
It sounds like the product your business is developing is scoped too large for the revenue or market share it can realistically capture. Scope according to money available, then your product, and your team, will be happy for it. The business will flourish too, and maybe you'll feel less stress.
It sounds like the product your business is developing is scoped too large for the revenue or market share it can realistically capture. Scope according to money available, then your product, and your team, will be happy for it. The business will flourish too, and maybe you'll feel less stress.
> you know why Spotify's engineering team does well?
> Stripe's? Netflix's? Because they have money
No. Some places have too much money, others enough and then there are those that may have to shut down in half a year. Seen them all, and "engineering aptitude" is completely independent of that.
> Stripe's? Netflix's? Because they have money
No. Some places have too much money, others enough and then there are those that may have to shut down in half a year. Seen them all, and "engineering aptitude" is completely independent of that.
I upvoted because I partly agree - if you're good you don't need these various methodologies. However, I'm curious - do you think these processes can actually convert a bad team into an ok one?
The processes help coordination and accountability; if they may be improved, the team will improve. Will it become an ok one? It may.
Money gets you to a certain point, and does provide a cushion against certain errors. But if you simply spend money on the best engineers without a plan and shared purpose, they will leave.
If you think this, their only actual plan will be to leave the company as soon as the opportunity arises.
Big difference between these things and no process at all.
Funny how there's a Show HN link for a standup app right above this post...
ah, gratuitous obscenity. the sign of someone that really knows what they're doing, from whom we should take advice.
it's still worth reading, not for what it says but what is between the lines. "how not to do sprints". admittedly this isn't (must not be, i guess) common, but at my current $JOB we do dedicate entire sprints to tech debt. remote people phone into our sprints and are well included. it actually HELPS remote contact as there is at minimum a daily interaction with the entire team. (@tapvt had a similar comment.) his comments about changing the course on a daily basis is another example of likely abuse of sprints.
it's still worth reading, not for what it says but what is between the lines. "how not to do sprints". admittedly this isn't (must not be, i guess) common, but at my current $JOB we do dedicate entire sprints to tech debt. remote people phone into our sprints and are well included. it actually HELPS remote contact as there is at minimum a daily interaction with the entire team. (@tapvt had a similar comment.) his comments about changing the course on a daily basis is another example of likely abuse of sprints.
ah, the insistence on PG language. The sign of someone that has a concrete criticism of an author's point, which we should pay attention to.
I am a bit saddened by the fact you are getting downvoted.
Swearing adds nothing to the author's arguments and I believe you are spot-on on the analysis of the blog post.
Edit:
I missed the following from HN's guidelines
Please don't comment about the voting on comments. It never does any good, and it makes boring reading.
Sounds very fair. The more you know... :)
Swearing adds nothing to the author's arguments and I believe you are spot-on on the analysis of the blog post.
Edit:
I missed the following from HN's guidelines
Please don't comment about the voting on comments. It never does any good, and it makes boring reading.
Sounds very fair. The more you know... :)
Complaining about swearing adds even less to the discussion.
The only time anyone cares about a standup is when they are talking.
In fact, all I like about standups is seeing my team mates once a day. Besides that, there's almost no upside. Literally everyone can read the project board to see what we're up to. If you're really so curious as to what everyone is doing, why not just look at that?