Launch HN: Spinach.io (YC W22) – Better daily standups
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, whe...
187 comments
[ 3.0 ms ] story [ 123 ms ] thread1. 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.
// Sounds like you're doing it right. Carry on. :-)
The Yesterday and Today bits seem to unavoidably bias stand ups into status meetings.
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.
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.
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".
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.
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.
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.
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.
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 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.
If there are issues with standups bloating to 30 minutes (???), that feels like a process/weak-PM problem, not a tooling problem.
lol. Which agile principle is this?
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.
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
We still do checkins, but that hooks into Linear as well, so creating a checkin is as easy as clicking a button.
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 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.
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.
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.
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...
https://sso.tax/
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.
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).
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?
:(
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/
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.
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.
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.
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 rest of your message about unblocking early seems to contradict your first statement of waiting until scrum to ask for help.
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
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.
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.
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.
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.
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.
You should be using standups to hear what your teams' blockers are, then spend the rest of the day getting rid of those blockers.
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.
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.
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.
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.
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.
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.
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!'
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.
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.
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).
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.
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.
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.
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.
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.
(Curious if the OP has an comments on this.)
Works great for cargo cult Agile(tm) if that's your market.
Between forced to write status updates and forced to write praise on forums, I guess your frustration bubbled into parody.
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.
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.
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.