I’ve tried to help those people understand that their organization is doing “Agile” wrong: they’re not doing what the Manifesto authors recommended, what Scrum recommends, what the many Agile Software Development experts recommend.
WRONG! SCRUM sucks also Agile Software Development experts suck even, bigger!
Claiming that they are doing it all wrong, is a clear indication that you have no clue what programming is. The big giant flaw in by these co called Agile software developers is that they try to "quantify" software development and assume that software development is team work and can be teached.
Great software is ready when it is ready, not when time is up.
Great software cannot be planned and predicted before, you create a fuzzy goal and ask the developers to create something that does this.
Great software developers work efficiently alone. They need to build their code reliably and that does not work when you get some idiot crippling all your code at random locations.
Now brace for impact, anyone that was brainwashed into SCRUM methodology, your life will suck because it is going to take many years to unlearn these bad behaviors. If you came from school and did not develop 5 years ago, then your brain was never trained to be creative and your career is over.
Reg. when software is ready, one also has to consider deadlines. In such a case, I would believe that it typically for most cases is a good idea to inform the relevant decision makers that are responsible for the given project or product whether you believe the goals can be reached, ask them how to prioritize, ensure that there are proper fallbacks if the deadline fails, and generally keep them well-informed such that they can take decisions. That does, as you say, depend on the case.
In any case, I strongly agree with you that prioritizing the company and keeping focus on how one can help the company achieve its goals are very important. And here I must apologize, for I believed the blog post cared more about how developers can do a better job, instead it indeed seems to "sell" things to developers, and I think that is similar to a lot of SCRUM marketing, because they tend to focus on how developers can be "empowered" (whether true, false or the opposite...) instead of focusing on how developers can better help the company, which ought to be the focus.
You need a soft deadline. deadlines are important because then we wrap everything up to a complete functional project.
What would be better is to have a soft deadline, and make developers try to do everything they can in this given deadline with certain directions to follow to. Any good developer will optimize the time and resources because they love to create and also love to win.
This blog post indeed is trying to create a new hype because their previous hype failed. It is the exact same people that tries to cover up their previous mistake by introducing yet another method that will fail exactly the same way.
More generally, developers’ work should adhere to the foundational principles....
Jesus, quit the "principles" reasoning!
The best developers don't follow principles, they create principles based on what they need. They don't follow patterns, they invent patterns for what they need. And what is needed depends on the company's needs.
Get rid of these SCRUM teams and you will notice that one good developer will replace one complete SCRUM team when they are allowed to do their work. Take developers that started their careers in the 90's. the period where good developers came into existence because they self-learned it all by themselves.
Coding should not be straight forward, as neither is language. The reason why we have this awesome technology that is only a certain percentage better is basically because of semantics. We need more out of the box coders not giving a fuck what they were taught, we need coders that will experiment and have fun with their codes.
If you can’t quite manage that, I’d advise you to take on less work in each time period, until you’ve taken on a small enough batch that you can actually get it done.
Massive FAIL! This never works in good programming.
In good programming you look at all the possible issues and then create a multiple dimensional level solution that solves it elegantly. The code will be a little bit more complex but it probably collapse the number of code to 20% of what you would have created.
And if done correctly, this slightly more complex code will be self correcting and self testing where your need for mocking and unit testing will be reduced to the minimum.
Good developers don't write code, they write cathedrals where every part has a function and well thought place.
Project managers superior term: scrum, agile, change management etc.
Developer words: don't try to force nine women to deliver a baby in a month!
I read this joke today and think its so true!
If you change requirements frequently enough to prioritize those changes above your fundamental design concerns you failed in your due diligence and in your project specification.
Yes and No. you don’t take into account budget concerns which can increase over time. Then you also have other items that might have been a wishlist bucket item that got pulled to the top. Waterfall also doesn’t help keep the client on the pulse of progress. My client has been awesome when hitting roadblocks for ours and their reasons. We also address bugs in a more timely fashion and the client since they are on top of all information doesn’t get upset during the process. They own it all the way through so we only have to make sprint deliveries while they get exactly what they want for the better or worse in our opinion.
We have also been able to expand beyond the original scope too.
But I guess this really all boils down to what kind of client you have. If I had a non-technical and a hands off type I would not use agile for them. The client I helped now is just as technically aware as we are, they just don’t want to have on board developers and they wanted agile.
Sounds like the environments you were didn’t follow agile but had micro managers who wanted to control in order to move up.
I’m gonna with a sprint plan that we use. We identify what the product owner wants and try to limit that scope. We then approach the QA and Dev teams for reasonable check. If they think they can manage the work load we proceed or adjust. We include new features and time to work on back log bugs and new bugs. Scrum meetings are for updates on what has been done and what road blocks need to be cleared. The product manager acts as scrum leader and keeps things on track and acts to clear road blocks and to interact with the product owner in case features / bugs can’t make it into the release. Normally bugs get carried over and features make it in. No critical bugs are allowed to remain outstanding (normally). The product owner hasn’t time test and verify the release prior to release date and found bugs during this stage end up getting fixed or moved to next release.
The dev team gets to work their way through the release at their own discretion but will get guidance to which bugs have priority. Code is under continual integration and the QA team keeps the dev team on their toes.
Let’s say we were building an island in the kitchen. The product owner says they want an island with granite counter tops and stained wood. The product manager tells the QA and Dev leads what is to be done. They both then ask their teams what the time frame is. QA makes sure the specs are on track. The dev team pushes along and brings up problems like a water line issue. The product manager discusses with the product owner and then harasses infrastructure to make it work or get the solution for the dev team. The dev might throw out that oak is better than maple and the this goes up to product owner too. The product owner might want a bigger sink but that will only get installed if it can still fit the schedule or the product owner is willing to delay and spend more money. It’s never the dev teams fault and they aren’t responsible to pull it off after work unless! This is a major change that everybody writes off on. Things like caulking might need a redo and that’s on the dev team but it will have been caught during the staged demos. At no point in time should the product owner’s expectations should be so far off that the schedule be missed or that a change is needed that deviates significantly from what the dev team is working on.
20 comments
0 u/PutinDid911 26 Aug 2018 21:39
lol, railing on Agile in 2018.
0 u/the_hidden_metric 27 Aug 2018 02:26
The guy who wrote this helped write the Agile Manifesto.
0 u/WhiteRonin 27 Aug 2018 03:35
Watch his video. He’s been saying this for a long time.
0 u/roznak 28 Aug 2018 17:24
WRONG! SCRUM sucks also Agile Software Development experts suck even, bigger!
Claiming that they are doing it all wrong, is a clear indication that you have no clue what programming is. The big giant flaw in by these co called Agile software developers is that they try to "quantify" software development and assume that software development is team work and can be teached.
Now brace for impact, anyone that was brainwashed into SCRUM methodology, your life will suck because it is going to take many years to unlearn these bad behaviors. If you came from school and did not develop 5 years ago, then your brain was never trained to be creative and your career is over.
0 u/notenoughstuff [OP] 28 Aug 2018 18:53
Reg. when software is ready, one also has to consider deadlines. In such a case, I would believe that it typically for most cases is a good idea to inform the relevant decision makers that are responsible for the given project or product whether you believe the goals can be reached, ask them how to prioritize, ensure that there are proper fallbacks if the deadline fails, and generally keep them well-informed such that they can take decisions. That does, as you say, depend on the case.
In any case, I strongly agree with you that prioritizing the company and keeping focus on how one can help the company achieve its goals are very important. And here I must apologize, for I believed the blog post cared more about how developers can do a better job, instead it indeed seems to "sell" things to developers, and I think that is similar to a lot of SCRUM marketing, because they tend to focus on how developers can be "empowered" (whether true, false or the opposite...) instead of focusing on how developers can better help the company, which ought to be the focus.
0 u/roznak 28 Aug 2018 19:10
You need a soft deadline. deadlines are important because then we wrap everything up to a complete functional project.
What would be better is to have a soft deadline, and make developers try to do everything they can in this given deadline with certain directions to follow to. Any good developer will optimize the time and resources because they love to create and also love to win.
This blog post indeed is trying to create a new hype because their previous hype failed. It is the exact same people that tries to cover up their previous mistake by introducing yet another method that will fail exactly the same way.
0 u/roznak 28 Aug 2018 17:33
Jesus, quit the "principles" reasoning!
The best developers don't follow principles, they create principles based on what they need. They don't follow patterns, they invent patterns for what they need. And what is needed depends on the company's needs.
Get rid of these SCRUM teams and you will notice that one good developer will replace one complete SCRUM team when they are allowed to do their work. Take developers that started their careers in the 90's. the period where good developers came into existence because they self-learned it all by themselves.
0 u/discobiscuit23 28 Aug 2018 20:13
Coding should not be straight forward, as neither is language. The reason why we have this awesome technology that is only a certain percentage better is basically because of semantics. We need more out of the box coders not giving a fuck what they were taught, we need coders that will experiment and have fun with their codes.
0 u/roznak 28 Aug 2018 19:51
Massive FAIL! This never works in good programming.
In good programming you look at all the possible issues and then create a multiple dimensional level solution that solves it elegantly. The code will be a little bit more complex but it probably collapse the number of code to 20% of what you would have created.
And if done correctly, this slightly more complex code will be self correcting and self testing where your need for mocking and unit testing will be reduced to the minimum.
Good developers don't write code, they write cathedrals where every part has a function and well thought place.
0 u/viperguy 29 Aug 2018 17:01
RIGID MEETING AT 9:30 or 10AM for all ruins the entire company!
The 20% of super coders that do over 80% of the hard productivity, leave work very very late and barely can come in at 9:30 AM.
They eventually quit in rage, and the company implodes in less than 18 months. I have seen this three times.
All because of SCRUM+Agile rigid daily meetings too early in the day.
0 u/happydaddy 28 Oct 2018 16:47
Project managers superior term: scrum, agile, change management etc. Developer words: don't try to force nine women to deliver a baby in a month! I read this joke today and think its so true!
-1 u/ninjent 26 Aug 2018 23:37
This is why software "engineering" is a fucking joke. Any rapid development approach is almost guaranteed to produce shitty software.
0 u/WhiteRonin 27 Aug 2018 03:36
So back to waterfall?
0 u/ninjent 27 Aug 2018 10:26
SSADM for life, mate.
0 u/WhiteRonin 27 Aug 2018 13:42
That sounds like waterfall.
I don’t mind agile since we can change requirements on the go.
0 u/ninjent 27 Aug 2018 16:16
If you change requirements frequently enough to prioritize those changes above your fundamental design concerns you failed in your due diligence and in your project specification.
0 u/WhiteRonin 27 Aug 2018 17:13
Yes and No. you don’t take into account budget concerns which can increase over time. Then you also have other items that might have been a wishlist bucket item that got pulled to the top. Waterfall also doesn’t help keep the client on the pulse of progress. My client has been awesome when hitting roadblocks for ours and their reasons. We also address bugs in a more timely fashion and the client since they are on top of all information doesn’t get upset during the process. They own it all the way through so we only have to make sprint deliveries while they get exactly what they want for the better or worse in our opinion.
We have also been able to expand beyond the original scope too.
But I guess this really all boils down to what kind of client you have. If I had a non-technical and a hands off type I would not use agile for them. The client I helped now is just as technically aware as we are, they just don’t want to have on board developers and they wanted agile.
0 u/ninjent 03 Sep 2018 11:42
This has been pretty much my experience of every "Agile" RAD practice I've been involved with in the last 20 years...
If it's working for you, brother, then I hope it works well.
0 u/WhiteRonin 03 Sep 2018 15:19
Sounds like the environments you were didn’t follow agile but had micro managers who wanted to control in order to move up.
I’m gonna with a sprint plan that we use. We identify what the product owner wants and try to limit that scope. We then approach the QA and Dev teams for reasonable check. If they think they can manage the work load we proceed or adjust. We include new features and time to work on back log bugs and new bugs. Scrum meetings are for updates on what has been done and what road blocks need to be cleared. The product manager acts as scrum leader and keeps things on track and acts to clear road blocks and to interact with the product owner in case features / bugs can’t make it into the release. Normally bugs get carried over and features make it in. No critical bugs are allowed to remain outstanding (normally). The product owner hasn’t time test and verify the release prior to release date and found bugs during this stage end up getting fixed or moved to next release.
The dev team gets to work their way through the release at their own discretion but will get guidance to which bugs have priority. Code is under continual integration and the QA team keeps the dev team on their toes.
Let’s say we were building an island in the kitchen. The product owner says they want an island with granite counter tops and stained wood. The product manager tells the QA and Dev leads what is to be done. They both then ask their teams what the time frame is. QA makes sure the specs are on track. The dev team pushes along and brings up problems like a water line issue. The product manager discusses with the product owner and then harasses infrastructure to make it work or get the solution for the dev team. The dev might throw out that oak is better than maple and the this goes up to product owner too. The product owner might want a bigger sink but that will only get installed if it can still fit the schedule or the product owner is willing to delay and spend more money. It’s never the dev teams fault and they aren’t responsible to pull it off after work unless! This is a major change that everybody writes off on. Things like caulking might need a redo and that’s on the dev team but it will have been caught during the staged demos. At no point in time should the product owner’s expectations should be so far off that the schedule be missed or that a change is needed that deviates significantly from what the dev team is working on.
0 u/x1x3x7 25 Sep 2018 05:21
UP