Excellent advice. Definitely working for a company that only listens to the company when we f'd up and they demand a change. Transitioning to devo tech space from automotive manufacturing, so your analogy hit home.
I often get asked why we can't work (as a development team) like the construction industry. This is basically the same premise as the car production line. I think they are ignoring the original design expenditure when they make this argument - and mean that, as you describe, why can't we have a predictable project roll-out? If I was quicker in my response I would have said - why can't the construction industry be more like software development? Roll out a new upgraded version of your house, deploy it almost instantly, anywhere in the world - all at very little cost. If a mistake comes to light - roll it back! I don't want a big reward for this world-saving idea - but a Nobel prize would be nice. ;)
I am afraid that Tesla's success is more-or-less based on this idea. They are experimenting how to maintain a traditional construction business using agile development methodologies...
@@tcfs you got it. The auto industry analogies I use here are harder to draw parallels to with Tesla - they are breaking the mold (no pun intended :P).
Came across this post, I know it's old, but thought I would opine. While I agree with many of your points, what you are talking about is proving a hypothesis before you go full board with development. This depends on many factors. If you are building something that customers need to adopt and use, then you need to design upfront and get as much feedback before coding. Design tools will allow us to simulate final look and workflow. This can save money and time with developers. UX/UI folks should be working with your customers and business people to understand what is required before kicking off any large engineering effort. However, if you are building out back-end infrastructure, or embedded system code, then you need a architectural implementation plan. Sometimes this involves tool evaluation and a proof of concept that follows a happy path to demonstrate value. Business leaders want to know how much it's going to cost and when it will be delivered. Their pockets are not endlessly deep, and developer should take care to properly manage the management teams expectations. Estimate conservatively, highlight items of risk and when you have more clarity and can estimate accurately, update the management team. Also, another tip is to let the management take responsibility of understanding the risk of doing something. Sometimes managers can make a decision to cut something that you thought they really needed. This can often be made if they are properly integrated into the decision making process.
I'm happy that you mentioned refactoring as such a critical part of the process, but I feel like you really glanced over the significant impact that it has on a project in both costs and budget. I've been doing this a long time also and in my experience, Agile and scrum practices end up neglecting code quality massively -- I've grown to just accept it as a side effect of the process. And spend the significant part of my job cleaning up behind other teams (that for the most part claimed they were Agile). Usually though sheer herculean efforts and non-billable time we are able to get a viable product out and yeah sure it does get feedback and iterated on, etc. But, the way it usually pans out, in my experience, is that a birds nest of code is delivered with obscene amounts of technical debt! And it rarely ever get budget for cleanup. What I've observed (over and over) is that eventually (months later) the usage of the software will starts to show significant performance (or functionality) issues. And finally when the customer(s) complains loud enough, then that particular item will get attention..... and smack -- the clients are confounded by the amount of complexity/time/costs it'll take to resolve it correctly! And, that's because, well. the devs (yes skillset is absolutely part of the issue, but not all) kept changing and adding on top of the birds nest of code driven by rapid change, whether its just bad code practices left for others, or the copy/paste of those practices because they were left there by others, etc. the snowball starts to roll down the hill very quickly! I'll be honest, I'm not sure how a true Agile or Scrum team should account for this, but I can tell you that not one team I've worked on has done it well (usually results in herculean efforts in overtime, non-billable effort, etc. to fix things just so we can make progress on a better foundation of quality. @Healthy Software Developer, Happy to hear your thoughts....
Great feedback and insights. I talked about the extra costs of agile some in another video “Why Do Leaders Treat Programmers Like Children?”: ruclips.net/video/Qp_yMadY0FA/видео.html and about the pressure to deliver features and the quality problems it creates in the videos about creativity, estimation, and feature factories. You’re absolutely right things go south fast if the engineers don’t know how to protect the pace of change in their workload to prevent things falling apart! Unfortunately as I’m sure you know the workforce tends to be on the younger side so there’s a challenge in the experience gap there.
My thoughts on Technical Debt are that it happens regardless of the methodology. In traditional waterfall style projects there is a huge amount of waste, and technical debt generally is never addressed either. The problem starts with budgeting, having big batch upfront design/reqs locked in, and measuring to the plan vs. measuring outcomes. Big batch/upfront designs lock in estimates in the plan, and requirements: you are fixed on time and scope. Technical Debt/Quality will be the first thing to be pushed down to meet the plan deadline. I honestly think if you have experienced this in agile development, then there was a lack of maturity from the Product Lifecycle perspective where you need to pivot btwn new features/MVP and tech debt/maintenance work; and agile methodology only really works when you can change the budgeting method, and you measure outcomes: an example of that for tech debt would be after MVP is released, you realize the next phase of the budgeting (the next release or month of the budget) is to minimize the defect/trend or scaling issues which are impacting the other areas in the value stream. Systems thinking. That's my view. Leadership/Mgmt have to understand iterative development and stop starting/start finishing when your out of the discovery phase.
I'm not sure I have a good answer except to have a track record of using this method and being able to speak to it. In my experience this is the hardest thing to convince a company to do. Actually ask the customer and stop taking the "safe" route where you build marginally useful features that don't really help the bottom line much.
I've got mixed feelings on this one. On one hand I do totally agree that companies must absolutely invest in writing flexible software with tests for the inevitable changes in the future. And while I do agree that some changes should be accepted from the customers, that is a balancing act in that customers don't always know what they actually want. All that to say you should listen to the customer and get feedback but your response to it should be measured. I've seen products (I'm sure you have too) that got polluted from every customer having slightly different needs and desires which turns a robust core domain into a ball of mud "enterprise" solution that now tries to be all things to all people but is now impossible to extend and maintain without significant costs.
Absolutely agree. There’s a balance between a company thinking they already know what customers want and delivering too much without their input, and letting the customer drag your product in all kinds of directions it doesn’t need to go. I guess in my experience more companies seem to have challenges with the former of those two extremes, but you’re right about the dangers on the other side too!
I'm glad you used the example of making a car as something that isn't agile, particularly since I'm working on software for an automotive supplier who has been trying (unsuccessfully) to do agile for the last 2 years. Our deliverable is just one small piece of the car, a device containing mechanical, electrical, and software components to it, all implemented to a mountain of requirements that were agreed to at quote time. It really feels like we are just doing scrum in the middle of a waterfall project, and the only purpose of scrum is for the PMs to make sure that the software stays "on track". Percent completion as you called it. Do you have any insights in how we can better leverage agile principles when the product itself might not be that flexible? I feel like there are definitely efficiencies we can get, but regular feedback and pivoting really isn't part of the way projects are quoted in the industry I'm in.
Hey Chris, thanks for sharing. It really is hard to get agile thinking going in companies that do traditional project management, hang in there. There’s a playlist on the channel called “Jayme’s Favorite Software Development Videos”. The first video on there with Jez Humble would be a great place to find some ideas and arguments for how that can work. If I remember correctly he uses the example of a printer company (physical product) which while not your exact situation, may be helpful.
Thanks Michael, glad you’re enjoying it. I definitely plan to come back. Getting some stuff in order in my life to make it possible. Appreciate your support! 👍
So I sort of skimmed this one...because the popups on screen distract me away from what originally felt like a 1 on 1 sort of lecture or tutor session. I could see having them at the end of the video to summarize the points you made. Ever since you made that help me be agile video I am gonna storm you with feedback...What does everyone else think? But from what I remember about the video, I do see this kind of manufacturing style of software development happen. The feeling that we should release a whole product at one time with all the bells and whistle that people think other people will enjoy without even asking them. i do feel like most people would be happier trying out a simpler product that doesn't have a lot of features, but does one thing well (or is at least trying to do it well) rather than try and learn an entirely new thing at once. I lost track where I was going with this, but "Yes business peoples stop treating software like manufacturing" which now I realize is ironic because didn't most software development processes come from car manufacturing....
Thanks for your feedback. I add graphics to try and provide a pattern interrupt so it’s a little less monotonous just watching me talk. I’m posting a new one in a bit tonight that’s dialed back a bit. Thanks for your suggestions.
Hey! Thanks for your efforts in making those videos, I enjoy them recently, but ... This video stands out among your over videos. Others I enjoyed much more, to put it mildly but honestly (I hope you don't mind hearing honest thoughts/feedback, at least that's what I got from some of your videos). This video starts with one thing - day-to-day developer work, crunching numbers/lines of code/etc. and how not to be a monkey for an already established company, but then it goes to angel investment/creating unicorn startups and the like. I think those are completely different, and even though there may be similar concepts to benefit both types of companies, they still have completely different configuration - different budgets, revenue streams, commitments, client base, market %, success metrics, etc. So applying a single "silver bullet" solution to both - is at least strange. Then you also jumped between listening to feedback as a means of gathering "tasks ideas" for incremental improvements, and throwing random ideas to the wall and seeing what sticks. Even though a client feedback is what's in common for both, yet they are different, again. I hope you take this feedback well. PS. I have 2 days left in Austin, wanna meet :) ?
By showing them that software is a creative process where everyone has to be involved. This is mostly a communication problem, you have to speak to the leaders and argument with a base, show them examples, case studies, sometimes you just have to shut their mouth and show them failure examples of why things would not work a certain way. Software development is mostly communication, but there's this concept of hierarchy that some companies have that the "code monkeys" should not speak to the big boys up there. Having a middle man is good sometimes, but in the development process, the developers have to know how the hell the big picture looks like, why they are doing what they're doing. And have the leaders read at least the basic of the development process, culturize themselves about the people they are "leading". Thankfully, the companies I have worked for I have had direct communication with the leaders, and saved them from disaster due to wrong concepts.
I can't agree with you enough. Last time I told my "leaders" about including us, as software engineers, in the big picture of what they are trying to build, the CEO himself could only understand that I was requesting them to show us the new UI design features they worked on during the week. That was one of the saddest and biggest anti-motivation experiences I've had in my career. Those are the guys that want to create the new tech unicorns. It's hilarious how much time is invested in meetings where no real communication like this is even present. Is it time to make it better ourselves?
I have been working as a developer at a new start-up agency for 4 years. I do agree with most of what you are saying, but do face some disagreements. Yes, in theory, you do invest for profit, not the product. But how does a development team know what kind of "product" gives profit? For that, they do need to be well educated, not just on programming, but the market domain of the product. For example, it doesn't matter how good you are at programming, you will never be able to create a profitable trading bot on your own, unless you have done trading yourself and know how to trade. Now, if you as a developer knew how to make "profitable" code, Then you could start your own business and you wouldn't need to work for somebody else. but since programmers mostly don't know that, leaders who know the business but not programming have to deliver the specification of a profitable product, and then the developers who know the programming but not the business can turn the specification into the actual product. Reality is, most programmers out there will be many magnitudes better in programming than what they will ever be in business, and this is why you as a client may want to invest in a product rather than "profit". For instance, you may be a day trader that has a successfull trading strategy, but don't know how to turn it into code. Thus you hire a programmer to make code that fullfills the trading strategy you specified. That's why as developers we should do our best to fullfill their requirements, and not make up our own ideas about what "product" will be the most profitable, unless we happen to know more about the market than the client.
Hey I appreciate this well thought feedback. I can see why you might come to the conclusion I’m advocating for engineers to design products on their own maybe from just this video. The point I try to make in most of my videos is a) product managers design features that customers say they want but don’t pay for all the time b) engineers are just as capable of innovative ways to solve customer problems (they know the capabilities of the technology better than anyone else as well) and c) treating engineers like code monkeys who just fulfill requirements leads to them not caring about work. The best teams I’ve worked with allow PMs and developers to work together to design the best ideas, and invest in a way where they can change the product when they get feedback together until they get the outcomes they want. Have you ever experienced a team that works like this? It’s pretty incredible what’s possible!
@@HealthyDev - you both have your well thoughtout poins. However, I believe you need to include risk. A daytrader, who knows what should be built and assumes little risk of being wrong, should probably go the traditional way. And vice-versa
@@ddamyanov thanks for the feedback. I don't say this to diminish your experience - but that's exactly the mindset that needs agile product design. You may think you know what should be built but that assumes you're the only user. In reality "subject matter experts" (like yourself) in ANY industry can certainly build a product. But building a product that *has the best design and most profitable ideas is not something that comes from expertise*. It comes from a humble learning mindset. I talk about this in many of the videos in the "Lean Software Development" playlist, one in particular that might be worth your time is "Minimum Viable Product: Letting Customers Help You Profit": ruclips.net/video/mj1neLc7swA/видео.html YMMV
Have you ever encountered a startup that is very agile in the sense that it is deploying incremental changes every couple of days or weeks and getting feedback and changing the design and plans to better meet the user feedback? I feel like this is how most startups function. week to week, month to month. Incremental. And have you seen such agile startups hire a lot of people and then get on the "Agile" bandwagon (scare quotes because it is not really agile) and start making grand plans and not being able to deliver anything?
Yes exactly! Startups or enterprise you hit the nail on the head. If companies lose that “who knows?” mindset to experiment and do incremental changes, it becomes agile theatre. Thanks for sharing your thoughts they’re bang on! 👍
Do you think companies have a lifecycle like a organism? I wonder if once you have tapped out your original business idea the whole code monkey environment comes in. Like they are just keeping there original idea on life support. Being a public company hurts too, YoY return is hard.
![[DRAGON BALL LEGENDS REVEALS ＆ STUFF] LEGENDS FESTIVAL 2024 Special Edition Part 2](http://i.ytimg.com/vi/af0phKxitX8/mqdefault.jpg)
How can we convince leaders to have the courage to stop investing in software like a manufacturing company? Leave me your thoughts below!
This is the best video about business and product development on the whole youtube.
It’s hard to expect people to have the attention span to watch the whole thing but I did my best to lay it out. Thanks for your support!! 👍
@@HealthyDev I've watched it twice today 😀. It really hits the spot. Great stuff!!👍
Excellent advice. Definitely working for a company that only listens to the company when we f'd up and they demand a change. Transitioning to devo tech space from automotive manufacturing, so your analogy hit home.
I often get asked why we can't work (as a development team) like the construction industry. This is basically the same premise as the car production line. I think they are ignoring the original design expenditure when they make this argument - and mean that, as you describe, why can't we have a predictable project roll-out?
If I was quicker in my response I would have said - why can't the construction industry be more like software development?
Roll out a new upgraded version of your house, deploy it almost instantly, anywhere in the world - all at very little cost. If a mistake comes to light - roll it back!
I don't want a big reward for this world-saving idea - but a Nobel prize would be nice. ;)
Exactly 👍
I am afraid that Tesla's success is more-or-less based on this idea. They are experimenting how to maintain a traditional construction business using agile development methodologies...
@@tcfs you got it. The auto industry analogies I use here are harder to draw parallels to with Tesla - they are breaking the mold (no pun intended :P).
Came across this post, I know it's old, but thought I would opine. While I agree with many of your points, what you are talking about is proving a hypothesis before you go full board with development. This depends on many factors. If you are building something that customers need to adopt and use, then you need to design upfront and get as much feedback before coding. Design tools will allow us to simulate final look and workflow. This can save money and time with developers. UX/UI folks should be working with your customers and business people to understand what is required before kicking off any large engineering effort.
However, if you are building out back-end infrastructure, or embedded system code, then you need a architectural implementation plan. Sometimes this involves tool evaluation and a proof of concept that follows a happy path to demonstrate value.
Business leaders want to know how much it's going to cost and when it will be delivered. Their pockets are not endlessly deep, and developer should take care to properly manage the management teams expectations. Estimate conservatively, highlight items of risk and when you have more clarity and can estimate accurately, update the management team. Also, another tip is to let the management take responsibility of understanding the risk of doing something. Sometimes managers can make a decision to cut something that you thought they really needed. This can often be made if they are properly integrated into the decision making process.
I'm happy that you mentioned refactoring as such a critical part of the process, but I feel like you really glanced over the significant impact that it has on a project in both costs and budget. I've been doing this a long time also and in my experience, Agile and scrum practices end up neglecting code quality massively -- I've grown to just accept it as a side effect of the process. And spend the significant part of my job cleaning up behind other teams (that for the most part claimed they were Agile).
Usually though sheer herculean efforts and non-billable time we are able to get a viable product out and yeah sure it does get feedback and iterated on, etc. But, the way it usually pans out, in my experience, is that a birds nest of code is delivered with obscene amounts of technical debt! And it rarely ever get budget for cleanup.
What I've observed (over and over) is that eventually (months later) the usage of the software will starts to show significant performance (or functionality) issues. And finally when the customer(s) complains loud enough, then that particular item will get attention..... and smack -- the clients are confounded by the amount of complexity/time/costs it'll take to resolve it correctly! And, that's because, well. the devs (yes skillset is absolutely part of the issue, but not all) kept changing and adding on top of the birds nest of code driven by rapid change, whether its just bad code practices left for others, or the copy/paste of those practices because they were left there by others, etc. the snowball starts to roll down the hill very quickly!
I'll be honest, I'm not sure how a true Agile or Scrum team should account for this, but I can tell you that not one team I've worked on has done it well (usually results in herculean efforts in overtime, non-billable effort, etc. to fix things just so we can make progress on a better foundation of quality.
@Healthy Software Developer, Happy to hear your thoughts....
Great feedback and insights. I talked about the extra costs of agile some in another video “Why Do Leaders Treat Programmers Like Children?”: ruclips.net/video/Qp_yMadY0FA/видео.html and about the pressure to deliver features and the quality problems it creates in the videos about creativity, estimation, and feature factories. You’re absolutely right things go south fast if the engineers don’t know how to protect the pace of change in their workload to prevent things falling apart! Unfortunately as I’m sure you know the workforce tends to be on the younger side so there’s a challenge in the experience gap there.
My thoughts on Technical Debt are that it happens regardless of the methodology. In traditional waterfall style projects there is a huge amount of waste, and technical debt generally is never addressed either. The problem starts with budgeting, having big batch upfront design/reqs locked in, and measuring to the plan vs. measuring outcomes. Big batch/upfront designs lock in estimates in the plan, and requirements: you are fixed on time and scope. Technical Debt/Quality will be the first thing to be pushed down to meet the plan deadline. I honestly think if you have experienced this in agile development, then there was a lack of maturity from the Product Lifecycle perspective where you need to pivot btwn new features/MVP and tech debt/maintenance work; and agile methodology only really works when you can change the budgeting method, and you measure outcomes: an example of that for tech debt would be after MVP is released, you realize the next phase of the budgeting (the next release or month of the budget) is to minimize the defect/trend or scaling issues which are impacting the other areas in the value stream. Systems thinking. That's my view. Leadership/Mgmt have to understand iterative development and stop starting/start finishing when your out of the discovery phase.
Very insightful.
Thanks Anand, glad you got something out of it!
I'm not sure I have a good answer except to have a track record of using this method and being able to speak to it. In my experience this is the hardest thing to convince a company to do. Actually ask the customer and stop taking the "safe" route where you build marginally useful features that don't really help the bottom line much.
Agreed. The budgeting and investment model in use on most projects today (IMHO) penalizes creativity and actually runs counter to being agile.
I've got mixed feelings on this one. On one hand I do totally agree that companies must absolutely invest in writing flexible software with tests for the inevitable changes in the future. And while I do agree that some changes should be accepted from the customers, that is a balancing act in that customers don't always know what they actually want. All that to say you should listen to the customer and get feedback but your response to it should be measured. I've seen products (I'm sure you have too) that got polluted from every customer having slightly different needs and desires which turns a robust core domain into a ball of mud "enterprise" solution that now tries to be all things to all people but is now impossible to extend and maintain without significant costs.
Absolutely agree. There’s a balance between a company thinking they already know what customers want and delivering too much without their input, and letting the customer drag your product in all kinds of directions it doesn’t need to go. I guess in my experience more companies seem to have challenges with the former of those two extremes, but you’re right about the dangers on the other side too!
I'm glad you used the example of making a car as something that isn't agile, particularly since I'm working on software for an automotive supplier who has been trying (unsuccessfully) to do agile for the last 2 years. Our deliverable is just one small piece of the car, a device containing mechanical, electrical, and software components to it, all implemented to a mountain of requirements that were agreed to at quote time.
It really feels like we are just doing scrum in the middle of a waterfall project, and the only purpose of scrum is for the PMs to make sure that the software stays "on track". Percent completion as you called it. Do you have any insights in how we can better leverage agile principles when the product itself might not be that flexible? I feel like there are definitely efficiencies we can get, but regular feedback and pivoting really isn't part of the way projects are quoted in the industry I'm in.
Hey Chris, thanks for sharing. It really is hard to get agile thinking going in companies that do traditional project management, hang in there.
There’s a playlist on the channel called “Jayme’s Favorite Software Development Videos”. The first video on there with Jez Humble would be a great place to find some ideas and arguments for how that can work. If I remember correctly he uses the example of a printer company (physical product) which while not your exact situation, may be helpful.
hey man just found the channel, been really enjoying the videos, hope you can come back and post some more in the future
Thanks Michael, glad you’re enjoying it. I definitely plan to come back. Getting some stuff in order in my life to make it possible. Appreciate your support! 👍
@@HealthyDev
I would work for you. Love the talks, interesting truth telling at times as well.
So I sort of skimmed this one...because the popups on screen distract me away from what originally felt like a 1 on 1 sort of lecture or tutor session. I could see having them at the end of the video to summarize the points you made. Ever since you made that help me be agile video I am gonna storm you with feedback...What does everyone else think?
But from what I remember about the video, I do see this kind of manufacturing style of software development happen. The feeling that we should release a whole product at one time with all the bells and whistle that people think other people will enjoy without even asking them. i do feel like most people would be happier trying out a simpler product that doesn't have a lot of features, but does one thing well (or is at least trying to do it well) rather than try and learn an entirely new thing at once. I lost track where I was going with this, but "Yes business peoples stop treating software like manufacturing" which now I realize is ironic because didn't most software development processes come from car manufacturing....
Thanks for your feedback. I add graphics to try and provide a pattern interrupt so it’s a little less monotonous just watching me talk. I’m posting a new one in a bit tonight that’s dialed back a bit. Thanks for your suggestions.
Now the company where I am working on, they need these advises
Hey! Thanks for your efforts in making those videos, I enjoy them recently, but ...
This video stands out among your over videos. Others I enjoyed much more, to put it mildly but honestly (I hope you don't mind hearing honest thoughts/feedback, at least that's what I got from some of your videos).
This video starts with one thing - day-to-day developer work, crunching numbers/lines of code/etc. and how not to be a monkey for an already established company, but then it goes to angel investment/creating unicorn startups and the like. I think those are completely different, and even though there may be similar concepts to benefit both types of companies, they still have completely different configuration - different budgets, revenue streams, commitments, client base, market %, success metrics, etc. So applying a single "silver bullet" solution to both - is at least strange.
Then you also jumped between listening to feedback as a means of gathering "tasks ideas" for incremental improvements, and throwing random ideas to the wall and seeing what sticks. Even though a client feedback is what's in common for both, yet they are different, again.
I hope you take this feedback well.
PS. I have 2 days left in Austin, wanna meet :) ?
Hey, I’m sorry I can’t this weekend. Thanks for the offer though!
Don't even speak about agile thinking in the world of IT consultancy business! I hope to get away from this soon and try myself in a product company!
By showing them that software is a creative process where everyone has to be involved. This is mostly a communication problem, you have to speak to the leaders and argument with a base, show them examples, case studies, sometimes you just have to shut their mouth and show them failure examples of why things would not work a certain way.
Software development is mostly communication, but there's this concept of hierarchy that some companies have that the "code monkeys" should not speak to the big boys up there. Having a middle man is good sometimes, but in the development process, the developers have to know how the hell the big picture looks like, why they are doing what they're doing.
And have the leaders read at least the basic of the development process, culturize themselves about the people they are "leading".
Thankfully, the companies I have worked for I have had direct communication with the leaders, and saved them from disaster due to wrong concepts.
Agree wholeheartedly! I love your attitude about this.
I can't agree with you enough. Last time I told my "leaders" about including us, as software engineers, in the big picture of what they are trying to build, the CEO himself could only understand that I was requesting them to show us the new UI design features they worked on during the week. That was one of the saddest and biggest anti-motivation experiences I've had in my career. Those are the guys that want to create the new tech unicorns.
It's hilarious how much time is invested in meetings where no real communication like this is even present. Is it time to make it better ourselves?
I have been working as a developer at a new start-up agency for 4 years. I do agree with most of what you are saying, but do face some disagreements.
Yes, in theory, you do invest for profit, not the product. But how does a development team know what kind of "product" gives profit? For that, they do need to be well educated, not just on programming, but the market domain of the product.
For example, it doesn't matter how good you are at programming, you will never be able to create a profitable trading bot on your own, unless you have done trading yourself and know how to trade. Now, if you as a developer knew how to make "profitable" code, Then you could start your own business and you wouldn't need to work for somebody else. but since programmers mostly don't know that, leaders who know the business but not programming have to deliver the specification of a profitable product, and then the developers who know the programming but not the business can turn the specification into the actual product.
Reality is, most programmers out there will be many magnitudes better in programming than what they will ever be in business, and this is why you as a client may want to invest in a product rather than "profit". For instance, you may be a day trader that has a successfull trading strategy, but don't know how to turn it into code. Thus you hire a programmer to make code that fullfills the trading strategy you specified. That's why as developers we should do our best to fullfill their requirements, and not make up our own ideas about what "product" will be the most profitable, unless we happen to know more about the market than the client.
Hey I appreciate this well thought feedback. I can see why you might come to the conclusion I’m advocating for engineers to design products on their own maybe from just this video. The point I try to make in most of my videos is a) product managers design features that customers say they want but don’t pay for all the time b) engineers are just as capable of innovative ways to solve customer problems (they know the capabilities of the technology better than anyone else as well) and c) treating engineers like code monkeys who just fulfill requirements leads to them not caring about work. The best teams I’ve worked with allow PMs and developers to work together to design the best ideas, and invest in a way where they can change the product when they get feedback together until they get the outcomes they want. Have you ever experienced a team that works like this? It’s pretty incredible what’s possible!
Much is possible, which has never been thought.
@@HealthyDev - you both have your well thoughtout poins. However, I believe you need to include risk. A daytrader, who knows what should be built and assumes little risk of being wrong, should probably go the traditional way. And vice-versa
@@ddamyanov thanks for the feedback. I don't say this to diminish your experience - but that's exactly the mindset that needs agile product design. You may think you know what should be built but that assumes you're the only user. In reality "subject matter experts" (like yourself) in ANY industry can certainly build a product. But building a product that *has the best design and most profitable ideas is not something that comes from expertise*. It comes from a humble learning mindset. I talk about this in many of the videos in the "Lean Software Development" playlist, one in particular that might be worth your time is "Minimum Viable Product: Letting Customers Help You Profit": ruclips.net/video/mj1neLc7swA/видео.html YMMV
Have you ever encountered a startup that is very agile in the sense that it is deploying incremental changes every couple of days or weeks and getting feedback and changing the design and plans to better meet the user feedback? I feel like this is how most startups function. week to week, month to month. Incremental.
And have you seen such agile startups hire a lot of people and then get on the "Agile" bandwagon (scare quotes because it is not really agile) and start making grand plans and not being able to deliver anything?
Yes exactly! Startups or enterprise you hit the nail on the head. If companies lose that “who knows?” mindset to experiment and do incremental changes, it becomes agile theatre. Thanks for sharing your thoughts they’re bang on! 👍
Do you think companies have a lifecycle like a organism? I wonder if once you have tapped out your original business idea the whole code monkey environment comes in. Like they are just keeping there original idea on life support. Being a public company hurts too, YoY return is hard.