Slashdot Mirror
The State of Agile Software in 2018 (martinfowler.com)
On the surface, the world of agile software development is bright, since it is now mainstream. But the reality is troubling, because much of what is done is faux-agile, disregarding agile's values and principles, writes programmer Martin Fowler. The three main challenges we should focus on are: fighting the Agile Industrial Complex and its habit of imposing process upon teams, raising the importance of technical excellence, and organizing our teams around products (rather than projects), he added. An anonymous reader shares his post: Now agile is everywhere, it's popular, but there's been an important shift. It was summed up quite nicely by a colleague of mine who said, "In the old days when we talked about doing agile, there was always this pushback right from the beginning from a client, and that would bring out some important conversations that we would have. Now, they say, 'Oh, yeah, we're doing agile already,' but you go in there and you suddenly find there's some very big differences to what we expect to be doing. As ThoughtWorks, we like to think we're very deeply steeped in agile notions, and yet we're going to a company that says, "Yeah, we're doing agile, it's no problem," and we find a very different world to what we expect.
Our challenge at the moment isn't making agile a thing that people want to do, it's dealing with what I call faux-agile: agile that's just the name, but none of the practices and values in place. Ron Jeffries often refers to it as "Dark Agile," or specifically "Dark Scrum." This is actually even worse than just pretending to do agile, it's actively using the name "agile" against the basic principles of what we were trying to do, when we talked about doing this kind of work in the late 90s and at Snowbird. So that's our current battle. It's not about getting agile respectable enough to have a crowd like this come to a conference like this, it's realizing that a lot of what people are doing and calling agile, just isn't. We have to recognize that and fight against it because some people have said, "Oh, we're going to 'post-agile,' we've got to come up with some new word," - but that doesn't help the fundamental problem. It's the values and principles that count and we have to address and keep pushing those forwards and we might as well use the same label, but we've got to let people know what it really stands for.
Our challenge at the moment isn't making agile a thing that people want to do, it's dealing with what I call faux-agile: agile that's just the name, but none of the practices and values in place. Ron Jeffries often refers to it as "Dark Agile," or specifically "Dark Scrum." This is actually even worse than just pretending to do agile, it's actively using the name "agile" against the basic principles of what we were trying to do, when we talked about doing this kind of work in the late 90s and at Snowbird. So that's our current battle. It's not about getting agile respectable enough to have a crowd like this come to a conference like this, it's realizing that a lot of what people are doing and calling agile, just isn't. We have to recognize that and fight against it because some people have said, "Oh, we're going to 'post-agile,' we've got to come up with some new word," - but that doesn't help the fundamental problem. It's the values and principles that count and we have to address and keep pushing those forwards and we might as well use the same label, but we've got to let people know what it really stands for.
Seems like with each new manager and team lead they change things. From codewords to project phases to agile. The not invented here mentality is the problem
Just the latest management fad in a long line of management fads, watch as we wave away criticism of our touted silver bullet.
...Sounds good on paper, disastrous in practice. I've never seen Agile do anything but drag offices down to the lowest common denominator. All it takes is one lazy manager and chaos reigns.
YMMV I still find it better then the old system and waterfall. My biggest problem you would get stuck in a 2-3 year death march when you know the project is going terrible due to the sunken cost fallacy. Now at least with agile the most you waste is 2 months.
“We are an Agile shop”: Your expected standard work week will be 80 hours
“We are a Post-Agile shop”: Your expected standard work week will be 95 hours
“We believe in work-life balance”: You’ll be required to wear a beeper whenever you’re not in the office
#DeleteChrome
If "agile" is the predominant software development process, can I conclude that it is the cause of all the utter CRAP software that has been produced in the last 10-15 years?
Is "agile" the reason why paying customers are now unpaid beta testers for the vast majority of crapware foisted on us by software houses?
I'm just asking.
It is an ideology that's great on paper*, but it seems like it falls apart once people get involved. It doesn't seem to account for human nature.
*Solution: Write the plan on True Scotsman brand paper.
The trouble with Agile is that eventually you run out of other peoples' time.
* "Daily standups" for each and every project no matter how trivial, leading to multiple hours of every workday wasted by everyone telling each other that there's nothing new to say
* Multiple layers of non-technical management deeply embedded into the development process, creating massive inefficiency (I am on month #4 of trying to delete four lines of code from one program)
* Devaluation of the importance of developer skill in the success of projects, since "agile" will ensure good results from whatever random assemblage of idiots you scrape together (developers usually referred to as "bodies")
* Selection of tools/technologies by cargo-culting other "agile" organizations (XYZ uses product ABC? We must use it too!)
I'd go on but I'm depressing myself too much.
I'd like to share some conclusions I've made over 30 years in the industry. The method of managing developers to a large extent doesn't make that much difference. Developers are going to be as productive as they want to be. The crux of the problem is this: managers would like to treat developers as an interchangeable resource, like ditch diggers or production line workers. They can do this because there's no real professional accreditation within the industry, other than having already worked with something, or for someone. It keeps wages low and the worker pool high, after all you can just hire random fresh faces and they'll do just as well as each other once they're brought up to speed, right? Well, no.
What I've seen is that although developers gain knowledge over time, what doesn't seem to vary that much is their skill level. A bad developer is always going to be a bad developer. Sure, they can be taught some tricks to reign in their worst excesses, but they're never going to be on a par with someone with natural talent, they're always going to be slow to understand, or never understand a concept at all. Meanwhile the few who are good at what they do won't just understand what they're doing, they'll invent new ways of doing things. All for the same wage, because managers really don't notice or care about these things.
And here is the crux of the problem. Programming is skill based, and with all the will in the world only a few people have a talent for programming. As long as no attempt is made to recognise this difference, and as long as managers continue to treat "programming" as just something that gets done, then no method of management is going to help you. I'd say currently about 90% of the industry has no right working in the field, and their talents would be best employed at some other kind of job.
"The human rights abuses of the Soviet Union and the People's Republic of China weren't REAL Communism. REAL Communism has never been tried."
Back in 2016, or maybe it was 2015, CNN or MSNBC started calling online news sources fake news.
The online people, recognizing that CNN, etc. sometimes publish biased or incorrect stories then turned it around and started calling CNN fake news.
Were CNN right that a lot of shit on the internet is fake? Sure. But that didn't matter. Once people started calling CNN fake news it spread quickly and they lost control of the plot.
Back in the day these guys came up with agile as a name for a set of best practices.
Then other people figured out how they could make money from it by writing books and selling them to managers where they explain how they can implement "agile".
Now the original agile people have lost all control over what agile is.
Same thing with hacker now being someone who downloads automated tools to find and exploit known vulnerabilities.
Meta-meetings and post-it note development
...its pervasiveness.
It's a valuable tool IN A TOOLBOX.
If you're NOT an ISV, and you make software solutions for individual customers (which is what the vast majority of software developers find themselves doing) - then Agile is probably the right way for your company to go.
If you ARE an ISV (and Independent Software Vendor makes products, unlike the folks above who work on PROJECTS) then use Agile at your peril.
ISVs that use agile are those that tend to have "Product Managers" who are not actually Product Managers, but are instead "Project Managers" with a penchant for making products up out of virtually thin air ("Oh, a customer wants this, so this must be part of the 'product.')
ISVs that know what they are doing start with Product Managers - because a Product Manager has DOMAIN EXPERTISE that means they actually know what the market wants - not just a single customer. The problem for wanna-be ISVs is that real Product Managers are expensive and difficult to find (but they're out there) due to the Product Management market being swamped with Project Managers calling themselves Product Managers.
If your company has a technology or product related vision - you should not use Agile.
If your company has a market dominance or growth related vision, and you make software tailored to a specific customer's needs - you should probably use Agile.
Loading...
... Our challenge at the moment isn't making agile a thing that people want to do, it's dealing with what I call faux-agile ...
... focusing far too much on what to call the process, and focusing not enough upon what problems the client needs to solve. Perhaps the move to "faux-agile" (as you call it) is really more of a move towards actually solving the problems the customers have, and less of a desire to make sure the process to achieve those solutions has the correct name.
What a mess of an article. Whoever wrote this is struggling to convey their thoughts. If you can't communicate your struggles with Agile, how is your organization going to do better at instituting it?
“We believe in work-life balance”: You’ll be required to wear a beeper whenever you’re not in the office
If anyone ever asks you to wear a beeper, find Doc Brown immediately. And it is critical that no matter how hot she is, under no circumstances should you make out with your teenage mom.
My beliefs do not require that you agree with them.
If I learned one thing from experience with "agile development", it is how totally different from the IT-perspective it is seen from non-IT people, especially customers and managers:
Customers: "Agile is great, because now we can change requirements whenever we like, and don't even need to think of what we really need in the beginning. Ah, and by the way: We don't have time to sit in your sprint-planning meetings. We just expect you to deliver."
Managers: "Agile is great, because now none of those IT wisenheimers can obstruct our great vision by telling us how time and effort consuming our projects will be before implementation starts. Once it becomes too obvious how much more work it will take to turn the software into something useful, it's too late to cancel the project as a whole, and we'll just demand long hours from the programmers."
Any management system that depends on each part running nearly perfect is probably either bullshit or doomed or both.
Sure, you can have tons of auditors to make sure everything works according to the mantra, but auditors and their interaction cost money.
Table-ized A.I.
While Martin Fowler does program, it's farcical to describe him as a 'programmer'.
Other labels might include software engineer, thought leader, visionary, author, scientist and 'probably the greatest software engineer the world has yet known'.
I'm sure he'll welcome people disagreeing with his writing, especially if they speak from informed positions, but he's one of the rare people that you really should look to understand and respect before you dismiss their views.
I have tremendous gratitude to people like Gamma and Beck; they're pioneers and have done more than almost anybody to turn programming into an engineering discipline.
Almost, but not quite. You see, there's Martin Fowler..
[Disclaimer: Early signer of the Manifesto for Agile Software Development and Scrum Master speaking]
"Agile Software"?! What crack have these guys been smoking?
A software development process can be agile in a way that it provides flexible and frequent kinda-sorta "on-demand" interaction with the customer. Usually customers who don't know what they want until they see it but somehow know exactly what it may cost and when it has to be finished. Classic corporate and web software stuff that is.
The aim of such a development process is agility in software development. The actual process itself often is very rigid (Scrum being one of those),
"Agile" as a nown is a huge part of the "agile" bullshit we've been hearing in the last 10 years. And there is no such thing as Agile Software. ... Well, no shit, buster.
Morons writing about some other moron bullshit that "didn't pan out".
I wish we could wrap all these douchebags into barbed wire and shoot them into the sun. That would be progress on the front of agile software development.
Bottom line:
Idiots babbling non-sense. Nothing to see here, please move along.
We suffer more in our imagination than in reality. - Seneca
The hardest thing about Agile is trying to fit it into your busted company. "Oh, we don't do requirements, we're Agile". Uh-huh. How about SOME direction on what we are trying to build here then? How about not having insane product owners who over-simplify everything, don't listen to actual development teams, and aren't actively engaged in the process? How about the CEO who hires a high-priced CTO who picks some oddball technology stack, then has an international contract team do the work because they are cheap, and after missing every promise of delivery over a year and a half period, moves on to another projet and leaves the onshore team with the bag of garbage.
Agile has always be bastardized. But when it works, even if it is not perfect, it is beautiful. I am old enough to remember the waterfall days and at that time it was the only thing around until iterative (the true original method), XP, and Agile came around. Agile is simply a tool to get the job done, and it will not solve all of your problems. But you absolutely do need to do it right, and maintain that process, to really make it work.
My beliefs do not require that you agree with them.
Corporations by and large still have this command and control mentality. It's hierarchical, and they want people to be replaceable, fit into nice little molds, and just turn people into interchangeable parts. The decisions all flow from the top down, and workers are deliberately diss-empowered primarly because of a class based system where the managers know best, and the workers are uneducated. And everything is under control where we create this nice finished controlled product like an assembly line. (Ignoring the fact that this was never a particularly great system even in the manufacturing world).
Agile completely up-ends that. The workers actually know more than the managers. The decisions have to start from the bottom up, not the top down. The workers are anything but replaceable and inter-changeable, and the process sometimes winds up completely changing what was originally conceived up from the start of things.
Essentially, there's a massive culture class here, and the corporate world is winning. Corporations have decided they just need to be agile, so they took their current command and control mentality, sprinkled in a couple agile terms, and declared they were Agile.
usually when an idea is good, it will be ruined if it goes to the masses and is hyped. so no suprise there.
I did some work on porting custom server OS to different. We were add no new features, we were only addressing any issues found. Agile was shoved on us and I constantly wondered how it was useful. Later when I had a bit of time to read up, I saw how useless it was for us. The most useful is web programming were the user is forced to use the latest version, next is software that requires upgrading but ignorant of hardware is the next, last any development the developer is interfacing with specific hardware there is no advantage
It never works at all in practice and when someone criticizes it, you'll undoubtedly have someone chiming in saying, "You're just not doing it right."
Newsflash: agile SUCKS!
Agile means: you realize after 3 sprints, the project is to big, the team is to slow, the team is to bad.
But what if it's Agile that made the project too big, the team slow and apparently bad?
I've seen the overhead of Agile make a project last longer than it realistically should have.
I've seen Agile metrics make a team to be slow when they were working on some part that appeared no different than others but simply required more thought and care to build.
I've seen great teams that worked well together look "bad" at times under Agile because over time the system was too rigid to allow for needed infrastructure work, which never got prioritized by the system over which the developers had little input.
Sure some of that is Agile being used badly, but after some time I am kind of wondering if perfect agile is like a working socialist system - any time there's a failure it was not REALLY agile you were practicing, and it seems rather hard to come by working examples that did practice the respective ideology properly that worked...
"There is more worth loving than we have strength to love." - Brian Jay Stanley
It's a waiting game until this fad blows over. Each fad always highlights its own successes and downplays successes achieved with anything else. And then we welcome the successor.
I hadn't the slightest objection to his spending his time planning massacres for the bourgeoisie... (P.G. Wodehouse)
"You're not holding it right."
Agile is horrible, just in the same way that UML is horrible. Artificially inflated everything, constant mess, prototypes that go nowhere, time wasted and a metric FUCKLOAD of documentation.
And, ironically, usually leads to bugs more often than not, IN SPITE OF PLANS. This is especially true with UML since it leads to inflated job roles filled by legit retards that don't know how to tie shoelaces, never mind program!
The newest, shittest project management meme like the others. Agile, SO FRESH, despite being from the 70s.
It's just all the hipster nutjobs getting behind it.
Agile-founded software ends up buggy as shit usually, because they never had time to produce actual solid code.
Then it leads to a constant issue of long maintenance requiremen... ah there we go, that's why it is the new hotness, maintenance costs from clients. Problem solved, everyone go home.
Then again if they had gone with that name (one that one of the guys at the original agile conference wanted to go with) people probably would have screwed it up anyway.
Did you know 80 to 90% of the moderators on slashdot wouldn't recognize a troll even if one dragged them under a bridge.
He says an awful lot about how it's fake and bad and not what his shining vision is. How about saying exactly what is going wrong? Nope, he could earn enough money by being forthright and honest. Fuck him.
Perhaps people are adopting what works for them, and leaving the garbage to the side?
If there's a persistent reluctance to adopt the whole thing, it's probably not because the missing pieces are making their lives easier and the projects better.
I know I've mentioned this before but the problem with agile is like that of law. The whole point of law is to make society fair and just. In a nut shell so you don't get treated differently because you're some schlub than you would if you were rich and well connected.(Don't laugh) Unfortunately law is complex so you need someone to help you navigate it. They're called lawyers and they're hopefully experts in law and can help you navigate the legal system. The problem is that while in theory a scrupulous lawyer will do his best to help his client, as will the lawyer for the other side, and in the end promote a more fair society. However all it takes is for a few dirt bag lawyers to take their knowledge and weaponize it, completely perverting any sense of justice to screw person after person over. You'd hope the legal system would have the person disbarred but some how that doesn't seem to happen enough.
I see the same problem in agile. In theory agile is all about empowering the developer, make his opinion valued and get him or her engaged in his work. By doing this motivating the developer to do their best work but also valuing his contribution and not turning them into a cog in the machine. However I've seen more than a few agile lawyers. Oh sure, they can quote agile principles at the drop of a hat. However when it comes time to actually empower anybody but themselves? Nope doesn't happen. How about listening to the developer, of course not let's use agile principles to just put the poor schmuck on a never ending treadmill and then wonder "Geez, why don't the developers like agile, guess they must be lazy." Simply put just perverting any sense of agile and then blaming the developer when their fucked up agile doesn't work. Why do they do it? I have no idea, maybe they get off on it or something but the problem is that agile lawyers sound like experts so management falls for it every time. The only thing you can do is move on and hope the next place either doesn't do agile or manages to be one of those rare places that has a clue and does it somewhere near right.
Did you know 80 to 90% of the moderators on slashdot wouldn't recognize a troll even if one dragged them under a bridge.
Agile is the current fad. As usual, it is critique-proof - if it doesn't work for you, you are not doing it right. Give it a few more years and it will essentially disappear, like all other fads that preceded it.
This explains matters quite well: http://www.thechurchofagile.org
What has "programmer" Martin Fowler actually programmed? All I could find is about agile and speaking engagements. Why is he an authority in software engineering if he doesn't have any wildly successful projects to his name? I've worked on some successful projects at FANGs. *Not a single one* used Agile. Half of them used continuous delivery. About one quarter were straight up waterfall (specs, coding, testing, bug fixing, all done in phases).
over and over. Yes, we get it. People are not doing agile the way you think it should be done.
That's not Agile. That's more like waterfall where you go through the entire process and produce the wrong result.
But they didn't produce the wrong result. The customer started out wanting a house and that is what was built, but were not really clear it should also be able to drive to a lake....
Although a silly example I totally think it has a kernel of a good point going on here, because Agile greatly amplifies focus on smaller feature work while generally ignoring the larger strategic picture. Agile would in fact be the first methodology I would say is most at risk for missing bigger features that are desired because everyone just starts off.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
*Not a single one* used Agile. Half of them used continuous delivery.
When you say Agile, do you mean scrum? Because I thought Agile was continuous delivery, with Scrum just being an implementation of Agile.
This gets really confusing because all of my coworkers hate Agile (because we tried Scrum for a while), yet we build roughly every two weeks and get feedback from our internal customers quite often. And my coworkers are fine with that.
Right. Hence the fact that the rest of the world is invading the space since they know it is what is produced that counts and it makes no damn difference whether it was pure agile or something else that got you to that product. The values and principles are called "agile religion" and that is part of the problem.
Have you ever voted with your team on changes to your development procedures, including frequency of meetings, choice of tools or direction of development?
If you haven't, you're working in a waterfall dictatorship that calls itself Agile much like North Korea is a "Democratic Republic". The whole point of Agile is the developers and the stake holders create a system where their opinions are truly valued (hence voting) and thus get buy-in from all parties. Otherwise it's just a cargo cult.
-- Political fascism requires a Fuhrer.
Was "Agile" a scheme to sell books and corporate consulting services and lectures?
I'm reminded of Feynman's anecdote of delivering a lecture to a group of philosophy professors and not making it past a very early part of his lecture because an argument erupted among audience members about the meaning of a basic word: "Agile"! (Disclaimer: The term in dispute was actually "apps"!)
Agile encourages no accountability, over run project costs, and no invented here syndrome. There is a serious disconnect between executive management and technology teams. Agile fosters politically charged environments and and the biggest cry babies climb to the top.
I stick Agile right up there with ISO 2000 and underwater basketweaving. If it's thick enough, you can use it to hold up the sofa.
I literally know nothing about Agile but these discussions seems be primarily religious with the keepers of the one true way denouncing heretics. I myself am in favor of anything that gets a good product out the door whether "real" agile, 'fake" agile or dancing to the moon goddess.
I've never really felt that agile was actually agile as it was always so fragile. If you didn't do it just right it didn't work or at least it was cause for failures. Granted, the alternatives are poor but a good team and team lead can do just about anything and make it work.
Nah, mostly bitter and twisted and perpetually outraged, not agile in any sense.
Churn is a much better term than Agile.
Agile = Let's not know what we are developing or bother to understand the business or system rules, let's just "make product" and jump with joy (or other emotion) when nothing of consequence has been produced.
Agile only works for code mills.
Everyone else gets burned or dies while a consultant defensively asserts "You're doing it wrong" before "sprinting" out the door.
All you could find? Did you search Wikipedia?
agile's values and principles
Hype, rush, and bullshit.
The only software development methodology worth a damn is waterfall. Yes, it's slow. No, that's not necessarily bad.
If you're doing something useful you know what you need to do, you do it, you TEST IT, and you LET PEOPLE USE IT IN A STABLE STATE.
THEN you think about changing it in a future version.
This is again an article that's written from a perspective 'in the eye of the beholder'.. What is agile exactly? there are different opinions about it.
Does agile work? Yes.... but in most cases it doesn't if it's exactly as one has written the 'agile rules' (whatever those exactly may be)..
There are so many different ways to good development, and Agile is just one of those 'tools'.
If you've been using 'Agile' for ages, you're propably so accustomed to it, you don't even know if it's really the best way. And in most cases, it's just a name given to a process people have been doing for ages, but never have given it a name..
You need to find a middleground, and do what's best for your company/team.
This article was clearly written by someone who sees Agile as his only holy grail... And 'we' IT people tend to stick what we know best and think the rest is just 'not so good'...
The last three or so jobs I've been in all jumped on the Agile bandwagon.
Because for some (most?) developers and team leads, it was great because it validated and formalized their "hacker in mom's basement" approach to developing software. One of the 4 Values reads "Working Software Over Comprehensive Documentation" so that was taken to mean no documentation needed to be written any more (who likes to write and read docs anyway?), and as long as the code passed the (few inadequate) test cases thrown at it, it needn't be maintainable or commented or strictly correct. If a bug was detected, it was logged and a work item to fix it would come around (again...) in the next sprint and the bug would be agiled away. Over time, with staff turnover leading to loss of system-specific knowledge and experience, the spaghetti just became more tangled and the development team gradually came to resemble the million monkeys at a million keyboards.
But management was quite fine with it, since it did not require them to understand what the coding monkeys actually needed or were up to, it was buzzword-compliant, and hey, one can always passive-aggressively demand that the devs put in more overtime (since they weren't paid for overtime anyway). They could just use this simple paint-by-numbers approach (4 values and 12 principles, "customized to our own needs") and churn out Rembrands by the truckload.
I see all of this wonky thinking on this subject. At a high level it is actually pretty simple. It is on one side there is the effort to develop and redevelop, on the other side there is the exact knowledge of what needs to happen. It is like the supply and demand curve. Maybe in your shop things have been specced out to a high degree of certainty and you as a developer just need to either live up to that expectation or understand why you can't. In another shop it is known that "something" in this general direction is needed, but what exactly that is as in implementation terms has not been thought through. In this case depending on where you are at on the team you are either suffering from a bad project lead or you are going out of your way to find out exactly what is needed, doing lots of research and thinking on your own mentally building and rebuilding as much as possible (what I consider front loading) because you know having to redo everything because nothing was done right in the first place is going to suck and may even be the end of your job (or even business). This latter, more common case is where you are supposed to use Agile practices. Even in the 'waterfall' method, if you are really strictly doing waterfall, you are probably doing something wrong. If you are writing code without a clear, reasonably coherent plan, and your code does not fit the need, then you the developer are the problem. (It is a tough life being a software engineer.) The thing is the usual case is everyone involved are mere mortals with differing capabilities and knowledge and so whatever 'Agile' development used needs to be a balance between the various forces at play and you as a developer have to be using every tool that is a good, proven tool to cut down on (re-)development time while still having a way to handle the evolution of ideas and understandings over time. Agile is just supposed to be a tool in the tool chest for seeking this balance in a well proven, structured manner.
Maybe another way to look at this is two really key things I see missing a lot is good, structured communication, and an accurate vision of what needs to happen. The thing about being a successful software engineer is you can be the most technically savvy person in the world and still fail. The reason for failure is often not technical know how, it is the lack of communication. There is also the deal in this realm where there is this 'polite' culture of not admitting to anything that may look like you messed up or are incompetent. The thing is we are moral humans and there are certain things that go along with this, so considering these things when communicating and setting up your business dealings can go a long ways to making a software project successful. After all software are just thoughts inputted into a computer. If you cannot convey thoughts around your group and the vision of what needs to happen is not properly shared and scrutinized, it does not matter how many technical tricks you know, what you entered into the computer is wrong and will not suit the needs of those who will use it.
... is the terminology.
I'll look up what role someone says I am and I go, oh, you mean what the rest of the world means project manager?
I hate to say it, but it's juvenile.
As for agile? It's basically iterative waterfall. I almost want ot laugh in some of the meetings I am in. Maybe it's the inexperienced people that need these strange meetings. For me, they are a waste of time.
He got some cushy job at a big corporation, but I don't see any game changer project.
How did they get that way? Discipline and practice; practice and discipline, more practice, more discipline.
Too often, Agile as applied to software development seems to mean the opposite of discipline, and I'm not sure where practice fits in.
--
.nosig
How may times has there been some statement or argument along the lines of: "Linux isn't really Open Source because it doesn't adhere to all of the professed tenants of the "Open Source" movement"
Guess what? Industry doesn't give a crap about "purity". If you can find good ideas, adapt them to the company/culture/situation and, most importantly, produce results then who cares? If the values present in company/culture/situation don't largely match that of the team and of their management then no tool or methodology is going to make that any better or lead to a demonstrably better result.
No, I mean stand ups sprints and all the other methodological bullshit. CD simply means that things get merged into master often, and master is kept well tested and stable, and released to prod at least every week. You donâ(TM)t need a âoemethodologyâ to do that.
buzzword for cult that focuses on internal metrics too much. ignore it.
In the article, the only specific problem stated with "faux-agile" is that teams aren't allowed to decide on their own process. Why is this the deal-breaker?
As teams scale and multiple, if each one is using it's own unique process, it makes it impossible for the company to see the whole picture.
Many enterprises have chosen Scrum. It's not perfect, but it's not bad either. It's CERTAINLY better than Waterfall! So why not take the good that comes with moving to Scrum, and run with it, instead of wanking about the loss of pure agile?
"The Absolute fucking state of the Agile Software Disaster as of 2018"
The clearly-titled Project Management: A Surefire Way to Kill Your Software Product by Steven Lowe hits the nail on the head. If you've ever found yourself frustrated or overwhelmed by a process—purporting to be agile or otherwise—you'll find this essay is a refreshing read.