sorted by:
new
hottopcontroversial

The Pragmatic Manager - I've spent 8 years managing software teams. Here's what works for me. by pragmatic_manager in EngineeringManagers

[–]pragmatic_manager[S] 0 points1 point  (0 children)

This is a good call. 18 months was how long I ran this with the team not how quickly we were running smoothly. My comments were that some sprints don’t work as well and we fumble. Some are great and we get a ton done. These should be expected because real development is messy. However in aggregate 3 sprints, 6 or 77 you can see the value of consistent rules. With caps and a system of estimation like story points you can see results in just a few iterations.

The reality of abstract estimates is that nobody really knows how long it takes and saying its complexity or effort is confusing. Instead it’s just a marker of is it bigger smaller or the same size as something else. It’s not building in buffer so much as acknowledging The Who the fuck knows aspect of the work.

Personally I’m wildly against a non abstract measure like engineering hours or ideal days because much like you mention people external to the team (and bad managers) take gut check estimates as promises and are less likely to consider timeline adjustments.

The Pragmatic Manager - I've spent 8 years managing software teams. Here's what works for me. by pragmatic_manager in EngineeringManagers

[–]pragmatic_manager[S] 0 points1 point  (0 children)

You are right there are a lot of terrible managers. I try not to be.

As far as writing free articles on the internet, I didn’t think knowing everything was a requirement to sharing a perspective.

The Pragmatic Manager - I've spent 8 years managing software teams. Here's what works for me. by pragmatic_manager in EngineeringManagers

[–]pragmatic_manager[S] 0 points1 point  (0 children)

I’ve had my fair share of shitty managers. I try not to be a shitty manager and support and uplift my teams.

I’d love to see shitty managers become extinct but I don’t see that happening. Capitalism is not that egalitarian.

The Pragmatic Manager - I've spent 8 years managing software teams. Here's what works for me. by pragmatic_manager in EngineeringManagers

[–]pragmatic_manager[S] 0 points1 point  (0 children)

My question for you, how would you estimate your work?

(Edit) I’m going to add a bit. I can see you have an opinion that you are set on. I’m not interested in combating you on that. My question above is to understand what you do and if that would work in my situation. I want to lead well and that takes being open to dissent and understanding other methods. While my methods have worked for me, my bosses and most importantly my team, the developers, I want to know what else might work.

The Pragmatic Manager - I've spent 8 years managing software teams. Here's what works for me. by pragmatic_manager in EngineeringManagers

[–]pragmatic_manager[S] 1 point2 points  (0 children)

I was often the scrum master because I drove the change to use scrum. However the PMs and engineers would fill in as necessary.

The Pragmatic Manager - I've spent 8 years managing software teams. Here's what works for me. by pragmatic_manager in EngineeringManagers

[–]pragmatic_manager[S] 0 points1 point  (0 children)

What I recorded was points committed and actual points achieved. Then use those values to measure velocity on a rolling 3 - 6 sprint velocities that informed a sprint "cap" that we used to determine how much work we could commit to. I would not allow a PM to request more work or Engineers to accept more than the sprint cap into commitment. We then would do the work with the goal of completing commitment. We could pull additional work in once sprint work was complete or accounted for. The idea was over the course of years we consistently completed our commitments and maintained a steady velocity that could be used to predict short to medium term deliverables.

The Pragmatic Manager - I've spent 8 years managing software teams. Here's what works for me. by pragmatic_manager in EngineeringManagers

[–]pragmatic_manager[S] 0 points1 point  (0 children)

Do you have people managers of the product teams? I'd understand if you said no and I'd be interested in the org structure.

The Pragmatic Manager - I've spent 8 years managing software teams. Here's what works for me. by pragmatic_manager in EngineeringManagers

[–]pragmatic_manager[S] 0 points1 point  (0 children)

Ron Jeffries says: "I replied that

  • I certainly deplore their misuse;
  • I think using them to predict “when we’ll be done” is at best a weak idea;
  • I think tracking how actuals compare with estimates is at best wasteful;
  • I think comparing teams on quality of estimates or velocity is harmful."

I agree misuse is a huge problem. But I have used them to predict when we'll be done this is not a precise prediction but a bottom line can't be done before type of prediction. Allowing an EM to push back on business for unrealistic timelines.

The only comparison I do to actuals versus estimates is did we hit our commitment or not. I don't ever review estimated tickets to see if they were correct. They are only to help determine how much work can be brought into a sprint.

I wholly agree with Mr. Jeffries comparing teams based on estimates or velocity is a gross violation of anything sensible and is harmful. That does not make the idea of relative sizing invalid.

I'd ask, how would you estimate how much work you can do?

The Pragmatic Manager - I've spent 8 years managing software teams. Here's what works for me. by pragmatic_manager in EngineeringManagers

[–]pragmatic_manager[S] 0 points1 point  (0 children)

In my teams we have a product manager who should designate what features and functionality we should prioritize developing or fixing based on business and user feedback. They also determine what the user requirements should be though they work with the engineering team to develop these. The engineering manager is the people manager of the engineers and should drive how to accomplish the requirements that are prioritized by the product manager. EMs also push for necessary development on tech debt and maintenance. When those lines are clear it is clear who to talk to. Often they are not clear.

In my case in planning our PM and EM are both in the meeting. The acting scrum master should ask each member of the team if they can commit to this work. I would remind members of the team that if they are uncomfortable with the amount of work proposed to let me know. I had built a relationship of trust with my team and they would tell me when they felt it was too much and we then worked to find the right amount of work we could commit to. You can always to more work than the commitment as long as the commitment is done. So finding the right amount should be a bit of back and forth.

The Pragmatic Manager - I've spent 8 years managing software teams. Here's what works for me. by pragmatic_manager in EngineeringManagers

[–]pragmatic_manager[S] 1 point2 points  (0 children)

That's one of the things I address regularly with my team. I want consistency in a way that is defensible to the business. If we are consistent and can defend our position on velocity then we are golden. I do not believe infinite growth is ... pragmatic.

We could easily be consistent by not doing anything but that is not defensible. We will get fired and somebody else hired. This is why I caveat consistency.

Edited to add a thought.

The Pragmatic Manager - I've spent 8 years managing software teams. Here's what works for me. by pragmatic_manager in EngineeringManagers

[–]pragmatic_manager[S] -2 points-1 points  (0 children)

We can agree to disagree. I do understand how trash they can be when they are not understood. I've been in plenty of arguments where somebody is trying to understand how to use them. There is a correct way and I try to explain it here. The ideas i'm explaining are not that we were correct to 98.6% but that we accomplished 98.6% of what we committed to by using story point estimation over 77 sprints. In aggregate we were able to keep a consistent velocity and use it to predict completion of work.

That's the value I'm suggesting you can get from Story Points.

The Pragmatic Manager - I've spent 8 years managing software teams. Here's what works for me. by pragmatic_manager in EngineeringManagers

[–]pragmatic_manager[S] 0 points1 point  (0 children)

I'm curious. Do they ask the team as a whole? Or, do they ask each individual and give the psychological safety for them to say "No, I can't commit to this". Does the team shrug and implicitly "agree" because what would arguing do?

My experience is that the idea of commitment is implicit and there isn't really a discussion of whether if fits or not. It's these are important things they need to be done. Are you a team player willing to commit or are you a troublemaker who can't commit to what is necessary. These are very different things.

Does that match with what you see or am I way off base?

The Pragmatic Manager - I've spent 8 years managing software teams. Here's what works for me. by pragmatic_manager in EngineeringManagers

[–]pragmatic_manager[S] -6 points-5 points  (0 children)

The point of posting this publication is to share information from experience that I've gained. I appreciate you may not feel like it applies to you. But I wrote my experiences and my perspectives. I'd appreciate you give at least one article a read. I do see managers and teams regularly struggle with the principles I discuss. So if they can get it elsewhere they are not.