Dan Lines

Very proud of the work by the data science team on this project - hopefully this will help guide other engineering teams.

Great to have Einat back! Loved her session at INTERACT in September.

Thank you! I'm hoping that as we iterate on the product it'll get better and better at solving the problem. This is a strating point - would love your feedback on the beta!

I'm hoping we can have the Slack integration done early 2022 - and I think there's other ways we can leverage the data we're getting from LinearB to help Devs. I'm pretty excited about it - I'd have KILLED for a tool like this back when I was coding regularly.

Thanks Connor, appreciate you reading!

Thanks Adam, really appreciate it!

Great stuff Doron! Thanks for coming on the podcast.

Thanks for highlighting LinearB Nick!

Great piece Thomas! Thanks for writing a Dev Interrupted/DZone piece!

Nice piece Nick!

Seriously great article Judy, I love the illustrations!

Can't wait to speak at this!

Great article Aviv! Loved having you on the podcast

Going to be a great conversation- can't wait!

Thanks Lior, I completely agree. Many of the changes we're seeing evolve from teams going hybrid remote will persist whether teams go back into the office or not. A new era for software development is upon us!

Thanks Mark and Yes, I believe a shared source-of-truth is highly beneficial for all hands on contributors and stakeholders in software projects.

2) Most project management tools have a "plan-first mindset". They make sure the initial skeleton of epics, stories, task, bugs etc...are created, defined, estimated and slotted into a backlog or sprint really well. But, what happens is as soon as coding starts, they become less valuable to the technical members (devs, tech leaders) on the team. Knowing that a ticket is "in-progress" is not very useful when you need real-time info about code, branches, PRs, releases to make good decisions during the iteration.

Lots of great comments and insights here! I've seen two main problems that happens to dev teams when using project management tools:

1) Most project management tools are highly flexible because teams work in many different ways and there are many use cases that they are trying to solve (because they have both technical and non-technical users to please). This "flexibility" makes it really easy to get the config/workflow setup into a state that is not great for the technical members of the team.

Thanks Lova!

"Why do I need to know what other groups in my department are working on?". I've success with the following formula:

1) Explain with 1 item that helps developers immediately. "If you understand what other groups in your department are working on, it can allow you to:
- Make better technical development decisions as you have expanded system context
- Make better product decisions as you may understand the customer better
- Understand dependencies that may make you have to redo your work

2) Explain 1 item that helps developers with career growth opportunities:
- Developers that get promoted to technical managers often get selected because they have a solid understanding of the entire department. (for example)

Thanks for your thoughts Oliver! The failed attempts definitely require discipline and I think the key is that the discipline through-out the company has to be accompanied with an understand of "why". If everyone buys into why allowing developers extended focus time is important it will be easier to stay disciplined.

Agreed on the status update that should be done via Slack or other means. To be fair, when it comes to a "commitment", I have seen this work well in newly forming teams if the commitment is to the team members (not the boss). I've seen it build trust early and then can fade away once the team is performing.

Love this comment Jing. Most everything has moved to async. It's a fair point to say that the standup should just be removed. Another way to look at it is that some of the information communicated and gathered in the stand up should just be continuous and in real time. Always available and accessible to all stakeholders whenever needed.

Hey Arun - Really cool to hear about your at Bell Labs, so awesome. It does seem that we are coming full circle, as the world usually works, things move in cycles. I think the shift needs to be back to developer empowerment and responsibility. We can build better products when devs are close to customer value.

Thanks Bruno! Great point that the company style/culture/constraints will have a major effect on your experience.

Knowing "the why" is super important. I like your adjustment on the first two questions with the "that others need to know about".

Internal communication (within the dev team) and external communication (outside the dev team) is always an interesting topic and never perfect. I think that within a dev team, developers are first to know if we "ahead" or "behind" the committed schedule. I like teams where all devs feel good about speaking up on the topic.

In terms of external communication. This has been broken in general since entering the industry. I'm not a big fan of limiting what Sales can and cannot say. I have a dream about an "open" development environment where sales has visibility into the development process and feature status. They can then make the decision of saying "this is coming next release" but at there own risk with no liability back to engineering. :)

Thanks Larry! Happy that you got value from the article. I think you're right about translating to other geographies. I've been meeting with teams across the globe and I think these points are applicable for most team leads I've met with

Glad you enjoyed it!

Thanks Praphull, happy this made your personal cheatsheet :)

Thanks Jawad! Happy to help our community.

Thanks Sandeep. We have an opportunity as a community to evolve. I also think that regardless of the team's maturity, if everyone comes in with the mindset of "how do I help the team the most in this meeting" - then the team will get an outcome they will enjoy.

Yeah couldn't agree more that the stand-up should not be about status. I love the mindset around volunteers stepping up with their time (most valuable asset) to help people who are stuck.

In terms of Waterfall --> Scrum - I think there was improvement but some of the core issues remain.

With the PO - I can relate. My thought here is, "why is the development team usually so disconnected from the customer of 'business value'". The best engineering teams I've seen build the product almost without a PO and are directly connected to the customer.

I think when this happens it's an organizational issue - not a problem with individual Sales folks. Engineering is too disconnected from Sales.

Thanks for the thoughts Rodrigo. I love the "Mentor our executives" aspect of what you are saying. Regardless of it relates to forecasting, performance metrics, capacity planning etc...providing knowledge to facilitate the right discussion is the key!

Hey Russell - I have seen this perception in general with everything getting turned against us. I think that most of the time, it is not coming out of an evil intention. I believe it's mostly due to lack of knowledge and we on the engineering side can help fix that knowledge gap (although it takes effort).

Two things come to mind:
1) People Perspective: create an environment where sharing something negative is met with encouragement and solutions. As a team leader, be the first to openly share and show that it is OK to not be in great shape.

2) Delivery Perspective: Come to the stand up with visibility and data. Sometimes people lose track of where they are in the sprint and simply do not realize that they are behind. Show number of days left, workload, and the team's average cycle time to deliver work.

Thanks Nawazish, happy to help!