
Considering leaving job because of SCRUM - chuck4932
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 &quot;research how to connect to this API&quot;, &quot;Evaluate if we can use this library&quot;, &quot;Write a proposal on how to do X&quot; etc.<p>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&#x2F;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.<p>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.<p>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.<p>Has anybody else experienced something similar? Are we not doing SCRUM right? If so what could we change about how we practice SCRUM?
======
matt_s
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.

~~~
chuck4932
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
If you are estimating things at increments like "a month" then you need to
break things down into smaller chunks that are deliverable.

The key part is continuous delivery - even if nobody uses the small addition
or you need to put a feature flag in that "turns it on" at some point in the
future. If you get into the practice of continuous delivery, which means a dev
can ship something into production anytime they need to (with approvals, code
review, etc.) then it becomes a more fluid process.

Take building a To Do app. It might take a month to deliver the whole thing,
right? What if you broke it down into smaller chunks like:

* Showing a static list of open items

* Clicking an item marks it complete in UI

* Save state to a database

* Archiving items

If each of those 4 were shippable to production with tests, etc. then you can
incrementally build the system. It may sound like extra work but once you
automate away the builds, running tests, and deploys you can respond much
quicker to changes.

------
tobywan
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
> 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.

------
sevilo
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.

------
tboyd47
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.

------
itronitron
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.

------
GFischer
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
> 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.

------
debacle
> 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
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)

~~~
tucaz
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.

~~~
sheepmullet
> May I ask what could possibly take 12 weeks worth of work before having
> anything useful?

12 person weeks is a tiny amount of effort.

> but in the first sprint you can release the component to tokenize strings,
> for example.

Ah I see - You just have to redefine what useful means :P.

If your customer needs a search engine then having a string tokenizer is not
useful at all.

You don't run a project this way to improve individual developer productivity.
You run it this way to reduce infrastructure and project risk.

Often using Scrum practices is a good tradeoff - the problem is the messaging.
The truth is we are trading off developer productivity and growth in order to
lower overall risk and make the software process more predictable.

------
seanwilson
> 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.

------
lovelearning
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-
an...](https://michaelochurch.wordpress.com/2015/06/06/why-agile-and-
especially-scrum-are-terrible/)

~~~
chuck4932
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”".

------
mod
> 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
> 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.

------
Dunedan
> 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.

------
lobsterloga
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.

------
muzani
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.

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

------
lamansion
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.

