5 Comments
User's avatar
Benedikt Kantus's avatar

It is a good point to focus on delivering value instead of following the most efficient, best-of-practice process. I recommend Matt LeMay’s “High-Impact Product Teams”!

Expand full comment
Artur Henriques's avatar

Interesting! I will have a look.

Thank you Benedikt,

Artur

Expand full comment
Benedikt Kantus's avatar

I might have said that 😉 Thanks for the mention!

Expand full comment
Verónica Olmos's avatar

Interesting. For developers, Agile doesn't directly pay the bills, but I think being able to contribute to an Agile team (vs the abstract concept of coding) does.

From my biased perspective, that's also the role of an engineering manager: In my team, I try to make sure engineers adhere to best practices, including Scrum if this is the methodology we are following!

Especially, as they grow in seniority, I ask them to help their peers owning the sprint (unblock other colleagues to reach "done status" vs selfishly taking new tickets) and I take the feedback the team provide in the retro as an opportunity to keep improving our ways of working (if somebody skipped a part of the process, why was that? If we thought we were gonna be able to deliver something and we couldn't, why?). Of course, I have their back if we fail as a team!

In my opinion, an engineer working in an Agile team in most Product-Tech organizations needs to understand how to contribute effectively under that framework. So progressively understanding how to co-own the process, giving timely feedback to Product when designing an epic, etc becomes part of their role as well. This might make things a bit more complicated, but I also think they become a bit richer too :)

Expand full comment
Artur Henriques's avatar

Hello Veronica,

Indeed, when the team already has a framework in place, the Developers adhere to it more easily. However, the number of times the framework needs to be taught every time a developer is onboarded is also daunting.

Today, Scrum is "applied" everywhere (the air quotes are because there are many bad Scrum implementations). Some notions should become second nature for the Devs, and that doesn't happen. The work of coaching your team members is gold and very important to have the machine flowing. However, once those developers switch teams, there will be the need for the "new Veronica" to do the same kind of follow-up and coaching.

Thank you for your contribution Veronica, is always valuable :)

Artur

Expand full comment