Considering leaving job because of SCRUM
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?
30 comments
[ 2.8 ms ] story [ 61.2 ms ] threadAgile Scrum is not the only way to do Agile.
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.
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.
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.
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.
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.
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.
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.
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?
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.
This isn't really how sprints are supposed to work. Seems like a misunderstanding of how to manage a backlog.
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
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.
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.
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 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.
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.
Which is the last thing you want to do if you have people above you in the org chart who love to micromanage.
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.
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.
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...
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.
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.