Need some advice setting up your software project for success? Here is a FREE pdf guide including all my top tips on how to start a new project. DOWNLOAD HERE ➡ www.subscribepage.com/new-project-guide
1. Success Depends on Perfect Plans 1:40 2. Too Many People 5:38 3. Process Over Outcomes 7:47 4. Slow to Make Simple Changes 10:00 5. Dev Team Morale 11:40 6. Reliance on Heroes 12:27 7. Low Scores on DORA Metrics 12:58 8. Big Steps 13:46 9. Poor, or No, Feedback Loops 15:27 10. Building the Wrong Thing 16:09
@@ih8people Yea, he's one of the only voices in the yuotube tech world that I actually really respect, it's obvious he has a wealth of knowledge & experience at enterprise level and gives fantastic advice!
1. We are Agile. 2. We do Scrum. 3. Put everything in Jira. 4. Points are the most important part of a story. 5. Sprint goals are stories and points based. 6. Daily standup is a status meeting. 7. Development teams cannot communicate directly. 8. Developers cannot communicate with customers directly. 9. "That's not what I designed." 10. Velocity is the best metric.
@@ZadakLeader I mean sometimes you gotta do what you gotta do 😂 Best thing is when the PM forces me to estimate the time of his stories that he was too lazy to estimate the value of. I mean if we need the feature anyways to win that client, then put the damn money of that contract as value. Then we can make an informed decision how much effort we wanna put. This isn't rocket science, man... 🙃 And the next thing is a PM who skipped physics class apparently because he doesn't understand that velocity describes directed movement, not just speed. Get rid of that stupid burndown chart and measure the actual outcome like usage stats and revenue. Hope I won't ever become a bad manager in case I get promoted.
True, sadly. Not sure if we'll ever get to a point, where everyone understands, that tests are not part of the scope, but more like a tool. To omit tests to be "faster", to me, is as if you tell the people who build your house not to use any measurement devices, because it would speed the construction up, if they are not checking for the correct lengths and if something is level/plumb.
@@tonileskiev5299 even simpler: Replace the word "tests" with "requirements". Because, that is what we are continually ensuring: That what we build live up to the requirements.
@@StarryNightSky587 Not sure if I understand the connection between tests/coverage and scope that you are implying. To me, tests are codified requirements. Scope change does not necessarily mean that the requirements change, but if they do and the tests are not changed aswell, things go downhill.
Almost perfect list (99%). 1% for the recommendation of "fail fast". No one wants to set himself for failure. how about "learn fast" or longer version "learn fast whether you are wrong about your assumptions". 😊 Great video, I loved it! Keep it up
Great video. I lost it at "watermelon status reporting" 😂😂 I'm really glad you've included suggestions on how to tackle each of the issues you described! Keeps the conversation on these things optimistic and growth oriented 😁
Haha true. "Our stuff is already kinda good". Meanwhile SonarQube showing 100 years of refactoring effort for a product that's just a few months on the market. Classic 🙃😂 Another variant of this is to put tickets of already implemented features into the sprint to work on the next thing under the radar. Then you only inform management about you successful experiments. It's toxic but some managers prefer it that way actually 😂
Daily stand-ups drove me to drink. At one point, because of international time zones, I was attending a stand-up at 11:30 and another at 18:30, all of which overran. Twelve hours a day for 6 weeks, never again.
Each time I find a way to speed up our delivery pipeline, someone finds a reason to add another gate in front of it. It's like they don't want us to deliver fast.
Lol. Got 1 month to deadline of a project, but management decided to take 2 of my most prolific developers to start working on another project, then proceed to ask if we're still gonna meet the deadline. Lol. This should have been done the other way around.
This is a really good video and I agree with the points Dave makes. The majority of the 'fixes' Dave indicates are management activities. My observation is that in most development environments, 'fixes' always take the form of a tech implementation, typically a pattern, often by a 'manager' with very little experience of managing either, and quickly misses the point. Same goes for interviews: you get measured on what patterns you know or what the latest syntax is but nothing about actual management. And then we go down the 'compartmentalisation' of disciplines in the industry which further frustrates progress, especially for the experienced who shouldn't be compartmentalised as they are capable of delivering the whole project anyway!
The DORA group found out, that this classic triangle is wrong for software. First of all, you build good quality. If you do so, you will achieve speed and low cost. Bad quality will make you slow and expensive.
Many years ago I worked on a piece of software where it often occurred that customers requested specific features, even urgently, and when we implemented and delivered them, years later the same customers would report a bug that revealed they must have just used the feature for the first time. And they even payed for the enhancement.
wait, do we work for the same company? :D i raise you a "we put everything in a onenote sheet on a weekly basis, that then gets copied manually to the overarching excel planner"
from someone who just left a team as it was failing. Having too many non-technical/inexperienced mangers for a very technical project. Alot of these points mentioned get enforced more when things are going bad. Not able to see this happening in real time and not able to make changes to prevent all the issues until its too late. Leads to bad politics and finger pointing. Usually, a consultant is brought in to try and save the day. However, most of good engineers have already left and management cannot see they are to blame. I think you need to have someone experienced with a track record of delivering successful project to be driving things from the beginning.
Pair and mob programming can be highly effective when they arise organically among teammates, but forcing them can lead to burnout and exploitation. Encouraging collaboration should never come at the cost of worker well-being.
2:37 but Dave, if we don't include detailed work breakdowns, what will the CEO's mistress, er, secretary, er, Program Manager, PMP do all day!? Their sole purpose in life is to create detailed plans and beat everyone harder when they don't follow the plan to the letter!
5:33 oh no, I thought the work was supposed to be dictated by a Grand Poobah Principal Enterprise Architect that hasn't written code in 70 years, and has at least two of the following: insulin pump, respirator, oxygen tank, double-digit or less employee number
This is the conundrum in a nutshell! Business management wants to know what it is going to get, when it is going to get it and how much it is going to cost. This requires IT teams to do upfront planning to tell them but we can't go far into the future because the more we do, the more inaccurate our planning becomes, yet business management wants to know the total cost for its budgets!
Those who are victorious plan effectively and change decisively. They are like a great river that maintains its course but adjusts its flow...they have form but are formless. They are skilled in both planning and adapting and need not fear the result of a thousand battles: for they win in advance, defeating those that have already lost. --Sun Tzu
Mine: Not seeing the writing on the wall (ie progress is poor vs. timescales), but mostly - Having a manager who has no coding background and no idea of the complexity of the work, yet insists on "just one more change" / "how about if we do...", causing changes which often cut to the heart of the system structure. New manager, please.
I'd collapse the 10 signs to two or three : 1. Most people associated with the project having a waterfall mental model 2. Managers who have significant pretension/delusion of their competence 3. (optional) The project group focusing entirely on coding (or not at all)- I usually find the balance off (too much or too little stress on code)
@@Patterner Yes, I'm often take up a sort of tech role and you are right. However I'm often involved in management decisions and set ups and that sort of competence is also often ignored.
Ok, I have 9/10. Only "Too Many People" is missing on my list, because I'm +- developing quite big project alone... But noooo, it will not fail. Sure...
I've seen much, if not all of these, over my decades working at various companies. I will say that not all are show-stoppers, but they certainly burn resources. Last couple of places I worked, the "managers" thought they had a handle on project management, yeah, no... they were abysmal, and had a bad case of Dunning-Kruger; No matter what you try to tell them they "knew better" , their arrogance and ego kept them from learning even in the face of obvious failure... they watermelon-ed themselves... I wished they'd learn from people such as yourself.
Again, a lot of projects out there are not learning what the scope is during development. Millions of people have to implement a new service to copy data from backend A to backend B or adjust the software to support the new tax-regulation or implement an API required by the new BMW X5 car on launch day of the vehicle. There are tons of projects with a pretty fixed scope and it would be much more efficient to implement them in a waterfall model because most customers/companies are unable to use at least Scrum appropriately. And i'm for sure no fan of waterfall, but Scrum is causing so much harm and waste in the hands of incompetent people - multiple large car manufacturers now treat each user story as a fixed price/fixed scope/fixed time contract so every review and planning is a series of contract negotiations, which results in ridiculous levels of micromanagement from the customer AND your own engagement managers.
@@ContinuousDelivery It may not be a rational choice but in the consultancy game, it is common to have contracts with a fixed time, scope and cost because that's what customers demand. It's also fairly common in many other industries: you contract to deliver something in a timescale for a price. Unfortunately, software development is not as precise as contracts to deliver x tables and chairs. In practice, IT project changes in scope are responded to with variation requests and costed, time adjusted accordingly.
Great video, as usual!! 👏👏👏 There is lot there to unpack, but I was curious in how would you approach objective key results (OKRs)? They are a formal way to declare, rather explicitly, both time and scope constrains. I agree wholeheartedly that we are fooling ourselves, but management often shrugs or play hard to get in understanding this fact since they've read silicon valley companys were very successful with them.
Somehow the Agile people are preaching that Engineers shouldn't use quantitive metrics for productivity, and saying that we cannot plan. Basically trying to convert engineering into sociology and psuedoscience.
Ah... "Too many people" hahahaha ... Most of what you say boils down to being controlled by nontechnical managers - which is the norm in the finance and other parts of the corporate world. Do you remember when there were say 12 people in you department - then suddenly there were 3 more levels of management, two new vendors and whole subdepartments responsible for support, testing, admin, requirements, POLITICS and "experience". Read "Bullsh*t Jobs" by David Graeber. Perfectly describes most of the corporate world.
Need some advice setting up your software project for success? Here is a FREE pdf guide including all my top tips on how to start a new project. DOWNLOAD HERE ➡ www.subscribepage.com/new-project-guide
@@ContinuousDelivery please provide outlines
1. Success Depends on Perfect Plans 1:40
2. Too Many People 5:38
3. Process Over Outcomes 7:47
4. Slow to Make Simple Changes 10:00
5. Dev Team Morale 11:40
6. Reliance on Heroes 12:27
7. Low Scores on DORA Metrics 12:58
8. Big Steps 13:46
9. Poor, or No, Feedback Loops 15:27
10. Building the Wrong Thing 16:09
As a middle aged developer myself, this is by far my favorite tech channel! 👋👌
It's probably also the best channel to watch to heal from burnouts or prevent them from happening in the first place
@@ih8people Yea, he's one of the only voices in the yuotube tech world that I actually really respect, it's obvious he has a wealth of knowledge & experience at enterprise level and gives fantastic advice!
Many companies don't hire people over 40 yo.
1. We are Agile.
2. We do Scrum.
3. Put everything in Jira.
4. Points are the most important part of a story.
5. Sprint goals are stories and points based.
6. Daily standup is a status meeting.
7. Development teams cannot communicate directly.
8. Developers cannot communicate with customers directly.
9. "That's not what I designed."
10. Velocity is the best metric.
You forgot to estimate story points in T-Shirt sizes and then converting that back to days 😂😂😂😂😂😂
@@marcotroster8247 I love a "good" micromanaging wannabe PM
Also add "devs have the freedom to organize the work" and have devs write the Epics.
I will always force finish what I started.
@@ZadakLeader I mean sometimes you gotta do what you gotta do 😂
Best thing is when the PM forces me to estimate the time of his stories that he was too lazy to estimate the value of. I mean if we need the feature anyways to win that client, then put the damn money of that contract as value. Then we can make an informed decision how much effort we wanna put. This isn't rocket science, man... 🙃
And the next thing is a PM who skipped physics class apparently because he doesn't understand that velocity describes directed movement, not just speed. Get rid of that stupid burndown chart and measure the actual outcome like usage stats and revenue.
Hope I won't ever become a bad manager in case I get promoted.
@@marcotroster8247 what about all of the above. Aka wanting estimations but also not putting in the time to define the features lol
The worst is when the time is fixed so the scope is changed ... to not include tests.
True, sadly. Not sure if we'll ever get to a point, where everyone understands, that tests are not part of the scope, but more like a tool.
To omit tests to be "faster", to me, is as if you tell the people who build your house not to use any measurement devices, because it would speed the construction up, if they are not checking for the correct lengths and if something is level/plumb.
@@tonileskiev5299 even simpler: Replace the word "tests" with "requirements". Because, that is what we are continually ensuring: That what we build live up to the requirements.
what about having 100% coverage, but because of wild scope rodeo - these are wildly outdated (yet green) and test the wrong things :D
@@StarryNightSky587 Not sure if I understand the connection between tests/coverage and scope that you are implying. To me, tests are codified requirements. Scope change does not necessarily mean that the requirements change, but if they do and the tests are not changed aswell, things go downhill.
Almost perfect list (99%). 1% for the recommendation of "fail fast". No one wants to set himself for failure. how about "learn fast" or longer version "learn fast whether you are wrong about your assumptions". 😊 Great video, I loved it! Keep it up
Great video. I lost it at "watermelon status reporting" 😂😂
I'm really glad you've included suggestions on how to tackle each of the issues you described! Keeps the conversation on these things optimistic and growth oriented 😁
Haha true. "Our stuff is already kinda good". Meanwhile SonarQube showing 100 years of refactoring effort for a product that's just a few months on the market. Classic 🙃😂
Another variant of this is to put tickets of already implemented features into the sprint to work on the next thing under the radar. Then you only inform management about you successful experiments. It's toxic but some managers prefer it that way actually 😂
Daily stand-ups drove me to drink. At one point, because of international time zones, I was attending a stand-up at 11:30 and another at 18:30, all of which overran. Twelve hours a day for 6 weeks, never again.
Each time I find a way to speed up our delivery pipeline, someone finds a reason to add another gate in front of it. It's like they don't want us to deliver fast.
Lol. Got 1 month to deadline of a project, but management decided to take 2 of my most prolific developers to start working on another project, then proceed to ask if we're still gonna meet the deadline. Lol. This should have been done the other way around.
This is a really good video and I agree with the points Dave makes.
The majority of the 'fixes' Dave indicates are management activities. My observation is that in most development environments, 'fixes' always take the form of a tech implementation, typically a pattern, often by a 'manager' with very little experience of managing either, and quickly misses the point. Same goes for interviews: you get measured on what patterns you know or what the latest syntax is but nothing about actual management. And then we go down the 'compartmentalisation' of disciplines in the industry which further frustrates progress, especially for the experienced who shouldn't be compartmentalised as they are capable of delivering the whole project anyway!
Always loved the business triangle: Speed, cost, and quality: Pick two. You can't have all three.
Good video too. Thanks!
The DORA group found out, that this classic triangle is wrong for software. First of all, you build good quality. If you do so, you will achieve speed and low cost. Bad quality will make you slow and expensive.
How do I convince a PO to watch this episode? He always requests “detailed plan” that never happens
We started a new project and it already has a good amount of those warning signs. Great...
Many years ago I worked on a piece of software where it often occurred that customers requested specific features, even urgently, and when we implemented and delivered them, years later the same customers would report a bug that revealed they must have just used the feature for the first time. And they even payed for the enhancement.
1. They put the COO in charge directly.
2. He doesn't use Jira
3. So everything has to be copied to Excel and emailed to him
wait, do we work for the same company? :D
i raise you a "we put everything in a onenote sheet on a weekly basis, that then gets copied manually to the overarching excel planner"
Note: you can't encourage autonomy with "daily scrums" and "scrum masters" which are exactly micro-management.
not the good ones, especially the SM should be the biggest advocate for autonomy
This was much better quality, than a half years ago. Well done.
First red flag mentioned - "plans that fix time & scope" - that's every sprint in every company I've worked for...
from someone who just left a team as it was failing. Having too many non-technical/inexperienced mangers for a very technical project. Alot of these points mentioned get enforced more when things are going bad. Not able to see this happening in real time and not able to make changes to prevent all the issues until its too late. Leads to bad politics and finger pointing. Usually, a consultant is brought in to try and save the day. However, most of good engineers have already left and management cannot see they are to blame. I think you need to have someone experienced with a track record of delivering successful project to be driving things from the beginning.
Pair and mob programming can be highly effective when they arise organically among teammates, but forcing them can lead to burnout and exploitation. Encouraging collaboration should never come at the cost of worker well-being.
2:37 but Dave, if we don't include detailed work breakdowns, what will the CEO's mistress, er, secretary, er, Program Manager, PMP do all day!? Their sole purpose in life is to create detailed plans and beat everyone harder when they don't follow the plan to the letter!
5:33 oh no, I thought the work was supposed to be dictated by a Grand Poobah Principal Enterprise Architect that hasn't written code in 70 years, and has at least two of the following: insulin pump, respirator, oxygen tank, double-digit or less employee number
This is the conundrum in a nutshell! Business management wants to know what it is going to get, when it is going to get it and how much it is going to cost. This requires IT teams to do upfront planning to tell them but we can't go far into the future because the more we do, the more inaccurate our planning becomes, yet business management wants to know the total cost for its budgets!
Those who are victorious plan effectively and change decisively. They are like a great river that maintains its course but adjusts its flow...they have form but are formless. They are skilled in both planning and adapting and need not fear the result of a thousand battles: for they win in advance, defeating those that have already lost. --Sun Tzu
Thank you, a great channel so much to learn.
Mine: Not seeing the writing on the wall (ie progress is poor vs. timescales), but mostly - Having a manager who has no coding background and no idea of the complexity of the work, yet insists on "just one more change" / "how about if we do...", causing changes which often cut to the heart of the system structure. New manager, please.
This is such a great video for project management!
I'd collapse the 10 signs to two or three : 1. Most people associated with the project having a waterfall mental model 2. Managers who have significant pretension/delusion of their competence 3. (optional) The project group focusing entirely on coding (or not at all)- I usually find the balance off (too much or too little stress on code)
non-tech people who are not listening to tech people who were hired for their tech knowledge were the bane of my existance as software engineer.
@@Patterner Yes, I'm often take up a sort of tech role and you are right. However I'm often involved in management decisions and set ups and that sort of competence is also often ignored.
Ok, I have 9/10. Only "Too Many People" is missing on my list, because I'm +- developing quite big project alone... But noooo, it will not fail. Sure...
This is some real Art of War talk right here.
Nice Hitchhikers shirt!
I've seen much, if not all of these, over my decades working at various companies. I will say that not all are show-stoppers, but they certainly burn resources. Last couple of places I worked, the "managers" thought they had a handle on project management, yeah, no... they were abysmal, and had a bad case of Dunning-Kruger; No matter what you try to tell them they "knew better" , their arrogance and ego kept them from learning even in the face of obvious failure... they watermelon-ed themselves... I wished they'd learn from people such as yourself.
12:51 I also do prayer-programming when things get hectic :D sorry I just had to mention it, great video as usual!
Again, a lot of projects out there are not learning what the scope is during development. Millions of people have to implement a new service to copy data from backend A to backend B or adjust the software to support the new tax-regulation or implement an API required by the new BMW X5 car on launch day of the vehicle. There are tons of projects with a pretty fixed scope and it would be much more efficient to implement them in a waterfall model because most customers/companies are unable to use at least Scrum appropriately. And i'm for sure no fan of waterfall, but Scrum is causing so much harm and waste in the hands of incompetent people - multiple large car manufacturers now treat each user story as a fixed price/fixed scope/fixed time contract so every review and planning is a series of contract negotiations, which results in ridiculous levels of micromanagement from the customer AND your own engagement managers.
So what do you do when you have managers who insist that the only serious or legitimate way to do dev is with fixed time and scope?
Try to convince them that this is not a rational choice!
@@ContinuousDelivery It may not be a rational choice but in the consultancy game, it is common to have contracts with a fixed time, scope and cost because that's what customers demand. It's also fairly common in many other industries: you contract to deliver something in a timescale for a price. Unfortunately, software development is not as precise as contracts to deliver x tables and chairs. In practice, IT project changes in scope are responded to with variation requests and costed, time adjusted accordingly.
Great video, as usual!! 👏👏👏 There is lot there to unpack, but I was curious in how would you approach objective key results (OKRs)? They are a formal way to declare, rather explicitly, both time and scope constrains.
I agree wholeheartedly that we are fooling ourselves, but management often shrugs or play hard to get in understanding this fact since they've read silicon valley companys were very successful with them.
Thank you sir, another great video.
Love your shirt !
Somehow the Agile people are preaching that Engineers shouldn't use quantitive metrics for productivity, and saying that we cannot plan. Basically trying to convert engineering into sociology and psuedoscience.
Probably because they have no idea about engineering.
@@MohamedSamyAlRabbani who says that?
First sign: You work on a project.
get a team of great devs and none of this will matter.
Biggest sign - you got a consultant! LOL!
Hi Dave 👋
The biggest red flag is if most of your team has rainbow hair and you're not working on an accounting software for a circus.
Yes, that too.😅
wouldn't it be a rainbow flag?
@ The team would demand to develop exclusively for non-binary CPUs.
💯 and 💯more!
Ah... "Too many people" hahahaha ...
Most of what you say boils down to being controlled by nontechnical managers - which is the norm in the finance and other parts of the corporate world.
Do you remember when there were say 12 people in you department - then suddenly there were 3 more levels of management, two new vendors and whole subdepartments responsible for support, testing, admin, requirements, POLITICS and "experience".
Read "Bullsh*t Jobs" by David Graeber. Perfectly describes most of the corporate world.
Love that shirt 😝
i like the qwertee shirts
Is it a software project within a company with more than 5 employees? 98.2% chance it fails. Am I funny yet? Or, is this too close to truth?
2025 and dave still contradicting himself. people over proccess. process over outcome. outcome whats matter. xp
Rule 1: Don't use agile or scrum.
Your doing agile development.. fails all the time
Bring back SSADM?
@dennymeta and get rid of the pretend engineers.
Do you mean Scrum or agile?
@@BryonLape same garbage, waste of time.
Such are carefully thought out and evidence based argument. :)