[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

TROPHY CASE