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.
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.
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.
> 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.
I enjoyed the book personally. I think the key point it was trying to get across is that of all the things that look like "common sense" to people, the combination of these particular things is what is actually effective. it was never about blindly following some magic recipe, simply "here is a way of thinking about the overall task of project management that may be helpful, and here are some specific techniques that support it".
note that "if the project is behind we should make the engineers work 12 hours a day instead of 8" is common sense to a very large percentage of managers.
I don't know, to me, that was not literature, but a guidebook with examples.
Here is Bill, he's tired and overworked. If only he can focus on the important tasks and clear the clutter...
Here is Security guy. He is grumpy and is in a war with the developers because they don't follow his ancient and unworkable security practices. if only he could update his security practices to something more modern and cool.
Here is Maxine. She is a PO. Her team is given task after task and not allowed to focus. If only Maxine could protect her team from outside influence...
Here is CEO guy. His company is failing and he is trigger happy on ever changing initiatives and transformations, and nothing comes to fruition. IF only he could chart the course for his team, set performance metrics, and not change direction every 15 seconds...
Here is operations linux admin guy. He has a bunch of scripts that make the deploys when devs throw some new garbage over the fence to him. He is mad because the devs wrote yet another service in yet another language, making the ratio of devs to languages used 10 to 17. If only he and the devs could agree on a deployment standard or read about the wonders of k8s...
If this kind of preachy obvious rhetoric inspires somebody to take a deep hard look at themselves, recognize their flaws, and change, more power to them. However, I am simply allergic to patronizing narratives like this.
> note that "if the project is behind we should make the engineers work 12 hours a day instead of 8" is common sense to a very large percentage of managers.
Then out with managers like that. Most engineers can do their job without a pencil pusher standing over their shoulder and trying to "manage" them. However, there are only few managers who actually can do anything useful without underlings...
it was literally meant to be a guidebook with examples. I found that an entertaining way to present the material - if you were looking for literature or subtlety I can see why you would have found it patronising but personally I didn't feel talked down to when I read it.
If it was meant to be a guidebook with examples, why all the fuss about it?
You don't see people worshipping Cooking for Dummies, so why are we so cult-y about Scrum or The Phoenix Project. What's with the weird zen/Kung fu kind of vibe of it, as if they have just discovered sliced fknin bread?
Sadly, I genuinely think that for some people the Phoenix Project is an eye opener. Their enthusiasm on just discovering how to be a professional in the role they have been half assing for decades bugs the living crap out of me.
To me, reading TPP felt like reading a patronizing self help book. I found it nauseating, shallow, bland, and anyone expressing even a tinge of enthusiasm about it feels like an affront to my sensibilities.
> Their enthusiasm on just discovering how to be a professional in the role they have been half assing for decades
that is literally an entire genre of fiction - amateurs who have no idea what they are doing get a wise old teacher and shape up into a killer team. i suspect a lot of the enthusiasm for the book comes from the popularity of "people level up and the magic happens" stories.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.