The last year I have seen a sharp increase in technology jobs adverts with SCRUM
20 11 May 2016 17:26 by u/roznak
The last year I have seen a sharp increase in technology jobs adverts with SCRUM. But what makes it interesting is that they need people urgent. So I start to wonder if these companies are burning through their developers at a fast pace and lose them?
The word SCRUM in a job description is a huge indicator that this company is going to fail in their projects and end up with developers that are burned out.
Why is SCRUM a project killer? Easy, it freaks the project managers and their managers out when their graph is showing that yet again they will fail in getting the next demo. And the last thing you want is a project manager freaking out and push the developers for yet another shortcut.
The only situation where SCRUM "appear" to work is when you are dead scared to change anything in your project and cripple new development just to get to that next demo. Your project is DOA.
16 comments
9 u/SwiftLion 11 May 2016 19:06
Yeah, I agree--phillips-head screwdrivers make really terrible hammers!
If your point is simply that most people tack the term 'SCRUM' onto a project and then manage it just like they always did--as if SCRUM were just some sort of tool like Excel--then I won't argue with you there. But, there seems to be a deeper misunderstanding of what SCRUM is and what it's for, which I'll try to address. And before anybody suggests that I'm just a manager fluffhead, no, I'm an engineer. I work in an agile environment and I've trained a couple of product managers in my time to SCRUM properly.
This is the point where I can see that somebody has missed the point of SCRUM. SCRUM says, "Look, you were going to miss that deadline anyway. But thanks to SCRUM, you are aware of it now." Specifically, the question is, what does the manager do when they see that, based on velocity, it looks like you're going to miss a deadline? If they are practicing SCRUM, there are two options. One, is to push back the release date. The other, is to remove features. And, very specifically--if your manager EVER tries to look at your timeline, and then "compress" it by making technical suggestions or asking the team to fish for shortcuts--then you have violated SCRUM and you've thrown away everything it can possibly give you.
Agile development is about responding to changing requirements. Ultimately, in the ideal case, it brings you down to making a releasable product improvement every sprint or three. It's also about reporting projections with mathematical frankness, which includes both the projection, and the awareness that the projection has uncertainty. If your product manager practices SCRUM correctly, then they'll go right to their own manager and say, "Ok, we're gonna deliver two sprints past our expectation." And when they're told that's unacceptable, they'll say, "Ok, cool. So, what features do we consider lowest priority?"
If you don't have a PM that will go to bat for you on those terms, then sorry--you aren't practicing SCRUM, you're just buzzwording your job advert.
4 u/roznak [OP] 11 May 2016 19:35
The issue is that both SCRUM and agile tries to mimic how I develop. The methods I use is very agile, and very reliable for very critical projects. I do have structures like daily builds and TDD like development.
However! My success is based on releasing when the time is right, never because of time is up. I will never commit a change that I do not trust. I will delay a commit up until the moment I have tested every part. I can also never predict what I am going to work on today. I optimize my development depending if I have a good day or not. When I have a razor sharp focus I go and get the toughest part, if I feel less optimized then I do the stuff that can't fail. But here is the clue, when I encounter a bug, I will hunt it down until I found I even if it takes days. The crazy thing is that I do all this in half the time a SCRUM sprint would take and zero stress.
3 u/SwiftLion 11 May 2016 20:34
It sounds like you just haven't participated in a well-run SCRUM process. You have to understand--SCRUM only makes room in the backlog for stories with points, and only points count. But this DOES NOT mean that you should only ever be working on pointed stories! If you have a 'chore' or a 'bug', then just work on them instead.
"But my velocity will go down, even though I'm working hard!" True. You're still working, but the work you're doing does not provide new user-facing value. This is SCRUM accurately reporting that less of the work you did was feature-driven.
If your manager comes back and says, “look, your velocity went down, therefore, you’re not working as hard”... Then your manager is not doing scrum.
4 u/roznak [OP] 11 May 2016 21:44
You sound like someone that read a book "Lean these 10 steps that successful business people do and become wealthy rich". With a twist "Learn these 10 SCRUM steps and make any software a big success" Software does not work like this.
I have 30+ years of developer experience and I have seen every trial to quantize software development and the all fail to understand what makes software projects a big success: "Human nature that does not want to be contained into a quantized number " You end up with brainless code monkeys.
Good developers: "Of course I can, give me a week and I come back when it is done."
Code monkeys: "Cool we these predefined jobs set in stone for the next 2 weeks. If we fail we don't care"
Good developers: "I am not allowed to do anything else for 2 weeks? I am outta here, bye"
Code monkeys: "We encountered this bug but we can't fix it until 6 months from now. If you crash then just reboot"
I think scrum masters should ask their development team the following question: "If there was no economic crisis and you are not scared of losing your job, would you stay here with this scrum?"
2 u/SwiftLion 11 May 2016 23:08
Yes. Which is why, if you read the 13 page SCRUM guide, near the bottom of page 5, in the definition of the responsibilities of a 'Development Team':
The meaning of this is that if you say, "Hey, I think before we do anything else, we should fix this thing over here." And if the rest of the development team nods and thumbs-ups, then bam, that's written in as a technical task on a relevant story. That's where your 'senior engineer freedom' is.
So far as your comparison of good versus bad developers, I'll respond to each pair of statements.
You're acting like the process of SCRUM is about laying out numbers and then telling a team they have two weeks to 'fit the bill'. That's just wrong, you've got it backwards. SCRUM says, "If you observe the people you're working with in this way, the numbers you get will be pretty reliable if you use them to inform your guesses about when things will be done". It also says that you just have to understand that you can't enforce changes to these numbers, you have to do that by dealing with the messy business of communicating, and collaborating, and figuring out what your team needs in order to do better. But, if your team chooses the right toolkit, and shares their knowledge, and leverages each other's strengths, and so on, these numbers will go generally up--and if your team sucks shit, these numbers will go generally down.
6 u/7even6ix2wo 12 May 2016 04:13
scrum, aka the the clusterfuck method.
4 u/IamSand 12 May 2016 16:04
The Crossfit of the IT industry.
-1 u/7even6ix2wo 12 May 2016 20:00
would downvote but not enough upvotes
2 u/Northvvait 12 May 2016 04:44
Required reading. https://www.aaron-gray.com/a-criticism-of-scrum/
Not much you can do if you're looking for a steady job and see nothing but Scrum everywhere (other than go freelance, but, hey, that's not for everyone), but at least you can form a resistance from the inside.
1 u/IamSand 12 May 2016 16:01
SCRUM, Agile etc. etc.
I love how these schemes of nothing in particular come and go in waves. Gives the middle management something to play with. Makes them look relevant.
0 u/NiklausTheNaked 12 May 2016 15:12
My engineering team has a scrum meeting every morning. It is an incredibly valuable tool for keeping up with the rest of the team's progress, and planning and setting goals for the team. I've worked at other places without scrum, but I didn't get even half as much work done.
0 u/SkepticalMartian 12 May 2016 16:41
What I found with SCRUM is that what starts with the best of intentions eventually devolves in to a waste of time that could be better spent punching off existing tickets. It's a process that requires reasonably strict discipline so it doesn't become counter-productive.