Launch HN: Spinach.io (YC W22) – Better daily standups
187 comments
Firstly, congrats on launching. Hard work is hard.
I don't want to be negative on your launch day, but at the same time feedback is important.
1. I couldn't see myself or the many agile/lean teams I've been part of using this. I don't feel enough of a burden when walking the board for this to be worth the money.
2. A user in spinach.io costs effectively the same amount as a user in Slack, the difference is that I'm going to use Slack all day every day and assuming the use of this tool it's a once a day task.[0]
3. Bringing 'intention' and 'structure' feels a little like it will become a straitjacket.
4. Moving talking during a standup to 'prep time' seems like it would remove any of the time benefits you're quoting. Worse that time would better be spent updating Jira/Trello/whatever, people don't do this reliably, so the prep becomes one more thing that doesn't get done.
This is only one data point, and there is of course the classic "what do we need Dropbox for we have FTP" HN comment, so don't be disheartened either. As PG has said (paraphrased), one of the reasons to launch quickly is that you haven't really begun until you've launched.
Having said that I'm happy to continue providing feedback as you iterate (my contact details are in my profile).
[0]: Enterprise price point is incredibly hard. Got to get enough dollars to make it worthwhile, but that excludes smaller businesses like mine that feel like a death by a thousand cuts from all the SaaS subscriptions (I know you have a free plan).
I don't want to be negative on your launch day, but at the same time feedback is important.
1. I couldn't see myself or the many agile/lean teams I've been part of using this. I don't feel enough of a burden when walking the board for this to be worth the money.
2. A user in spinach.io costs effectively the same amount as a user in Slack, the difference is that I'm going to use Slack all day every day and assuming the use of this tool it's a once a day task.[0]
3. Bringing 'intention' and 'structure' feels a little like it will become a straitjacket.
4. Moving talking during a standup to 'prep time' seems like it would remove any of the time benefits you're quoting. Worse that time would better be spent updating Jira/Trello/whatever, people don't do this reliably, so the prep becomes one more thing that doesn't get done.
This is only one data point, and there is of course the classic "what do we need Dropbox for we have FTP" HN comment, so don't be disheartened either. As PG has said (paraphrased), one of the reasons to launch quickly is that you haven't really begun until you've launched.
Having said that I'm happy to continue providing feedback as you iterate (my contact details are in my profile).
[0]: Enterprise price point is incredibly hard. Got to get enough dollars to make it worthwhile, but that excludes smaller businesses like mine that feel like a death by a thousand cuts from all the SaaS subscriptions (I know you have a free plan).
You've shared many of my thoughts as well.
Congrats on the launch, but from the website I even struggle to see what Spinach really does. I guess I have to watch the video to get a good impression, but "running standups" doesn't feel that complicated that the website couldn't be a bit more clear on which parts of a standup Spinach is going to help me with.
I also wonder if this is something that engineers will enjoy. Feels more its targeted at Agile consultants and old school big corps. I don't know a single engineer who likes standups or agile, especially not if its "structured" as it's kind of the opposite of agile.
EDIT:
Also I never understood what the point is of a recorded standup history? To me that is a massive huge red flag and evidence that Scrum/Agile ceremonies are just a way for management to manage. It serves no purpose to the actual team. Yesterdays standup is completely irrelevant today. If there is still something important to discuss then it will be discussed today. It's actually quite counter productive to suggest that someone has to go through old notes to get informed about somethign they need to know. That is not in the spirit of what standups were originally meant to be.
Congrats on the launch, but from the website I even struggle to see what Spinach really does. I guess I have to watch the video to get a good impression, but "running standups" doesn't feel that complicated that the website couldn't be a bit more clear on which parts of a standup Spinach is going to help me with.
I also wonder if this is something that engineers will enjoy. Feels more its targeted at Agile consultants and old school big corps. I don't know a single engineer who likes standups or agile, especially not if its "structured" as it's kind of the opposite of agile.
EDIT:
Also I never understood what the point is of a recorded standup history? To me that is a massive huge red flag and evidence that Scrum/Agile ceremonies are just a way for management to manage. It serves no purpose to the actual team. Yesterdays standup is completely irrelevant today. If there is still something important to discuss then it will be discussed today. It's actually quite counter productive to suggest that someone has to go through old notes to get informed about somethign they need to know. That is not in the spirit of what standups were originally meant to be.
I completely second this! And I would like to extend the view from an Agile angle:
In Scrum, the Daily Standup is to inspect and adapt to reach the Sprint goal. We always do a "Walk the board", where the complete team focus on what do we need to do, to get an item to progress towards done. Which is a discussion using the swarm intelligence.
When only focusing on the (outdated) three questions (What have you done yesterday, what do you plan to do today and do you have any impediments), that not only feels like a status meeting, but also ignores the goal and collaboration.
In Scrum, the Daily Standup is to inspect and adapt to reach the Sprint goal. We always do a "Walk the board", where the complete team focus on what do we need to do, to get an item to progress towards done. Which is a discussion using the swarm intelligence.
When only focusing on the (outdated) three questions (What have you done yesterday, what do you plan to do today and do you have any impediments), that not only feels like a status meeting, but also ignores the goal and collaboration.
I work with lots of companies that have different variations. I have to agree my favourite daily/standup is a walk the board style.
Often it's the retro where I spend a lot of time trying to encourage the team to do it "properly". I've had one that just wanted to do kumbaya sessions where they pat each other on the back for the last sprint. It feels great, but it's not what the retrospective was designed to work toward -- continuous improvement (Kaizen).
Often it's the retro where I spend a lot of time trying to encourage the team to do it "properly". I've had one that just wanted to do kumbaya sessions where they pat each other on the back for the last sprint. It feels great, but it's not what the retrospective was designed to work toward -- continuous improvement (Kaizen).
Thanks for the feedback, that's what we're looking for!
The way we built the prep experience leverages previous tasks and goals and leverages our Jira integration which allows users to complete it in 1-2 minutes. The time saving you get by the whole team doing it is in many cases 10-20 minutes a day so well worth it.
We're working on more features which leverage our Jira integration so eventually you'll be able to do everything you need during standup directly from Spinach in Zoom/Meet/Teams without having to use another app and/or screen share
Everyone take note, this is how you post constructive criticism on HN.
100% on “prep that doesn’t get done”. We have a slackbot at my place of work that asks people to do extremely quick updates for yesterday, today in lieu of the standup. Even getting people to consistently do that is an exercise.
Yes. As a lead with a team spread across time zones, I’m constantly reminding (nagging) people to check in. I don’t want to have to corral people into a ‘least inconvenient’ meeting slot to get updates.
This is because demanding that people spout what they did since yesterday is not how to manage humans. You need to engage with them. Call them up (voice ideally, but a slack DM thread is ok) and ask questions like they're another human being (not : what did you do since yesterday?).
> Call them up (voice ideally, but a slack DM thread is ok) and ask questions
What? This is what developers hate the most. Leave me be, and I'll update you when there's something to update. A gentle slack nudge "remember to update trello/jira/post here/whatever" is fine since I can do that whatever.
If you call me with "hey, how's it going" while I'm in the zone and holding 7 things in my mind, you've just ruined my day and wasted at least an hour of my time.
What? This is what developers hate the most. Leave me be, and I'll update you when there's something to update. A gentle slack nudge "remember to update trello/jira/post here/whatever" is fine since I can do that whatever.
If you call me with "hey, how's it going" while I'm in the zone and holding 7 things in my mind, you've just ruined my day and wasted at least an hour of my time.
> demanding that people spout what they did since yesterday is not how to manage humans
Yeah I made it sound that way a bit right? Happy to say that's not what's happening.
It's more that if I don't ask, they'll tend not to volunteer anything. We only have a few hours cross-over every day, and it's hard to generate a good sense of 'team!'
Yeah I made it sound that way a bit right? Happy to say that's not what's happening.
It's more that if I don't ask, they'll tend not to volunteer anything. We only have a few hours cross-over every day, and it's hard to generate a good sense of 'team!'
Maybe your company should take the hint. Nobody wants to do that stuff.
As an EM, I use documented standups to keep track of how long and when people work on tasks. When a person is under performing, this document is invaluable reference. When a person is exceeding expectations, this document helps me write their promo doc.
This could could be useful to manage that data better, but currently I use a Google Doc sheet.
That being said, I couldn't justify the cost of this tool to my manager when Google Docs does it well enough. Perhaps, this could be sold as a cost savings strategy for finding low performers?
This could could be useful to manage that data better, but currently I use a Google Doc sheet.
That being said, I couldn't justify the cost of this tool to my manager when Google Docs does it well enough. Perhaps, this could be sold as a cost savings strategy for finding low performers?
I guarantee you're driving some employees to worse performance because they're depressed from having a meeting every single day at which they have to justify their continued employment. This kind of thing is absolutely soul-crushing.
You're likely also straight-up killing standups as a collaboration tool for the team. They work best when the team can be very open and honest. This use of standups ruins that. You probably shouldn't be in the standups at all, in fact, unless you're also contributing code to the project(s) on a more-or-less daily basis. Further, these practices tend to turn standups into sharing way too many details about every little problem or task the previous day, which also contributes to making them worthless for the people actually doing the work (plus, even more miserable to sit/stand through every single day—see again: the first paragraph, like, the general principle here is maybe don't have a standing daily meeting that everyone completely fucking dreads)
Also: where the hell's your project manager? And how is your issue tracker broken enough that you can't tell what people are working on or for roughly how long, without this? Between the tracker and the repo(s) and occasionally just chatting with people, you should not need this to tell how well people are working.
You're likely also straight-up killing standups as a collaboration tool for the team. They work best when the team can be very open and honest. This use of standups ruins that. You probably shouldn't be in the standups at all, in fact, unless you're also contributing code to the project(s) on a more-or-less daily basis. Further, these practices tend to turn standups into sharing way too many details about every little problem or task the previous day, which also contributes to making them worthless for the people actually doing the work (plus, even more miserable to sit/stand through every single day—see again: the first paragraph, like, the general principle here is maybe don't have a standing daily meeting that everyone completely fucking dreads)
Also: where the hell's your project manager? And how is your issue tracker broken enough that you can't tell what people are working on or for roughly how long, without this? Between the tracker and the repo(s) and occasionally just chatting with people, you should not need this to tell how well people are working.
[deleted]
As a bona-fide, certified, rarified SCRUM-MASTER here (respect mah authoritay), I just have to say - does anyone really think a standup is a 'collaborative' meeting?
It's a check-in meeting! If you weren't productive yesterday, just say so - as long as you are generally keeping your commitments and shipping your features on time, it's fine. If you are behind, you can verbalize it - and if it makes sense, it makes sense. If it doesn't, well you are starting to break the bonds of trust between teammates. That's on you. And high performing teams don't have a place for that.
Now, if that's not the culture at your company, then you frankly have much bigger problems than a stand-up meeting.
It's a check-in meeting! If you weren't productive yesterday, just say so - as long as you are generally keeping your commitments and shipping your features on time, it's fine. If you are behind, you can verbalize it - and if it makes sense, it makes sense. If it doesn't, well you are starting to break the bonds of trust between teammates. That's on you. And high performing teams don't have a place for that.
Now, if that's not the culture at your company, then you frankly have much bigger problems than a stand-up meeting.
A check-in meeting is still a collaboration tool (the phrase I used), so... yes? But I get the sense you're using these words differently from their normal meaning, so it's possible that in some jargon-sense they're not, because a check-in meeting can't be a collaboration tool because those have strictly exclusionary definitions, or something. But under ordinary usage of the terms, yes, sure, a check-in meeting's probably usually a collaboration tool. I don't even know how it wouldn't be, except, again, maybe under some "house" usage of the terms, or if the meeting's gone pathological and is just a zombie-meeting serving no purpose at all.
My main point is that the meeting should chiefly be for the team doing the work. They're the ones whose collaboration (yes!) should be served by the meeting. If the meeting's a bunch of people taking turns saying stuff the rest of the team already knows, or doesn't need to know, to turn it into a status report for a manager, that's a shitty standup for a bunch of reasons. If a manager's basing fire/raise/promote decisions off data gathered in standups, people are gonna avoid saying things they ought to, and say tons of shit (maybe even true shit! Not necessarily lies) that no-one but the data-collecting manager needed or wanted to hear. Those kinds of practices tend to change standups to make them far less useful to the team. The useful-to-the-team communication that the standup's supposed to encourage will instead happen elsewhere, or even not at all.
That is how you get standups that the ICs dread and derive no value from. It's how you get people half-sleeping the whole time except when they have to talk. It's (part of) how you get half-hour standups. It's a big step down the path to the agile-as-micromanagement thing that's much of the reason so many people hate agile, as it exists in the wild.
My main point is that the meeting should chiefly be for the team doing the work. They're the ones whose collaboration (yes!) should be served by the meeting. If the meeting's a bunch of people taking turns saying stuff the rest of the team already knows, or doesn't need to know, to turn it into a status report for a manager, that's a shitty standup for a bunch of reasons. If a manager's basing fire/raise/promote decisions off data gathered in standups, people are gonna avoid saying things they ought to, and say tons of shit (maybe even true shit! Not necessarily lies) that no-one but the data-collecting manager needed or wanted to hear. Those kinds of practices tend to change standups to make them far less useful to the team. The useful-to-the-team communication that the standup's supposed to encourage will instead happen elsewhere, or even not at all.
That is how you get standups that the ICs dread and derive no value from. It's how you get people half-sleeping the whole time except when they have to talk. It's (part of) how you get half-hour standups. It's a big step down the path to the agile-as-micromanagement thing that's much of the reason so many people hate agile, as it exists in the wild.
Oof, half hour stand-ups.
I see what you are saying though, I think my definition of 'collaboration' didn't immediately translate into your head. When I think of check-in, I just think of taking attendance. Who is at work today? In two or three sentences, what are you working on today? This way, the PM knows who has a little bit more slack in their day, and who can be assigned to triage a bug that pops out of nowhere, for example. I work at a smaller company, where product engineering goes hand in hand with fixing bugs. They aren't different teams.
'Collaboration' implies some sort of positive activity, that creates or generates something, whereas I think of a standup as simple a check-in exercise that provides a mechanism for people to notify someone 'hey, I need to discuss this with you, let's stay on after the call'.
My definitions are my own though, and probably pretty weird. I've tried to internalize the spirit of Agile, and through that internalization my main conclusion with a standup is that it's just a way to check in, and springboard into deeper triage conversations while allowing product management to understand what is being worked on.
I see what you are saying though, I think my definition of 'collaboration' didn't immediately translate into your head. When I think of check-in, I just think of taking attendance. Who is at work today? In two or three sentences, what are you working on today? This way, the PM knows who has a little bit more slack in their day, and who can be assigned to triage a bug that pops out of nowhere, for example. I work at a smaller company, where product engineering goes hand in hand with fixing bugs. They aren't different teams.
'Collaboration' implies some sort of positive activity, that creates or generates something, whereas I think of a standup as simple a check-in exercise that provides a mechanism for people to notify someone 'hey, I need to discuss this with you, let's stay on after the call'.
My definitions are my own though, and probably pretty weird. I've tried to internalize the spirit of Agile, and through that internalization my main conclusion with a standup is that it's just a way to check in, and springboard into deeper triage conversations while allowing product management to understand what is being worked on.
It's disappointing that standups are used in this way. I don't know you and I don't know your team but this kind of approach to standups is probably wrecking your standups.
The standup has it's roots in the agile manifesto[0] (gross simplification). Specifically "Individuals and interactions over processes and tools". The coming together every day for just a few minutes is an opportunity to ask for help (blockers).
Both the standup and to an even greater extent the retrospective are exercises in trust. I agree to show weakness and tell you and the team when I'm struggling with a task, or when things aren't going well, seeking continuous improvement. You agree not to use that against me.
The sooner roadblocks and problems are discovered the less likely they are to become larger problems. This is one of the fundamental benefits of a standup. But this requires trust. Recording and documenting for the purposes of performance management is probably the number one way of destroying that trust.
All of this means they're a very fragile beast. Prone to becoming exercises is puffery, or even worse a list of cards being worked on that you could just as easily get from the wall/Jira/trello.
The team also succeeds or fails together, a much better way of dealing with employees that are struggling is to use pairing (sparingly) to ensure that anyone blocked on a task doesn't face it alone. Some things are just hard. I've got 20+ years of programming under my belt and I still manage to struggle at times.
I've got the experience to work through this and ask for help where needed, but the earlier you are in your career the more imposter syndrome makes it desirable to crawl into a hole rather than ask for help. Standup in a great team helps break down those barriers. But only if a very fragile trust is maintained.
[0]: https://agilemanifesto.org/
The standup has it's roots in the agile manifesto[0] (gross simplification). Specifically "Individuals and interactions over processes and tools". The coming together every day for just a few minutes is an opportunity to ask for help (blockers).
Both the standup and to an even greater extent the retrospective are exercises in trust. I agree to show weakness and tell you and the team when I'm struggling with a task, or when things aren't going well, seeking continuous improvement. You agree not to use that against me.
The sooner roadblocks and problems are discovered the less likely they are to become larger problems. This is one of the fundamental benefits of a standup. But this requires trust. Recording and documenting for the purposes of performance management is probably the number one way of destroying that trust.
All of this means they're a very fragile beast. Prone to becoming exercises is puffery, or even worse a list of cards being worked on that you could just as easily get from the wall/Jira/trello.
The team also succeeds or fails together, a much better way of dealing with employees that are struggling is to use pairing (sparingly) to ensure that anyone blocked on a task doesn't face it alone. Some things are just hard. I've got 20+ years of programming under my belt and I still manage to struggle at times.
I've got the experience to work through this and ask for help where needed, but the earlier you are in your career the more imposter syndrome makes it desirable to crawl into a hole rather than ask for help. Standup in a great team helps break down those barriers. But only if a very fragile trust is maintained.
[0]: https://agilemanifesto.org/
A large part of Agile, at least from what I remember in my ScrumMaster training, is to recognize reality.
You estimated that you would do x amount of work. You only did y. Or, you did x + z - wow, you are a great performer. You should verbalize your success more often.
A part of confronting reality, is confronting the prospect of under-performing employees.
I think your 'ideology' is blinding you a little bit OP, at least - if you want to base your concept of standups based on how they were formulated in the original Agile manifesto - 'At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.'
Frankly, most dev teams don't give a whit about Agile and just do stand-ups to keep the PMs and SMEs appraised of progress and to check in on a couple of things here and there.
You estimated that you would do x amount of work. You only did y. Or, you did x + z - wow, you are a great performer. You should verbalize your success more often.
A part of confronting reality, is confronting the prospect of under-performing employees.
I think your 'ideology' is blinding you a little bit OP, at least - if you want to base your concept of standups based on how they were formulated in the original Agile manifesto - 'At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.'
Frankly, most dev teams don't give a whit about Agile and just do stand-ups to keep the PMs and SMEs appraised of progress and to check in on a couple of things here and there.
The selective pressures of your model reward dishonesty (under promise over deliver / make estimates as high as possible to mitigate downside and reduce pressure). Why is that making your team better?
Honest question: why is this bad?
If my estimates are padded to the point where I always complete what I commit to and my boss is happy with my output, what’s the problem? My boss gets value from being able to accurately convey estimates to clients, the client 9/10 gets the work done on time or maybe even gets a couple extra features completed in the same timeline, and I as the engineer, have a relaxed work environment, free of the stress of cramming every story point possible into 40 hours a week.
Seems like a win win win to me.
If my estimates are padded to the point where I always complete what I commit to and my boss is happy with my output, what’s the problem? My boss gets value from being able to accurately convey estimates to clients, the client 9/10 gets the work done on time or maybe even gets a couple extra features completed in the same timeline, and I as the engineer, have a relaxed work environment, free of the stress of cramming every story point possible into 40 hours a week.
Seems like a win win win to me.
This might be okay in isolation, but eventually as the entire team of engineers start to underdeliver, the team and company does get affected in terms of feature rollouts / velocity, and it's difficult to recover from it. People won't want to suddenly correct / do more work even if it's crucial, and they can point to their previous underestimated commitments and say that is a full week's worth of work. YMMV as with anything, but not knowing a team's true velocity does affect planning and sales.
Parent said "boss is happy with output", there is no underdelivering here.
The actual work doesn't change, it just changes your point estimations. Either the boss is happy with the actual pace and quality of the work, in which case you don't need points to begin with, or the boss doesn't understand the difference between story points and actual time, in which case it's all a dog and pony show anyway.
All this teaches employees is to lie to make themselves look good. If you really want to increase development velocity, implement better coding practices and devops and tooling and training and invest in your employees instead of making jump through stupid hoops like circus animals.
All this teaches employees is to lie to make themselves look good. If you really want to increase development velocity, implement better coding practices and devops and tooling and training and invest in your employees instead of making jump through stupid hoops like circus animals.
> wow, you are a great performer.
No, you aren't. You just either suck at estimation, or you deliberately underestimate to shine brighter in the eyes of your slavemaster. And if the rest of your team also "overperforms" consistently, there's a conspiracy, which means I will stop making you commit on stuff and will just ram more tasks down your collective throats, abandoning another aspect of the agile way of work.
See how easily such an abuse of standups can be turned around to make the very same person look bad? If that is possible, is the approach a good one?
> most dev teams don't give a whit about Agile and just do stand-ups to keep the PMs and SMEs appraised of progress
This is mostly related to PMs and SMEs pushing a perverted interpretation of Agile.
No, you aren't. You just either suck at estimation, or you deliberately underestimate to shine brighter in the eyes of your slavemaster. And if the rest of your team also "overperforms" consistently, there's a conspiracy, which means I will stop making you commit on stuff and will just ram more tasks down your collective throats, abandoning another aspect of the agile way of work.
See how easily such an abuse of standups can be turned around to make the very same person look bad? If that is possible, is the approach a good one?
> most dev teams don't give a whit about Agile and just do stand-ups to keep the PMs and SMEs appraised of progress
This is mostly related to PMs and SMEs pushing a perverted interpretation of Agile.
> The coming together every day for just a few minutes is an opportunity to ask for help (blockers).
The rest of your message about unblocking early seems to contradict your first statement of waiting until scrum to ask for help.
The rest of your message about unblocking early seems to contradict your first statement of waiting until scrum to ask for help.
I don't think I suggested that someone should wait, just that the opportunity to talk about blockers (ask for help) was important.
Each of the loops is about shortening the cycle before you discover problems. These are seen through the lens of traditional waterfall software development. The problems vary in nature, from technical blockers and dependencies, to unrealistic deadlines and expectations, to not building what the customer wants (why we involve the customer early and do showcases).
In some ways the more mature your team becomes the more you can move past some of the rules. The 'standup' was designed to avoid the meeting becoming overly long, everyone would become foot sore. Once you understand and embrace making the meeting not turn into an hour long (or even 30 min long) meeting, the standing itself becomes less important (which is good because remote teams make this harder).
Similarly, there are even shorter cycles of being able to remove blockers now. Granted Slack team channels can be a blessing and a curse, but it does make it possible to just put problems out there for consideration[0]. These sometimes go unanswered though, which means that the aforementioned standup becomes a backup.
I've been part of so many lean/agile teams that all do things slightly different. The highest preforming of those were the ones where the trust was the highest. Great teams become "a rising tide lifts all boats"[1].
I hope you don't see this (and the previous post) as an attack. It's near on impossible from a distance to really see. It felt like a red flag but that's two lines of text on a semi-anonymous message board.
[0]: draft PRs also fall into this category. Though again, devs have to find time to read them.
[1]: https://en.wikipedia.org/wiki/A_rising_tide_lifts_all_boats
Each of the loops is about shortening the cycle before you discover problems. These are seen through the lens of traditional waterfall software development. The problems vary in nature, from technical blockers and dependencies, to unrealistic deadlines and expectations, to not building what the customer wants (why we involve the customer early and do showcases).
In some ways the more mature your team becomes the more you can move past some of the rules. The 'standup' was designed to avoid the meeting becoming overly long, everyone would become foot sore. Once you understand and embrace making the meeting not turn into an hour long (or even 30 min long) meeting, the standing itself becomes less important (which is good because remote teams make this harder).
Similarly, there are even shorter cycles of being able to remove blockers now. Granted Slack team channels can be a blessing and a curse, but it does make it possible to just put problems out there for consideration[0]. These sometimes go unanswered though, which means that the aforementioned standup becomes a backup.
I've been part of so many lean/agile teams that all do things slightly different. The highest preforming of those were the ones where the trust was the highest. Great teams become "a rising tide lifts all boats"[1].
I hope you don't see this (and the previous post) as an attack. It's near on impossible from a distance to really see. It felt like a red flag but that's two lines of text on a semi-anonymous message board.
[0]: draft PRs also fall into this category. Though again, devs have to find time to read them.
[1]: https://en.wikipedia.org/wiki/A_rising_tide_lifts_all_boats
> As an EM, I use documented standups to keep track of how long and when people work on tasks.
:(
:(
I'm an EM as well and this is horrible, both from a personnel management standpoint but also just from the "understanding what the standup is for" standpoint.
You should be using standups to hear what your teams' blockers are, then spend the rest of the day getting rid of those blockers.
You should be using standups to hear what your teams' blockers are, then spend the rest of the day getting rid of those blockers.
We're actually coming at it from the other side -- we built it to take the pain out of standup and encourage more meaningful communication. It's definitely not designed as a people management tool.
documented stand-ups is a real red flag for me. You're forcing everyone on the team to participate in your in=person, synchronous, verbal task tracking system. It also sounds like you're making important career decisions based on the single dimension of "how many daily tasks are you crushing?". How can that work for anyone above a junior developer when the real value can't be measured in such small units? Just a guess, but I'd suspect your 1:1s (if you do them) are also msotly status updates.
I'd suggest you focus your stand-ups on blockers more than what did everyone accomplish, then review work async on your time. If it's not getting done yet no blockers are raised, that's something to investigate.
I'd suggest you focus your stand-ups on blockers more than what did everyone accomplish, then review work async on your time. If it's not getting done yet no blockers are raised, that's something to investigate.
Can I ask which company you work for? I want to be sure I never work for them.
When they say "people don't quit jobs, they quit managers"... pretty sure they mean you. God, that's toxic, and I'm so sad you're in our industry.
When they say "people don't quit jobs, they quit managers"... pretty sure they mean you. God, that's toxic, and I'm so sad you're in our industry.
Doesn't sound fun at all. I wonder what the employee attrition level is.
Maybe everyone is happy with this (or don't question it), I certainly wouldn't be. :shrug:
Unless it's not clear, remember people leave employment because of bosses rather than the company.
Maybe everyone is happy with this (or don't question it), I certainly wouldn't be. :shrug:
Unless it's not clear, remember people leave employment because of bosses rather than the company.
I feel sad for your teams. I mean this with respect but you should consider management training.
This strategy is set by my manager.
The only feedback I am seeing in this post is how standup should be used to report blocks. I encourage my team to message me when they have questions and not to wait until a sync meeting to report issues. We rarely discuss blockers because those are address in 1:1 or project focused meetings.
The only feedback I am seeing in this post is how standup should be used to report blocks. I encourage my team to message me when they have questions and not to wait until a sync meeting to report issues. We rarely discuss blockers because those are address in 1:1 or project focused meetings.
It's not async vs sync thing, it's that you're perverting stand-up from a tedious but low-stakes collaborative process (hey, what's everyone working on, who can help me with this quick problem...) to a grueling and ruthless micromanagement process that gives you false metrics to judge your employees by. It's a sign that you don't really care about your people or your team or their morale and just want to find easy numbers to evaluate people by, the engineering equivalent of "you're fired because you clocked in three minutes late four times this year". It's totally irrelevant to the job at hand...
Yeesh, it scares me that there are people like you who actually think this is a good management style. It's not even a management style, it's just petty sadism. Please seriously consider another career, this is not good for anyone on your team. Sorry to be so harsh, but god damn, this is one of the most braindead, heartbreaking, soulsucking posts I've ever seen on HN. Your team deserves a better manager than you.
Yeesh, it scares me that there are people like you who actually think this is a good management style. It's not even a management style, it's just petty sadism. Please seriously consider another career, this is not good for anyone on your team. Sorry to be so harsh, but god damn, this is one of the most braindead, heartbreaking, soulsucking posts I've ever seen on HN. Your team deserves a better manager than you.
Why would blockers wait for 1:1s and project meetings? Hopefully those are happening less frequently and should be addressed sooner.
But the in another of your replies you said you want people to contact you directly when there is a blocker rather than wait until the following standup? Those statements seem contradictory.
It sounds like you prefer to micromanage rather than really being Agile and allowing developer autonomy. This approach just frustrates good developers who want to learn enough about the business and the team that they can go directly to the source rather than having a micromanager as a go between too continually slow down the team.
But the in another of your replies you said you want people to contact you directly when there is a blocker rather than wait until the following standup? Those statements seem contradictory.
It sounds like you prefer to micromanage rather than really being Agile and allowing developer autonomy. This approach just frustrates good developers who want to learn enough about the business and the team that they can go directly to the source rather than having a micromanager as a go between too continually slow down the team.
Tried similar tools and ad-hoc processes during the pandemic. None worked as effectively as turning your camera's on and walking the board for 15 minutes. In fact, the chance of miscommunication increased when we introduced tooling like this.
Though agile has been bastardized and gotten a bad rep, it's core values of "Individuals and interactions over processes and tools" and principles like "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation" I still believe are quite valuable.
The time where these tools did add value when there was a time difference and asynchronous communication was unavoidable. I had a project a few years back where I was leading 15 teams in Ukraine. It helped there.
Though agile has been bastardized and gotten a bad rep, it's core values of "Individuals and interactions over processes and tools" and principles like "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation" I still believe are quite valuable.
The time where these tools did add value when there was a time difference and asynchronous communication was unavoidable. I had a project a few years back where I was leading 15 teams in Ukraine. It helped there.
I agree with you there. We did email-based stand-ups for a while and ditched it. It devolved into a mechanical habit of "everything is going great" type answers that nobody payed attention to..
The async aspect of it is convenient, but for me as a team lead, often times the standup is also an opportunity to ask follow up questions, to see if stories are on track, or to determine if somebody would benefit from pairing for the day. These things become increasingly important if you have an uneven balance of dev experience or domain knowledge within the team.
The async aspect of it is convenient, but for me as a team lead, often times the standup is also an opportunity to ask follow up questions, to see if stories are on track, or to determine if somebody would benefit from pairing for the day. These things become increasingly important if you have an uneven balance of dev experience or domain knowledge within the team.
To add, the stand-up loses its value if it becomes rote; people will tune out or wait for their turn to speak.
One trick we're using is that the order is always random, and whoever's turn it is gets to pick who is next. Ideally you pick the one who is not paying attention.
One trick we're using is that the order is always random, and whoever's turn it is gets to pick who is next. Ideally you pick the one who is not paying attention.
Yeah, totally agree on this. Needs to stay fresh. Curious if you've seen other ways of keeping people engaged.
People will stay engaged if standups are valuable.
If enough people are having trouble paying attention that it's becoming a problem, your standups suck. Your team may not need them (they may be communicating just fine without them) or may need them to be run differently. You may have too many people in them, implicit or explicit expectations of saying stuff just to have something to say (which contributes to people losing interest and tuning out), you may have multiple barely- or not-at-all connected teams in the same standup (I've seen this! And of course every member of one team tunes completely out when someone from another team is talking) or any number of other problems. Or, again, your team may just not need daily standups because they communicate fine without them.
If enough people are having trouble paying attention that it's becoming a problem, your standups suck. Your team may not need them (they may be communicating just fine without them) or may need them to be run differently. You may have too many people in them, implicit or explicit expectations of saying stuff just to have something to say (which contributes to people losing interest and tuning out), you may have multiple barely- or not-at-all connected teams in the same standup (I've seen this! And of course every member of one team tunes completely out when someone from another team is talking) or any number of other problems. Or, again, your team may just not need daily standups because they communicate fine without them.
Haha i bet people hate the person that introduced it. However if you use a randomizer it might be ok.
Yea, same here both as a manager and an IC. I definitely see the value with async stand-ups. A daily slack reminder just doesn't cut it there for most teams. But if you have a time where everyone can meet for 15 minutes then just talking for 10-15 minutes (my team has 30 minutes blocked off but we rarely hit that unless there's some kind of more in-depth discussion that arises) is invaluable.
We support both live meetings and async syncs and allow teams to go back and forth between the two formats as needed while maintaining context from one day to the next
We've also tried various tools in the past which didn't really to the trick which is why we wanted to build something different that's integrated into the Zoom/Meet meeting and streamlines the meeting. Really curious to hear how Spinach.io worked for you if you're up to giving it a shot :)
Is this what agile/scrum is now? I feel burned out just reading it.
IMHO the 'standup' (keep them on their toes!) was always suspect if it was just a PM 'what have you done lately' meeting.
Progress can be reported asynchronously.
IMHO the point of having the team together daily is to raise exceptions/problems/blockers/whatever to the rest of the team, and perhaps co-ordinate the rest of the day.
IMHO the 'standup' (keep them on their toes!) was always suspect if it was just a PM 'what have you done lately' meeting.
Progress can be reported asynchronously.
IMHO the point of having the team together daily is to raise exceptions/problems/blockers/whatever to the rest of the team, and perhaps co-ordinate the rest of the day.
> Progress can be reported asynchronously.
Progress shouldn't even need to be reported; it should be obvious from the board, when it comes to communicating upwards. And IMO that's only relevant to the scrum master (who needs to ensure everything is going smoothly) and maybe the product owner; above the PO level, if they care about progress during a sprint they're paid too much. The level above PO should only care about sprint results, maybe.
Progress shouldn't even need to be reported; it should be obvious from the board, when it comes to communicating upwards. And IMO that's only relevant to the scrum master (who needs to ensure everything is going smoothly) and maybe the product owner; above the PO level, if they care about progress during a sprint they're paid too much. The level above PO should only care about sprint results, maybe.
I've had better success with face-to-face standups. In my experience, "progress should be obvious from the board" and async "standups" have been far less effective than actual standups. Lots of engineers are introverted and hate writing; a good product manager can extract context and blockers via voice (without making it feel like a pop quiz or a blame game) that a shy engineer might be hesitant to broadcast in writing in Slack, and other engineers/designers are _far_ more likely to hear the person when they're speaking than they are to read their boring Slack update (or, even more unlikely, read through that other person's tickets). My rule of thumb has been to keep standups to 7 minutes max, have the other 7 minutes after for any breakout that's needed, and schedule something else if there are still thorny issues to go through.
If there are issues with standups bloating to 30 minutes (???), that feels like a process/weak-PM problem, not a tooling problem.
If there are issues with standups bloating to 30 minutes (???), that feels like a process/weak-PM problem, not a tooling problem.
>> Lots of engineers are introverted and hate writing
I think it’s the time that introverts start going to a therapist to get it fixed, because they’re slowly getting to the top of my most hated bunch of people with this expectation that the whole world need to be put in a passive and painful misery to accommodate them
I think it’s the time that introverts start going to a therapist to get it fixed, because they’re slowly getting to the top of my most hated bunch of people with this expectation that the whole world need to be put in a passive and painful misery to accommodate them
"manager can extract context and blockers via voice"
lol. Which agile principle is this?
lol. Which agile principle is this?
> The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
'convey', not 'extract'.
It's a quite different stance. The PM does not 'run' this meeting. That's just a traditional project manager daily status meeting, the inverse of a 'scrum' where the team themselves huddle together and discuss their problems, and what they're going to do next, etc.
It's a quite different stance. The PM does not 'run' this meeting. That's just a traditional project manager daily status meeting, the inverse of a 'scrum' where the team themselves huddle together and discuss their problems, and what they're going to do next, etc.
[deleted]
Individuals and interactions over processes and tools.
Yeah progress is an output from your tools imo. We have a single channel in our Slack that has GitHub, Linear, and Notion events piped into it. You’d think it’d become a mess, but we encourage people to add keywords to Slack so they get notified when things they want/need to read pop up. So far it’s worked great for a small team (5 people).
We still do checkins, but that hooks into Linear as well, so creating a checkin is as easy as clicking a button.
We still do checkins, but that hooks into Linear as well, so creating a checkin is as easy as clicking a button.
100% this.
I don't mind status meetings but call them what they are: a status meeting. It is not a standup.
Standups were about alignment and movement so you didn't get blocked trying to communicate through a broker like your manager.
They are completely abused and probably always will be.
I don't mind status meetings but call them what they are: a status meeting. It is not a standup.
Standups were about alignment and movement so you didn't get blocked trying to communicate through a broker like your manager.
They are completely abused and probably always will be.
Totally agree on the point of having dailies. For days where there's no blockers or other items to discuss we support async as well. The idea is to allow a more dynamic meeting series which is live when needed and async on days when the team only needs to share status.
Yes, standups are for identifying blockers, issues, etc. or to request help. Reporting on progress is minor and takes very little time and could be done via slack.
I have to pass after two minutes of looking. I'm in a small, but mature company of ~250 employees. We're on Office365 and use Okta for SSO.
I see a MS Teams icon on the front page, click pricing, don't see MS teams in the integrations list. Then I see SSO under Enterprise, call us for pricing. I'm out.
I have to have SSO for a few reasons. 1) It's a common sense security measure and greatly reduces employee onboard/offboarding efforts. 2) I need to be able to prove to my site reliability insurance company that I have MFA virtually everywhere. 3) Employees will no longer readily adopt tools that require them to setup another login.
I'm 'stuck' on MS Teams because it's extremely difficult to justify spending on Slack when I've already paid for Teams. We are definitely not what I would call a Microsoft shop. I'm hoping the EU solves this for the world.
I see a MS Teams icon on the front page, click pricing, don't see MS teams in the integrations list. Then I see SSO under Enterprise, call us for pricing. I'm out.
I have to have SSO for a few reasons. 1) It's a common sense security measure and greatly reduces employee onboard/offboarding efforts. 2) I need to be able to prove to my site reliability insurance company that I have MFA virtually everywhere. 3) Employees will no longer readily adopt tools that require them to setup another login.
I'm 'stuck' on MS Teams because it's extremely difficult to justify spending on Slack when I've already paid for Teams. We are definitely not what I would call a Microsoft shop. I'm hoping the EU solves this for the world.
You may like this:
https://sso.tax/
https://sso.tax/
Thanks for the feedback
We plan to integrate with Teams and for now teams running their standups on Teams use our web app.
We do support SSO, just need to set it up per customer which is why we ask folks to reach out for the enterprise tier.
I didn't intend to come off as highly critical, but I think the tone followed my arc of interest and disappointment.
SSO shouldn't be a manual setup, as many SaaS products offer self service SAML or OIDC configuration. I heard the SSO tax is often used as a filter for larger companies that will drag you through lengthy security assessments as part of their vendor process. That makes sense, however, these days, SSO is hardly limited to larger organizations.
I see you offer Google sign-in at the lower tier, and the same workaround could be available for Microsoft. If you offered sign in with Microsoft, I can use my Okta SSO, without your involvement, because it is already configured within my Microsoft organization. I would imagine Google + Microsoft would cover the vast majority of organizations.
https://learn.microsoft.com/en-us/azure/active-directory/dev...
SSO shouldn't be a manual setup, as many SaaS products offer self service SAML or OIDC configuration. I heard the SSO tax is often used as a filter for larger companies that will drag you through lengthy security assessments as part of their vendor process. That makes sense, however, these days, SSO is hardly limited to larger organizations.
I see you offer Google sign-in at the lower tier, and the same workaround could be available for Microsoft. If you offered sign in with Microsoft, I can use my Okta SSO, without your involvement, because it is already configured within my Microsoft organization. I would imagine Google + Microsoft would cover the vast majority of organizations.
https://learn.microsoft.com/en-us/azure/active-directory/dev...
As a user, I also hate non-transparent pricing and call for sales. I also dont buy many things if I can't see transparent pricing.
BUT as a 2x SAAS business I found that this absolutely worked. Make them call. I hate that it works. I have tried irrationally hard to make transparent pricing work for larger customers, and failed. I don't think it's a law of nature, and in some cases it can work. But generally, talk to larger customers.
I think SSO (particularly something like Okta) means they will be a client with whom calling and talking to will be a net positive for you and the business. This is basically the single most obvious feature to segment off.
BUT as a 2x SAAS business I found that this absolutely worked. Make them call. I hate that it works. I have tried irrationally hard to make transparent pricing work for larger customers, and failed. I don't think it's a law of nature, and in some cases it can work. But generally, talk to larger customers.
I think SSO (particularly something like Okta) means they will be a client with whom calling and talking to will be a net positive for you and the business. This is basically the single most obvious feature to segment off.
> BUT as a 2x SAAS business I found that this absolutely worked. Make them call. I hate that it works. I have tried irrationally hard to make transparent pricing work for larger customers, and failed. I don't think it's a law of nature, and in some cases it can work. But generally, talk to larger customers.
I think some managers like the process. It's a good excuse to kill 1-4 hours emailing back and forth, scheduling calls, having calls, et c. Low-stress, even enjoyable, still counts as Real Work. Gives you something to brag about when angling for raises or promotions, or when interviewing, if you get a discount (even if ~everyone gets the same "discount"). Plus I think some of them just aren't comfortable signing up for something for business purposes when they haven't spoken with a real person on the other end. Gives them some kind of reassurance or confidence.
I think some managers like the process. It's a good excuse to kill 1-4 hours emailing back and forth, scheduling calls, having calls, et c. Low-stress, even enjoyable, still counts as Real Work. Gives you something to brag about when angling for raises or promotions, or when interviewing, if you get a discount (even if ~everyone gets the same "discount"). Plus I think some of them just aren't comfortable signing up for something for business purposes when they haven't spoken with a real person on the other end. Gives them some kind of reassurance or confidence.
Thanks for this
And of course anyone can try it out first with no need to talk to us
I really like the idea. It's easy to tell people what they're supposed to do, but people need help to stick to the plan. Automated guiderails are a great way to smoothly enforce a process.
Some things I'd suggest based on the demo:
- A splash page right before the stand-up begins to remind people to resist the urge to explain in detail what they did; two sentences per item is more than enough. If a question can't be answered in two sentences, it should immediately become a Team Topic.
- A big countdown timer that gets more red and shakes as time goes on, both for each individual person, and for how long the whole standup is taking.
- Some buttons to create a Jira item, Zoom meeting, etc from a Team Topic, and share the link to it.
- A help screen with the most important takeaways about stand-ups, like the fact that it should not be run by a product owner or manager, that it is to serve the sprint goal, etc.
Some things I'd suggest based on the demo:
- A splash page right before the stand-up begins to remind people to resist the urge to explain in detail what they did; two sentences per item is more than enough. If a question can't be answered in two sentences, it should immediately become a Team Topic.
- A big countdown timer that gets more red and shakes as time goes on, both for each individual person, and for how long the whole standup is taking.
- Some buttons to create a Jira item, Zoom meeting, etc from a Team Topic, and share the link to it.
- A help screen with the most important takeaways about stand-ups, like the fact that it should not be run by a product owner or manager, that it is to serve the sprint goal, etc.
This is great, thanks!
We actually experimented with a countdown timer but folks found it too stressful :)
Hm, from a purely agile standpoint: This seems to reduce daily stand-ups to status report meetings (and then, why have a stand-up at all?). Does a stand-up that is over in 5 minutes (and has 10-15 minutes of prep time) really bring value to anyone but a team lead?
I can't speak for everybody. But for me: yes, a 5 minute standup is valuable. It's much, much better than a 30 minute standup IMO.
Most people can pay attention for 5 minutes. So if the meeting's only 5 minutes, most people will actually listen and engage. Followups can happen afterwards.
If the standup is 30 minutes though, most people are probably going to tune out and start doing other stuff. It becomes an "ignore the meeting while I wait for my turn" kind of thing. A waste of everybody's time.
I don't want to watch the team-lead click a Jira board for 30 minutes, and I'm guaranteed to get bored and tune out. And once that attention's been lost, the standup loses a lot of utility.
Most people can pay attention for 5 minutes. So if the meeting's only 5 minutes, most people will actually listen and engage. Followups can happen afterwards.
If the standup is 30 minutes though, most people are probably going to tune out and start doing other stuff. It becomes an "ignore the meeting while I wait for my turn" kind of thing. A waste of everybody's time.
I don't want to watch the team-lead click a Jira board for 30 minutes, and I'm guaranteed to get bored and tune out. And once that attention's been lost, the standup loses a lot of utility.
Yesterday, today, blockers… already feels like a relic from the past.
Here’s something I just started thinking about: what if you took out the Yesterday and Today bits from the stand up and just made it about Blockers+Issues… ?
The Yesterday and Today bits seem to unavoidably bias stand ups into status meetings.
The Yesterday and Today bits seem to unavoidably bias stand ups into status meetings.
I wish more standups would bring back that format, honestly. It's a lot more interesting than the "watch somebody use Jira" format that seems to be more common today.
We're working on enabling dynamic prompts so teams can customize. What's your standup format?
Something like…
1. Bit of banter. 2. Talk about aging cards/blockers 3. Talk about the cards on the board, from right to left. Since further right is most important. 3. Share things with each other that came up since last standup that you think is worth sharing. 4. Ask for help. Offer help. How can I help you get that card over the line? 5. Final bants.
1. Bit of banter. 2. Talk about aging cards/blockers 3. Talk about the cards on the board, from right to left. Since further right is most important. 3. Share things with each other that came up since last standup that you think is worth sharing. 4. Ask for help. Offer help. How can I help you get that card over the line? 5. Final bants.
But why talk about the actual work cards when you can pay the cost of a full office suite to talk about a completely different set of cards?
// Sounds like you're doing it right. Carry on. :-)
// Sounds like you're doing it right. Carry on. :-)
I do like to know where we stand, but in an ideal scrum team everyone's constantly aware of what is going on and catching each other up is no longer necessary.
But that's idealized circumstances; during the Panny-D and people working remotely, it turns out people prefer to just keep their head down all day and maybe only check in at the stand-up. That is also fine, I guess.
But that's idealized circumstances; during the Panny-D and people working remotely, it turns out people prefer to just keep their head down all day and maybe only check in at the stand-up. That is also fine, I guess.
Great question
Our goal is to make standups more effective, not necessarily faster. We found that by adding more structure and allowing people to easily prepare, the result is a more effective meeting that in many cases is also faster.
The prep experience actually makes preparing really fast by leveraging your previous tasks/goals
Has anyone else noticed the number of comments (and upvotes) that are very likely fake/misleading? Many 1-karma accounts that I doubt made their first comment only because they love this product so much, and other founders/colleagues/cohort that are probably just friends.
I get this is the "growth hacking" mindset, but it really sucks. I wish this wasn't allowed on HN. This product clearly wouldn't be anywhere near the front page without this fake engagement.
I get this is the "growth hacking" mindset, but it really sucks. I wish this wasn't allowed on HN. This product clearly wouldn't be anywhere near the front page without this fake engagement.
"Launch HN" is a perk/benefit available to some YC-funded startups, so it's sort of "unfair by design".
https://news.ycombinator.com/yli.html
https://news.ycombinator.com/yli.html
I didn't know that fake engagement and alternate accounts are part of the perks. Makes YC looks really legit if companies can't even market themselves without shady tactics.
As soon as I see something like this it makes me want to run the other way and tell everyone I know to run the other way and never ever touch the product or company.
As soon as I see something like this it makes me want to run the other way and tell everyone I know to run the other way and never ever touch the product or company.
maybe /u/dang can take a look at it.
Looks fascinating.
The only concern I have pitching this to my company is security. There isn't a dedicated page (or even a blog) talking about security practices Spinach has taken into account with the platform.
The only thing I saw regarding security was a semi concerning mention in the Privacy Policy:
> Company takes reasonable steps to protect the Personal Data provided via the Services from loss, misuse, and unauthorized access, disclosure, alteration, or destruction. However, no Internet or email transmission is ever fully secure or error free. In particular, email sent to or from the Services may not be secure. Therefore, you should take special care in deciding what information you send to us via email. Please keep this in mind when disclosing any Personal Data to Company via the Internet.
All stand ups we run technically contain "Personal Data".
The only concern I have pitching this to my company is security. There isn't a dedicated page (or even a blog) talking about security practices Spinach has taken into account with the platform.
The only thing I saw regarding security was a semi concerning mention in the Privacy Policy:
> Company takes reasonable steps to protect the Personal Data provided via the Services from loss, misuse, and unauthorized access, disclosure, alteration, or destruction. However, no Internet or email transmission is ever fully secure or error free. In particular, email sent to or from the Services may not be secure. Therefore, you should take special care in deciding what information you send to us via email. Please keep this in mind when disclosing any Personal Data to Company via the Internet.
All stand ups we run technically contain "Personal Data".
Thanks for raising this
Security is a top priority for us. We lean on OWASP and best practices to ensure all data collected through the app is secure. The app has passed diligent security reviews at many companies including big public companies and fintechs.
Great callout on adding more info on the website, will do
Congrants on launching, but I have to be negative here: the idea that a standup is a time when everyone cycles through and gives a status update IS the problem with standup.
This is like Jira for standups (and I don't mean that in a good way)
This is like Jira for standups (and I don't mean that in a good way)
As I see it, this doesn't reduce the the overhead at all but just increases it by introducing a third party tool to the mix and requiring everyone to engage with it.
Sure, it might help if your daily standup is already a mess, but overall just by fixing the process by having a single person running the daily and making sure no-one starts to ramble too much solves the problem of excess time spent in dailies. Assuming you want to keep them.
I could of course be wrong and if I am, best of the luck for you.
Sure, it might help if your daily standup is already a mess, but overall just by fixing the process by having a single person running the daily and making sure no-one starts to ramble too much solves the problem of excess time spent in dailies. Assuming you want to keep them.
I could of course be wrong and if I am, best of the luck for you.
In don’t get the problem but I think that is because I have worked at more traditionally managed (less startuppy?) companies that wouldn’t let standups drag out. A simple fix for long standups is “no tech details”. If remembering yesterday takes time then don’t ask about yesterday just catch up per task on the board. I think a good blog post about how to run a standup might be the MVP for this. If no one wants to run it maybe ditch standups? Standups are useful as a forcing function. Before they were popular you had the “team leader doing the
rounds” which may or may not be better but is also a good check
in. The benefit is catching people getting lost, stuck or working on something they don’t need to.
Seems very cool. Honestly, the biggest selling point for me would be the historic data.
Having a place to check in and to look at from time to time would be great. It would allow to evaluate progress, direction, etc.
Looking for something like this for some time!
Thanks for the feedback, would love to hear your thoughts after giving it a try!
My company is a small business but we require Okta SSO for every app. What is the reasoning behind SSO being an enterprise feature (aside from the fact that most SaaS apps do that)?
This is a blocker to us using many SaaS products because the enterprise tier is always very expensive. I think TeamRetro got it right with SAML support at the first paid tier, we started with a smaller plan and stepped it up as we grew.
So, perhaps you might consider providing SCIM support at the enterprise tier and SAML support at the business tier? I feel this is a nice compromise between security and administration hassle.
This is a blocker to us using many SaaS products because the enterprise tier is always very expensive. I think TeamRetro got it right with SAML support at the first paid tier, we started with a smaller plan and stepped it up as we grew.
So, perhaps you might consider providing SCIM support at the enterprise tier and SAML support at the business tier? I feel this is a nice compromise between security and administration hassle.
Great suggestion, SAML SSO should really become commodity and made available to all tiers. Enterprise tiers are clearly dictated RFP/Security Questionnaires, there's no bigger admin hassle than that.
The simple reason is that it requires setup on our side. Do you see SSO as a blocker to trying? What we've seen teams do in most cases is use the free tier with email signup and try it out for a bit, once they like it and want to upgrade they contact us to upgrade and set up SSO.
You could make SSO setup self-served. Happy to help you simplify your SSO implementation so you can make it available across all tiers, open-source on an Apache 2.0 license - https://github.com/boxyhq/jackson
It's not a blocker to trying but I equate "enterprise" with $expensive so it does certainly put me off, as I'd need to enter into negotiations that I don't really have time for in order to comply with our policies. I also find often when I begin this conversation there is a set price that is inflexible and a minimum spend way in excess of what we need, and I usually end up just looking at another product.
I appreciate you have technical limitations at present but consider adding a SSO administration UI to your backlog - you can certainly set it up so it's all managed in the software. It is a bit more of a technical problem when it goes wrong, so that justifies an increased price tag for the support. I don't expect anything for free but I don't want to have to talk to someone to get it.
I appreciate you have technical limitations at present but consider adding a SSO administration UI to your backlog - you can certainly set it up so it's all managed in the software. It is a bit more of a technical problem when it goes wrong, so that justifies an increased price tag for the support. I don't expect anything for free but I don't want to have to talk to someone to get it.
> Do you see SSO as a blocker to trying?
Yes, absolutely.
And if you have setup on your side, you're doing it wrong.
There should be two fields for the customer to paste or an auto-config file, and a cert. Even without registering a preconfigured app in the IdP directory, its a no brainer.
Yes, absolutely.
And if you have setup on your side, you're doing it wrong.
There should be two fields for the customer to paste or an auto-config file, and a cert. Even without registering a preconfigured app in the IdP directory, its a no brainer.
Congrats on launching. No doubt a lot of hard work led to this point and I have tremendous respect for the resolve that it takes to go from idea to a launched product. Sharing some feedback:
- I noticed in the demo video that engineers are effectively just repeating what they previously wrote in the tool before the meeting. So where is the time saving? If anything I am seeing time added not saved.
- One of the benefits (for me) of walking through the board during standup, is that I ensure all tickets exist and are properly updated to reflect current status. This reinforces the message that Jira (in our case) is the source of truth. My concern is that introducing another tool risks muddying the waters concerning where source of truth lays.
- Standups usually result in parking lot items for a subset of the team, but seldom is the entire team needed. I think you could improve "team topics" by changing it to "parking lot" and allowing people to +1 their involvement. From this new conversations (chat or video) could later spin off to close out a parking lot item.
Best of luck with the future of your product. I have no doubt that some teams will find it useful.
- I noticed in the demo video that engineers are effectively just repeating what they previously wrote in the tool before the meeting. So where is the time saving? If anything I am seeing time added not saved.
- One of the benefits (for me) of walking through the board during standup, is that I ensure all tickets exist and are properly updated to reflect current status. This reinforces the message that Jira (in our case) is the source of truth. My concern is that introducing another tool risks muddying the waters concerning where source of truth lays.
- Standups usually result in parking lot items for a subset of the team, but seldom is the entire team needed. I think you could improve "team topics" by changing it to "parking lot" and allowing people to +1 their involvement. From this new conversations (chat or video) could later spin off to close out a parking lot item.
Best of luck with the future of your product. I have no doubt that some teams will find it useful.
We have been using https://www.dailybot.com (another YC company) for the last 2-3 years. That one is great, too!
Slackbots like DailyBot are great for fully async standups. We've found that many topics a better handled on a live conversation, so support both live and async use cases as well as alternating between live and async
For me, the reasons I tried to push for doing our daily update on Slack (back in 2016 I think) were:
1. Enable asynchronous work (by that I mean that we should both be avoiding a context switch at a fixed time of the day + not discriminate anyone working from home).
2. In every team that I've been, I've found that during traditional "standups" I found that most attendant would think about their own update rather than listening to the current speaker, which totally defeats the purpose of this meeting (which I guess should be to sync as a team).
And so in the video demo, it seems very redundant to see each speaker describe what they already put in writing. Instead, if a face-to-face meeting is to be held in addition to a textual update, I would have expected the team to discuss any question they might have for their team mates which rises from the update they read _prior_ to the meeting.
P.S. In the video demo, the cut from Heather's update to the summary of what we've seen was kind of blatant, and I can only guess that any women who might watch this demo and have experienced being disregarded on meetings by a group of men, might feel uncomfortable. I'm not saying this is in any way represent the culture in your company, but having seen this in real life (and despite myself identifying as a man) I felt like it really stood out.
1. Enable asynchronous work (by that I mean that we should both be avoiding a context switch at a fixed time of the day + not discriminate anyone working from home).
2. In every team that I've been, I've found that during traditional "standups" I found that most attendant would think about their own update rather than listening to the current speaker, which totally defeats the purpose of this meeting (which I guess should be to sync as a team).
And so in the video demo, it seems very redundant to see each speaker describe what they already put in writing. Instead, if a face-to-face meeting is to be held in addition to a textual update, I would have expected the team to discuss any question they might have for their team mates which rises from the update they read _prior_ to the meeting.
P.S. In the video demo, the cut from Heather's update to the summary of what we've seen was kind of blatant, and I can only guess that any women who might watch this demo and have experienced being disregarded on meetings by a group of men, might feel uncomfortable. I'm not saying this is in any way represent the culture in your company, but having seen this in real life (and despite myself identifying as a man) I felt like it really stood out.
Or we could just do our work and not deal with a daily standup. Can we get an App for that please? or maybe a JIRA replacement? or AI that can go instead of ME?
I can sell you a tool for avoiding standups. It is called an espresso machine. Make sure you are using it at 9:30am or whenever the standup is.
I actually did this and took diy baristra training to be the only one on my floor to make good espresso shots. Its a good way to vanish for 30mins as espresso making time.
I can also offer one: "I have a conflict at ${standup time} and will not be able to attend"
That's exactly what we're optimizing for - reduce the coordination overhead and allow builders to focus on building
We've been using Spinach for months and have found it really useful for our team. Our startup's team is young and I feel like Spinach helps us sit down and be thoughtful about our work (tasks completed yesterday, tasks we're working on today, and what is blocking us.)
I like that we can use it live during standup, but also have developers who can't make standup report asynchronously. After the meeting, developers can read through the summary and see if they missed anything.
As a founder/developer, I think it's great as we don't have an official PM and we manage ourselves.
My biggest feature request would be an Asana sync that allows us to see what tasks we completed yesterday and add them to the completed section.
I like that we can use it live during standup, but also have developers who can't make standup report asynchronously. After the meeting, developers can read through the summary and see if they missed anything.
As a founder/developer, I think it's great as we don't have an official PM and we manage ourselves.
My biggest feature request would be an Asana sync that allows us to see what tasks we completed yesterday and add them to the completed section.
> we charge $6 per month per user
For comparison, this is the same price as O365 (Microsoft Office) or Google Workspaces.
If you can't profitably grow this tool for, say, $1.00/user, you may want to rethink your approach. Realistically a stack to do this should cost almost nothing per user/month to create or maintain.
For comparison, this is the same price as O365 (Microsoft Office) or Google Workspaces.
If you can't profitably grow this tool for, say, $1.00/user, you may want to rethink your approach. Realistically a stack to do this should cost almost nothing per user/month to create or maintain.
I have to agree. As a tool that adds a little more value than a slack extension, I can't justify 6$ per user. As another comparison, Miro is 8$ per user. Heck, Slack is 7$. On the other hand, this is free for a single team.
"crush your daily standup" - I am not sure that will be appealing to audiences outside America (assuming the target is dev teams worthwhile).
If I knew the first few mins of a standup were going to be a round table like "what's your all time fav book?", I would just join late.
If I knew the first few mins of a standup were going to be a round table like "what's your all time fav book?", I would just join late.
Same here, this kind of "go-getter, overachiever" tone of voice in marketing seems a bit odd to the European audience.
Before I saw this comment by the parent, my impression was that the action-packed verbs (such as crushing) indicate that the subject mater is challenging and involves hardship. This attitude seems to come from a very stress-prone perspective, which, again, is a bit alien over here.
Before I saw this comment by the parent, my impression was that the action-packed verbs (such as crushing) indicate that the subject mater is challenging and involves hardship. This attitude seems to come from a very stress-prone perspective, which, again, is a bit alien over here.
Omg why can’t we just get rid of the whole agile crap and communicate when there are meaningful things to be communicated, since agile took place I’ve been hating software development more and more, it’s just an endless flow of stuff you need to hear and don’t give a shit about
God I'm so happy that our standups are simple, laid back and quick that we have never even consider using something like this.
Google Meet, <10 minutes, bam. One meeting per day, unless I'm getting direct feedback from customers or triaging bugs.
Google Meet, <10 minutes, bam. One meeting per day, unless I'm getting direct feedback from customers or triaging bugs.
Congrats on the launch! As a user of dozens of Slack apps, and a lover of async work, I encourage as much competition in this space as possible.
I don’t think my company would be a fit for this, as we’ve successfully killed all internal meetings, including stand ups. We do daily checkins, but that looks like a secondary function of spinach, and one solved by other Slack apps.
I’m unsure if you plan on getting into the async space and providing more tooling around that, but if you do, I’d be all ears. There are a lot of opportunities to improve async workflows through tools.
Regardless, best of luck!
I don’t think my company would be a fit for this, as we’ve successfully killed all internal meetings, including stand ups. We do daily checkins, but that looks like a secondary function of spinach, and one solved by other Slack apps.
I’m unsure if you plan on getting into the async space and providing more tooling around that, but if you do, I’d be all ears. There are a lot of opportunities to improve async workflows through tools.
Regardless, best of luck!
We already support async! Please give it a try and tell us what you think
> We’re starting by taking on the daily status meeting, a.k.a. standups.
Are you able to share other ways you're setting out to reduce the overhead dev projects, beyond daily-status updates? It sounds like you've got the integration part nailed, which is really cool, but the problem space you're tackling first (daily standups) sounds like it could be resolved with automated Slack bots / a Google Doc (albeit more clumsily). As the tip of the iceberg in a much larger meeting-optimization system though, this might make perfect sense.
Are you able to share other ways you're setting out to reduce the overhead dev projects, beyond daily-status updates? It sounds like you've got the integration part nailed, which is really cool, but the problem space you're tackling first (daily standups) sounds like it could be resolved with automated Slack bots / a Google Doc (albeit more clumsily). As the tip of the iceberg in a much larger meeting-optimization system though, this might make perfect sense.
We want to facilitate and reduce the coordination overhead across project/cycle. After the daily standup we're planning to help teams with planning/prioritization at the start of a cycle
Appears you’re using the standard format of “yesterday, today, blockers” — which on my part is maybe me trying to over optimize, but never understood the format since I assume if someone said the were going to do something that it got done unless there was a blocker; meaning to me saying what you did yesterday feels like it’s repetitive. Mentioned this to number of notable scrum thought leaders and normally get to responses: (1) just do it, or (2) agile is anything you want it to be.
(Curious if the OP has an comments on this.)
(Curious if the OP has an comments on this.)
While we're seeing this is the most common format it doesn't work for everyone and some teams want to have the flexibility to configure the prompts. This is a feature we're currently building and will soon release!
The defaults are among the indicators of a poor 'ceremony based' dev culture.
Works great for cargo cult Agile(tm) if that's your market.
Works great for cargo cult Agile(tm) if that's your market.
It would be really great if team members / OP were highlighted in these Launch HN threads. It would really help understand the official nature of responses vs community discussion.
totally agree. I'm of the team!
[deleted]
[deleted]
Seems like treating the symptoms rather than the disease.
Get rid of dailies and status checks from stakeholders and you dont need this tool in the first place.
But if you can't then it's a nice little project to make ones life a bit less miserable.
Get rid of dailies and status checks from stakeholders and you dont need this tool in the first place.
But if you can't then it's a nice little project to make ones life a bit less miserable.
My main gripe with this, is that the tool focuses the standup on a per-person status update, instead of talking about the work that you need to complete as a team. This is a common anti-pattern and it needs to go.
Best daily standups are those that dont need tools. Just have a friendly chat about yesterday, today and any blocker. Have a coffee and hold them in a casual environment. No need for ceremony or “supervisors”.
Could you elaborate on the "Team Topics"?
During a check in, if there is a follow up question to dive deeper on, how does the flow for that work? I watched the demo video but wasnt able to catch it.
During a check in, if there is a follow up question to dive deeper on, how does the flow for that work? I watched the demo video but wasnt able to catch it.
Sounds like the typical "parking lot", where you just move long discussions to the end of the standup, and everyone who's not involved can leave.
If there are multiple parking lots, either you go through them quickly (if it's a series of questions affecting only a few team members), or you just break into breakout groups.
If there are multiple parking lots, either you go through them quickly (if it's a series of questions affecting only a few team members), or you just break into breakout groups.
> Each team member writes a brief check-in.
OK, but at that point, is standup not done? Why do you need another meeting, much less software to run it if everyone has already checked in?
OK, but at that point, is standup not done? Why do you need another meeting, much less software to run it if everyone has already checked in?
You say you're YC W22 - when did you apply and when did you get interviewed, and approved? I thought submissions were closed only recently.
We went through YC earlier this year, W22 was January-April of 2022
This is great. We faced similar challenges as our team grew.
Since our organization was already on MS Teams, we designated one person on each team to transcribe each standup into a channel on Teams.
The feedback I've seen on this thread about taking too much effort for a dev each day is odd to me. Just as it's not wise to dive head-first into code before understanding problem, I think spending 5-10 minutes planning out your day is cheap; I'm already paying it, I'll just paste that into Spinach.
The feedback I've seen on this thread about taking too much effort for a dev each day is odd to me. Just as it's not wise to dive head-first into code before understanding problem, I think spending 5-10 minutes planning out your day is cheap; I'm already paying it, I'll just paste that into Spinach.
Thanks for the feedback! Curious to hear your thoughts after trying it out
Better is just to not have them.
Why is this called "Spinach"? Is it a play off of Popeye the Sailor Man?
Nobody likes spinach but you eat it because it's good for you. Interpret that as you will for standups...
maybe a nice capresse salad?
I've been informed that capresse salad is not made with spinach. I retract my previous comment. Spinach with strawberries and a nice vinaigrette is pretty good.
We aim to create healthier work habit, Spinach is good for you :)
Congrats guys! Really great product and execution
Really well built stuff!! Nicely done guys.
Congrats on the launch, guys! A much needed product!
Manishimwe jcloude my app systemice
[deleted]
Congratulations on your launch. Great work! Hope to see you this weekend.
Thanks!
We'll be there!
Congrats on the launch. I've worked in environments with structured and unstructured standups. And the former is so much more impactful.
Exactly! and we've found that in most cases it's unstructured...
Thanks for the support
Congrats on the launch guys! I'm a big fan.
Great tool for businesses to optimise their time. Best business productivity tool that I know.
We use Spinach. You should too.
Not sure if the maintainers of the SSO Wall of Shame[0] read this, but by the pricing page[1] it would appear this qualifies.
[0] https://sso.tax/
[1] https://spinach.io/pricing
[0] https://sso.tax/
[1] https://spinach.io/pricing
I (Matan) am an engineer, and Josh and Yoav led design and product teams. One of the big pains we’ve all experienced is the massive overhead that goes on in dev projects: meetings, planning, goal setting, communication, project and task management—and on and on. All this is time consuming, slows you down, and can burn you out. It was already challenging in an office setting, but for us it amplified even further in remote work with back-to-back meetings and endless pings on Slack. If you’re like us, you want to spend more time building stuff and simplify the rest. With Spinach.io, we’re making tools to support that and to help projects run with far less overhead.
We’re starting by taking on the daily status meeting, a.k.a. standups. If you do 30 minute daily standups, you’re spending 120 hours a year—that’s 15 work days! Besides all that overhead, it’s a pain to make everyone wait around when all they want to do is get moving with actual work. We cut the overhead by bringing intention and structure to the process, making standups more organized, focused and productive.
Here’s how it works.
Before standup: Spinach makes prep easy in Slack. Each team member writes a brief check-in. Writing helps you plan your day and articulate that plan to the team. When the team is prepared, standup can be spent sharing meaningful context instead of watching someone try to remember what they did yesterday.
During standup: Spinach rotates through each person’s check-in, fast and efficiently. No screen sharing or “who wants to go next”. You see and hear each person’s check-in, and there’s a timer to keep it moving. If you have a question or idea, you add it to Team Topics and Spinach will bring it up at the end of standup, so the meeting doesn’t get derailed.
After standup: Spinach creates a summary and automatically posts it to Slack. This is a useful reference for the team and can be shared with stakeholders to cut back on status updates throughout the day.
Async friendly: On days when you need to miss standup, your check-in can still get shared with your team, and you can still read the summary so you don’t miss anything. If the whole team wants to skip the live meeting and do an async standup, that’s also supported. You can switch between live and async without losing any history or context.
There's a demo video here: https://www.youtube.com/watch?v=4bdimeouLDA.
We’re integrated both with Zoom (as one of the first apps in their marketplace) and Google Meet (as a Chrome extension), which means you can use Spinach.io inside of Zoom or Meet and don’t need to have another window or tab open. We also have a web app which can be used side-by-side with Zoom, Meet, Teams, Slack Huddles, Discord or any other meeting app. We’re integrated with Jira to pull in relevant tasks and context from your board, and Slack to enable async collaboration throughout the day.
For one team of up to 9 users the app is free forever, so anyone can easily try us out. For companies with multiple teams or 10+ users we charge $6 per month per user (with a free 30-day trial).
Our app is written in TypeScript using React, Express, Node.js, and Socket.io. The stack is hosted in AWS using Elastic Beanstalk, ElastiCache Redis, MongoDB, StepFunctions, Lambda, and EventBridge to name a few. Infrastructure is written as code using Serverless and AWS CDK.
The opportunity to reduce meeting overhead is bigger than we thought—we've already helped many teams cut their time spent in standups by 50%. At the same time, we’re still early and would love to hear what you think about what we’re building. We look forward to your comments and experiences, whether about daily standups or other points where tooling could help cut overhead. Thanks!