lovedev

Hey AdoptOpenJDK team! :)

Looks like it was an issue with our Webflow set up. Nice catch! It should be up and running now :)

TBH I love the skepticism here. It's important to think about metrics critically in this way to make sure we're building truly useful applications of data.

We've found that evaluating individuals, stack ranking teams, and measuring an individual's 'productivity' to be an ultimately futile effort.

It's more important to focus on team delivery as described in many research studies. My favorite being the book Accelerate by nicole forsgren. If you haven't, I do encourage you to check it out!

As the founder of Haystack I can be seen as biased so its probably more helpful to checkout their research across thousands of teams on what makes an 'elite engineering team' and how elite engineering teams ultimately help drive successful organizations across profitability, market share, and customer satisfaction :)

Looks cool!

You beat me to it :)

Thanks for the kind words :)

Our main goal is to build eng analytics that are genuinely useful for teams :)

But I suppose we will be building a Bitbucket integration shortly?

Awesome! Every person on our team has Accelerate on our their desk :) highly recommended read and is a huge part of how we've shaped our product

Loving all the Gitlab requests! If you sign up and select "Gitlab" as your tool of choice, it will put you on our waitlist and help us prioritize that work :)

Definitely! We support Github at the moment with plans to expand into Bitbucket and Gitlab shortly :)

Great question! I'll try to cover them :)

1. While we do use pull requests as a unit of measure, we don't actually consider # of commits and # of pull requests as great proxies for productivity. We mainly track Cycle Time, Deployment Frequency, Change Failure Rate, and Throughput which help encapsulate speed vs. quality of an engineering teams. It's important for engineering metrics to correlate to engineering work. Specifically, that the engineering team has full control over those metrics. When looking from an Epic, Story, or Task perspective - this is often controlled by other parties, making it more difficult to know if engineering itself is improving or not. In addition to this, Epics often don't reflect actual engineering work in the same way that pull requests in Github do making them problematic to focus on.

2. Because we focus on engineering work itself from Github. Haystack can be used with any methodology so long as the team is using Git!

3. From an engineering perspective, the main goal is '# of successful iterations'. Product's main goal is that those successful iterations are pointed in the right direction. Looking at # of successful iterations (aka speed, deployment frequency, and quality) allow us to see how often we deploy value to customers and what is the quality of those deployments. Focusing on these metrics allow engineering teams to improve 'how they deliver'.

4. We actively don't look at individual engineers and we especially don't compare them using any metric since we've seen that lead to some bad takeaways like the one you mentioned. We help measure at the team-level to simply highlight improvements and bottlenecks rather than cross-compare any team or individual which is like comparing apples to oranges