[HN Gopher] Launch HN: Spinach.io (YC W22) - Better daily standups
___________________________________________________________________
Launch HN: Spinach.io (YC W22) - Better daily standups
Hi HN, we're Josh, Yoav and Matan and we're building Spinach.io
(https://spinach.io). We help development teams run projects more
effectively, starting with 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, whether about daily standups or
other points where tooling could help cut overhead. Thanks!
Author : talmi
Score : 197 points
Date : 2022-09-20 13:16 UTC (9 hours ago)
| victorbojica wrote:
| 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!
| talmi wrote:
| Thanks for the feedback, would love to hear your thoughts after
| giving it a try!
| glintik wrote:
| Better standup is to have a beer in pub :).
| mrv_dev wrote:
| The hero we need!
| talmi wrote:
| Not mutually exclusive :) work hard play hard
| touchandpay wrote:
| Congratulations on your launch. Great work! Hope to see you this
| weekend.
| talmi wrote:
| Thanks! We'll be there!
| asutekku wrote:
| 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.
| talmi wrote:
| Agree a single person running it can help. In many cases that
| doesn't happen or folks just don't like playing that role so
| the app takes care of it
| adave wrote:
| But it does not since when things get off track no one is
| paying attention or too afraid to interject. You need a
| person anyways.
| DocTomoe wrote:
| 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?
| talmi wrote:
| 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
| nrclark wrote:
| 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.
| majikandy wrote:
| Yesterday, today, blockers... already feels like a relic from
| the past.
| nrclark wrote:
| 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.
| talmi wrote:
| We're working on enabling dynamic prompts so teams can
| customize. What's your standup format?
| pramodbiligiri wrote:
| 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.
| Cthulhu_ wrote:
| 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.
| pc86 wrote:
| 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
| owfwduke wrote:
| Congrats on the launch Josh and team!
| talmi wrote:
| Thanks!!
| joegahona wrote:
| > 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.
| talmi wrote:
| 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
| butterlesstoast wrote:
| 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".
| talmi wrote:
| 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
| ramsundhar20 wrote:
| Great tool for businesses to optimise their time. Best business
| productivity tool that I know.
| talmi wrote:
| Thanks for the support!
| joegahona wrote:
| Why is this called "Spinach"? Is it a play off of Popeye the
| Sailor Man?
| talmi wrote:
| We aim to create healthier work habit, Spinach is good for you
| :)
| dorkrawk wrote:
| Nobody likes spinach but you eat it because it's good for you.
| Interpret that as you will for standups...
| joshwillis2000 wrote:
| maybe a nice capresse salad?
| joshwillis2000 wrote:
| 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.
| [deleted]
| vertis wrote:
| 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).
| SOLAR_FIELDS wrote:
| 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.
| dustedcodes wrote:
| 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.
| Shindi wrote:
| Everyone take note, this is how you post constructive criticism
| on HN.
| talmi wrote:
| 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
| itake wrote:
| 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?
| noam_compsci wrote:
| I feel sad for your teams. I mean this with respect but you
| should consider management training.
| itake wrote:
| 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.
| vlod wrote:
| 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.
| appletrotter wrote:
| > As an EM, I use documented standups to keep track of how
| long and when people work on tasks.
|
| :(
| pc86 wrote:
| 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.
| itake wrote:
| I prefer to be told when blockers happen and not 12-24
| hours later. There are many different types of management
| styles though...
| vertis wrote:
| 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/
| itake wrote:
| > 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.
| mikhael28 wrote:
| 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.
| stefanmichael wrote:
| 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?
| yurishimo wrote:
| 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.
| sahila wrote:
| 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.
| yamtaddle wrote:
| 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.
| [deleted]
| mikhael28 wrote:
| 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.
| yamtaddle wrote:
| 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.
| mikhael28 wrote:
| 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.
| joshwillis2000 wrote:
| 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.
| lnxg33k1 wrote:
| 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
| sergiotapia wrote:
| 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.
| talmi wrote:
| We went through YC earlier this year, W22 was January-April of
| 2022
| bsick7 wrote:
| 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.
| talmi wrote:
| Thanks for the feedback! Curious to hear your thoughts after
| trying it out
| asommer12 wrote:
| Awesome product, awesome team!
| talmi wrote:
| Thanks for the support!!
| danabrams wrote:
| 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)
| recroad wrote:
| 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.
| talmi wrote:
| 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 :)
| dev360 wrote:
| 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.
| Cthulhu_ wrote:
| 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.
| joshwillis2000 wrote:
| Yeah, totally agree on this. Needs to stay fresh. Curious if
| you've seen other ways of keeping people engaged.
| yamtaddle wrote:
| 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.
| adave wrote:
| Haha i bet people hate the person that introduced it. However
| if you use a randomizer it might be ok.
| bot41 wrote:
| Sounds toxic-ish! Why pick on someone who isn't paying
| attention?
| awill wrote:
| It doesn't have to be toxic. If the team gets along well,
| it's all a bit of fun.
| rockostrich wrote:
| 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.
| talmi wrote:
| 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
| gmat_akhil wrote:
| Congrats on the launch guys, god speed!
| talmi wrote:
| Thanks!!
| jacknews wrote:
| 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.
| talmi wrote:
| 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.
| eek2121 wrote:
| 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.
| Cthulhu_ wrote:
| > 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.
| ryanSrich wrote:
| 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.
| joegahona wrote:
| 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.
| jacknews wrote:
| "manager can extract context and blockers via voice"
|
| lol. Which agile principle is this?
| zacharycohn wrote:
| Individuals and interactions over processes and tools.
| joegahona wrote:
| > The most efficient and effective method of conveying
| information to and within a development team is face-to-
| face conversation.
| jacknews wrote:
| '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.
| joegahona wrote:
| If "extract" is too triggering, you can replace it with
| "glean." Probably a bad word choice on my part.
| jacknews wrote:
| maybe, but your original description does not seem to be
| in the spirit of agile, but more like a manager
| controlling a team.
| [deleted]
| lnxg33k1 wrote:
| >> 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
| leetrout wrote:
| 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.
| sjkoelle wrote:
| We love Spinach - the slack integration in particular is <chefs-
| kiss>
| talmi wrote:
| :) Glad you like it!
| bozhark wrote:
| Is your goal to be incorporated within slack?
| talmi wrote:
| We're integrated with Slack for reminders, sharing meeting
| summaries and async experiences. We're also integrated with
| Zoom and Google Meet for the live meetings and with Jira for
| the board/tasks
| sagarsoni wrote:
| Exciting! Go team spinach
| talmi wrote:
| Thanks!!
| thedougd wrote:
| 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.
| talmi wrote:
| 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.
| mchusma wrote:
| 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.
| yamtaddle wrote:
| > 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.
| talmi wrote:
| Thanks for this And of course anyone can try it out first
| with no need to talk to us
| thedougd wrote:
| 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...
| codegeek wrote:
| You may like this:
|
| https://sso.tax/
| vertis wrote:
| 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.
| joshwillis2000 wrote:
| totally agree. I'm of the team!
| O__________O wrote:
| 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.)
| talmi wrote:
| 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!
| kobimantzur wrote:
| Congrats on the launch guys! I'm a big fan.
| goldlist wrote:
| We use Spinach. You should too.
| AngelaCastillo wrote:
| I absolutely love it!
| rakeshgoyal wrote:
| congrats guys. great product!
| talmi wrote:
| Thanks!!
| tamalsaha001 wrote:
| We have been using https://www.dailybot.com (another YC company)
| for the last 2-3 years. That one is great, too!
| talmi wrote:
| 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
| 0xbadcafebee wrote:
| 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.
| talmi wrote:
| This is great, thanks! We actually experimented with a
| countdown timer but folks found it too stressful :)
| siamakfr wrote:
| We used Spinach since early beta days and it was pretty helpful
| with running concise & effective morning standups.
| talmi wrote:
| Great to hear!
| sundbry wrote:
| a> We used Spinach since early beta days and it was pretty
| helpful with running concise & effective morning standups.
| gtsteve wrote:
| 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.
| talmi wrote:
| 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.
| gtsteve wrote:
| 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.
| bot41 wrote:
| "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.
| talmi wrote:
| Thanks for the feedback! Icebreakers are totally optional. Some
| teams do it and like it, others skip.
| bot41 wrote:
| That's fair enough. I would imagine managers would like it
| though :)
| 97-109-107 wrote:
| 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.
| mikhael28 wrote:
| 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.
| nithayakumar wrote:
| Congrats on the launch. I've worked in environments with
| structured and unstructured standups. And the former is so much
| more impactful.
| talmi wrote:
| Exactly! and we've found that in most cases it's
| unstructured... Thanks for the support
| adave wrote:
| 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?
| talmi wrote:
| That's exactly what we're optimizing for - reduce the
| coordination overhead and allow builders to focus on building
| ryanSrich wrote:
| 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!
| talmi wrote:
| We already support async! Please give it a try and tell us what
| you think
___________________________________________________________________
(page generated 2022-09-20 23:00 UTC)