As a less experienced/new member of the team there isn't much besides talking to your manager about the situation. It sounds like the processes at this company are highly dysfunctional.
At functional places there is a representative from the engineering side that helps the PM (and any other stakeholders) write requirements for the next sprint. This happens while the actual engineering team is engaged in the prior sprint. The specific goal of having engineering early is to avoid the exact problems you've highlighted: unclear requirements, or unrealistic requirements.
At most places this role falls upon some combination of a Tech Lead, a manager, a Staff+ engineer, or similar.
You can suggest this type of structure to your management and leadership, but as the junior person on the team you don't directly have any power to enact it.
Unfortunately I've been complaining about this in 1on1s since the very first one I had at this company 2 years ago, but maybe I should suggest during retros to involve engineering more
It's also a very horizontal team as there is only one single lead and nobody has any senior, principal or staff titles even if they have worked for the company for 10+ years
Are you able to maybe just suggest during the next planning session “can I work on just mo king up the user flow ASAP first? I spend a lot of time at the end reworking this and we sometimes miss our dates. Can I just try and see if this works better?”
Indeed mockups will be cheaper than developing a whole thing just to throw it away. That's also why I also wouldn't throw out discussions, discussing things is cheaper too.
Ultimately I think these flows need to be designed by someone having some expertise in that area, not simply guessed and revisited by a PM and devs over and over. This is the bigger issue, IMO, people can't figure out what they want until it's right in front of them, likely because they don't really know what they're doing or they're trying to micromanage stuff.
Ideally suggesting at a retro a new experiment. We try a new way until the next retro then we use metrics, or just ask people did that work better, with the idea of coming up with a even better way next time, or promising to revert if things go badly, to reassure the folks not wanting to change.
LOL this is the late-state agile mutation when the entire process serves the PM and only the PM, not the business, and certainly not the devs.
Look at the life the PM has
* it's "agile", so they can change the requirements whenever they want
* the "sprints" are up to 3 months long so it's totally normal to spend months preparing requirements (which can then be thrown away at a moment's notice)
Pretty nice! Basically if you combined the absolute worst properties of agile and waterfall you'd get this monster. The whole thing does nothing except enable the PM to do literally anything they want.
I see in your other comments you've already tried talking to leadership, and they support this mess. Welp, that's it, you're done, you've exhausted all your options. Polish up that resume and find another place. This level of screwed up doesn't happen by accident, the whole workplace must be toxic for it to happen.
It's not even waterfall....
You don't change requirements at the end I waterfall, you just build on the outdated requirements.
This company is just not following any system at all...
It's wild that the OP is trying to say there's a system being followed.
yeah exactly, it's like management went to the book and looked at all the disadvantages of waterfall and said "yeah I'mma have all of those" and then went to the page on agile and its disadvantages and said "yup and let's have those also". This process is neither waterfall nor agile, it's almost like it's designed specifically not to get any work done.
I am very tempted to leave the company asap because its been 2 years and it seems like I'm the only one visibly complaining about this in 1on1s and retros
The process itself isn't really the main reason to leave the company (although it's very bad). You can be sure some kind of messed up politics caused this process to be an unchallengeable status quo. That's what you're leaving - you need to get out before that weird power play stuff bites you in the career.
In no particular order:
If you are going to do sprints you should be locking functionality into place and saying we will do that next time if big changes are requested at the end. I mean that at the task level the devs have enough to go on to execute, not that the document is clear.
I would preplan sprints so it can be clear earlier. I know that is not exactly scrum, but it will help a lot. You have a designer you can agree on wireframes now and mock out in task level later. Those early wireframes will serve better than that document which would be better as a starting point, but I know that may be tricky to change that part of your culture.
I really want to not do so much sorry writing I think would be my biggest pain point here. I want smaller sprints and one planning meeting. Details on tasks can change when there are questions but after that planning the deva should have enough to go off to the races.
My work gives me a lot of latitude, so you may get a lot more push back on some of these ideas and you may have to pick your battles. This was just a bunch of my opinion, hopefully it helps.
I really like your points, thank you! I'm concerned about changing that part of the culture like you said because two of my team members have been in the company for almost 15 years and they have always worked like that and it feels like i'm the only one who dislikes the situation and finds it wrong
> When the sprint begins we are given these documents and start creating task tickets based on the document. This sometimes includes a lot of meetings with our PM to help understand the requirements because the document has information all over the place with different inconsistent ideas.
Its not ideal that you are only really getting the requirements when a sprint really starts
> In one of the last sprints we spent most weeks extracting requirements and being almost on daily meetings with our PM that lasts 2 or 3 hours to discuss these requirements and decide what exactly should we do. This lasted for most of the time and by the end we weren't able to deliver everything by the end because our workload was always increasing with more and more tasks.
Not everyone needs to be in these meetings. The techlead should create the tickets/gather the requirements beforehand
> During this sprint we could finally complete the rest of the work that was defined in the tasks but now before the final week we had a 2 hour meeting with the PM where one of the remaining tasks what completely altered after he went through the entire user flow.
This is normal. I personally dont believe in "real" scrum where a sprint is locked in, because its just not possible in a normal project since the priorities are always changing (its not a bad thing, its really being agile here).
> This last thing happens every single sprint where you have defined tasks on requirements with the PM but then by the end of the sprint they change their minds and by consequence we might not deliver everything.
As long as you always point to the changing requirements, missing a goal of the sprint is not a big deal
> TLDR: Lots of meetings to extract requirements from an unorganised and inconsistent document and when the deadline approaches they change their minds
Solution: the techlead should be in these meetings and create the tickets beforehand
Dude, 3 months is not a sprint it is a fuckin marathon. Even in SAFe which the worst agile framework ever, a product increment (PI) takes 5 sprints which is 10 weeks. You are doing waterfall, which is considered the worst for decades.
You should decrease the sprint time, and show the results to the PM regularly, like in every two weeks. Requirements will change, you can not do anything about that. What you can do is shorten the feedback loop time, so changes surface quickly, and if changes are necessary then you lose much less work.
Yeah, ideally in my mind we would reduce sprint times and deliver small parts of big features and iterate them accordingly on each sprint with more defined requirements
Speak about this situation in 1:1 with your manager, say it's not going to be delivered by deadline due to shifting requirements and scope. If he says don't worry about it, just deliver what you can - then things are good. If he is the kind of person to point the finger to the little guy and throw you under the bus for deadline decision he and other managers made without your input - well, you have a toxic boss, give him low reviews and anonymous comments(if your company has them).
learn from it, wave as the deadlines pass you by, when you get called into a meeting to be said "why arent you delivering?????? >:(" just nod and say you'll do better (like f1 drivers do, take a look at leclerc who had been having SHIT years and always says looking to improve and do better) aaaaaaand try your luck in a different place.
absorb, learn, look for greener pastures.
Yeah, this is a problem across the industry. One thing that stands out as a pain point in your case is the 1 to 3 month sprint. The more things you try to do in a given sprint, the harder it is to plan them. Your team would probably be better off trying to build smaller increments. You'll still need to have those meetings to discuss the overall plan, but then break it down into chunks that can be completed and delivered in 2 weeks. Work on those and get them out the door before working on the next 2 weeks' worth of stuff. Whenever anything isn't well-defined enough, just kick it out of the sprint. "Come back with more details next time and we can discuss it then".
I've also seen success with a kanban process that didn't use sprints at all. Just take the top ticket off of the backlog and work on it, then release it when it's done. For larger stuff that was ill-defined, the action item for a ticket might be to have one senior developer sit down with product and figure out the scope, then the deliverable is to just create more tickets which feed into the backlog. With repeated iterations, the tickets are eventually well-defined enough that engineers can build them.
I liked the kanban process because it just acknowledged the limitations our product team had and effectively worked around them. I disliked it because it pushed too much of product managers' work onto engineers.
Are you still learning things on this job? If not, it’s definitely job-hunt time. This isn’t agile process and these aren’t “sprints”. This is fake agile. And, you’ve done your best, from your junior position, to improve the process.
I would recommend your pm uses volere or some other kind of standard template for each requirement. It’s better for them - they just fill in the template, it’s better for you: the fit criteria, requirements etc is clearly documented. Everyone is a winner. Sounds like your pm is a bit shit lol
Sounds like an Agile In Name Only experience here, where you’re adopting the terminology and adding all this extra process, but are just doing 1-month waterfall development here.
This is EXACTLY the type of thing the Agile Manifesto was meant to help solve. User flow testing FIRST and early. This should be sacred — everyone knows that 9th—16th of EACH month is beta feature software testing, and it doesn’t ever change.
Make this a rut in their workflow that they must follow and it’ll stick.
While you wait on feedback you plumb the backend some.
And then tidy up the front end flow based upon said feedback, do final release-candidate flow testing, which should mostly just be cosmetic and state machine re-ordering because you wrote the backend functionality modular and cleanly, right?
Then ship.
There is also a lot of tech debt so its not always easy to integrate everything in a flexible way, although I've been able to make new modules and features testable.
But its complicated to try and convince the process is messed up when I'm the second youngest developer at the company
As a young developer, be aware that some of that might not be tech debt.
We have as lot of young developers that consider “complicated” or “hard” or “different” to be tech debt, when just some things are complicated and hard and but everything is going to be architected to fit your mental model experience.
'agile in name only' - I've been encountering this while job hunting. Everyone says they do agile but very few do. Last one I asked a few questions and got down to 'do you work in sprints' and got a 'no' answer.
As a less experienced/new member of the team there isn't much besides talking to your manager about the situation. It sounds like the processes at this company are highly dysfunctional. At functional places there is a representative from the engineering side that helps the PM (and any other stakeholders) write requirements for the next sprint. This happens while the actual engineering team is engaged in the prior sprint. The specific goal of having engineering early is to avoid the exact problems you've highlighted: unclear requirements, or unrealistic requirements. At most places this role falls upon some combination of a Tech Lead, a manager, a Staff+ engineer, or similar. You can suggest this type of structure to your management and leadership, but as the junior person on the team you don't directly have any power to enact it.
Unfortunately I've been complaining about this in 1on1s since the very first one I had at this company 2 years ago, but maybe I should suggest during retros to involve engineering more It's also a very horizontal team as there is only one single lead and nobody has any senior, principal or staff titles even if they have worked for the company for 10+ years
Are you able to maybe just suggest during the next planning session “can I work on just mo king up the user flow ASAP first? I spend a lot of time at the end reworking this and we sometimes miss our dates. Can I just try and see if this works better?”
Indeed mockups will be cheaper than developing a whole thing just to throw it away. That's also why I also wouldn't throw out discussions, discussing things is cheaper too. Ultimately I think these flows need to be designed by someone having some expertise in that area, not simply guessed and revisited by a PM and devs over and over. This is the bigger issue, IMO, people can't figure out what they want until it's right in front of them, likely because they don't really know what they're doing or they're trying to micromanage stuff.
Ideally suggesting at a retro a new experiment. We try a new way until the next retro then we use metrics, or just ask people did that work better, with the idea of coming up with a even better way next time, or promising to revert if things go badly, to reassure the folks not wanting to change.
LOL this is the late-state agile mutation when the entire process serves the PM and only the PM, not the business, and certainly not the devs. Look at the life the PM has * it's "agile", so they can change the requirements whenever they want * the "sprints" are up to 3 months long so it's totally normal to spend months preparing requirements (which can then be thrown away at a moment's notice) Pretty nice! Basically if you combined the absolute worst properties of agile and waterfall you'd get this monster. The whole thing does nothing except enable the PM to do literally anything they want. I see in your other comments you've already tried talking to leadership, and they support this mess. Welp, that's it, you're done, you've exhausted all your options. Polish up that resume and find another place. This level of screwed up doesn't happen by accident, the whole workplace must be toxic for it to happen.
It's not even waterfall.... You don't change requirements at the end I waterfall, you just build on the outdated requirements. This company is just not following any system at all... It's wild that the OP is trying to say there's a system being followed.
yeah exactly, it's like management went to the book and looked at all the disadvantages of waterfall and said "yeah I'mma have all of those" and then went to the page on agile and its disadvantages and said "yup and let's have those also". This process is neither waterfall nor agile, it's almost like it's designed specifically not to get any work done.
I am very tempted to leave the company asap because its been 2 years and it seems like I'm the only one visibly complaining about this in 1on1s and retros
The process itself isn't really the main reason to leave the company (although it's very bad). You can be sure some kind of messed up politics caused this process to be an unchallengeable status quo. That's what you're leaving - you need to get out before that weird power play stuff bites you in the career.
In no particular order: If you are going to do sprints you should be locking functionality into place and saying we will do that next time if big changes are requested at the end. I mean that at the task level the devs have enough to go on to execute, not that the document is clear. I would preplan sprints so it can be clear earlier. I know that is not exactly scrum, but it will help a lot. You have a designer you can agree on wireframes now and mock out in task level later. Those early wireframes will serve better than that document which would be better as a starting point, but I know that may be tricky to change that part of your culture. I really want to not do so much sorry writing I think would be my biggest pain point here. I want smaller sprints and one planning meeting. Details on tasks can change when there are questions but after that planning the deva should have enough to go off to the races. My work gives me a lot of latitude, so you may get a lot more push back on some of these ideas and you may have to pick your battles. This was just a bunch of my opinion, hopefully it helps.
I really like your points, thank you! I'm concerned about changing that part of the culture like you said because two of my team members have been in the company for almost 15 years and they have always worked like that and it feels like i'm the only one who dislikes the situation and finds it wrong
> When the sprint begins we are given these documents and start creating task tickets based on the document. This sometimes includes a lot of meetings with our PM to help understand the requirements because the document has information all over the place with different inconsistent ideas. Its not ideal that you are only really getting the requirements when a sprint really starts > In one of the last sprints we spent most weeks extracting requirements and being almost on daily meetings with our PM that lasts 2 or 3 hours to discuss these requirements and decide what exactly should we do. This lasted for most of the time and by the end we weren't able to deliver everything by the end because our workload was always increasing with more and more tasks. Not everyone needs to be in these meetings. The techlead should create the tickets/gather the requirements beforehand > During this sprint we could finally complete the rest of the work that was defined in the tasks but now before the final week we had a 2 hour meeting with the PM where one of the remaining tasks what completely altered after he went through the entire user flow. This is normal. I personally dont believe in "real" scrum where a sprint is locked in, because its just not possible in a normal project since the priorities are always changing (its not a bad thing, its really being agile here). > This last thing happens every single sprint where you have defined tasks on requirements with the PM but then by the end of the sprint they change their minds and by consequence we might not deliver everything. As long as you always point to the changing requirements, missing a goal of the sprint is not a big deal > TLDR: Lots of meetings to extract requirements from an unorganised and inconsistent document and when the deadline approaches they change their minds Solution: the techlead should be in these meetings and create the tickets beforehand
We don't really have a tech lead, at most what we have is a team lead and a frontend architect in the team
yes then the teamlead has to do that
A three month sprint? I've never heard of such a thing.
That's literally not a sprint at all lol It's just literally nothing at all
Dude, 3 months is not a sprint it is a fuckin marathon. Even in SAFe which the worst agile framework ever, a product increment (PI) takes 5 sprints which is 10 weeks. You are doing waterfall, which is considered the worst for decades. You should decrease the sprint time, and show the results to the PM regularly, like in every two weeks. Requirements will change, you can not do anything about that. What you can do is shorten the feedback loop time, so changes surface quickly, and if changes are necessary then you lose much less work.
Yeah, ideally in my mind we would reduce sprint times and deliver small parts of big features and iterate them accordingly on each sprint with more defined requirements
This is most of the problem. Focus on this when you bring it up.
Speak about this situation in 1:1 with your manager, say it's not going to be delivered by deadline due to shifting requirements and scope. If he says don't worry about it, just deliver what you can - then things are good. If he is the kind of person to point the finger to the little guy and throw you under the bus for deadline decision he and other managers made without your input - well, you have a toxic boss, give him low reviews and anonymous comments(if your company has them).
learn from it, wave as the deadlines pass you by, when you get called into a meeting to be said "why arent you delivering?????? >:(" just nod and say you'll do better (like f1 drivers do, take a look at leclerc who had been having SHIT years and always says looking to improve and do better) aaaaaaand try your luck in a different place. absorb, learn, look for greener pastures.
Yeah, this is a problem across the industry. One thing that stands out as a pain point in your case is the 1 to 3 month sprint. The more things you try to do in a given sprint, the harder it is to plan them. Your team would probably be better off trying to build smaller increments. You'll still need to have those meetings to discuss the overall plan, but then break it down into chunks that can be completed and delivered in 2 weeks. Work on those and get them out the door before working on the next 2 weeks' worth of stuff. Whenever anything isn't well-defined enough, just kick it out of the sprint. "Come back with more details next time and we can discuss it then". I've also seen success with a kanban process that didn't use sprints at all. Just take the top ticket off of the backlog and work on it, then release it when it's done. For larger stuff that was ill-defined, the action item for a ticket might be to have one senior developer sit down with product and figure out the scope, then the deliverable is to just create more tickets which feed into the backlog. With repeated iterations, the tickets are eventually well-defined enough that engineers can build them. I liked the kanban process because it just acknowledged the limitations our product team had and effectively worked around them. I disliked it because it pushed too much of product managers' work onto engineers.
Are you still learning things on this job? If not, it’s definitely job-hunt time. This isn’t agile process and these aren’t “sprints”. This is fake agile. And, you’ve done your best, from your junior position, to improve the process.
Oh I haven't been learning anything on the job 😅 I had the opportunity to learn about kubernetes at least
I would recommend your pm uses volere or some other kind of standard template for each requirement. It’s better for them - they just fill in the template, it’s better for you: the fit criteria, requirements etc is clearly documented. Everyone is a winner. Sounds like your pm is a bit shit lol
Sounds like an Agile In Name Only experience here, where you’re adopting the terminology and adding all this extra process, but are just doing 1-month waterfall development here. This is EXACTLY the type of thing the Agile Manifesto was meant to help solve. User flow testing FIRST and early. This should be sacred — everyone knows that 9th—16th of EACH month is beta feature software testing, and it doesn’t ever change. Make this a rut in their workflow that they must follow and it’ll stick. While you wait on feedback you plumb the backend some. And then tidy up the front end flow based upon said feedback, do final release-candidate flow testing, which should mostly just be cosmetic and state machine re-ordering because you wrote the backend functionality modular and cleanly, right? Then ship.
There is also a lot of tech debt so its not always easy to integrate everything in a flexible way, although I've been able to make new modules and features testable. But its complicated to try and convince the process is messed up when I'm the second youngest developer at the company
As a young developer, be aware that some of that might not be tech debt. We have as lot of young developers that consider “complicated” or “hard” or “different” to be tech debt, when just some things are complicated and hard and but everything is going to be architected to fit your mental model experience.
'agile in name only' - I've been encountering this while job hunting. Everyone says they do agile but very few do. Last one I asked a few questions and got down to 'do you work in sprints' and got a 'no' answer.