Cross-cutting concerns, such as coherent error handling, logging (and metrics and alerting if you're more advanced), etc. do not produce visible benefit to the customer rapidly if they are done for a large-scale system. They get shunted aside That has nothing to do with "agile". If you neglect this stuff, you would do it in any other development approach, too.
Management of technical debt gets relegated to secondary status because it's essentially invisible to someone not trained in software engineering. Actually agile methods emphasize to have zero technical dept. If you neglect this stuff, you would do it in any other development approach, too.
User feature requests that are improperly curated (or not curated at all) lead to a system that has no coherent development evolution. If that is happeneing: you are doing ti wrong. And you would do it wrong in any other development approach, too.
Agile tends to be reactive, and tends not to be conducive to any vision of where the software should go. That has nothing to do with "agile". If you neglect this stuff, you would do it in any other development approach, too.
Architecture, the stuff you wish you had done afterwards, gets short shrift. Never happened in a project I was involved.
Because due to global warming the glaciers are shrinking, that means the average size over the course of a year gets less from year to year or decade to decade. As you surely know that: what kind of nonsense do you ask here?
Strange, Climate modeling, weather forecasts, most fluid dynamics code, and so on, need to be compiled to get enough speed. The meteorologic institutes on the world disagree. Most of their software is Python.
There are still shops that use cobol, but no one starts new projects in that language Of course they start new projects in COBOL.
It's important to remember that there are an order of magnitude more programmers now than there were in the days cobol was popular Yeah, most people don't think about that.
According to this: https://www.statista.com/stati... The Android app store has about 4 million apps, the Apple one about 2 million. Obviously many apps are super simple. But assuming you do something decent an App easy will have a few 10,000 lines of code. And that are only Apps, no one is really counting how much lines of code in house software developers create for stuff that is never used outside of the organization
I guess we have a significant increase of lines of code written per year. Even if it is only 2% it doubles every 35 years.
When, in the process of building a product, a programmer is expected to do their work in 2 week chunks exactly as (usually someone else) has decided with very little room for deviation (gotta maintain that velocity!), it's hard to feel invested in what he or she is building. It's hard to feel like your human judgement means anything at all. If "someone else" has decided what "chunk" fits into a 2 week sprint, then: you are doing it wrong!
(gotta maintain that velocity!) No, you don't have to maintain your velocity: you have to for funk sake measure it, that is all. If you think you have to maintain it: you are doing it wrong!
You certainly don't care if the project succeeds or fails. Then you are a moron and should be working in a business that does projects. You are doing everything wrong!
You just want to get your sprint finished as quickly and easily as possible so you can go home A sprint finishs, when the time is over, not when "everything is done", if you think otherwise: you are doing it wrong!
And, agile in practice reinforces that, because that is how management sees it. Then your management has not understand what sprints and being agile is about, hence: you are doing it wrong!
(because I've never worked for a manager who had any experience programming... which is sad in and of itself). Then stop whining, get _agile_ quit your current job and find a manager that has a clue about software development.
Only scrummy people consider scrum agile. Agile people do not. Everyone considers Scrum agile. Except you obviously.
Point to any reference to Scrum in the Agile manifesto. Why would there be any? Point to any reference of Kanban or XP in the Agile Manifesto!
The agile manifesto is a destination of many agile methods, to nail down the core principles. Why would they need to point to the "methods" they consider agile?
And I really wonder abut your hate to "agile", "Scrum", "XP" (and other people like arth1 etc.)... what is so fucking hard in finding an employer "Who does Agile right?" Why are you complaining all the time but seem to be _frozen in place_ instead of being _agile_ and for funk sake change your job?
Scrum: process, process, process, you are just replaceable cogs. Scrum dos not define any software development process. It defines a meta process and rituals/ceremonies to keep the meta process on track.
No, it does not make developers cog wheels... if that is happening for you: you are doing it wrong;D
If your "faux-agile" team managed to release working software successfully every two weeks, and had reasons to increase sprint time under pressure: then it was superbly agile and no faux at all.
And then again: if you release weekly it does not indicate at all that you are agile. It only indicates: you are releasing weekly.
"True agile" developers have to master how to implement changes in small steps: increasing throughput means implementing more small steps in the same time. "Faux agile" developers don't master that and increasing througput ends up meaning increasing the steps lenght, defeating the whole idea of agile. You are an idiot. You do not value people at all. You treat them like machines. Worse is: you apply your own metric when a person is successful and when he is a true versus faux agile developer, actually you are an asshole. You are exactly that where every guy here in the thread is talking about: you treat developers like slaves, press them to work harder instead of letting them work smarter. You failed to grasp what agile is about.
TL;DR: if the dev cycle under demanding workload shortens you are doing agile right, if it gets longer you are doing it wrong. If your workload gets more demanding, your organization/company is doing something wrong: e.g. they forgot to hire more developers. Shortening the cycles increases the "residual load", like wasted time in sprint planing, sprint reviews and sprint retros, integration testing, acceptance testing etc. The shorter the sprint the more relative time you spent in meetings and the less relative time you actually do work. You got all this completely backward. If your team struggles to deliver features every sprint, then you have to lengthen the sprint period, not shorten it. You are simply an complete idiot.
my limited set of empirical data strongly suggests that Agile(tm) is a supremely craptastic method for producing software. Then you neither understand Spiral Model nor Agile Methods... perhaps you want to read up again what their core principles are, moron.
Agile is no better and no worse that any other way of doing business. Waterfall: I analyze 3 month, I design 3 month, I implement 3 month, I test 3 month. After 12 month I deliver a product that is no longer adequate for a market that has changed over the course of said 12 months. Agile: I deliver after ~6 weeks a working, tested, approved, subset of the project. Every ~6 weeks I can change course, change the scope of the project, change priorities of features. Heck, I can cancel the project after 3 sprints because I realize: the team is to slow, it will take them 18month, which takes to long, or is to expensive.
First approach has the risk of sinking a HUGHE amount of money. the second approach has the risk to sink a considerably smaller amount of money. That is the reason why most modern SD is done agile (or abuses agile by 'doing it wrong').
The simple reality is that 50% of the software developers out there really should not be developing software because they just plain aren't good at it. That is unfortunately true for every job.
the ostensibly Agile-focused helpers say that's not part of Agile, it wasn't in any of their training, and that they got Agile certification so they should know. A "certified scrum master" course goes over two days, and can be abbreviated into one day if the students are prepared: there are hundreds or thousands of things a student might not know afterwards.
When I point out "Responding to change over following a plan" was part of the manifesto, If they don't know that they are morons. The core principles of the Agile manifesto, Scrum, or Extrem Programming fit on a single page of paper, even with 2 sentences of explanation.
The "Atlassian Story" indicates the guys mix up process with tools... probably the reason why old school CSMs use paper cards to track everything instead of tools.
For example, Extreme Programming was, and still is, a stupid idea. Sorry, two people can't use a single keyboard efficiently. People who mix up "Extreme Programming" (a software development process) with "Pair Programming" (an optional 'habit') in discussions like this (note: it is not the same thing), are like people who mix up sand with bricks or cows with milk.
You don't belong into discussions like this as you obviously have no clue about software development. What is next? Mixing up what a file is with what a database is? Or mixing up what ASCII is with a compiler that reads ASCII files and writes object files?
The fact is, a good team will be successful regardless of the process (arguable). A bad team will be unsuccessful regardless of the process (true). IT'S NOT THE PROCESS! It's the PEOPLE! Exactly, the first paragraph of the Agile Manifesto:D emphasizes mine.
I work with agile methods since 1993. I only was in one company/project where they did everything wrong and in another project where the Scrum-Mistresses thought every "meeting" is a socializing event and needs to introduce a new "meeting conducting strategy", when I pointed out that this is not the job of a ScrumMaster, I got fired the day after:D In other words: I do more or less agile projects since 25 years, and all went FINE! The best running project (from 2004 - 2008) was supposed to be integrated into SAP (around 2016). Obviously that failed (was basically impossible, and everyone involved should have known that). That was at a energy holding company... they sold and closed off the sub company that was using the product and wanted it integrated. A management decision... not a failed software project but bad management of an energy company, because that energy company does not grasp that _all_ modern companies are IT companies and rely on their software to have a business advantage and not on their power plants.
So bottom line, during 25 years of mainly doing agile software development I had less than 2 years of bad examples, the rest went quite fine. And that is why I say: "If you don't get it working: you are doing it wrong!" But most likely you would do every software development (process) wrong anyway, so: who cares:P
Which part of: "You are doing it wrong" did you not get till yet? If you do 4 daily meetings: you are not doing an agile method but some bullshit.
Can't be so hard to grasp.
Agile requires that you intentionally ruin any long term planning since you don't think long-term but instead think of sprints. That is nonsense. If you think like that, then: You are doing it wrong!
but according to Agile you work people to death for two weeks That is nonsense. If you think like that, then: You are doing it wrong!
abuse them, insult them, insult them, and then repeat that process every two weeks. That is nonsense. If you think like that, then: You are doing it wrong! And you should have the guts to QUIT!
It's all about abusing people as much as you can legally without being charged with a crime. No it is not, you simply are a moron or a troll or both.
However daily meetings help to realize that perhaps always the same developers are not finishing their work as planned. Perhaps they overestimate their capabilities constantly and pick to hard work from the issue tracker. Or you realize since days some of the developers are "blocked" because some administrative issues don't get fixed.
In a ten man team, a daily meeting can be over after 5 minutes, and indication is: most is running fine It can take longer, indication is: you have problems
Identify the problems, address them to upper management, get them fixed.
If you waste time in meetings, then you either organize/conduct the meetings wrong, or you are not reacting to the issues raised in the meetings properly.
Tasks must be explained to one manager, who has the status to talk to another manager, who has the status to speak to their team, and _each_ layer must be completely convinced I really wonder: what actually do you et wrong with "agile"? The point of agile is to REMOVE those layers and have ONE SINGLE DECISION POINT.
Why is it that people don't grasp the most simplest things about agile methods?
I've worked in plenty of secretive companies where agile is a problem as information is intentionally withheld from the developers That has probably nothing to do with companies where agile but with information is intentionally withheld Regardless what software process... if the developers know not enough they can not design or architect, or even code. What the funk has that to do with agile? Agile methods are ALL about an open backlog where everyone involved sees the complete backlog. If you don't have such a backlog, then: a) you are doing it wrong (regardless of process) b) you are not agile
I guess you got Scrum wrong. In Scrum, there is basically no manager, the team is self managing. That is more or less true for all agile methods.
Ultimately that is the opposite of Agile, which says, "We value individuals and interactions over processes and people." If you don't trust your developers, the focus should be on improving the skill of your developers so you can trust them. The best agile methods focus on improving the soft skills of the programmers, rather then beating them down or 'controlling' them with process That is exactly what Scrum and XP are doing.
Maybe mobile apps or web apps, but not so much platforms that are expected to exist for a decade or more and grow along the way, or where high reliability is important, That is nonsense. The "niche" of choice is completely irrelevant.
or where it's not just software but also hardware that is much harder to change. The origins of Kanban come from a hardware company: Toyota!
"you aren't doing Agile right" argument is old and tired and just plain wrong. No it is not wrong. You are wrong. Ever tried to cut a soft cake with the dull side of the knife? Works surprisingly well, but is wrong. Try the same thing with a salami, but don't make the mistake to push with you other hand down on the blade of the knife. Point is: it does not work to cut the salami with the dull side of the blade. You are doing it wrong, your holding the knife wrong. However it is an excellent variation of holding the knife if you want to stab one to death. Much more effective if the cutting edge is on the upper side.
If your software development method is not working: you do it wrong! Regardless what kind of method you use. First: learn how to develop software. Then: pick a process/method that works for you.
If you can not do Scrum or XP: then you can not develop software, period. It is not the method but your immaturity in making software that makes you fail.
Since I've started working in Agile groups for a number of years the development has been way more subject to "here's a feature that can be added in two weeks, let's go for it" w/o a coherent overall view of where we were headed. If you have no coherent over all view: then you are not doing software development right Regardless if you, your team or your company labels something with "agile" or "not agile" When you can not even do software development right, why do you think going for "agile" would be an improvement?
Slashdot Mirror
Cross-cutting concerns, such as coherent error handling, logging (and metrics and alerting if you're more advanced), etc. do not produce visible benefit to the customer rapidly if they are done for a large-scale system. They get shunted aside
That has nothing to do with "agile". If you neglect this stuff, you would do it in any other development approach, too.
Management of technical debt gets relegated to secondary status because it's essentially invisible to someone not trained in software engineering.
Actually agile methods emphasize to have zero technical dept. If you neglect this stuff, you would do it in any other development approach, too.
User feature requests that are improperly curated (or not curated at all) lead to a system that has no coherent development evolution.
If that is happeneing: you are doing ti wrong. And you would do it wrong in any other development approach, too.
Agile tends to be reactive, and tends not to be conducive to any vision of where the software should go.
That has nothing to do with "agile". If you neglect this stuff, you would do it in any other development approach, too.
Architecture, the stuff you wish you had done afterwards, gets short shrift.
Never happened in a project I was involved.
Not for the software development teams ... what exactly would s/he manage?
Because due to global warming the glaciers are shrinking, that means the average size over the course of a year gets less from year to year or decade to decade. As you surely know that: what kind of nonsense do you ask here?
What they seemed to miss was the idea that if the glacier was NOT melting, there would also be no water downstream....
What you seem to miss is: glaciers are supposed to regrow in winter. So the average size is constant
And nevertheless most people don't can distinguish Java from C/C++ or JavaScript code ...
No idea why you hate people who prefer to write in Java.
Code is code, get over it.
Hardware is irrelevant in > 90% of all cases of software development.
Here some C code to bloat about:
int* ptr = 0x3FAD;
*ptr = 1;
What dos it do? Spare me the answer: you don't know. But it is perfect C, isn't it?
For example a Java 8 compiler won't even compile Java 2k code.
And why would it? Java2k is a language like brainfuck, just made for fun and nerdyness.
Strange,
Climate modeling, weather forecasts, most fluid dynamics code, and so on, need to be compiled to get enough speed.
The meteorologic institutes on the world disagree. Most of their software is Python.
There are still shops that use cobol, but no one starts new projects in that language
Of course they start new projects in COBOL.
It's important to remember that there are an order of magnitude more programmers now than there were in the days cobol was popular
Yeah, most people don't think about that.
According to this: https://www.statista.com/stati...
The Android app store has about 4 million apps, the Apple one about 2 million. Obviously many apps are super simple. But assuming you do something decent an App easy will have a few 10,000 lines of code. And that are only Apps, no one is really counting how much lines of code in house software developers create for stuff that is never used outside of the organization
I guess we have a significant increase of lines of code written per year. Even if it is only 2% it doubles every 35 years.
When, in the process of building a product, a programmer is expected to do their work in 2 week chunks exactly as (usually someone else) has decided with very little room for deviation (gotta maintain that velocity!), it's hard to feel invested in what he or she is building. It's hard to feel like your human judgement means anything at all.
If "someone else" has decided what "chunk" fits into a 2 week sprint, then: you are doing it wrong!
(gotta maintain that velocity!)
No, you don't have to maintain your velocity: you have to for funk sake measure it, that is all. If you think you have to maintain it: you are doing it wrong!
You certainly don't care if the project succeeds or fails. Then you are a moron and should be working in a business that does projects. You are doing everything wrong!
You just want to get your sprint finished as quickly and easily as possible so you can go home
A sprint finishs, when the time is over, not when "everything is done", if you think otherwise: you are doing it wrong!
And, agile in practice reinforces that, because that is how management sees it. Then your management has not understand what sprints and being agile is about, hence: you are doing it wrong!
(because I've never worked for a manager who had any experience programming... which is sad in and of itself).
Then stop whining, get _agile_ quit your current job and find a manager that has a clue about software development.
Only scrummy people consider scrum agile. Agile people do not.
Everyone considers Scrum agile. Except you obviously.
Point to any reference to Scrum in the Agile manifesto.
Why would there be any? Point to any reference of Kanban or XP in the Agile Manifesto!
The agile manifesto is a destination of many agile methods, to nail down the core principles. Why would they need to point to the "methods" they consider agile?
And I really wonder abut your hate to "agile", "Scrum", "XP" (and other people like arth1 etc.) ... what is so fucking hard in finding an employer "Who does Agile right?" Why are you complaining all the time but seem to be _frozen in place_ instead of being _agile_ and for funk sake change your job?
Scrum: process, process, process, you are just replaceable cogs.
Scrum dos not define any software development process.
It defines a meta process and rituals/ceremonies to keep the meta process on track.
No, it does not make developers cog wheels ... if that is happening for you: you are doing it wrong ;D
If your "faux-agile" team managed to release working software successfully every two weeks, and had reasons to increase sprint time under pressure: then it was superbly agile and no faux at all.
And then again: if you release weekly it does not indicate at all that you are agile. It only indicates: you are releasing weekly.
"True agile" developers have to master how to implement changes in small steps: increasing throughput means implementing more small steps in the same time. "Faux agile" developers don't master that and increasing througput ends up meaning increasing the steps lenght, defeating the whole idea of agile.
You are an idiot. You do not value people at all. You treat them like machines. Worse is: you apply your own metric when a person is successful and when he is a true versus faux agile developer, actually you are an asshole.
You are exactly that where every guy here in the thread is talking about: you treat developers like slaves, press them to work harder instead of letting them work smarter. You failed to grasp what agile is about.
TL;DR: if the dev cycle under demanding workload shortens you are doing agile right, if it gets longer you are doing it wrong.
If your workload gets more demanding, your organization/company is doing something wrong: e.g. they forgot to hire more developers.
Shortening the cycles increases the "residual load", like wasted time in sprint planing, sprint reviews and sprint retros, integration testing, acceptance testing etc. The shorter the sprint the more relative time you spent in meetings and the less relative time you actually do work. You got all this completely backward. If your team struggles to deliver features every sprint, then you have to lengthen the sprint period, not shorten it. You are simply an complete idiot.
my limited set of empirical data strongly suggests that Agile(tm) is a supremely craptastic method for producing software. ... perhaps you want to read up again what their core principles are, moron.
Then you neither understand Spiral Model nor Agile Methods
Agile is no better and no worse that any other way of doing business.
Waterfall: I analyze 3 month, I design 3 month, I implement 3 month, I test 3 month. After 12 month I deliver a product that is no longer adequate for a market that has changed over the course of said 12 months.
Agile: I deliver after ~6 weeks a working, tested, approved, subset of the project. Every ~6 weeks I can change course, change the scope of the project, change priorities of features. Heck, I can cancel the project after 3 sprints because I realize: the team is to slow, it will take them 18month, which takes to long, or is to expensive.
First approach has the risk of sinking a HUGHE amount of money. the second approach has the risk to sink a considerably smaller amount of money. That is the reason why most modern SD is done agile (or abuses agile by 'doing it wrong').
The simple reality is that 50% of the software developers out there really should not be developing software because they just plain aren't good at it.
That is unfortunately true for every job.
the ostensibly Agile-focused helpers say that's not part of Agile, it wasn't in any of their training, and that they got Agile certification so they should know.
A "certified scrum master" course goes over two days, and can be abbreviated into one day if the students are prepared: there are hundreds or thousands of things a student might not know afterwards.
When I point out "Responding to change over following a plan" was part of the manifesto,
If they don't know that they are morons. The core principles of the Agile manifesto, Scrum, or Extrem Programming fit on a single page of paper, even with 2 sentences of explanation.
The "Atlassian Story" indicates the guys mix up process with tools ... probably the reason why old school CSMs use paper cards to track everything instead of tools.
For example, Extreme Programming was, and still is, a stupid idea. Sorry, two people can't use a single keyboard efficiently.
People who mix up "Extreme Programming" (a software development process) with "Pair Programming" (an optional 'habit') in discussions like this (note: it is not the same thing), are like people who mix up sand with bricks or cows with milk.
You don't belong into discussions like this as you obviously have no clue about software development.
What is next? Mixing up what a file is with what a database is? Or mixing up what ASCII is with a compiler that reads ASCII files and writes object files?
The fact is, a good team will be successful regardless of the process (arguable). A bad team will be unsuccessful regardless of the process (true). IT'S NOT THE PROCESS! It's the PEOPLE! :D emphasizes mine.
Exactly, the first paragraph of the Agile Manifesto
I work with agile methods since 1993. :D ... they sold and closed off the sub company that was using the product and wanted it integrated. A management decision ... not a failed software project but bad management of an energy company, because that energy company does not grasp that _all_ modern companies are IT companies and rely on their software to have a business advantage and not on their power plants.
I only was in one company/project where they did everything wrong and in another project where the Scrum-Mistresses thought every "meeting" is a socializing event and needs to introduce a new "meeting conducting strategy", when I pointed out that this is not the job of a ScrumMaster, I got fired the day after
In other words: I do more or less agile projects since 25 years, and all went FINE! The best running project (from 2004 - 2008) was supposed to be integrated into SAP (around 2016). Obviously that failed (was basically impossible, and everyone involved should have known that). That was at a energy holding company
So bottom line, during 25 years of mainly doing agile software development I had less than 2 years of bad examples, the rest went quite fine. And that is why I say: "If you don't get it working: you are doing it wrong!" But most likely you would do every software development (process) wrong anyway, so: who cares :P
Which part of: "You are doing it wrong" did you not get till yet?
If you do 4 daily meetings: you are not doing an agile method but some bullshit.
Can't be so hard to grasp.
Agile requires that you intentionally ruin any long term planning since you don't think long-term but instead think of sprints.
That is nonsense. If you think like that, then: You are doing it wrong!
but according to Agile you work people to death for two weeks
That is nonsense. If you think like that, then: You are doing it wrong!
abuse them, insult them, insult them, and then repeat that process every two weeks.
That is nonsense. If you think like that, then: You are doing it wrong!
And you should have the guts to QUIT!
It's all about abusing people as much as you can legally without being charged with a crime.
No it is not, you simply are a moron or a troll or both.
Of course it is not for status updates.
However daily meetings help to realize that perhaps always the same developers are not finishing their work as planned. Perhaps they overestimate their capabilities constantly and pick to hard work from the issue tracker. Or you realize since days some of the developers are "blocked" because some administrative issues don't get fixed.
In a ten man team, a daily meeting can be over after 5 minutes, and indication is: most is running fine
It can take longer, indication is: you have problems
Identify the problems, address them to upper management, get them fixed.
If you waste time in meetings, then you either organize/conduct the meetings wrong, or you are not reacting to the issues raised in the meetings properly.
Tasks must be explained to one manager, who has the status to talk to another manager, who has the status to speak to their team, and _each_ layer must be completely convinced
I really wonder: what actually do you et wrong with "agile"?
The point of agile is to REMOVE those layers and have ONE SINGLE DECISION POINT.
Why is it that people don't grasp the most simplest things about agile methods?
I've worked in plenty of secretive companies where agile is a problem as information is intentionally withheld from the developers ... if the developers know not enough they can not design or architect, or even code.
That has probably nothing to do with companies where agile but with information is intentionally withheld
Regardless what software process
What the funk has that to do with agile? Agile methods are ALL about an open backlog where everyone involved sees the complete backlog. If you don't have such a backlog, then:
a) you are doing it wrong (regardless of process)
b) you are not agile
I guess you got Scrum wrong.
In Scrum, there is basically no manager, the team is self managing. That is more or less true for all agile methods.
Ultimately that is the opposite of Agile, which says, "We value individuals and interactions over processes and people." If you don't trust your developers, the focus should be on improving the skill of your developers so you can trust them. The best agile methods focus on improving the soft skills of the programmers, rather then beating them down or 'controlling' them with process
That is exactly what Scrum and XP are doing.
Maybe mobile apps or web apps, but not so much platforms that are expected to exist for a decade or more and grow along the way, or where high reliability is important,
That is nonsense. The "niche" of choice is completely irrelevant.
or where it's not just software but also hardware that is much harder to change.
The origins of Kanban come from a hardware company: Toyota!
"you aren't doing Agile right" argument is old and tired and just plain wrong.
No it is not wrong. You are wrong.
Ever tried to cut a soft cake with the dull side of the knife? Works surprisingly well, but is wrong. Try the same thing with a salami, but don't make the mistake to push with you other hand down on the blade of the knife.
Point is: it does not work to cut the salami with the dull side of the blade. You are doing it wrong, your holding the knife wrong.
However it is an excellent variation of holding the knife if you want to stab one to death. Much more effective if the cutting edge is on the upper side.
If your software development method is not working: you do it wrong! Regardless what kind of method you use. First: learn how to develop software. Then: pick a process/method that works for you.
If you can not do Scrum or XP: then you can not develop software, period. It is not the method but your immaturity in making software that makes you fail.
Since I've started working in Agile groups for a number of years the development has been way more subject to "here's a feature that can be added in two weeks, let's go for it" w/o a coherent overall view of where we were headed.
If you have no coherent over all view: then you are not doing software development right Regardless if you, your team or your company labels something with "agile" or "not agile"
When you can not even do software development right, why do you think going for "agile" would be an improvement?