2 ms·

Having been a manager, PM, and lead engineer this article really resonated with me. Scrum has a brief window of utility if a team isn't delivering at all, and

by lumost 9y ago

Having been a manager, PM, and lead engineer this article really resonated with me. Scrum has a brief window of utility if a team isn't delivering at all, and has lost management trust. It also has a large window of dis-utility where everyone haggles over points, shows velocity as results, and leaves customers and businesses wondering what their engineers are doing. Trust your engineers to do the right thing on their own and they might just surprise you.

ebbv 9y ago
What does “trust your engineers to do the right thing on their own” look like to you? And how is that stopped by SCRUM? For the way we do it, when a stakeholder wants our team to do something, they come to us with user stories and acceptance criteria that matter to them. Then we hash out the rest of it. I don’t really see a useful way we could be trusted more. The Marketing department knows best what feature it is they want on the website, and why. So they specify that part. We estimate complexity and the business weighs the priority of that feature against other stuff in our backlog and it falls into an appropriate sprint based on that and other motivating factors. Then we do the work. I don’t see a lack of trust? So I’m curious where you see it and feel it should be done better?
- stctgion 9y ago
  Perhaps they meant when the engineers decide the the priority of the features and maybe even define some features themselves
  - ebbv 9y ago
    If your company isn’t tiny your engineers generally shouldn’t be deciding priority. Unless your company is small enough that the engineers have a clear view of all the priorities of the business all we are capable of is saying “This seems really important to us.” And then that has to be weighed by people who have the bigger picture. But outside of a very small company to me it’s a bigger crime to waste engineer time with all the meetings necessary to give them that full perspective. When I started at my current company I was the only developer and I worked directly with the CEO and our single marketing person. Back then I helped decide priority. Now the company is too big for that. I don’t have time for all the manager and marketing and business planning meetings to be able to decide priority. As far as defining features, we can propose them like anybody else but I think I already explained why usually it makes sense for them to come from whoever owns that piece of what you’re doing. But this of course again depends on the structure of your company.
cbsmith 9y ago
It's curious that this it is interpreted as a lack of trust of engineers. > Trust your engineers to do the right thing on their own and they might just surprise you. Yes, they might surprise you. That's potentially quite terrible because there's a whole ton of other people & roles involved in the success of a product... and of course that's assuming that the project is what the customer wants, requires no marketing message for the customer to understand, and sells itself.
PaulRivers 9y ago
> Trust your engineers to do the right thing on their own and they might just surprise you. I mean - trust but verify. While I largely agree with you it's always demotivating for the team to realize one dev is doing no actual work and getting away with it. Obviously not good for the business either.

by lumost 9y ago

ebbv 9y ago

What does “trust your engineers to do the right thing on their own” look like to you? And how is that stopped by SCRUM? For the way we do it, when a stakeholder wants our team to do something, they come to us with user stories and acceptance criteria that matter to them. Then we hash out the rest of it. I don’t really see a useful way we could be trusted more. The Marketing department knows best what feature it is they want on the website, and why. So they specify that part. We estimate complexity and the business weighs the priority of that feature against other stuff in our backlog and it falls into an appropriate sprint based on that and other motivating factors. Then we do the work. I don’t see a lack of trust? So I’m curious where you see it and feel it should be done better?

stctgion 9y ago
Perhaps they meant when the engineers decide the the priority of the features and maybe even define some features themselves
- ebbv 9y ago
  If your company isn’t tiny your engineers generally shouldn’t be deciding priority. Unless your company is small enough that the engineers have a clear view of all the priorities of the business all we are capable of is saying “This seems really important to us.” And then that has to be weighed by people who have the bigger picture. But outside of a very small company to me it’s a bigger crime to waste engineer time with all the meetings necessary to give them that full perspective. When I started at my current company I was the only developer and I worked directly with the CEO and our single marketing person. Back then I helped decide priority. Now the company is too big for that. I don’t have time for all the manager and marketing and business planning meetings to be able to decide priority. As far as defining features, we can propose them like anybody else but I think I already explained why usually it makes sense for them to come from whoever owns that piece of what you’re doing. But this of course again depends on the structure of your company.

cbsmith 9y ago

It's curious that this it is interpreted as a lack of trust of engineers. > Trust your engineers to do the right thing on their own and they might just surprise you. Yes, they might surprise you. That's potentially quite terrible because there's a whole ton of other people & roles involved in the success of a product... and of course that's assuming that the project is what the customer wants, requires no marketing message for the customer to understand, and sells itself.

PaulRivers 9y ago

> Trust your engineers to do the right thing on their own and they might just surprise you. I mean - trust but verify. While I largely agree with you it's always demotivating for the team to realize one dev is doing no actual work and getting away with it. Obviously not good for the business either.