As a former unofficial lead programmer, more true than imaginable. You should just provide new estimates daily, so the deadline isn't a specific day but "until it's done"...
How is your software project forecasted? Leave me your feedback and thoughts below. Skip to points in the video: 0:00 Introduction 0:40 A Tale of Two Forecasts 1:45 What Is Forecasting? 2:37 Why Forecast on Software Projects? 5:38 What Questions Does Forecasting Answer? 6:30 How % Complete Forecasting Makes Agile Teams Toxic 6:51 Problem #1 - Assumes Up Front Design 7:37 Problem #2 - Relies on Unreliable Estimates 10:40 Problem #3 - Discourages Collaboration 13:07 How Provide Investors Confidence Without % Complete Budgeting? 13:02 Solution #1 - Work With People Who Understand Agile Forecasting 14:09 Solution #2 - Learning Milestones from (Eric Ries' "The Lean Startup") 15:58 Why Are Learning Milestones A Better Way To Forecast? 17:33 Preview Of The Next Episode
the forecasting is simple: the business sets a set of requirements, a deadline by which those have to be met, and a budget with which to meet them, and then tells the development team to meet those requirements and deadline without going over the budget or heads will roll. THAT's how software projects are forecasted in my experience over the last 25 years, especially in an agile environment. Maybe it's because more than a few projects I've been involved with were the result of changes in legal requirements forcing a deadline (and almost always a very tight one), or companies failing to realise soon enough that a core piece of infrastructure the system depended on was going to be unsupported by its supplier. Most stressful projects obviously are those where both those things happen at the same time. Like one project where we HAD TO be ready to work with new data formats coming in from foreign sources based on international treaties going into effect at a set date, while at the same time we had to by that same date have the entire system rewritten to work against a completely different database engine AND a different application server AND run it on different hardware because of changes to the corporate IT infrastructure announced with only a few months lead time by the corporate IT infrastructure department. Obviously the business wasn't interested in the infrastructure changes so provided no budget for the changes needed to accommodate those, and infrastructure wasn't interested in the changing business requirements. So we had funding to (barely) meet the business requirement changes but at the same time had to rewrite the very core of our system to accommodate the infrastructure changes as well. Pitching the problem to the business was met with the usual blank stares of incomprehension. Just put in the extra hours as unpaid overtime and stop bothering us is the usual outcome of such meetings. Inevitably things crack, obviously, people leave in frustration and others end up with a burnout and on the sick roll for months (and then get fired for "not being committed" or "not meeting targets"), the project fails, the business loses trust in the developers who had long ago lost all trust in the business. Not just the team has become toxic, but the entire IT department and its relationship with the rest of the organisation.
My company loves getting a $105 return. In fact they seem happy with a $50 return. No amount of telling them I used to write hundreds of lines of code a day tempts them to take chains off the devs and let them rip.
Wow. I can totally relate to the prioritising your own deadlines over helping others. It sucks, I love helping others, but I made a promise and know i can hit my deadline "if I ignore everyone else" and "all distractions". In the end I succeed, but my colleagues and relationships suffer...
Have you ever turned down a colleague, so that you can hunker down and nail that deadline, only for that same colleague to come back with approval from someone higher than your boss' pay-grade?
Toxic thing with the standup, if management thinks it's for status report. It should be for developers not interrupting each other, just having a set time to discuss some of the problems that others need to be aware of - or taking it into a specific meeting if it is longer and agreed that it needs discussion. It is literally about unblocking: this is what I've done yesterday, this is what I'm planning to do today, this is what is a problem for me that is holding me up. Nothing on percentages etc.
Hey Jayme, As a new front end engineer, I find an immense amount of value in your videos. It’s very, very hard to find an engineer online speak intelligibly about the industry, let alone what an entry level position looks like. It’s not possible to get even a slightly honest description of this career from someone with whom I work, because there is an effort to describe everything done as “rosey”. I wanted you to know that to me, an engineer of < 1 year, at a very very small company, your videos are invaluable. Thanks a lot.
You’re very welcome! I would have really benefited from some of what I’ve learned the hard way myself earlier in my career. So it makes me really happy to hear sharing this stuff may help you figure it out much earlier!!
I think devs should be learning more about agile, lean and management, but the problem is the business hires managers which dont allow developers to work in a way that works best for them or the project. They have set mindsets on the way things should be done and that's final. Devs are just there to write the code. Unfortunately many devs have bought into this structure and just complain about management behind their backs instead of getting involved.
I wish most of the project managers (who are pretending to be agile) knows this. Good to have you back Jayme and continuously creating content again. but I noticed your aura is dark, are you getting enough sleep?
WOW the flaws you laid out regarding % complete forecasting and up front design describe the experiences I'm having on my current project so well that I could have sworn you were in the room for the past few months. How would you suggest confronting management w.r.t. changing their mindset on % complete planning for features and the like in place of learning milestones especially when you have Product Managers and/or Scrum Masters who promise it can be done and treat agile processes like a rain dance that are certain/proven to work? Also what are your thoughts on what makes a good scrum master? I'm of the opinion that a reasonable understanding of how software is produced is essential to being useful but I've met people in the past who believe it's solely about being a 'people person' as if the SM is a mini HR rep for the scrum team.
Hey thanks for the feedback! As far as changes to management mindset, the upcoming videos in this segment will give you some more insights. I tend to find if the attitude of leadership is one of growth and learning - there can be productive conversations. If they “got this” in their mind with respect to software, it can be a lost cause. I’ll talk more about scrum masters as the channel goes on, but I’m of the personal opinion that technical skills are just as important (in fact maybe more so) in an SM role. A developer tasked with the SM role can do a better job than a pure manager. YMMV
Many, many, many morning project estimate meetings with project managers, architects, developers, and QA. Yes, QA. We all had a deck of cards, and it was "bad-ass" and "techy" because we used only the Fibonacci numbers in the set. The scrum master would bring up one of the projects, and after asking who wanted to take it on, we would have a "mouthed" drum roll as we all got ready to show our estimates (at the same time, so no switching at the last minute if it was WAY off. If it was WAY off, you would have to explain why the number was what it was. We would ask questions like: Does this include requirements? Do we HAVE all the requirements? Are the front-end guys going to be on the same schedule as us, as well as the backend developers, so the middle tier developers wouldn't always get stuck waiting? Do these estimates include unit tests, integration tests, code reviews? I've heard that the version 2 of a product kills 90% of all software development companies. Back in 2019, we were 5 years late on version 2, and went through 3 years of front-end turn-over Hell, along with switching technologies 4 or 5 times. Many times, while alone, I get caught up on thinking i'm not good at my job...then this stuff happens, and I don't feel so bad. I really think that most people in the world suck, to some extent, at their jobs. We all do our best, but I believe this to be true. I guess that's enough for tonight.
It sounds like y'all tried hard to estimate well - better than most companies. Sure there may have been some corporate cringe to it (the drumrolls? hehe) but given most people don't understand lean software development yet I can see it. About the 5 year late project that's what I talk about in the earliest videos on the channel. Managers seem to forget the failures of the past too often when they say estimation is the only way to keep investor confidence. It takes a more sophisticated person to do A/B releases and run measurable experiments so I can see why the industry is still slow to try that stuff.
Your content is great. This stuff is usually only covered by Scrum Masters with no dev experience, which say how great estimates are. In my experience most developers say estimates are bs but their managers love it, so devs just thumb suck something so management can see some numbers. Management also usually thinks that you can big upfront design projects and agile is only about minor detail changes which dont affect anything else ie doesnt really affect the estimates or original solution. When management requires you to have the perfect solution upfront and for the code to be "complete" it makes finding the best possible solution a gamble.
Wow this is really useful. I've been struggling how to bill a client for some software dev work, and have that conversation about expectations and a roadmap. This helps with that a lot. Love the idea of learning milestones!
The trick is to estimate difficulty, not time. If a simple task has a difficulty rating of 1, then a 2 is twice as difficult, and a 5 is five times as difficult. This gives the planners enough data to both build out a road map, and to prioritize tasks based on risk. They can also have the business assign value ratings to tasks as well, in order to prioritize high value, low risk tasks first.
Yes the difficulty helps with estimating a fixed backlog, for sure. There's a chance that you may enjoy my video on Minimum Viable Products where I talk about some aspects of work prioritization our industry seems to misunderstand. I'm not sure if it would help you or not, but here's a link if you want to check it out at some point: ruclips.net/video/mj1neLc7swA/видео.html
I think the reality is that people have no idea about software. If you were building a football stadium, first you would hire someone to do market research, then you would hire an architect and project designers to design the stadium, then you would present those design documents to contracting firms and they would bid on a budget, you would select a contracting firm based on their track record and an estimate of their ability to finish the project within the budget etc. When people come to software shops, they have incredibly vague ideas about they want, they haven't done market research, often the market research is performed by the software shop itself and presented as initial findings to the investor. They rely on the software shop to come up with the design themselves, and estimate the time themselves. The plans end up being absolute garbage, you always find out mid-project they're building the wrong thing or didn't understand the requirements etc. Nobody does their due diligence creating a clear and unambiguous design spec document. If developers were given clear and unambiguous design spec documents then we could easily estimate how long to complete those requirements exactly as specified and deliver the product exactly as specified. Any reasonable team should be able to correctly estimate, for example, how long it would take them to implement say, the RealWorld example app (called "Conduit", it's a Medium clone). If software engineering were mature, you would produce a spec at that level of detail before you handed it off to a development team. And that's where the problem comes in, of course. In software, a completely accurate specification is sort of *the same thing* as working code. The code itself is a formal language specifying behavior. The work of specifying the behavior is in a deep sense equivalent to the work to implement it. That being said, it is still where you would need to work toward to mature the industry.
Its interesting you state the presence of investors, who want to know at the beginning, and along the way, what are state of software affairs. The presence of a monetary force occurred to me long ago; investors are promised returns by such and such dates. The need to keep to those dates leads to the forces that push adherence to forecasting. I think I agree with what your alluding to - forecasting requires accurate information, but there are disincentives to this. By the way, as ancillary forecasting information, I took some Earth science. In meteorology, the forecasting of hurricanes depends on a) a good model relying on atmospheric physics and momentum b) good data (which was available by radio sounding balloons until satellite). Apparently, forecasting for hurricanes was at least partially motivated by war concerns, for it leads to a possibly more successful invasion right after a hurricane. So I agree there are forces behind software forecasting.
Oh, so familiar, right down to the PO announcing the release and completely lying about the new features in it. No-one in management noticed. Everyone in dev knew.
Thank you for your great videos! I think there is no solution to this within a company: investors need estimates to decide whether to keep the team, but the development process is unpredictable. Looking from both perspectives, developer and client, I believe the only way to ensure accountability of developers is through a bounty market: let them bid on work items and have contractual definitions of done. That way, price discovery will happen, and the best and fastest developers are adequately rewarded. Granted, this does not work in a team, only on something like a freelancer market.
Thanks for the feedback, some good things to consider here. I talk a little more about this in the video "How Agile Teams Grow Toxic! Ep. 4 Commitments" ruclips.net/video/p6VUHGe1HuU/видео.html and many of the earliest videos on the channel about lean software development. You're right it's a very tough culture change to make. We need to address the way management measures effectiveness of software development to be outcome based, and not % complete based. It's possible but we're fighting decades of management that works for production of physical goods but not knowledge work. I also covered some thoughts that may be of interest to you in the video "An Agile Budget Keeps you From Being a Code Monkey": ruclips.net/video/pG4wNLopMZA/видео.html maybe you've experienced some of what I talk about in that video too?
@@HealthyDev The videos seem to hit the spot. I will watch them later, and probably everything else you created! Though that might take a while... heh! Thanks again for your content, and your reply!
Hey I am having a job interview today and wanted to ask you what it means that their Junior Team has been working on a project for 2 years now and they reached "beta phase" isn't Scrum something where a beta phase is reached in a time of a few weeks or months through multiple sprints? I am *very* scared of working overtime and burning out because in my last job (not IT at all, switching industry) I literally worked from 7 to 7 minimum because of work overload and more and more task assignments a day.
17:00, the entire world just exploded..... how many times has this happened "i need it yesterday" stay unpaid overtime to get it done, check logs.... never been used not even once.
I can relate to this on how we try to teach AI to learn on it own to reach its requirement ( e.g. learn to walk ) instead of feeding AI with upfront/fixed data like "Stand up at A. Take 1st Leg forward and 2nd Leg.... repeat until reach B" Lead : how long its take ...? Developer : Yeah its piece of cake .... i can do that in 2 days. After 2 Days Lead : Is it done can we move on to jumping. Developer : well .... i don't know man its keep on falling. it will take another week to figure it out. as of now "it can able to stand!" Lead : ☹️. @Jayme can you comment on how this can be done in leaning milestone way.... it helps me understand better in this way.😎 thanks in advance.
That depends on the management and how autonomous the team’s work is. My first preference would be not to estimate at all and let the cost of delay in having a feature (the business value of having it) drive what’s worked on. If that’s not possible, story points only communicated within the development team that represent relative effort. And if that’s not possible points communicated outside the team. In my experience management who have not developed software (and some who do) almost always attempt to convert points to hours despite that being a misuse of their purpose.
@@HealthyDev As much as I learned story points are important for the Product Owner so he/she can forecast. Anything more? In my opinion you can avoid estimating stories if the PO knows hows the team works.
In my experience of watching this situation unfold things happened like this. The agile manifesto was a set of principles created to help teams who realized software development has too many variables to be very predictable, to produce valuable software more cost effectively. Notice I said more cost effectively which does not imply faster or more predictably. 😉 Story points were originally just a helpful tool created to help those teams break work down into smaller pieces to show progress by completing things more often. Then along came Burn-down charts - a tool added on top of story points that completely misses the point that points are relative effort and not translatable to hours to appease managers who can’t accept the unpredictability the manifesto was created to address in the first place. And eventually sprint forecasting was added on top of it all to further appease managers that they can still have long term forecasts with the predictability they don’t understand isn’t reliable in software development. The sad result is that story points as understood by many companies (and even people who certify scrum masters and coaches) are often taught in this bastardized, completely anti-agile way that gives the impression they can produce accurate forecasts.
People confuse an estimate with a promise.
Exactly! And the more promises you have, the harder it is to be agile! I’m going to talk about this in the next video :)
As a former unofficial lead programmer, more true than imaginable.
You should just provide new estimates daily, so the deadline isn't a specific day but "until it's done"...
It is, in fact, is more than a promise, is a commitment. That's why they call it a *commit*
Which is why you don't do them
which is exactly why you shouldn't do them.
How is your software project forecasted? Leave me your feedback and thoughts below.
Skip to points in the video:
0:00 Introduction
0:40 A Tale of Two Forecasts
1:45 What Is Forecasting?
2:37 Why Forecast on Software Projects?
5:38 What Questions Does Forecasting Answer?
6:30 How % Complete Forecasting Makes Agile Teams Toxic
6:51 Problem #1 - Assumes Up Front Design
7:37 Problem #2 - Relies on Unreliable Estimates
10:40 Problem #3 - Discourages Collaboration
13:07 How Provide Investors Confidence Without % Complete Budgeting?
13:02 Solution #1 - Work With People Who Understand Agile Forecasting
14:09 Solution #2 - Learning Milestones from (Eric Ries' "The Lean Startup")
15:58 Why Are Learning Milestones A Better Way To Forecast?
17:33 Preview Of The Next Episode
the forecasting is simple: the business sets a set of requirements, a deadline by which those have to be met, and a budget with which to meet them, and then tells the development team to meet those requirements and deadline without going over the budget or heads will roll.
THAT's how software projects are forecasted in my experience over the last 25 years, especially in an agile environment.
Maybe it's because more than a few projects I've been involved with were the result of changes in legal requirements forcing a deadline (and almost always a very tight one), or companies failing to realise soon enough that a core piece of infrastructure the system depended on was going to be unsupported by its supplier.
Most stressful projects obviously are those where both those things happen at the same time.
Like one project where we HAD TO be ready to work with new data formats coming in from foreign sources based on international treaties going into effect at a set date, while at the same time we had to by that same date have the entire system rewritten to work against a completely different database engine AND a different application server AND run it on different hardware because of changes to the corporate IT infrastructure announced with only a few months lead time by the corporate IT infrastructure department.
Obviously the business wasn't interested in the infrastructure changes so provided no budget for the changes needed to accommodate those, and infrastructure wasn't interested in the changing business requirements.
So we had funding to (barely) meet the business requirement changes but at the same time had to rewrite the very core of our system to accommodate the infrastructure changes as well.
Pitching the problem to the business was met with the usual blank stares of incomprehension.
Just put in the extra hours as unpaid overtime and stop bothering us is the usual outcome of such meetings.
Inevitably things crack, obviously, people leave in frustration and others end up with a burnout and on the sick roll for months (and then get fired for "not being committed" or "not meeting targets"), the project fails, the business loses trust in the developers who had long ago lost all trust in the business. Not just the team has become toxic, but the entire IT department and its relationship with the rest of the organisation.
My company loves getting a $105 return. In fact they seem happy with a $50 return. No amount of telling them I used to write hundreds of lines of code a day tempts them to take chains off the devs and let them rip.
Wow. I can totally relate to the prioritising your own deadlines over helping others.
It sucks, I love helping others, but I made a promise and know i can hit my deadline "if I ignore everyone else" and "all distractions".
In the end I succeed, but my colleagues and relationships suffer...
Not exactly a good system for teamwork is it?
Have you ever turned down a colleague, so that you can hunker down and nail that deadline, only for that same colleague to come back with approval from someone higher than your boss' pay-grade?
Toxic thing with the standup, if management thinks it's for status report. It should be for developers not interrupting each other, just having a set time to discuss some of the problems that others need to be aware of - or taking it into a specific meeting if it is longer and agreed that it needs discussion. It is literally about unblocking: this is what I've done yesterday, this is what I'm planning to do today, this is what is a problem for me that is holding me up. Nothing on percentages etc.
Hey Jayme,
As a new front end engineer, I find an immense amount of value in your videos. It’s very, very hard to find an engineer online speak intelligibly about the industry, let alone what an entry level position looks like. It’s not possible to get even a slightly honest description of this career from someone with whom I work, because there is an effort to describe everything done as “rosey”. I wanted you to know that to me, an engineer of < 1 year, at a very very small company, your videos are invaluable. Thanks a lot.
You’re very welcome! I would have really benefited from some of what I’ve learned the hard way myself earlier in my career. So it makes me really happy to hear sharing this stuff may help you figure it out much earlier!!
I think devs should be learning more about agile, lean and management, but the problem is the business hires managers which dont allow developers to work in a way that works best for them or the project. They have set mindsets on the way things should be done and that's final. Devs are just there to write the code. Unfortunately many devs have bought into this structure and just complain about management behind their backs instead of getting involved.
Exactly, it’s a self defeating system unless you take a step back to rethink everybody’s expectations. Happy to hear you’re there!
00:16:51 - 00:17:21 ... That's the note about something called Experiencie sampling... I read about it in design sprint bootcamps and it's great!
I wish most of the project managers (who are pretending to be agile) knows this.
Good to have you back Jayme and continuously creating content again.
but I noticed your aura is dark, are you getting enough sleep?
I still haven’t fully recovered from sleep problems I had a couple years ago :/ I’m doing OK for the most part. ;)
WOW the flaws you laid out regarding % complete forecasting and up front design describe the experiences I'm having on my current project so well that I could have sworn you were in the room for the past few months.
How would you suggest confronting management w.r.t. changing their mindset on % complete planning for features and the like in place of learning milestones especially when you have Product Managers and/or Scrum Masters who promise it can be done and treat agile processes like a rain dance that are certain/proven to work?
Also what are your thoughts on what makes a good scrum master? I'm of the opinion that a reasonable understanding of how software is produced is essential to being useful but I've met people in the past who believe it's solely about being a 'people person' as if the SM is a mini HR rep for the scrum team.
Hey thanks for the feedback!
As far as changes to management mindset, the upcoming videos in this segment will give you some more insights.
I tend to find if the attitude of leadership is one of growth and learning - there can be productive conversations.
If they “got this” in their mind with respect to software, it can be a lost cause.
I’ll talk more about scrum masters as the channel goes on, but I’m of the personal opinion that technical skills are just as important (in fact maybe more so) in an SM role. A developer tasked with the SM role can do a better job than a pure manager.
YMMV
Many, many, many morning project estimate meetings with project managers, architects, developers, and QA. Yes, QA. We all had a deck of cards, and it was "bad-ass" and "techy" because we used only the Fibonacci numbers in the set. The scrum master would bring up one of the projects, and after asking who wanted to take it on, we would have a "mouthed" drum roll as we all got ready to show our estimates (at the same time, so no switching at the last minute if it was WAY off. If it was WAY off, you would have to explain why the number was what it was. We would ask questions like: Does this include requirements? Do we HAVE all the requirements? Are the front-end guys going to be on the same schedule as us, as well as the backend developers, so the middle tier developers wouldn't always get stuck waiting? Do these estimates include unit tests, integration tests, code reviews? I've heard that the version 2 of a product kills 90% of all software development companies. Back in 2019, we were 5 years late on version 2, and went through 3 years of front-end turn-over Hell, along with switching technologies 4 or 5 times. Many times, while alone, I get caught up on thinking i'm not good at my job...then this stuff happens, and I don't feel so bad. I really think that most people in the world suck, to some extent, at their jobs. We all do our best, but I believe this to be true. I guess that's enough for tonight.
It sounds like y'all tried hard to estimate well - better than most companies. Sure there may have been some corporate cringe to it (the drumrolls? hehe) but given most people don't understand lean software development yet I can see it. About the 5 year late project that's what I talk about in the earliest videos on the channel. Managers seem to forget the failures of the past too often when they say estimation is the only way to keep investor confidence. It takes a more sophisticated person to do A/B releases and run measurable experiments so I can see why the industry is still slow to try that stuff.
MVP MVP MVP
Worry about expanding it to cover new features and have robust error handling later!
Your content is great. This stuff is usually only covered by Scrum Masters with no dev experience, which say how great estimates are. In my experience most developers say estimates are bs but their managers love it, so devs just thumb suck something so management can see some numbers. Management also usually thinks that you can big upfront design projects and agile is only about minor detail changes which dont affect anything else ie doesnt really affect the estimates or original solution. When management requires you to have the perfect solution upfront and for the code to be "complete" it makes finding the best possible solution a gamble.
Wow this is really useful. I've been struggling how to bill a client for some software dev work, and have that conversation about expectations and a roadmap. This helps with that a lot. Love the idea of learning milestones!
I came to the same conclusion intuitively that this process have very very high tendency to turning highly toxic, but you explained it much better.
So much truth in one video
The trick is to estimate difficulty, not time. If a simple task has a difficulty rating of 1, then a 2 is twice as difficult, and a 5 is five times as difficult. This gives the planners enough data to both build out a road map, and to prioritize tasks based on risk. They can also have the business assign value ratings to tasks as well, in order to prioritize high value, low risk tasks first.
Yes the difficulty helps with estimating a fixed backlog, for sure. There's a chance that you may enjoy my video on Minimum Viable Products where I talk about some aspects of work prioritization our industry seems to misunderstand. I'm not sure if it would help you or not, but here's a link if you want to check it out at some point: ruclips.net/video/mj1neLc7swA/видео.html
So, that's exactly the story points (speaking of user stories) or the usage of things like sizes (s,m,l..) on project festure estimating
I think the reality is that people have no idea about software. If you were building a football stadium, first you would hire someone to do market research, then you would hire an architect and project designers to design the stadium, then you would present those design documents to contracting firms and they would bid on a budget, you would select a contracting firm based on their track record and an estimate of their ability to finish the project within the budget etc.
When people come to software shops, they have incredibly vague ideas about they want, they haven't done market research, often the market research is performed by the software shop itself and presented as initial findings to the investor. They rely on the software shop to come up with the design themselves, and estimate the time themselves.
The plans end up being absolute garbage, you always find out mid-project they're building the wrong thing or didn't understand the requirements etc.
Nobody does their due diligence creating a clear and unambiguous design spec document. If developers were given clear and unambiguous design spec documents then we could easily estimate how long to complete those requirements exactly as specified and deliver the product exactly as specified.
Any reasonable team should be able to correctly estimate, for example, how long it would take them to implement say, the RealWorld example app (called "Conduit", it's a Medium clone). If software engineering were mature, you would produce a spec at that level of detail before you handed it off to a development team.
And that's where the problem comes in, of course. In software, a completely accurate specification is sort of *the same thing* as working code. The code itself is a formal language specifying behavior. The work of specifying the behavior is in a deep sense equivalent to the work to implement it. That being said, it is still where you would need to work toward to mature the industry.
Its interesting you state the presence of investors, who want to know at the beginning,
and along the way, what are state of software affairs. The presence of a monetary force occurred to me long ago; investors are promised returns by such and such dates. The need to keep to those dates leads to the forces that push adherence to forecasting. I think I agree with what your alluding to - forecasting requires accurate information, but there are disincentives to this. By the way, as ancillary forecasting information, I took some Earth science. In meteorology, the forecasting of hurricanes depends on a) a good model relying on atmospheric physics and momentum b) good data (which was available by radio sounding balloons until satellite). Apparently, forecasting for hurricanes was at least partially motivated by war concerns, for it leads to a possibly more successful invasion right after a hurricane. So I agree there are forces behind software forecasting.
Oh, so familiar, right down to the PO announcing the release and completely lying about the new features in it. No-one in management noticed. Everyone in dev knew.
Thank you for your great videos!
I think there is no solution to this within a company: investors need estimates to decide whether to keep the team, but the development process is unpredictable.
Looking from both perspectives, developer and client, I believe the only way to ensure accountability of developers is through a bounty market: let them bid on work items and have contractual definitions of done. That way, price discovery will happen, and the best and fastest developers are adequately rewarded. Granted, this does not work in a team, only on something like a freelancer market.
Thanks for the feedback, some good things to consider here. I talk a little more about this in the video "How Agile Teams Grow Toxic! Ep. 4 Commitments" ruclips.net/video/p6VUHGe1HuU/видео.html and many of the earliest videos on the channel about lean software development.
You're right it's a very tough culture change to make. We need to address the way management measures effectiveness of software development to be outcome based, and not % complete based. It's possible but we're fighting decades of management that works for production of physical goods but not knowledge work.
I also covered some thoughts that may be of interest to you in the video "An Agile Budget Keeps you From Being a Code Monkey": ruclips.net/video/pG4wNLopMZA/видео.html maybe you've experienced some of what I talk about in that video too?
@@HealthyDev The videos seem to hit the spot. I will watch them later, and probably everything else you created!
Though that might take a while... heh!
Thanks again for your content, and your reply!
Hey I am having a job interview today and wanted to ask you what it means that their Junior Team has been working on a project for 2 years now and they reached "beta phase" isn't Scrum something where a beta phase is reached in a time of a few weeks or months through multiple sprints? I am *very* scared of working overtime and burning out because in my last job (not IT at all, switching industry) I literally worked from 7 to 7 minimum because of work overload and more and more task assignments a day.
U r a guru. Im subscribing.
I'm so glad i work in RF engineering for the government. Y'all have some next level drama.
The guy from the it crowd actually
Knows about it? Who’d have thought it
17:00, the entire world just exploded..... how many times has this happened "i need it yesterday" stay unpaid overtime to get it done, check logs.... never been used not even once.
Lol yup
I can relate to this on how we try to teach AI to learn on it own to reach its requirement ( e.g. learn to walk ) instead of feeding AI with upfront/fixed data like "Stand up at A. Take 1st Leg forward and 2nd Leg.... repeat until reach B"
Lead : how long its take ...?
Developer : Yeah its piece of cake .... i can do that in 2 days.
After 2 Days
Lead : Is it done can we move on to jumping.
Developer : well .... i don't know man its keep on falling. it will take another week
to figure it out. as of now "it can able to stand!"
Lead : ☹️.
@Jayme can you comment on how this can be done in leaning milestone way.... it helps me understand
better in this way.😎 thanks in advance.
Do you estimate stories like giving them Points?
That depends on the management and how autonomous the team’s work is. My first preference would be not to estimate at all and let the cost of delay in having a feature (the business value of having it) drive what’s worked on. If that’s not possible, story points only communicated within the development team that represent relative effort. And if that’s not possible points communicated outside the team. In my experience management who have not developed software (and some who do) almost always attempt to convert points to hours despite that being a misuse of their purpose.
@@HealthyDev As much as I learned story points are important for the Product Owner so he/she can forecast. Anything more? In my opinion you can avoid estimating stories if the PO knows hows the team works.
In my experience of watching this situation unfold things happened like this.
The agile manifesto was a set of principles created to help teams who realized software development has too many variables to be very predictable, to produce valuable software more cost effectively. Notice I said more cost effectively which does not imply faster or more predictably. 😉
Story points were originally just a helpful tool created to help those teams break work down into smaller pieces to show progress by completing things more often.
Then along came Burn-down charts - a tool added on top of story points that completely misses the point that points are relative effort and not translatable to hours to appease managers who can’t accept the unpredictability the manifesto was created to address in the first place.
And eventually sprint forecasting was added on top of it all to further appease managers that they can still have long term forecasts with the predictability they don’t understand isn’t reliable in software development.
The sad result is that story points as understood by many companies (and even people who certify scrum masters and coaches) are often taught in this bastardized, completely anti-agile way that gives the impression they can produce accurate forecasts.
Now I'm stuck in a situation where I know there is design flaw but scrum master diesnt want me to correct it
We have the same lamp.
When a good metric becomes a target, it ceases to be a good metric .
Yeah thats sux, but in the end its the thing of culture, if the company not true agile, we have a problem here.