Considering leaving job because of SCRUM

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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

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

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

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.

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.

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

My problem is not with releasing new code every 2 weeks. I am 100% in favour of that I try and keep my releases as small and as frequent as possible.

My problem is with planning/grooming/reviewing/presenting every single 2 week release. I think it should be up to the developer to decide how often they release new code not the product manager or anybody else. Of course it is always better to release often and in small amounts but this is not always possible hence why it should be at the developer's discretion.

To address the estimate point I must say that there’s nothing in scrum preventing you from trying things before giving an estimate.

Having a task specifically to do exploratory coding is, in fact, encouraged by extreme programming.

Even after that if you find that you estimated completely wrong it’s no big deal. That’s what it is for. You need to find mistakes.

I’m not saying this is the case but it seems that your particular implantation of scrum is very poorly done. Especially if your only resource is the scrum guide.

The actual book written by Ken Schwaber mentions that you can add things to a sprint of work is completed before the end of the sprint. This is part of the process and just like in the previous case is also saying that your knowledge is lacking because you finished the work before you thought you would.

Agile methods are tools to help improve the cadence and predictability of software delivery.

But isn't it a rule in SCRUM that no new cards can be introduced in the middle of a sprint? And isn't it also a rule two co-dependent cards cannot be done in the same sprint? (i.e. if card B depends on card A being finished).

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

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

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

> 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?

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

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

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.

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.

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

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.