4 ms·

Considering leaving job because of SCRUM

28 points by chuck4932 9y ago

I am a software developer and I love software development. I love coming up with clever solutions to problems, I love refactoring parts of a codebase - reduing the number of lines of code and making things more understandable, I even love the boring bits - fixing bugs etc. However I feel that the practice of SCRUM in my current job is preventing me from doing that. Anytime an interesting problem comes up to solve we reduce it into ridiculously small cards like "research how to connect to this API", "Evaluate if we can use this library", "Write a proposal on how to do X" etc. So a problem which would take 1-2 months for a couple developers working together to solve now takes 6 months. Because we break it into unrealistically small steps and as soon as you finish one step you have to wait for the end of the sprint (2 weeks) and present it, then groom/plan the next step. Its micromanagement to the extreme. No boss would ever be able to micro manage this much but for an entire team participating in scrum this is what happens. Its impossible for me to sink my teeth into any interesting problems. I feel like the other developers on the team have bought into the scrum mindset and we treat each other like children who need to be told exactly what to do and how to do it, there can be no unknowns. For somebody who gets a thrill out of a challenge the SCRUM mentality is driving me crazy. I have brought up some of these issues and nobody else on the team feels the same way. I think I am not a good fit for this team because of that. The reason why this is a dilemma for me is because everything else about this job is good: the colleagues are nice, the pay is good, the work-life balance is good. But the way we work is frustrating and boring. Has anybody else experienced something similar? Are we not doing SCRUM right? If so what could we change about how we practice SCRUM?

lobsterloga 9y ago
Convince the team to switch to Agile Kanban. Now you can work on your card as long as you need to. Problem solved. :) Agile Scrum is not the only way to do Agile.
Dunedan 9y ago
> Because we break it into unrealistically small steps and as soon as you finish one step you have to wait for the end of the sprint (2 weeks) and present it, then groom/plan the next step. That sounds utterly wrong. If you're ahead of what you planned to achieve in a sprint you usually fetch the next tasks sitting in the backlog to get as much done as possible. The sprint scope should just be a realistic goal the team commits to. If it can achieve more: even better.
matt_s 9y ago
Kanban is better, especially paired up with continuous delivery. Once something is done, ship it and move onto something else. Longer research things can be broken down into smaller cards, you're just constantly pulling them in. We skip estimates, they prove to be useless indicators of when something will be done so why bother? I think our PM's use velocity as a metric (num of cards done over time) and generally plan enough work so we aren't idle. If you have a weekly grooming session to keep grooming the cards that are next, there shouldn't be wait times. Waiting for sprint review before moving onto further steps is wasting time which goes against Lean Software Development principles.
- jfaucett 9y ago
  Completely agree. I arrived at a more or less kanban methodology, with a few leftovers from SCRUM of things that do work, like biweekly reviews of the past "sprint period" to evaluate progress and direction, and groom the backlog. It took a couple years of pain and struggle to develop the highly adaptive and dynamic continuous delivery system I now use when managing projects, and I would never return to SCRUM. It works better than the good ol waterfall method perhaps, but it is nowhere near the SE optimum.
- chuck4932 9y ago
  I will look into Kanban since it has been suggested many times here. However, I'm skeptical of these rigid processes in general. I dont see the need for them unless you have extremely strict requirements from management. I don't see whats wrong with having somebody who is a project manager who understands the work being done and who coordinates with the developers to ensure it gets done in time. In other places it would have been like Project Manger says "we need a feature to do this, this and this, how long do you think it will take?", "I say I will need to spend a few days working on it and then tell you a very rough estimate", after a few days I say "I think it will take at least a month maybe two" or something like that. If I see that there is more work that needs to be done or it will take longer than I initially I thought then I go back to the PM and we re-evaluate what to do. Its not that difficult.
  - matt_s 9y ago
GFischer 9y ago
Did you bring it up with your management? The sibling comments about Kanban are spot on. Management probably is rightly worried about tracking and estimating, if you can offer an alternative that can get them that they'll be on board. However, your description of "1-2 months for a couple developers" does ring warning bells for me. Having the adequate granularity is good. Also, many times "1-2 months" doesn't take into account everything needed. I absolutely agree that "wait for the end of the sprint and present" is not a good way to do it. If I were a manager, I'd try to minimize "unknowns" and "challenges", I understand what you're saying as a developer, there has to be a balance - where I am we agreed to have google-style 20% research time and us developers have a lot of agency and input into schedules and next steps.
- sheepmullet 9y ago
  > Management probably is rightly worried about tracking and estimating The real question is why are they worried about tracking and estimating? From there you can work out the granularity required. Unfortunately often when management shows interest in sprint level details it is because they don’t trust the team and tracking the numbers helps them feel in control. > If I were a manager, I'd try to minimize "unknowns" and "challenges" A senior dev should be looking across the project and trying to minimize unknowns and challenges. Then it aggregates up the chain. Scrum does have an unfortunate tendency of removing responsibility for the bigger picture from developers.
mofino 9y ago
Classic problem of non-technical management making technical decisions.
seanwilson 9y ago
> Has anybody else experienced something similar? Are we not doing SCRUM right? If so what could we change about how we practice SCRUM? Not much to add except I've been in a similar situation and it just sucked all the fun and productivity out of coding for me. I was told what order tasks had to be done in even when it was obviously going to create merge conflicts with other developers, wasn't allowed to do a quick refactor as I went as that had to be added as a new task, had very little influence over what was to be implemented even though I had a better understanding of the risks involved as I understood the code etc. Maybe it works when some developers need more hand holding to keep focused but I prefer being given higher level tasks, a deadline and just being left to get on with things.
mod 9y ago
> Anytime an interesting problem comes up to solve we reduce it into ridiculously small cards like "research how to connect to this API", "Evaluate if we can use this library", "Write a proposal on how to do X" etc. Disclaimer: I'm not familiar with SCRUM. But I don't get it, these don't seem ridiculously small at all. I guess if you're blocked before you get the next task, I understand that pain point, but those seem like nice actionable tasks. It seems like revisiting the old codebase is something you could do during all your waiting time?
- sheepmullet 9y ago
  > Disclaimer: I'm not familiar with SCRUM. But I don't get it, these don't seem ridiculously small at all. The problem is the process is only indirectly driven by the real problem you are trying to solve and the feedback loop is slowed down 100 fold. In reality you might look at an API for a couple of hours and realise it isn’t suitable. Maybe in fact you realise that using an external API is the wrong approach altogether. This kind of think, investigate, tinker, evaluate, change loop happens hundreds of times in solving a reasonably sized 6-8 week feature. If you have to stop and wait for the next team meeting before moving forwards to the next iteration of the loop you are in trouble. In reality it causes developers to stop thinking or caring about solving the actual problem optimally. Instead it becomes all about just finishing the next ticket and leaving the hard thinking to once a fortnight.
debacle 9y ago
> Because we break it into unrealistically small steps and as soon as you finish one step you have to wait for the end of the sprint (2 weeks) and present it, then groom/plan the next step. This isn't really how sprints are supposed to work. Seems like a misunderstanding of how to manage a backlog.
- quickthrower2 9y ago
  How is it supposed to work? You have a piece of work that takes about 12 weeks, for example. You have 2 week sprints. You need to break it down into chunks you can do inside 2 weeks. However estimating sucks. You might need 4 weeks for one of the chunks, or 4 hours. You find out once you start looking at the legacy code and find you need to refactor 10k lines of code, or just flick a bit. If it takes 4 hours, do you wait 2 weeks to do the next chunk or bring it forward. In the scrum guide [1] there is no mention about putting more stuff in mid-sprint, so I assume it is OK to do that. What if it takes too long? Roll it over to the next sprint. I guess in spite of Scrum you can continuously work on the 12 week feature, and make the right motions to keep the process happy. [1] http://www.scrumguides.org/scrum-guide.html http://www.scrumguides.org/scrum-guide.html
  - quickthrower2 9y ago
    Add: I think the breaking up of the 12 weeks into chunks is a good practice so you can measure progress, and have discussions about removing bits if you blow up on time. However if 1 dev is doing this work they can do it on their own rhythm - maybe releasing 3 things in one week and nothing for 3 weeks. There is no need to synchronize with the team.
  - tucaz 9y ago
    May I ask what could possibly take 12 weeks worth of work before having anything useful? The idea behind any agile method is exactly to fight that kind of mentality that says you can only have software done in a Big Bang approach where everything gets released all at once. If a piece of software needs 12 weeks to be done then there is something wrong with your software environment. There’s always a way to release something useful in 2 weeks or even less. Some people do daily releases. The catch here that might not be obvious unless you look for it is that what you release in 2 weeks doesn’t have to be complete. Just ready. If you are making a search engine of course you need more than 12 weeks, but in the first sprint you can release the component to tokenize strings, for example.
lamansion 9y ago
If there are other people in your team who think the same, then bring it up to your manager(s). Unless you bring it up nothing will change so the only way out is to leave the company at that point.
tobywan 9y ago
Scrum can be sane and in no way mandates 'unrealistically small steps.' To me it sounds like there's a problem in youir team's story/ticket writing. Stories should be manageable by a single developer, and can be broken out with subtasks as needed. (note: I'm in the Agile is Dead camp espoused by Dave Thomas - watch that vid if you haven't). Agile is supposed to enable visibility and transparency and of course agility. That's the essence, really. If you have an overly-religious Agile zealot in your presence, I feel for you; try to talk them away from the dogmatism.
- sheepmullet 9y ago
  > supposed to enable visibility and transparency Which is the last thing you want to do if you have people above you in the org chart who love to micromanage.
muzani 9y ago
I recommend you bring it up to your boss. Tech leads are supposed to one on one anyway, to spot issues like this. Other alternatives would be Kanban and XP. Kanban might give you the flow and flexibility you like, XP might give management the control they want but still give you more flexibility.
sevilo 9y ago
I have experienced similar, not as extreme but the feeling of being overly mindful of "risks", creating lots of spikes rather than just doing what needs to be done. Estimation in scrums are meant for exactly -- estimation, a way for developers to do a sanity check on if there are major disagreements on how complex an issue is and therefore its value when comparing to current business priorities. If you're breaking it down so small just so you feel you have "completed" sprints, you're gaming the system and lying to yourselves. Just understand that it is OK to not complete sprints, as long as you have a goal you can measure against and get a good feeling to how well you did. Why not try to be more transparent and open with your team? Exactly what you just wrote here and let them know and then maybe you can have a discussion and see what happens from there, maybe they could move to something else like Kanban, or maybe they can improve the current way they work. If still nobody is willing to change and your frustration continues, then consider if you should leave your job. Sometimes people in a team develop this group-think and it doesn't necessarily mean there's no hope, often it just takes someone to take the initiative and voice their frustrations.
lovelearning 9y ago
I think trying to find satisfaction in your day job can be a lottery. Since these methodologies are so popular, there's no guarantee the next job is going to be any better. This article - on the topic of such methodologies working great for the employer but not for employees - may resonate with your personal experiences [1]. Given that everything else about the job is good, I suggest staying there, coding your own software at home, doing it in whatever way you enjoy most, and finding satisfaction through your personal projects. [1]: https://michaelochurch.wordpress.com/2015/06/06/why-agile-and-especially-scrum-are-terrible/ https://michaelochurch.wordpress.com/2015/06/06/why-agile-an...
- chuck4932 9y ago
  The "Terminal juniority" part really resonates with me. Especially about programmers focusing on "the low-yield, easy stuff that the business doesn’t actually need but that is “safe”".
rajacombinator 9y ago
Sounds horrific. I’d definitely leave and go somewhere with more intelligent people.
itronitron 9y ago
One option may be to assign you work at a higher level and have the product manager define stories/epics with corresponding acceptance criteria to be met at the end of the sprint. That would remove a lot of the sub-task explosion and provide you some freedom to decide how to write the code in order to satisfy the acceptance criteria. Kanban is a bit more flexible than Scrum, as devs aren't locked into a specific set of tasks for each sprint but the micro-management with cards still exists. In my experience, teams are more productive when they spend time on design discussions (and not card creation.) I consider standups completely useless.
tboyd47 9y ago
To feed your challenge withdrawal, I recommend getting into DevOps. Companies these days are goo-goo ga-ga over anything automated. If you can automate any part of your build pipeline, just try it and see how it goes. You'll need to make time, and here's how: use your scrum tickets for cover. Pick an average amount of work off the backlog, and take an average amount of time to complete it. Probably, you will have a lot of time in between for your own projects. Work on it in secret and don't let management know what you're doing until you can SHOW them. Long-term, I recommend getting into management, either product, if you're more inclined to creative pursuits, or project, if you're more inclined to helping others. This will allow you to be released from the tedious grind of scrum tickets and do more high-level, skunkworks projects.

28 points by chuck4932 9y ago

lobsterloga 9y ago

Convince the team to switch to Agile Kanban. Now you can work on your card as long as you need to. Problem solved. :) Agile Scrum is not the only way to do Agile.

Dunedan 9y ago

> Because we break it into unrealistically small steps and as soon as you finish one step you have to wait for the end of the sprint (2 weeks) and present it, then groom/plan the next step. That sounds utterly wrong. If you're ahead of what you planned to achieve in a sprint you usually fetch the next tasks sitting in the backlog to get as much done as possible. The sprint scope should just be a realistic goal the team commits to. If it can achieve more: even better.

matt_s 9y ago

Kanban is better, especially paired up with continuous delivery. Once something is done, ship it and move onto something else. Longer research things can be broken down into smaller cards, you're just constantly pulling them in. We skip estimates, they prove to be useless indicators of when something will be done so why bother? I think our PM's use velocity as a metric (num of cards done over time) and generally plan enough work so we aren't idle. If you have a weekly grooming session to keep grooming the cards that are next, there shouldn't be wait times. Waiting for sprint review before moving onto further steps is wasting time which goes against Lean Software Development principles.

jfaucett 9y ago
Completely agree. I arrived at a more or less kanban methodology, with a few leftovers from SCRUM of things that do work, like biweekly reviews of the past "sprint period" to evaluate progress and direction, and groom the backlog. It took a couple years of pain and struggle to develop the highly adaptive and dynamic continuous delivery system I now use when managing projects, and I would never return to SCRUM. It works better than the good ol waterfall method perhaps, but it is nowhere near the SE optimum.
chuck4932 9y ago
I will look into Kanban since it has been suggested many times here. However, I'm skeptical of these rigid processes in general. I dont see the need for them unless you have extremely strict requirements from management. I don't see whats wrong with having somebody who is a project manager who understands the work being done and who coordinates with the developers to ensure it gets done in time. In other places it would have been like Project Manger says "we need a feature to do this, this and this, how long do you think it will take?", "I say I will need to spend a few days working on it and then tell you a very rough estimate", after a few days I say "I think it will take at least a month maybe two" or something like that. If I see that there is more work that needs to be done or it will take longer than I initially I thought then I go back to the PM and we re-evaluate what to do. Its not that difficult.
- matt_s 9y ago

GFischer 9y ago

Did you bring it up with your management? The sibling comments about Kanban are spot on. Management probably is rightly worried about tracking and estimating, if you can offer an alternative that can get them that they'll be on board. However, your description of "1-2 months for a couple developers" does ring warning bells for me. Having the adequate granularity is good. Also, many times "1-2 months" doesn't take into account everything needed. I absolutely agree that "wait for the end of the sprint and present" is not a good way to do it. If I were a manager, I'd try to minimize "unknowns" and "challenges", I understand what you're saying as a developer, there has to be a balance - where I am we agreed to have google-style 20% research time and us developers have a lot of agency and input into schedules and next steps.

sheepmullet 9y ago
> Management probably is rightly worried about tracking and estimating The real question is why are they worried about tracking and estimating? From there you can work out the granularity required. Unfortunately often when management shows interest in sprint level details it is because they don’t trust the team and tracking the numbers helps them feel in control. > If I were a manager, I'd try to minimize "unknowns" and "challenges" A senior dev should be looking across the project and trying to minimize unknowns and challenges. Then it aggregates up the chain. Scrum does have an unfortunate tendency of removing responsibility for the bigger picture from developers.

mofino 9y ago

Classic problem of non-technical management making technical decisions.

seanwilson 9y ago

> Has anybody else experienced something similar? Are we not doing SCRUM right? If so what could we change about how we practice SCRUM? Not much to add except I've been in a similar situation and it just sucked all the fun and productivity out of coding for me. I was told what order tasks had to be done in even when it was obviously going to create merge conflicts with other developers, wasn't allowed to do a quick refactor as I went as that had to be added as a new task, had very little influence over what was to be implemented even though I had a better understanding of the risks involved as I understood the code etc. Maybe it works when some developers need more hand holding to keep focused but I prefer being given higher level tasks, a deadline and just being left to get on with things.

mod 9y ago

> Anytime an interesting problem comes up to solve we reduce it into ridiculously small cards like "research how to connect to this API", "Evaluate if we can use this library", "Write a proposal on how to do X" etc. Disclaimer: I'm not familiar with SCRUM. But I don't get it, these don't seem ridiculously small at all. I guess if you're blocked before you get the next task, I understand that pain point, but those seem like nice actionable tasks. It seems like revisiting the old codebase is something you could do during all your waiting time?

sheepmullet 9y ago
> Disclaimer: I'm not familiar with SCRUM. But I don't get it, these don't seem ridiculously small at all. The problem is the process is only indirectly driven by the real problem you are trying to solve and the feedback loop is slowed down 100 fold. In reality you might look at an API for a couple of hours and realise it isn’t suitable. Maybe in fact you realise that using an external API is the wrong approach altogether. This kind of think, investigate, tinker, evaluate, change loop happens hundreds of times in solving a reasonably sized 6-8 week feature. If you have to stop and wait for the next team meeting before moving forwards to the next iteration of the loop you are in trouble. In reality it causes developers to stop thinking or caring about solving the actual problem optimally. Instead it becomes all about just finishing the next ticket and leaving the hard thinking to once a fortnight.

debacle 9y ago

quickthrower2 9y ago
How is it supposed to work? You have a piece of work that takes about 12 weeks, for example. You have 2 week sprints. You need to break it down into chunks you can do inside 2 weeks. However estimating sucks. You might need 4 weeks for one of the chunks, or 4 hours. You find out once you start looking at the legacy code and find you need to refactor 10k lines of code, or just flick a bit. If it takes 4 hours, do you wait 2 weeks to do the next chunk or bring it forward. In the scrum guide [1] there is no mention about putting more stuff in mid-sprint, so I assume it is OK to do that. What if it takes too long? Roll it over to the next sprint. I guess in spite of Scrum you can continuously work on the 12 week feature, and make the right motions to keep the process happy. [1] http://www.scrumguides.org/scrum-guide.html http://www.scrumguides.org/scrum-guide.html
- quickthrower2 9y ago
  Add: I think the breaking up of the 12 weeks into chunks is a good practice so you can measure progress, and have discussions about removing bits if you blow up on time. However if 1 dev is doing this work they can do it on their own rhythm - maybe releasing 3 things in one week and nothing for 3 weeks. There is no need to synchronize with the team.
- tucaz 9y ago
  May I ask what could possibly take 12 weeks worth of work before having anything useful? The idea behind any agile method is exactly to fight that kind of mentality that says you can only have software done in a Big Bang approach where everything gets released all at once. If a piece of software needs 12 weeks to be done then there is something wrong with your software environment. There’s always a way to release something useful in 2 weeks or even less. Some people do daily releases. The catch here that might not be obvious unless you look for it is that what you release in 2 weeks doesn’t have to be complete. Just ready. If you are making a search engine of course you need more than 12 weeks, but in the first sprint you can release the component to tokenize strings, for example.

lamansion 9y ago

If there are other people in your team who think the same, then bring it up to your manager(s). Unless you bring it up nothing will change so the only way out is to leave the company at that point.

tobywan 9y ago

Scrum can be sane and in no way mandates 'unrealistically small steps.' To me it sounds like there's a problem in youir team's story/ticket writing. Stories should be manageable by a single developer, and can be broken out with subtasks as needed. (note: I'm in the Agile is Dead camp espoused by Dave Thomas - watch that vid if you haven't). Agile is supposed to enable visibility and transparency and of course agility. That's the essence, really. If you have an overly-religious Agile zealot in your presence, I feel for you; try to talk them away from the dogmatism.

sheepmullet 9y ago
> supposed to enable visibility and transparency Which is the last thing you want to do if you have people above you in the org chart who love to micromanage.

muzani 9y ago

I recommend you bring it up to your boss. Tech leads are supposed to one on one anyway, to spot issues like this. Other alternatives would be Kanban and XP. Kanban might give you the flow and flexibility you like, XP might give management the control they want but still give you more flexibility.

sevilo 9y ago

I have experienced similar, not as extreme but the feeling of being overly mindful of "risks", creating lots of spikes rather than just doing what needs to be done. Estimation in scrums are meant for exactly -- estimation, a way for developers to do a sanity check on if there are major disagreements on how complex an issue is and therefore its value when comparing to current business priorities. If you're breaking it down so small just so you feel you have "completed" sprints, you're gaming the system and lying to yourselves. Just understand that it is OK to not complete sprints, as long as you have a goal you can measure against and get a good feeling to how well you did. Why not try to be more transparent and open with your team? Exactly what you just wrote here and let them know and then maybe you can have a discussion and see what happens from there, maybe they could move to something else like Kanban, or maybe they can improve the current way they work. If still nobody is willing to change and your frustration continues, then consider if you should leave your job. Sometimes people in a team develop this group-think and it doesn't necessarily mean there's no hope, often it just takes someone to take the initiative and voice their frustrations.

lovelearning 9y ago

I think trying to find satisfaction in your day job can be a lottery. Since these methodologies are so popular, there's no guarantee the next job is going to be any better. This article - on the topic of such methodologies working great for the employer but not for employees - may resonate with your personal experiences [1]. Given that everything else about the job is good, I suggest staying there, coding your own software at home, doing it in whatever way you enjoy most, and finding satisfaction through your personal projects. [1]: https://michaelochurch.wordpress.com/2015/06/06/why-agile-and-especially-scrum-are-terrible/ https://michaelochurch.wordpress.com/2015/06/06/why-agile-an...

chuck4932 9y ago
The "Terminal juniority" part really resonates with me. Especially about programmers focusing on "the low-yield, easy stuff that the business doesn’t actually need but that is “safe”".

rajacombinator 9y ago

Sounds horrific. I’d definitely leave and go somewhere with more intelligent people.

itronitron 9y ago

One option may be to assign you work at a higher level and have the product manager define stories/epics with corresponding acceptance criteria to be met at the end of the sprint. That would remove a lot of the sub-task explosion and provide you some freedom to decide how to write the code in order to satisfy the acceptance criteria. Kanban is a bit more flexible than Scrum, as devs aren't locked into a specific set of tasks for each sprint but the micro-management with cards still exists. In my experience, teams are more productive when they spend time on design discussions (and not card creation.) I consider standups completely useless.

tboyd47 9y ago

To feed your challenge withdrawal, I recommend getting into DevOps. Companies these days are goo-goo ga-ga over anything automated. If you can automate any part of your build pipeline, just try it and see how it goes. You'll need to make time, and here's how: use your scrum tickets for cover. Pick an average amount of work off the backlog, and take an average amount of time to complete it. Probably, you will have a lot of time in between for your own projects. Work on it in secret and don't let management know what you're doing until you can SHOW them. Long-term, I recommend getting into management, either product, if you're more inclined to creative pursuits, or project, if you're more inclined to helping others. This will allow you to be released from the tedious grind of scrum tickets and do more high-level, skunkworks projects.