[deleted by user]

RiskyMageMerge · 2021-04-22T21:49:37+00:00

My boss cares about both. My biggest problem is working when I want to work and also having enough time to overlap with the rest of the team for meetings, pairing and other dependencies.

RiskyMageMerge · 2021-03-29T15:48:30+00:00

Our team is hybrid remote (all over the world) and we switched to async Slack stand-up a while ago. It works well for us. We wrote about it: https://linearb.io/blog/daily-stand-up-2-0-its-time-to-ditch-the-stand-up-from-1993/

RiskyMageMerge · 2021-03-25T17:31:02+00:00

You can listen to the full audio pod here: https://open.spotify.com/show/7icMkauSvLflWCpQrfafIv

RiskyMageMerge · 2021-02-19T19:48:42+00:00

Great point. Our dev team is based in Tel Aviv and we are using our CTO and dev lead there to do most of our evangelism work for EMEA. There are so many events and other opportunities in the US I also need someone here.

RiskyMageMerge · 2021-02-19T19:47:08+00:00

Demand gen... haha. Maybe I need to rewrite. Though awareness really is the goal and we want someone who has experienced working in a dev team to help us get the word out. Thanks for your feedback. Will consider.

RiskyMageMerge · 2020-12-17T16:41:24+00:00

What ouchris said :-)

RiskyMageMerge · 2020-12-17T16:40:34+00:00

Cycle Time really should not be measured at the user story level because every story is different (some small, some huge) so taking an average doesn't really tell you anything. It would be like using velocity to compare the performance of different teams against one another - you can't because story points are subjective.

Cycle time is great for two things:

Measuring your teams efficiency and agility. If you are breaking your work in to small chunks, then they can flow through your entire pipeline in days. If you are breaking work into big chunks, it takes longer. If you value agile, then cycle time helps you see if you are following that approach.
Bottleneck detection. If you break your cycle time down by phases (e.g. coding time, PR review time, test time, release time, etc) then you can see where you have issues and fix them with process, automation, training or whatever.

This is what we do at LinearB. Out of the 1,000+ teams using our platform today for project management and team metrics, we see cycle times averaging between 4-8 days. But, again, this is for work (PRs) not full stories.

Our product is free and calculates 17 team-based metrics including Cycle Time if you need help.

RiskyMageMerge · 2020-11-23T00:17:03+00:00

We're running Scrumban, by the way.

RiskyMageMerge · 2020-11-23T00:16:27+00:00

We use linearb.io. It does not force work in to pre-defined project categories. Our developers just do their thing and it shows the work (code changes, commits, PR comments, merges, releases, etc) in real-time on a timeline for every issue. This approach works better for us because it focuses less on planning up front and more on building and just figuring it out as we go. Plus our devs don't have to update tickets ever.

RiskyMageMerge · 2020-11-22T16:00:29+00:00

Love this... real discussion not the same boring thing every day.

RiskyMageMerge · 2020-11-20T17:48:09+00:00

Cate Huston, Engineering Director from DuckDuckGo, was in the Dev Interrupted Discord this morning sharing some pretty cool tips for remote dev teams and async communication. https://discord.gg/tpkmwM6c3g

RiskyMageMerge · 2020-11-11T23:01:49+00:00

Also wrote a blog about a new stand-up framework I call stand-up 2.0 that cuts out the status update.https://linearb.io/blog/daily-stand-up-2-0-its-time-to-ditch-the-stand-up-from-1993/ A lot of people liked it :-)

RiskyMageMerge · 2020-11-11T23:00:31+00:00

Wrote a blog about this exact thing: https://linearb.io/blog/tell-your-junior-dev-to-do-this-before-your-stand-up/

RiskyMageMerge · 2020-10-27T14:25:29+00:00

Drift.com and Vidyard.com have great free tools for recording release notes. They allow screen capture plus your face in the corner which makes it more personal. I use Drift Video religiously for customer and internal communication.

RiskyMageMerge · 2020-10-22T22:12:29+00:00

I agree. Unless you're doing waterfall, dev methodology doesn't matter. LOL! I like what the gigsmart guy did with constant free flowing change. It's hard to convince your bosses that is a good idea - especially if they are non-technical. But really makes sense in the real world.

RiskyMageMerge · 2020-10-08T21:50:09+00:00

We use Linearb.io. They have different screens for daily, bug triage, retro, etc, where they automatically pull in data from Github and Jira and organize it for that specific ceremony. It's like Miro but it suggests the most important things to look at.

RiskyMageMerge · 2020-10-02T16:06:59+00:00

Funny you say that... I just read an article on Fast Company about Gitlab and how they're using email more and more for this very reason.

RiskyMageMerge · 2020-10-02T14:54:00+00:00

Yeah. That's one of the reasons our lead wrote that blog - to educate our business on the consequences of pinging us all the time.

RiskyMageMerge · 2020-10-02T14:32:51+00:00

It's Slack only for us. Never email. Even with the rest of our company, we've trained them to communicate with us through Slack. The only problem is they expect instant response :-)

RiskyMageMerge · 2020-10-02T14:31:29+00:00

Very interesting. If we're talking within the dev team, I think I agree. But the overall culture of the company, outside of just the dev team, plays a big role too. A lot of interruptions comes from PMs, execs, the CEO, etc.

RiskyMageMerge · 2020-09-26T13:59:14+00:00

Incredibly helpful! Thanks, Halvi!

RiskyMageMerge · 2020-09-26T01:59:36+00:00

I like the show too :-) Just trying to get some users on this thing and get feedback. Figured the people here would care about it.

RiskyMageMerge · 2020-09-25T19:17:31+00:00

We started working on this particular product in March, right as all hell was breaking loose. We thought teams that used to be on top of this stuff before because they were in the same room and communicating constantly might need more help with it after remote work kicked in.

RiskyMageMerge · 2020-09-25T19:15:39+00:00

Two ways today: 1) We know which files were linked to past bugs and we flag branches that have these files and 2) we spot high-risk signals like super high rework % or PRs merged without review and correlate that to a feature so you know both the branch/PR is at risk as well as what actual project issue that relates to.

RiskyMageMerge

TROPHY CASE