Interesting sideeffect doing SCRUM.
3 26 Apr 2017 21:48 by u/roznak
I did not expect this but I have noticed interesting side effects doing AGILE/SCRUM.
I already knew that AGILE/SCRUM killed projects and development at the pace of your worst develop in your team. But inside those teams the very people that hates it are also the most productive.
And it is very obvious, the people that hates it are people that are already good in AGILE. They hate SCRUM because it slows them down in developing things. They hate SCRUM because they force them to become unproductive.
And here is the very interesting thing: These people that hate SCRUM are so agile that they adapt to the crippling nature. they find ways to bypass crippling productivity and create new tools to cheat on SCRUM. They learn to cheat when you have have to estimate these crazy numbers. You try to guess what the other will show. They even learn to pretend that they are happy in these team events.
Evolution at its finest, natural selection in your developers. SCRUM probably burns out 90% of your developers in about 6-12 months but some will survive and become even better developers. But these fittest of developer escape your company every moment they can.
Currently I am in one of the most stable SCRUM teams I ever worked in. Very high end developers. Equals in my eyes. But it won't last.
21 comments
0 u/SwiftLion 27 Apr 2017 00:57
How do all of you suck so hard at Agile?
3 u/roznak [OP] 27 Apr 2017 16:52
Because we come from a time where we used 90% of our time on creating great products. Now we use 90% of our time to develop tools to bypass the restrictions imposed by SCRUM and to recover the wasted hours we lost on stupid SCRUM meetings.
0 u/SwiftLion 27 Apr 2017 17:59
Yeah, see? That's you, or your product manager fucking up hard. Explain to me, please, what are the restrictions of SCRUM that need bypassing? If your SCRUM meetings are wasted, then what the fuck are you actually talking about in them?
SCRUM is a series of restrictions on how your product manager is permitted to interfere with you building great products. End of story. If it is functioning differently in your organization, then yeah, you guys are fucking it up hard.
1 u/roznak [OP] 27 Apr 2017 19:11
If you were a developer you would not even ask such a question. The overhead 90% that SCRUM creates and prevents you from doing your job. You literally waste productivity by "opening the road- put in the red cable, close the road. Open the road, put in the yellow cable, close the road. Open the Road, put in a green cable, close the road"
I am going to repeat the challenge: Take one good developer let him do the exact same job as the complete SCRUM team and he will outpaced the SCRUM team, and produce better code. I am not asking you to believe me. Dare to do the test!
No! SCRUM causes so much overhead that it prevents great products to be developed. Your so called velocity is only an illusion number that makes you think that your are productive. That number is solving problems that is caused by SCRUM in the first place.
May I give you a clue what good developers can do? Good developer create code in such a way that they have absolutely no problem when a product manager comes in with last minute changes.
0 u/SwiftLion 27 Apr 2017 19:23
I own a product used by three hundred thousand people a month and work on an agile team with eight engineers. We love it. We push out great products every two weeks on the dot and we participate in the agile process to maximize our parallelism. Everybody can work on everything in the backlog at basically any time, because our requirements were clearly defined, agreed upon by all of us, and we push back in all the ways Agile suggests that we should.
You can't substantiate your claims. All you can tell me is, "NOBODY CAN DO IT EVERYBODY HATES IT RAH RAH RAH". You just don't know what the fuck you're doing, clearly. And/or your product manager doesn't.
What you're telling me is that you suck at understanding any problem whatsoever unless you are actively programming at the time. Why can't you look at a user story and the associated design of the page, and then tell me how you're going to write it? Are you trying to say that you're incapable of predicting anything at all ahead of time? Well, if so, you suck at your tools and you suck at development. You should ALWAYS be able to just rattle off, "Ok, this is about what I'm going to need to do in order to achieve this story".
"WHAT ABOUT EXPERIMENTAL FEATURES RAH RAH RAH" I hear you screech autistically.
Spikes! Spikes. Any agile practitioner worth their salt knows exactly how to handle this: you write a story to do just enough code writing, just enough technical investigation for a proof-of-concept or a skeleton implementation of the thing. If it makes sense to hold onto your branch and use it as the basis for the story, then have-the-fuck-at it.
I have taken the challenge. I've been on very functional agile teams, and I've been on reasonably functional non-agile teams. In non-agile teams, everybody has to confine themselves to separate locations in the app, or else merge hell ensues. In non-agile teams, you'll try to "boil the ocean", writing a smidgen of code here and a smidgen there, just sorta lumping together shit until you have the whole feature in place. And then once you do, how do you even know it really works? What about that edge case you introduced when you wrote three functions that "seemed exciting" early on and then you realized you had to spend half a day writing support and UI code before you could actually integrate and exercise them?
The most damning part of this whole thing is your complaints about SCRUM/Agile. You're bitching about the exact problems that Agile fixes.
You, sir, are just employed at a shitty job. Don't blame Ford when your cab driver drops you off two miles away from your destination after taking the long way there. The tools are fine. Your PEOPLE suck.
1 u/TelescopiumHerscheli 27 Apr 2017 22:23
I call bullshit on this one.
0 u/SwiftLion 27 Apr 2017 23:51
You can "call it" all you want. My team and I still use Pivotal Tracker all day, every day.
0 u/roznak [OP] 27 Apr 2017 23:37
Just take the challenge, take one of your "best" developers and let him work "outside" the SCRUM team. All you need to do is answer his question "What do you want?"
0 u/SwiftLion 27 Apr 2017 23:41
I can't hear you over the sound of hot productive my agile team and I are.
0 u/roznak [OP] 27 Apr 2017 23:52
Too scared to do the test and discover that your productive agile team can't keep up with a single developer that is not confined into the SCRUM restrictions?
0 u/SwiftLion 27 Apr 2017 23:55
Ok. I have eight engineers. We have one product. What EXACTLY are you suggesting? How do you want me, hypothetically, to instruct this other developer?
It sounds like you want me to dump a pile of design screenshots on a desk, for some arbitrary amount of work, and just wait for my engineer to get them done. Is that right?
0 u/roznak [OP] 28 Apr 2017 00:43
No. Give him the same user stories as your highly successful SCRUM team. That is his general direction he is going to head for. Don't expect him to follow the user stories, it is the end result that counts.
No pre-planning no scheduling, no fixed deadline. Just a deadline around your next demo but give him wiggle room to delay a few days, no code review, no stand-up meeting. He builds from withing the code towards the desired result.
He will be far more productive when he is in "the zone" and can focus at the best problematically path to reach that end-goal that encompasses all user stories. He will focus on hard things when he feels good and only do boring stuff when he feels in no not so good day. And that can change by the hour.
He is going to use AGILE how it is mean to be, without the slowdown.
He is faster because he does not get slowed down with internal communications and endless debates and team meetings. He is faster because he does not have to also know the other unimportant things for the current goal he needs to have right now. He is also faster because he can test multiple results in one test, while the SCRUM equivalent would be every test for every user story.
The issue here is that not every developer will be this effective. And you must also trust that developer that the outcome will be a success. But when the developer has a track history of near zero bugs and lots of success rates then you must trust this knowledge.
Don't worry, at the end when the demo happens, you will still to test it the SCRUM way user story by user story. And you will still have the same unit tests and builds/deployments. Bit it will be highly optimized code, more reliable, less bugs and easier deployable.
But but but, how about transfer of knowledge? That is a none issue since good developers can jump into any project, focus on it and they will be up and running in a very short time.
0 u/SwiftLion 28 Apr 2017 01:16
I'll address these points in order, but I really need to call out this one first, because it says everything that you really need to hear.
Well said! "Agile how it is meant to be". In other words, the process you are doing is "agile how it is not meant to be". Your "slowdown" is external. Somebody is not enforcing the rules of scrum to prevent the slowdown.
Now, to address all your other points one by one...
This doesn't exactly make sense. Stories are small packets of acceptance criteria. They must be "followed" or else the end result won't match them, so that doesn't make sense. If you're referring to the strict ordering of stories by priority, which I think you might be, then you're certainly on a moderately dysfunctional team. The ordering of stories is dependent on which feature must build on the code of another. I don't care how cool your engineer is, if I have a screen C that is a detail view of an item selected from a list on screen A, then screen A has to be written first. Code quality will suffer otherwise.
If you are fixing a deadline and yelling at your engineers when they are 3 days from the end of the sprint, then you are not doing Scrum. Setting the contents of a sprint does not grant the product manager the authority to yell at you to work extra hours, to insist that your team fucked up, or to tie a product demo deadline to the day the sprint ends. Sprint endings are designed to create a feedback loop that continually refines your team's ability to commit only to the amount of work you can actually do.
In particular, if you allow a team to say, "Ok, we have two weeks worth of work." and then, they work for two and a half or three weeks before it's done, what's to stop them from committing to "Ok, we have two weeks worth of work" again the next sprint, and missing again? Scrum doesn't allow you to yell at your engineers for missing their sprint targets. Rather, Scrum says, "When you reach the end of the sprint, and work is not done, you are required to have a conversation about why and to reason, together as a team, about WHETHER and HOW the miscalculation should be avoided". Your manager changed the requirements? The API didn't support the feature you needed? Everybody should leave the meeting saying, "Yes, this was a special instance that could not be avoided, we will ignore it and carry on". On the other hand, if you have missed your sprint deadline by three points, three sprints in a row? You have to sit down in a meeting room and agree, "Ok, we actually aren't capable of 18 points a sprint, so from now on, we'll draw our sprint line at 15 points and see what happens".
The only thing that Scrum dictates here is that you decide on the best path through your user stories in the interval planning meeting as a team. If there are dependencies in your stories, they must be ordered in such a way that the dependencies are respected. Additionally, there is the matter of regression testing to consider. You try to put the stories that need the most re-examination towards the top of your backlog. Code quality suffers if you don't, because if you pile up all of your "sure thing" stories at the front of the sprint, then you write a bunch of bulletproof code right away, and then, at the end of your sprint, you write a bunch of code that may have edge cases that you haven't thought about, and you only get to test it a day or two before deployment. This fucks your code quality.
Scrum dictates a daily stand-up that is not permitted to take longer than 10 minutes, an interval planning meeting that may not take longer than an hour, and a sprint retro that may not take longer than an hour. If you are having more meetings than this, well, you aren't Scrumming. If you can't spare two hours and ten minutes a week to talk to your managers, then Scrum sure as shit isn't going to help you, but I don't know what else will either.
Correct. According to Scrum, there are several ways in which the engineer's knowledge may not be challenged, no matter how much the product manager wants to. In particular, if your engineer that has a track history of zero bugs and lots of success rates says, "This is not reasonable for us to complete in this sprint", then you are forbidden explicitly by the Scrum manual from even so much as needling him "but couldn't you try?". If you have ever, even once, been overridden on this point by your PM, you are fucking up Scrum.
This is a coded way of saying, "the results from scrum and from undirected development are indistinguishable, so long as you use stories with acceptance criteria to dictate work". I don't disagree.
This here is the most damning statement of all. There is a specific point to be made about Scrum: I should be able to walk up to any engineer mid-level or above (because juniors always need a little more guidance) and hand him one story, and my source code as it exists right now, and expect him to return to me a product with the new feature integrated. If you cannot do this--YOU GUESSED IT--you are fucking up Scrum.
There is no way in hell that, whatever broken, shitty process you're using, it's actually agile. It sounds to me like you are being strangled in process by managers that are abusing the rules to try to make it sound the way they want. I have two hours and ten minutes of meetings about my product a week. My engineers and I pick up whatever stories we want in the order we want, so long as it makes sense in the "order of stories"--as determined by US. That is, if I know that story C describes a feature that can only be reached by selecting an item from a list in feature A, then I have to wait for feature A to be written first. This is pure common-sense, there's nothing process oriented around it.
All you just proved to me is that you have a shitty process that somebody taped over the label of, and scrawled "SCRUM" in crayon over the front, and then went to their manager and declared proudly, "WE IS DOING AGILE NOW".
All this hostility aside, I feel sorry for you if these complaints are actually legit from your workplace. You should look for another job. It sounds like yours sucks.
0 u/roznak [OP] 28 Apr 2017 02:34
It is the 4th time I am in a SCRUM team now. I am in an escape route. Good developers already left, I probably will be next.
0 u/SwiftLion 28 Apr 2017 02:41
It's a logical fallacy for me to simply insist that your scrum isn't real scrum. It's the "no true scottsman" fallacy. I absolutely believe in shittily-run scrum, and like I said, it really, really sounds to me like your managers leafed through the scrum manual and took notes on "this is how I need to phrase it when I jump on my engineers' asses so that they can't argue with me".
What do you write in? My company needs engineers a lot and we don't suck.
0 u/SwiftLion 27 Apr 2017 23:52
Ok, ok, seriously though. What do you work on, and how many people use it? What is it for?
0 u/kevf4 07 May 2017 20:12
Scrum is okay if you adapt it for your team and keep team sizes reasonable. The whole scrum process is just a management tool in the end.