5 ms·

I agree that the full commodification of technical work is a bad idea and will, hopefully, continue to fail. However, having read the Phoenix Project twice and

I agree that the full commodification of technical work is a bad idea and will, hopefully, continue to fail. However, having read the Phoenix Project twice and hating most of Scrum, I disagree that’s what the Phoenix Project is advocating for. My main takeaways from the PP are: 1. Have clear systems in place to carry out and manage your repeatable work, automate where possible 2. Minimise the time work is in progress for so people aren’t bogged down with a million tasks 3. Share information widely and have multiple members of the team able to carry out the same task 4. Make sure the work being done is what the business actually needs doing 5. Reduce noise and unplanned work so staff can get on with the higher value work they actually enjoy rather than wading through a quagmire of disorganised chaos The point of PP isn’t to turn people into interchangeable automatons - it is to put a system in place to allow people the headspace and time to do the really valuable work that can’t be automated or systematised. I’ve run a factory and been a dev so I see it from both sides and making devs production factory workers isn’t sensible but likewise where work looks like factory work (known work, repeatable steps etc) it should be treated in a similar way.

Pet_Ant 3y ago
> hating most of Scrum I'll just say that if you look at Scrum itself there is really nothing objectionable to it. https://scrumguides.org/scrum-guide.html https://scrumguides.org/scrum-guide.html It's the other shit people pack on top of calling it Scrum that usually sucks ass. I've found the best way to fight back against shitty-Scrum is not to fight it, but actually feign puritanical allegiance to the actual doctrine, it's much less repulsive. I makes you look like less of contrarian and it's easier to make an impact that way.
- simonbarker87 3y ago
  Very true, after being told many times “that’s not what it says in the Scrum guide, we need to do it like …” by a Scrum Master and a PO I decided to read it. I was astounded to find that the guide says very little and they were just using it as a weapon to push their own controlling desires on to the team. All the devs read it and the next time they used that line we asked them what it actually does say, they just made stuff up, clearly they had never read it either.
  - whstl 3y ago
    Yep. In pretty much every team I was in, devs would always push for "their own version of Scrum" that differed from the PO, which always ended up being much closer to vanilla Scrum than whatever some crazy PO or Scrum Master wanted. Also funny: when the PM is is actually good, you barely have to discuss "the process". Almost any shit just fucking works. Who knew.
- ebiester 3y ago
  The Scrum guide does not capture the culture and ecosystem of scrum that has developed around it. It’s like Node without NPM.
  - Pet_Ant 3y ago
    That’s my point. Keep the guide, ditch the ecosystem. You don’t have to use Rails, Boost, Spring, or Scrum-XP-Rational-Waterfall. Sometimes back to the basics of the tool is needed, but don’t throw out the baby with the bath water.
    - ath3nd 3y ago
      Let's throw the guide as well, cause it's the people reading the guide who made the ecosystem. If one is faced with a guide that essentially tells them: communicate well, don't be a douche, improve constantly, and do hard and smart work, and they are shocked by the guide's revelations, maybe we went somewhere wrong along the way.
      - Pet_Ant 3y ago
        I strongly doubt it’s the people who read the guide. It’s the people who learn about it from word of mouth that produce Jira-driven behemoths. Really, try the guide. It’s minimal.
- gardenhedge 3y ago
  The naming of the time blocks as "Sprints" is objectionable. Let me just _sprint_ 20 times back to back in a year, year on year for my whole career!
  - simonbarker87 3y ago
    Hard agree, the naming of much of Agile/Scrum is terrible from the dev perspective.
- ath3nd 3y ago
  I don't want to make an impact in any organization where experienced engineers are treated like children. So Timmy, what did you do today? Ah, cool, make sure to raise your hand if you make a boo boo, and involve your little buddy Mike, okay? Mhm, thanks. Hey guys, let's theorize how difficult it would be to make a tree house? Would it be 1 candy? 2 candy? 11 candies? No, that's too much, let's agree on 5, parents are eagerly waiting for the tree house to be built. Okay? Thanks. Well, 2 hours passed, time to tuck you in bed. Hey children, this is Jake, he is a bit slow in the head. He can't read yet but I have decided to make him the one deciding what is most important in your reading curriculum. I also have decided to talk only with Jake and check only with him what is your reading progress. If you haven't read all the books in the curriculum by (deadline made up by the first number which comes to Jake, and he can count max to 3), it's your fault, not Jake's cause let's be honest, he is a tool and he can't read. But if you all read your books, Jake gets cake. I believe all those methodologies were invented because manager types are terrified of depending on people who are different from them and who they don't understand. So they decided to embed one of their own business types (who also has 0 qualifications to judge whether the engineers are doing a good work) to make sure the engineers are not playing ping pong all day.
  - diracs_stache 3y ago
    Yep, stand-ups and retros literally feel like presenting my homework and saying what I've "learned" today most of the time. I've found myself as the ic that must speak and present on behalf of the group and this is all too accurate.
- marcosdumay 3y ago
  You mean dividing features into fixed-size timeboxes without even bothering to fully define them isn't objectionable?
gustavus 3y ago
The entirety of the Phoenix project is literally just copying Goldratt's the goal and then doing a s/manufacturing/IT/g and updating the references to modern day. I'm not saying I don't like it, I've read the book half a dozen times and try and get every team I'm on to read it to help modify their thinking to be more systems focused, but I'm not going to pretend that it much deeper or insightful than the goal.
- ath3nd 3y ago
  I feel I have to respond to this, as the Phoenix Project is probably the cringiest book I ve read in my life, and I've read The Effective Executive... I just don't understand why we have to veil common sense practices (like continuous improvement, good communication, shared goals, etc) in this vaguely culty, vague Japanese kind of dev ops propaganda. My biggest problem with the book is the same problem I have with scrum and all its hellspawn variations: it preaches how a method is special and if you only follow this method, everything will be okay. Well, guess what, if your team is full of people who don't communicate well, no management method can bring them up to be geniuses or to be suddenly a star team. On the other hand, if you have a team/teams of good devs, then you don't have the problem that The Phoenix Project/DevOps/Scrum are pretending to solve. If anything, what you get out of blindly following the scrum recipes and people who fetishize The Phoenix Project, is mediocrity. We need to have value delivered on 2 week intervals, we need to always pester clients for their opinion, we need Friday demos each week to show how much we centered this div, and how much value this new button gives... If you think you can chop value on small little chunks week by week blindly following the first thing that gives value, because long term planning is waterfall, and waterfall is bad, then you are a dummy and deserve your scrum and card estimations, and cringe standups. And you deserve it cause you gobble that bullcrap that those books and methodologies preach. Card estimations with Fibonacci numbers? Scrum masters? Product owners? Product managers? (that is somehow different from Product owners) Sprints? Standups? Just take the retrospective, add some standups, kick all all non technical people from the tech meetings, add a sync or two with other teams, and you are done. But please don't write a book about it cause I will absolutely hate on it.
  - zem 3y ago
Multicomp 3y ago
yeah I learned of the Phoenix Project as the 'why' behind doing the orange DevOps handbook 'how' when our company was hit with the DevOps wave. Continuous Learning + automation + instrumentation are many of the tools that let you do the 1-5 in your post. Saying it is only to "work harder to get more work done faster" is not what I took away from TPP.
ludicity 3y ago
I actually totally agree with all of this, and these are the positive takeaways from the Phoenix Project. It was actually a valuable read despite my ribbing re: prose. There are many things people do wrong with known work/repeatable steps that can't be rightfully laid at the feet of Phoenix Project-type thinking. But the one that can is that I think it ignores is that I rarely do known work with repeatable steps, because I'm programming: whenever this happens, it's because we've made tactical errors in stakeholder management and now I don't have time to automate them - but it has been a long time since my last reading, so it is possible that I've forgotten some sections that make substantial concessions in this area. A thoughtful, sensible reading definitely leads to your last paragraph even if the writers don't explicitly call it out, but I simply know for a fact that most of the managers I meet don't understand the difference between producing widgets and designing systems.

Pet_Ant 3y ago

> hating most of Scrum I'll just say that if you look at Scrum itself there is really nothing objectionable to it. https://scrumguides.org/scrum-guide.html https://scrumguides.org/scrum-guide.html It's the other shit people pack on top of calling it Scrum that usually sucks ass. I've found the best way to fight back against shitty-Scrum is not to fight it, but actually feign puritanical allegiance to the actual doctrine, it's much less repulsive. I makes you look like less of contrarian and it's easier to make an impact that way.

simonbarker87 3y ago
Very true, after being told many times “that’s not what it says in the Scrum guide, we need to do it like …” by a Scrum Master and a PO I decided to read it. I was astounded to find that the guide says very little and they were just using it as a weapon to push their own controlling desires on to the team. All the devs read it and the next time they used that line we asked them what it actually does say, they just made stuff up, clearly they had never read it either.
- whstl 3y ago
  Yep. In pretty much every team I was in, devs would always push for "their own version of Scrum" that differed from the PO, which always ended up being much closer to vanilla Scrum than whatever some crazy PO or Scrum Master wanted. Also funny: when the PM is is actually good, you barely have to discuss "the process". Almost any shit just fucking works. Who knew.
ebiester 3y ago
The Scrum guide does not capture the culture and ecosystem of scrum that has developed around it. It’s like Node without NPM.
- Pet_Ant 3y ago
  That’s my point. Keep the guide, ditch the ecosystem. You don’t have to use Rails, Boost, Spring, or Scrum-XP-Rational-Waterfall. Sometimes back to the basics of the tool is needed, but don’t throw out the baby with the bath water.
  - ath3nd 3y ago
    Let's throw the guide as well, cause it's the people reading the guide who made the ecosystem. If one is faced with a guide that essentially tells them: communicate well, don't be a douche, improve constantly, and do hard and smart work, and they are shocked by the guide's revelations, maybe we went somewhere wrong along the way.
    - Pet_Ant 3y ago
      I strongly doubt it’s the people who read the guide. It’s the people who learn about it from word of mouth that produce Jira-driven behemoths. Really, try the guide. It’s minimal.
gardenhedge 3y ago
The naming of the time blocks as "Sprints" is objectionable. Let me just _sprint_ 20 times back to back in a year, year on year for my whole career!
- simonbarker87 3y ago
  Hard agree, the naming of much of Agile/Scrum is terrible from the dev perspective.
ath3nd 3y ago
I don't want to make an impact in any organization where experienced engineers are treated like children. So Timmy, what did you do today? Ah, cool, make sure to raise your hand if you make a boo boo, and involve your little buddy Mike, okay? Mhm, thanks. Hey guys, let's theorize how difficult it would be to make a tree house? Would it be 1 candy? 2 candy? 11 candies? No, that's too much, let's agree on 5, parents are eagerly waiting for the tree house to be built. Okay? Thanks. Well, 2 hours passed, time to tuck you in bed. Hey children, this is Jake, he is a bit slow in the head. He can't read yet but I have decided to make him the one deciding what is most important in your reading curriculum. I also have decided to talk only with Jake and check only with him what is your reading progress. If you haven't read all the books in the curriculum by (deadline made up by the first number which comes to Jake, and he can count max to 3), it's your fault, not Jake's cause let's be honest, he is a tool and he can't read. But if you all read your books, Jake gets cake. I believe all those methodologies were invented because manager types are terrified of depending on people who are different from them and who they don't understand. So they decided to embed one of their own business types (who also has 0 qualifications to judge whether the engineers are doing a good work) to make sure the engineers are not playing ping pong all day.
- diracs_stache 3y ago
  Yep, stand-ups and retros literally feel like presenting my homework and saying what I've "learned" today most of the time. I've found myself as the ic that must speak and present on behalf of the group and this is all too accurate.
marcosdumay 3y ago
You mean dividing features into fixed-size timeboxes without even bothering to fully define them isn't objectionable?

gustavus 3y ago

The entirety of the Phoenix project is literally just copying Goldratt's the goal and then doing a s/manufacturing/IT/g and updating the references to modern day. I'm not saying I don't like it, I've read the book half a dozen times and try and get every team I'm on to read it to help modify their thinking to be more systems focused, but I'm not going to pretend that it much deeper or insightful than the goal.

ath3nd 3y ago
I feel I have to respond to this, as the Phoenix Project is probably the cringiest book I ve read in my life, and I've read The Effective Executive... I just don't understand why we have to veil common sense practices (like continuous improvement, good communication, shared goals, etc) in this vaguely culty, vague Japanese kind of dev ops propaganda. My biggest problem with the book is the same problem I have with scrum and all its hellspawn variations: it preaches how a method is special and if you only follow this method, everything will be okay. Well, guess what, if your team is full of people who don't communicate well, no management method can bring them up to be geniuses or to be suddenly a star team. On the other hand, if you have a team/teams of good devs, then you don't have the problem that The Phoenix Project/DevOps/Scrum are pretending to solve. If anything, what you get out of blindly following the scrum recipes and people who fetishize The Phoenix Project, is mediocrity. We need to have value delivered on 2 week intervals, we need to always pester clients for their opinion, we need Friday demos each week to show how much we centered this div, and how much value this new button gives... If you think you can chop value on small little chunks week by week blindly following the first thing that gives value, because long term planning is waterfall, and waterfall is bad, then you are a dummy and deserve your scrum and card estimations, and cringe standups. And you deserve it cause you gobble that bullcrap that those books and methodologies preach. Card estimations with Fibonacci numbers? Scrum masters? Product owners? Product managers? (that is somehow different from Product owners) Sprints? Standups? Just take the retrospective, add some standups, kick all all non technical people from the tech meetings, add a sync or two with other teams, and you are done. But please don't write a book about it cause I will absolutely hate on it.
- zem 3y ago

Multicomp 3y ago

yeah I learned of the Phoenix Project as the 'why' behind doing the orange DevOps handbook 'how' when our company was hit with the DevOps wave. Continuous Learning + automation + instrumentation are many of the tools that let you do the 1-5 in your post. Saying it is only to "work harder to get more work done faster" is not what I took away from TPP.

ludicity 3y ago

I actually totally agree with all of this, and these are the positive takeaways from the Phoenix Project. It was actually a valuable read despite my ribbing re: prose. There are many things people do wrong with known work/repeatable steps that can't be rightfully laid at the feet of Phoenix Project-type thinking. But the one that can is that I think it ignores is that I rarely do known work with repeatable steps, because I'm programming: whenever this happens, it's because we've made tactical errors in stakeholder management and now I don't have time to automate them - but it has been a long time since my last reading, so it is possible that I've forgotten some sections that make substantial concessions in this area. A thoughtful, sensible reading definitely leads to your last paragraph even if the writers don't explicitly call it out, but I simply know for a fact that most of the managers I meet don't understand the difference between producing widgets and designing systems.