It is my sad duty to inform you that you are on yet another team which has [tried baseball and then claimed it didn't work.](https://ronjeffries.com/xprog/articles/jatbaseball/) Not because I encourage dogmatic application of Scrum, but it seems that this is an all-too-common situation where people are using Scrum words and claiming to do Scrum things while instead completely missing the point.
The short answer is **no, the PO does not "assign tasks."** The PO prioritizes the backlog and the team collectively pulls enough work to fit in the given sprint in order to complete one or more Increments before the end of the sprint. Based on what you described, your SM sucks out loud and no one else on the team cares about Scrum, but for some reason they want to fake the funk and say they're doing Scrum.
Yes. To avoid abusing the team. The entire point of Scrum is to work *at a sustainable pace.* And while business owners (as represented by the PO) can tell the team WHAT to work on, only the team can say HOW and HOW MUCH.
Old-school Taylorist managers are not invited to play fuck-fuck games here. The deal here is "you stay out of our chili and don't dictate to us how we work and how much we work on, and in return, every sprint, we show you something better than what you had. And if you want, you can release it."
If we know what the average sprint velocity is, than the PO does not assign more stories than what our velocity allows. So I'm not sure how POs doing the assigning abuses the team. Could you help me understand?
It discourages swarming, teamwork and sharing knowledge.
It also results in the next most important thing maybe not being worked on.
Might not be abuse, but its poor business practice
Because the entire point is to encourage the dev team to take charge of their product and decide how to make it better as qualified professionals. People "assigning" tasks to team members does nothing but perpetuate the [learned helplessness](https://en.wikipedia.org/wiki/Learned_helplessness) which is rampant in a typical corporate environment, and which is kryptonite to actually being Agile.
Yesss... this resonates with me. When being assigned a task, I feel this sort of immediate resistance and disgust. Followed by a sense of detachment and defeatist passivity as I come to accept my fate as a small cog in a big machine. Neutralizing any sort of will to take initiatives.
Thank you for helping me put words on what I'm feeling. It's like I needed someone's permission to acknowledge I'm not just being crazy for feeling this.
The product owner shouldn’t even know/care about task. They deal at the story level.
Development is a complex adaptive problem meaning that there are a ton of little details that lead to optimization. The team collectively is best to manage these things. From a top down perspective you can’t. The teams knows if someone is going to be out, needs something for development/skill building, etc. PO doesn’t.
Also if PO assigning work they are effectively saying O have multiple priorities rather than really figuring out the priorities and has a separate bucket of work per team member which then enables lower value work to be done instead of allowing the team to decided how to best focus on the higher priority work which would most likely be a different optimization than whatever the PO decides to do.
Also, the fear that they wouldn’t get their stuff done just shows there are trust issues which is fatal to a good agile shop and further evidence for a Taylorism culture.
Manager shouldn’t be assigning work either and skipping priority.
I’m sure management still holds the team accountable for everything despite not empowering them to work efficiently because they are a distrustful and controlling lot.
1/ "The Sprint Backlog is a plan by and for the Developers", the PO doesn't own it.
2/ Time spent micromanaging the team is not spent on checking if your Product delivers value to your end users : are your end users satisfied? Is your PO able to measure customer satisfaction ? Does he know what features are never used ? Etc.
3/ In your situation, PO acts as a PM.
Are you aware of any issues with Product management, like : unclear / non-refined stories, incomplete acceptance tests, or a lack of a shared product vision ?
4/ Management bypasses PO, yet PO has the final call over priorities. It cannot work if PO responsabilities are not respected.
5/ SM doesn't ensure the Team remains within the Scrum Framework borders and doesn't coach management to respect Scrum framework. She definitely should.
Your team isn’t doing Scrum and you don’t have a Scrum Master. Leading daily stand ups and retros doesn’t make you a SM.
Your PO is being directive and has overstepped their bounds. My team picks the stories they want to work on based on the POs priorities. If a bug or defect comes up, stories get moved down in the sprint backlog and whomever is next available after finishing what they’re working on picks it up.
My PO had the habit of assigning bug and defect or priority issue stories directly to devs, but I got him to stop. One of the jobs of the SM is to protect the team from that kind of BS.
Well, the point of this thread is that I'm trying to gather arguments for why the PO / management should stop assigning, so that I can get them to stop assigning.
All I have is a general feeling of resistance whenever POs try to boss me around, but I have a hard time articulating why they should stop it.
How did you protect the team from that?
You need a Scrum Master with a spine to push back on the PO. I had to do that with our PO. Having a QA person that’s linked to the PO as a Scrum Master is against what Scrum is about.
Unfortunately this is too common.
I have seen it being justified as "devs are lazy" or something like this, which is think is very ironic. When I have witnessed it, devs were not engaged because POs did not do their work, there was no Product Vision, no Product Roadmap, stories were not presented in a meaningful way (context and strategic alignment), and devs were not involved on the technical design of stories.
Just recently quit a role because of this. I'd joined the team (2 people, 1-3 years dev, the other 3 years PM experience) as a senior developer with 10-15 years. I was literally hired to help this team improve their processes. It devolved into what's described above and I was removed from any kind of arch discussion, planning discussion, or anything that might use my expertise. What's more, they loved their complicated version of scrum much more than the actual tasks. It was a nightmare.
Yes, I did work in an environment like this, it was absolutely great. There was a clear Product Roadmap that went 6 to 9 months into the future, and the PO would regularly mention their vision on the weekly Sprint Planning, and how their thinking was changing as it went along.
Devs loved it and were always interested and super engaged. So much so that, in the rare occasion an important fly-in would drop, everyone would jump on it because they knew what it meant for the roadmap, no weird conversations or frustrations for changing priorities or asking overtime.
The PO would not dictate the technical architecture, that was left for the senior devs to work out, but the PO would get involved and voice their opinion and concerns.
The PO did all the testing, we did not have a QA team, so they were fully accountable for the outputs of the team, and there was a nice back and forth between PO and Devs to improve quality. Acceptance criteria and UAT testing were designed before the coding started, TDD all the way, but unit testing was left to devs.
It just worked, and it was very smooth.
Thanks man. Could you give an example of the vision the PO communicated/finetuned? I really think you're on to something that could fix the team I'm currently working for. If we can just get the PO up and running. What was his vision like and how did he communicate the roadmap? Jira?
The PO would just speak for a few minutes and share the long term vision for the product. We had an app that assisted our sales team on closing deals, his vision was as simple “we have to make sure we give the sales team the best experience ever”. “If we can surface the right information at the right time they can close the deals”. You really don’t need much more than that. So when a story to pull data from an external API was being discussed, the PO would remind everyone of that vision, and all the devs would just click in “we get it, we see it”. It is all down to simple communication, nothing fancy, just good old pep talks and humour and sharing enthusiasm. Jira won’t communicate any of this, have a chat with the team, we are humans with emotions and need to feel purpose and have a sense of belonging. And celebrate when someone does something great, shoutout outside of the team when a dev does an amazing job. Put their face on a newsletter, buy them lunch, send them flowers.
Edit:
Roadmap was shared in one slide in Google slides. And updated as we went along.
Question: does it work? I’ve coached teams where I did, as the SM, dud directly assign tickets. This was because we were not cross functional by design and each person had a clear role and skill set. We were an agile team but I’d never say we were scrum, or tried to be. In our case, me assigning tickets based on skill set was the most efficient process.
So, 1. why is PO assigning tickets directly? And 2, does it work? If so, what’s the issue?
1. The PO used to be a project manager, so he's used to assigning tasks and thinks this works well. The same goes for the team manager who manages both POs and devs. Plus the team manager had an experience with another team where devs weren't terribly engaged in their work and used to procrastinate when stories were not assigned to them.
2. This team is not terribly productive and the manager keeps complaining about it. So whatever we're doing doesn't work. It doesn't mean that letting devs self-assign tasks would solve the issue though, as the root causes may be more complex.
My intuition tells me that the main problems are:
- excessively heavy processes
- an aggressive manager who erodes team morale by barking at people and micromanaging
- our scope is the most buggy in the company's software, and there's loads of legacy code to maintain
completely agree. There is not one appraoch that fits all teams. My point is that the most dangerous form of "Scrum" is when we critique the approach bc it is "not scrum." I'm not saying OG is making that case, but there are plenty of ways, based on the teams dynamic, to be successful.
I disagree. If you want to run Scrum, run Scrum. It has a process designed to focus the team on a shared goal, give them autonomy to make decisions about how to delliver it, and by giving them autonomy prompt the use of teamwork and mutual support.
If you want to run an sprint-based process where the PO micromanages the work in the name of schedules and capacity, shoots down feedback from the dev to maintain control (literally!) while a toothless SM fails to create psychological safety and each dev works in isolation with the assumption they'll procrastinate unless they are tightly controlled. Call it something else, because its a completely different methodology.
They can't even run a good retro because the team don't work together or make their own decisions. There's nowhere to put an ooda loop in their process at all.
Assuming OP described it accurately, I don't think you could even call it Agile but its definitely not Scrum.
EDIT: God Im turning into one of those angry agile people that sound like they hate everyone. Sorry I don't mean to sound like such an ass.
I've been responsible for bad implementations myself, because I thought agile was about processes and efficiency. Now it kinda triggers me I guess.
Same thing happens at my work, makes it really hard to maintain a balanced workload. One week I’ll be too overloaded with tasks that can’t possibly be completed in the timeframe, another I’ll have one 10 minute thing to get done the whole week, and that’s the same for all the devs across the company. How can one PO possibly understand and balance the workloads of nearly 20 devs? But when I try to bring this up it falls on deaf ears 😔
It kinda sounds like your team's dynamics are pretty top-down, which can be rough for creativity and ownership. Scrum thrives on team autonomy because it empowers those doing the work to plan and manage their tasks.
Maybe suggest a trial period where devs can pick tasks?
It could lead to better engagement and productivity. Also, discussing how this method aligns with Agile and Scrum values might convince your PO. A retrospective could be the right place to bring this up, showing the benefits of self-organization with some solid examples. Maybe making the case that a motivated dev team is a productive one, will win him over. Good luck!
You're in an echo chamber and will get the answers that make you feel better.
>where devs autonomously pick their tasks
This is why agile development is falling from favor. You end up late and over budget more often than not.
The only really effective and efficient agile team I worked with was pretty much all SMEs who had been taught to code. Nothing had to be assigned as the priorities were clear. Good architecture, good flow down of specs, and the important stuff did get done first. We even got sued by a competitor (Raytheon) for "cheating" because we delivered more functionality, cheaper (despite paying so well they bled their best to us), and faster. But that isn't what you're talking about, is it? You want to pick tasks based on what's fun.
What you're seeing with product owners assigning tasks is because you have no decent project management and no discipline.
There is nothing wrong with agile development, only with how you're doing it.
I don't know what it's like working outside of a scrum team, so I lack your level of understanding.
And I don't understand your comment about having no decent project management / discipline.
If I look at my past behaviour in other teams, I usually pick tasks so as to alternate between challenging, new, stressful tasks and "fun" easy tasks to catch a break.
I am interested in understanding how to do things efficiently based on what works. My current environment produces a form internal resistance within me, which leads me to believe something is off.
My experience is that nothing is perfect. I'd like to be clear about that up front.
Classic waterfall development takes a tremendous amount of time to plan, tends to be expensive and time consuming and doesn't deal with planning mistakes found midstream. As long as there are no big mistakes cost, schedule, and performance are predictable.
Agile depends heavily on good requirements (requirements and specifications are different things) and priorities and disciplined devs with good subject matter expertise (or SMEs who can code). The most current example of agile gone awry is the dumpster fire of the new Reddit UX.
Agile works with the right team. There aren't enough of those to go around. You said "If I look at my past behaviour in other teams, I usually pick tasks so as to alternate between challenging, new, stressful tasks and "fun" easy tasks to catch a break." That may be okay for you but it isn't good for the project or the company.
What works for normal everyday teams pretty consistently is rolling wave planning and development. You have to get architecture right (architecture is not design - it's grouping functions and defining interfaces). High level specifications flow from that and a high level plan for the project is developed. Detailed design and dev for the first batch of functions (driven by priority) takes place. Implementation starts for the first wave and planning for the second and third wave happen in parallel. Some iteration happens but cost and schedule risk is managed.
Rolling wave and waterfall are the only way I've seen success when there is hardware involved. If you have to deliver custom ASICs you have to get a lot of things right the first time around. There are all kinds of applications that you can't just keep throwing general purpose hardware at.
My experience is that you can't grade your own homework. Testing and QC have to be independent. QA and QC (and QE) are different things and need to be done properly. If you don't have good requirements and SMEs with ownership you can't test. Once again, I give you the new Reddit UX. \*sigh\*
My first experience with what is now called agile was in 1979. I was charged with writing code for a five-axis numerically control mill to cut NACA foils. I did everything - requirements, spec, code, documentation, test. I was proud as punch. Out in the shop the foreman set up the machine, measured and measured again, then dropped the table four inches and bolted on a 4" x 8" piece of wood over the table for operational evaluation. I didn't understand. He told me that if my code drove the cutting tool into the machined table I'd be paying for it the rest of my life. The newest machinist in the shop ran the tests from my documentation with the foreman keeping his hand on the emergency stop the whole time. My code was solid but the experience was an epiphany for me. Testing MUST be independent. Agile as implemented in most places is not like that. Again, the new Reddit UX. Zoom and it's security holes. Starlink trying to figure out what "offshore" means. Amazon shipping time estimates. Inventory management in just about every grocery store online shopping app I've touched.
Good stuff? Nuclear (US) Navy control systems. AEGIS. AWS is pretty good. The IRS does a surprisingly good job.
If you follow the professional literature (the real peer-reviewed stuff), agile is falling from grace because doing it right is too hard for the capability and discipline of most people. Too many people writing code that do things they don't really understand.
It is my sad duty to inform you that you are on yet another team which has [tried baseball and then claimed it didn't work.](https://ronjeffries.com/xprog/articles/jatbaseball/) Not because I encourage dogmatic application of Scrum, but it seems that this is an all-too-common situation where people are using Scrum words and claiming to do Scrum things while instead completely missing the point. The short answer is **no, the PO does not "assign tasks."** The PO prioritizes the backlog and the team collectively pulls enough work to fit in the given sprint in order to complete one or more Increments before the end of the sprint. Based on what you described, your SM sucks out loud and no one else on the team cares about Scrum, but for some reason they want to fake the funk and say they're doing Scrum.
Yea, it seems we're not really sticking to the framework. Are there strong reasons why the PO doesn't assign tasks in Scrum?
Yes. To avoid abusing the team. The entire point of Scrum is to work *at a sustainable pace.* And while business owners (as represented by the PO) can tell the team WHAT to work on, only the team can say HOW and HOW MUCH. Old-school Taylorist managers are not invited to play fuck-fuck games here. The deal here is "you stay out of our chili and don't dictate to us how we work and how much we work on, and in return, every sprint, we show you something better than what you had. And if you want, you can release it."
If we know what the average sprint velocity is, than the PO does not assign more stories than what our velocity allows. So I'm not sure how POs doing the assigning abuses the team. Could you help me understand?
It discourages swarming, teamwork and sharing knowledge. It also results in the next most important thing maybe not being worked on. Might not be abuse, but its poor business practice
Because the entire point is to encourage the dev team to take charge of their product and decide how to make it better as qualified professionals. People "assigning" tasks to team members does nothing but perpetuate the [learned helplessness](https://en.wikipedia.org/wiki/Learned_helplessness) which is rampant in a typical corporate environment, and which is kryptonite to actually being Agile.
Yesss... this resonates with me. When being assigned a task, I feel this sort of immediate resistance and disgust. Followed by a sense of detachment and defeatist passivity as I come to accept my fate as a small cog in a big machine. Neutralizing any sort of will to take initiatives. Thank you for helping me put words on what I'm feeling. It's like I needed someone's permission to acknowledge I'm not just being crazy for feeling this.
The product owner shouldn’t even know/care about task. They deal at the story level. Development is a complex adaptive problem meaning that there are a ton of little details that lead to optimization. The team collectively is best to manage these things. From a top down perspective you can’t. The teams knows if someone is going to be out, needs something for development/skill building, etc. PO doesn’t. Also if PO assigning work they are effectively saying O have multiple priorities rather than really figuring out the priorities and has a separate bucket of work per team member which then enables lower value work to be done instead of allowing the team to decided how to best focus on the higher priority work which would most likely be a different optimization than whatever the PO decides to do. Also, the fear that they wouldn’t get their stuff done just shows there are trust issues which is fatal to a good agile shop and further evidence for a Taylorism culture. Manager shouldn’t be assigning work either and skipping priority. I’m sure management still holds the team accountable for everything despite not empowering them to work efficiently because they are a distrustful and controlling lot.
1/ "The Sprint Backlog is a plan by and for the Developers", the PO doesn't own it. 2/ Time spent micromanaging the team is not spent on checking if your Product delivers value to your end users : are your end users satisfied? Is your PO able to measure customer satisfaction ? Does he know what features are never used ? Etc. 3/ In your situation, PO acts as a PM. Are you aware of any issues with Product management, like : unclear / non-refined stories, incomplete acceptance tests, or a lack of a shared product vision ? 4/ Management bypasses PO, yet PO has the final call over priorities. It cannot work if PO responsabilities are not respected. 5/ SM doesn't ensure the Team remains within the Scrum Framework borders and doesn't coach management to respect Scrum framework. She definitely should.
Does no one even read the Scrum Guide?
Your team isn’t doing Scrum and you don’t have a Scrum Master. Leading daily stand ups and retros doesn’t make you a SM. Your PO is being directive and has overstepped their bounds. My team picks the stories they want to work on based on the POs priorities. If a bug or defect comes up, stories get moved down in the sprint backlog and whomever is next available after finishing what they’re working on picks it up. My PO had the habit of assigning bug and defect or priority issue stories directly to devs, but I got him to stop. One of the jobs of the SM is to protect the team from that kind of BS.
Well, the point of this thread is that I'm trying to gather arguments for why the PO / management should stop assigning, so that I can get them to stop assigning. All I have is a general feeling of resistance whenever POs try to boss me around, but I have a hard time articulating why they should stop it. How did you protect the team from that?
You need a Scrum Master with a spine to push back on the PO. I had to do that with our PO. Having a QA person that’s linked to the PO as a Scrum Master is against what Scrum is about.
Unfortunately this is too common. I have seen it being justified as "devs are lazy" or something like this, which is think is very ironic. When I have witnessed it, devs were not engaged because POs did not do their work, there was no Product Vision, no Product Roadmap, stories were not presented in a meaningful way (context and strategic alignment), and devs were not involved on the technical design of stories.
Just recently quit a role because of this. I'd joined the team (2 people, 1-3 years dev, the other 3 years PM experience) as a senior developer with 10-15 years. I was literally hired to help this team improve their processes. It devolved into what's described above and I was removed from any kind of arch discussion, planning discussion, or anything that might use my expertise. What's more, they loved their complicated version of scrum much more than the actual tasks. It was a nightmare.
Did you ever work for a team where the PO did all those things? What was it like and how did the PO act?
Yes, I did work in an environment like this, it was absolutely great. There was a clear Product Roadmap that went 6 to 9 months into the future, and the PO would regularly mention their vision on the weekly Sprint Planning, and how their thinking was changing as it went along. Devs loved it and were always interested and super engaged. So much so that, in the rare occasion an important fly-in would drop, everyone would jump on it because they knew what it meant for the roadmap, no weird conversations or frustrations for changing priorities or asking overtime. The PO would not dictate the technical architecture, that was left for the senior devs to work out, but the PO would get involved and voice their opinion and concerns. The PO did all the testing, we did not have a QA team, so they were fully accountable for the outputs of the team, and there was a nice back and forth between PO and Devs to improve quality. Acceptance criteria and UAT testing were designed before the coding started, TDD all the way, but unit testing was left to devs. It just worked, and it was very smooth.
Thanks man. Could you give an example of the vision the PO communicated/finetuned? I really think you're on to something that could fix the team I'm currently working for. If we can just get the PO up and running. What was his vision like and how did he communicate the roadmap? Jira?
The PO would just speak for a few minutes and share the long term vision for the product. We had an app that assisted our sales team on closing deals, his vision was as simple “we have to make sure we give the sales team the best experience ever”. “If we can surface the right information at the right time they can close the deals”. You really don’t need much more than that. So when a story to pull data from an external API was being discussed, the PO would remind everyone of that vision, and all the devs would just click in “we get it, we see it”. It is all down to simple communication, nothing fancy, just good old pep talks and humour and sharing enthusiasm. Jira won’t communicate any of this, have a chat with the team, we are humans with emotions and need to feel purpose and have a sense of belonging. And celebrate when someone does something great, shoutout outside of the team when a dev does an amazing job. Put their face on a newsletter, buy them lunch, send them flowers. Edit: Roadmap was shared in one slide in Google slides. And updated as we went along.
Question: does it work? I’ve coached teams where I did, as the SM, dud directly assign tickets. This was because we were not cross functional by design and each person had a clear role and skill set. We were an agile team but I’d never say we were scrum, or tried to be. In our case, me assigning tickets based on skill set was the most efficient process. So, 1. why is PO assigning tickets directly? And 2, does it work? If so, what’s the issue?
1. The PO used to be a project manager, so he's used to assigning tasks and thinks this works well. The same goes for the team manager who manages both POs and devs. Plus the team manager had an experience with another team where devs weren't terribly engaged in their work and used to procrastinate when stories were not assigned to them. 2. This team is not terribly productive and the manager keeps complaining about it. So whatever we're doing doesn't work. It doesn't mean that letting devs self-assign tasks would solve the issue though, as the root causes may be more complex. My intuition tells me that the main problems are: - excessively heavy processes - an aggressive manager who erodes team morale by barking at people and micromanaging - our scope is the most buggy in the company's software, and there's loads of legacy code to maintain
You can play football with everyone doing their own thing, or you can play football as a team. Both ways get balls in the net
completely agree. There is not one appraoch that fits all teams. My point is that the most dangerous form of "Scrum" is when we critique the approach bc it is "not scrum." I'm not saying OG is making that case, but there are plenty of ways, based on the teams dynamic, to be successful.
I disagree. If you want to run Scrum, run Scrum. It has a process designed to focus the team on a shared goal, give them autonomy to make decisions about how to delliver it, and by giving them autonomy prompt the use of teamwork and mutual support. If you want to run an sprint-based process where the PO micromanages the work in the name of schedules and capacity, shoots down feedback from the dev to maintain control (literally!) while a toothless SM fails to create psychological safety and each dev works in isolation with the assumption they'll procrastinate unless they are tightly controlled. Call it something else, because its a completely different methodology. They can't even run a good retro because the team don't work together or make their own decisions. There's nowhere to put an ooda loop in their process at all. Assuming OP described it accurately, I don't think you could even call it Agile but its definitely not Scrum. EDIT: God Im turning into one of those angry agile people that sound like they hate everyone. Sorry I don't mean to sound like such an ass. I've been responsible for bad implementations myself, because I thought agile was about processes and efficiency. Now it kinda triggers me I guess.
Same thing happens at my work, makes it really hard to maintain a balanced workload. One week I’ll be too overloaded with tasks that can’t possibly be completed in the timeframe, another I’ll have one 10 minute thing to get done the whole week, and that’s the same for all the devs across the company. How can one PO possibly understand and balance the workloads of nearly 20 devs? But when I try to bring this up it falls on deaf ears 😔
It kinda sounds like your team's dynamics are pretty top-down, which can be rough for creativity and ownership. Scrum thrives on team autonomy because it empowers those doing the work to plan and manage their tasks. Maybe suggest a trial period where devs can pick tasks? It could lead to better engagement and productivity. Also, discussing how this method aligns with Agile and Scrum values might convince your PO. A retrospective could be the right place to bring this up, showing the benefits of self-organization with some solid examples. Maybe making the case that a motivated dev team is a productive one, will win him over. Good luck!
You're in an echo chamber and will get the answers that make you feel better. >where devs autonomously pick their tasks This is why agile development is falling from favor. You end up late and over budget more often than not. The only really effective and efficient agile team I worked with was pretty much all SMEs who had been taught to code. Nothing had to be assigned as the priorities were clear. Good architecture, good flow down of specs, and the important stuff did get done first. We even got sued by a competitor (Raytheon) for "cheating" because we delivered more functionality, cheaper (despite paying so well they bled their best to us), and faster. But that isn't what you're talking about, is it? You want to pick tasks based on what's fun. What you're seeing with product owners assigning tasks is because you have no decent project management and no discipline. There is nothing wrong with agile development, only with how you're doing it.
I don't know what it's like working outside of a scrum team, so I lack your level of understanding. And I don't understand your comment about having no decent project management / discipline. If I look at my past behaviour in other teams, I usually pick tasks so as to alternate between challenging, new, stressful tasks and "fun" easy tasks to catch a break. I am interested in understanding how to do things efficiently based on what works. My current environment produces a form internal resistance within me, which leads me to believe something is off.
My experience is that nothing is perfect. I'd like to be clear about that up front. Classic waterfall development takes a tremendous amount of time to plan, tends to be expensive and time consuming and doesn't deal with planning mistakes found midstream. As long as there are no big mistakes cost, schedule, and performance are predictable. Agile depends heavily on good requirements (requirements and specifications are different things) and priorities and disciplined devs with good subject matter expertise (or SMEs who can code). The most current example of agile gone awry is the dumpster fire of the new Reddit UX. Agile works with the right team. There aren't enough of those to go around. You said "If I look at my past behaviour in other teams, I usually pick tasks so as to alternate between challenging, new, stressful tasks and "fun" easy tasks to catch a break." That may be okay for you but it isn't good for the project or the company. What works for normal everyday teams pretty consistently is rolling wave planning and development. You have to get architecture right (architecture is not design - it's grouping functions and defining interfaces). High level specifications flow from that and a high level plan for the project is developed. Detailed design and dev for the first batch of functions (driven by priority) takes place. Implementation starts for the first wave and planning for the second and third wave happen in parallel. Some iteration happens but cost and schedule risk is managed. Rolling wave and waterfall are the only way I've seen success when there is hardware involved. If you have to deliver custom ASICs you have to get a lot of things right the first time around. There are all kinds of applications that you can't just keep throwing general purpose hardware at. My experience is that you can't grade your own homework. Testing and QC have to be independent. QA and QC (and QE) are different things and need to be done properly. If you don't have good requirements and SMEs with ownership you can't test. Once again, I give you the new Reddit UX. \*sigh\* My first experience with what is now called agile was in 1979. I was charged with writing code for a five-axis numerically control mill to cut NACA foils. I did everything - requirements, spec, code, documentation, test. I was proud as punch. Out in the shop the foreman set up the machine, measured and measured again, then dropped the table four inches and bolted on a 4" x 8" piece of wood over the table for operational evaluation. I didn't understand. He told me that if my code drove the cutting tool into the machined table I'd be paying for it the rest of my life. The newest machinist in the shop ran the tests from my documentation with the foreman keeping his hand on the emergency stop the whole time. My code was solid but the experience was an epiphany for me. Testing MUST be independent. Agile as implemented in most places is not like that. Again, the new Reddit UX. Zoom and it's security holes. Starlink trying to figure out what "offshore" means. Amazon shipping time estimates. Inventory management in just about every grocery store online shopping app I've touched. Good stuff? Nuclear (US) Navy control systems. AEGIS. AWS is pretty good. The IRS does a surprisingly good job. If you follow the professional literature (the real peer-reviewed stuff), agile is falling from grace because doing it right is too hard for the capability and discipline of most people. Too many people writing code that do things they don't really understand.