Story points are even more useless than estimation.
Ask yourself this .. why am I in a meeting instead of writing code. If you get to 5 whys I'll be impressed.
The problem is people are too young, we've forgotten old knowledge and research like Fred Brooks "The Mythical Man Month" .. from 1975. Yup 1975, that's not a typo.
Almost as dumb as the project management triangle, which is the dumbest rubbish I've ever heard.
We can all deliver more, better quality software at a lower price in less time by hiring a better team, giving them autonomy, giving them a better goal, having a better process, using lighter tech .... and not doing any of the scrum rituals gives you back 25% of your week in my experience.
Your posts always get a laugh from me, I always enjoy receiving them in my inbox - thanks Adam!
I'm glad you're enjoying my rants. Getting it off my chest definitely makes me feel better too. What you said about Fred Brooks and going back to 1975 is so true. These are lessons the industry has to learn over and over—they just keep forgetting. Hiring a good team and giving them autonomy is what Fred Brooks, W. Edwards Deming, Peter Drucker, Stephen Covey, Tom DeMarco, and Timothy Lister all talk about, and the list goes on. And those are just the old voices. There are a lot of newer ones too.
Maybe if we keep bringing up these ideas, one day they'll finally find a permanent place in our collective subconscious. In the meantime, it feels good to find like-minded people here on Substack. Thanks for your comment!
Absolutely. It amazes me though that people watch the same stuff as me, like Henrik Kniberg's awesome Spotify Engineering Culture 1&2 .. but they ignore totally his main point, that it's ALL about motivation through autonomy .. and they just take away "I need squads, chapters" and whatnot. Same with the agile manifesto - they read it, but they ignore the main points and focus on the rituals despite line #1 which says don't focus on the rituals so much, focus on the people. It's like selective dumbness, I don't get it.
I wrote a post about this a while back. I think one of the problems that engineers (including my past self) contribute to this issue is to put code on a pedastal. Refactoring sounds like a bad thing. Deleting code that isn't legacy code sounds like a bad thing.
What happens when you put working software in front of users though? You get feedback that will result in either a bit of refactoring, or just wholesale throwing out some stuff and rewriting it. Code is a means to an end, not the end itself. The end is to make something useful.
That's not wasted work in my opinion. That's part of gathering requirements. It goes a lot faster when we put working software in front of users, even if that software isn't quite production ready.
Story points are even more useless than estimation.
Ask yourself this .. why am I in a meeting instead of writing code. If you get to 5 whys I'll be impressed.
The problem is people are too young, we've forgotten old knowledge and research like Fred Brooks "The Mythical Man Month" .. from 1975. Yup 1975, that's not a typo.
Almost as dumb as the project management triangle, which is the dumbest rubbish I've ever heard.
We can all deliver more, better quality software at a lower price in less time by hiring a better team, giving them autonomy, giving them a better goal, having a better process, using lighter tech .... and not doing any of the scrum rituals gives you back 25% of your week in my experience.
Your posts always get a laugh from me, I always enjoy receiving them in my inbox - thanks Adam!
I'm glad you're enjoying my rants. Getting it off my chest definitely makes me feel better too. What you said about Fred Brooks and going back to 1975 is so true. These are lessons the industry has to learn over and over—they just keep forgetting. Hiring a good team and giving them autonomy is what Fred Brooks, W. Edwards Deming, Peter Drucker, Stephen Covey, Tom DeMarco, and Timothy Lister all talk about, and the list goes on. And those are just the old voices. There are a lot of newer ones too.
Maybe if we keep bringing up these ideas, one day they'll finally find a permanent place in our collective subconscious. In the meantime, it feels good to find like-minded people here on Substack. Thanks for your comment!
Absolutely. It amazes me though that people watch the same stuff as me, like Henrik Kniberg's awesome Spotify Engineering Culture 1&2 .. but they ignore totally his main point, that it's ALL about motivation through autonomy .. and they just take away "I need squads, chapters" and whatnot. Same with the agile manifesto - they read it, but they ignore the main points and focus on the rituals despite line #1 which says don't focus on the rituals so much, focus on the people. It's like selective dumbness, I don't get it.
I wrote a post about this a while back. I think one of the problems that engineers (including my past self) contribute to this issue is to put code on a pedastal. Refactoring sounds like a bad thing. Deleting code that isn't legacy code sounds like a bad thing.
What happens when you put working software in front of users though? You get feedback that will result in either a bit of refactoring, or just wholesale throwing out some stuff and rewriting it. Code is a means to an end, not the end itself. The end is to make something useful.
That's not wasted work in my opinion. That's part of gathering requirements. It goes a lot faster when we put working software in front of users, even if that software isn't quite production ready.