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.
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
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.
*Solution: Write the plan on True Scotsman brand paper.
Yeah, the "you're not doing agile right" mantra as the explanation for failure, and repeated in every agile "state of the union address" is becoming tiresome. You'd think that if there were a right way that made the companies and customers more happy, we'd all be drifting that way and things would get better and better, simply because those doing it right would outcompete the others. This is not what we observe happening.
Is "agile" the reason why paying customers are now unpaid beta testers for the vast majority of crapware foisted on us by software houses?
If they won't pay for proper QA under agile, what makes you think they'll do it under waterfall?
...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.
...Sounds good on paper, disastrous in practice.
Another similarity is that when it fails, the proponents will say that is only because you weren't doing it right.
My opinion:
Good agile practices: TDD, FBF
Ok in moderation: Standups, sprints, stories
Bad: Everything else
TDD = Test Driven Development
FBF = Fix Bugs First
Agile (as conceived originally) only works for small teams of competent people.
The problem is that it's cheaper to hire cheap people who need a simple set of procedures to complete a task.
So of course companies boil it down to a simple tick the boxes style procedure regardless of the intent.
Whether this is a failure of agile to take into account human nature, or companies doing it wrong is irrelevant.
we'd all be drifting that way and things would get better and better, simply because those doing it right would outcompete the others. :D
This is actually what is happening
This is not what we observe happening. ...
You don't observe it. I do. Change job to place where it works
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Also having an issue tracker, a decent source code control, continuous integration, working build system, everything automated that takes time or can fail due to human interaction, there are probably a dozen more.
FBF is probably the most important.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
“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.
My opinion: Good agile practices: TDD, FBF Ok in moderation: Standups, sprints, stories Bad: Everything else
TDD = Test Driven Development FBF = Fix Bugs First
The fact is you don't need agile to do TDD and FBF. Every _good_ software developer would do that. On the other hand, if you have bad developers, no matter the method, you're going to get mediocre software.
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.
[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.
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
TDD is unrealistic in a world driven by surreal deadlines.
My test coverage is less than 20% because if I spent time writing tests I'd never get anything done on the timeframe demanded of me.
You must work where I do. We just introduced "agile" to our team, the immediate effects are:
- no longer allowed to meet with stakeholders as needed, must wait for weekly "demo"
- daily standup that just takes tons of time to say "no change from yesterday because I'm still not allowed to find out what the stakeholders want because it's not Tuesday yet"
- our group is cross functional, so that means that the learning project manager can do development work right?
- my agile group is only 3 hours a day, strictly scheduled, so I'm only allowed to work on that project for those 3 hours, and work on nothing else during that time, nevermind that my projects fluctuate daily in their requirements, and one day I might have 8 hours work for this project, and none for others, but tomorrow it could be the reverse, and with deadlines as tight as they are, I can't afford to twiddle my thumbs because the wrong project has work ready.
The main thing I'm finding is that "agile" is anything but. It's extremely inflexible, and is stifling the ability to both meet end user needs, and to get any actual work done.
Right. And all sprints do is tell the team not to think long term and try to turn everyone into an agile generalist so they can be shuffled more easily onto stories.
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)
"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."
Arguably, real democracy, real capitalism, real anarchy, real socialism, etc., haven't been tried either.
I don't think any system of governance or economy has ever been practiced in strict adherence to its theoretical definitions. And rightly so.
If it weren't for deadlines, nothing would be late.
"You're not holding it right."
By TDD do you mean unit testing or more of a functional testing? I got cooled off from unit tests, in favor of functional ones (spanning multiple classes/modules). The rest has been my experience too.
It also helps of those team members are well trained in all aspects of the project. This way any member can work on any story. In reality though it's obvious that this never works except on the simplest of projects. You want your security expert to design the security stuff, you want your gui expert to work on the gui, you want your network expert to work on the protocols, etc. If you're lucky enough to have multiple members for each specialty then congratulations you are not a typical company.
TDD as a general concept is fine, but the textbook definition is crap. Writing one test at a time and then modifying the code to pass that test without regressing is asking for trouble for anything complicated. If you want to sit down and write a full set of unit tests first, though, that's generally a good idea. In trying to think of all the different ways the code could break, it helps a lot when it comes down actually writing it. It also ensures that test cases get written, because everyone knows that shit isn't getting done afterwards.
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.
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.
...Sounds good on paper, disastrous in practice.
I don't agree - it doesn't sound good on paper. It does sound like a lot of hand-waving, with very little in the way of fact and substance.
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).
Every great software developer does those things, but plenty of "good" software developers are operating in environments that push or even compel them to abandon their own good sense.
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
I think coverage is key. Are the important areas of the code covered? Are all branches within those areas covered? Does all this information get generated automatically?
The fact is you don't need agile to do TDD and FBF.
Sure. But I learned to do both in the context of Agile development. Agile is basically a bag of tricks. Some are good, a few are bad, and some are good in some situations but not in others.
TDD and FBF are always good ideas, and tech-debt accumulates rapidly when they are not done.
Pair programming is good for training newbies, or for a 2nd set of eyes when wrangling with a gnarly bug like a race condition, but mostly holds back good coders.
We do standups, but not everyday, and there is no penalty for not attending ... or for bringing a chair. We don't take them seriously.
Sprints are good for procrastinators and perfectionists, who work better with deadlines.
Stories are good, but they don't replace good docs. My experience is that you start with stories, then write the docs. During initial development we refer to the stories far more than the docs. But the docs are important for wrapping up the details.
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.
I got cooled off from unit tests, in favor of functional ones (spanning multiple classes/modules).
They are not alternatives. You need both. Write the unit tests while you code each class. Write the functional tests while you do integration.
If you are hardcore Agile, you write all the tests first, but in practice almost nobody does that.
... modifying the code to pass that test without regressing ...
Who said you don't regress? Regression testing should be a standard part of any dev process. Before you commit code, you should run your full test suite ... with a single command (or 'click', if you use an IDE). In you don't then: "You are doing it wrong."
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.
It's not magic - it's a collection of practices that work well in the real world. And while you might thing that all good developers do TDD and FBF, for example, that's not the case - both those ideas were obscure and radical before XP/Agile/Scrum pushed them into the mainstream.
Enable 3D printed prosthetics!
Sprints are very valuable, if there's good transparency about stories and burn-down (or burn-up) charts, because they let everyone know how the team is doing, continuously, so if there's a problem and the team is going to miss a commitment, it's visible and can be fixed. And having a regular cadence helps teams learn to estimate and hit commitments, which is valuable for all concerned.
The value of standups is that they give everyone a chance to ask for / offer help, raise challenges, etc., but by doing it at a fixed time every day avoids frequent interruptions during the day, which break concentration and decrease productivity. If standups are boring daily wastes of time, you're doing it wrong - standup should be as short as possible - what tasks did you complete yesterday, what tasks are you working on today, and do you have any blockers. 15 minutes is plenty of time.
Stories don't replace more detailed documents, they are just a short representation of the work for purposes of managing the work. If a story is complex and needs a detailed writeup, or screen design, to make sure that everyone agrees on the details, that document is critical and the story should link to that. But if the developer can ask the product owner a few questions, and that's sufficient and a big written document would be a waste of time. And for big projects, the specifying alone can take a year, which is a year wasted compared to getting something simple in front of users to find out what they actually want in reality rather than in theory.
Enable 3D printed prosthetics!
Exactly. Though I have never heard of TDD being "write one test at a time and then write the code to pass the test" - everywhere I've done TDD (and I've been doing it since the 1990s) we've written a whole suite of tests that defined the expected behavior of the system being built, and then written code until we passed that test suite.
Enable 3D printed prosthetics!
I was always taught that tests should be written by a QA developer instead of the application developer, because if you write your own tests you have symmetrical oversights and logical mistakes.
Also, I was taught to be suspicious of anything that wants to "drive" the development process that isn't the use case! The goal is to match the implementation to the semantics of the problem domain, not to the semantics of the testing framework.
TDD is great for web apps, since there is unlikely to be enough profit to afford QA, but why do those even need a lot of thrash?
if I spent time writing tests I'd never get anything done on the timeframe demanded of me.
You are doing it wrong. TDD saves time. Even during death marches, I write unit tests. The time spent writing tests is way less than time spent chasing bugs.
I simply commit and continue working.
The CI server is running the tests.
Why should I waste time running tests on my machine?
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Is that a kind of provocation?
- no longer allowed to meet with stakeholders as needed, must wait for weekly "demo"
That is not agile, it is stupid. And all agile methods demand access to the stakeholders. So why are you trolling?
- daily standup that just takes tons of time to say "no change from yesterday because I'm still not allowed to find out what the stakeholders want because it's not Tuesday yet"
Trolling again? A standup should not take more than 90 seconds pr person.
- our group is cross functional, so that means that the learning project manager can do development work right?
Yes he can. What has that to do with agile, non agile?
- my agile group is only 3 hours a day, strictly scheduled, so I'm only allowed to work on that project for those 3 hours,
If that is made clear to every stakeholder, it is fine. What is your problem?
and work on nothing else during that time,
EXACTLY. That is called "commitment" and "accountablility"!
nevermind that my projects fluctuate daily in their requirements, ... at least your sprint can't. And if you really have to react daily: then for funk sake don't use sprints but Kanaban
it can't
and one day I might have 8 hours work for this project, and none for others, but tomorrow it could be the reverse, and with deadlines as tight as they are, I can't afford to twiddle my thumbs because the wrong project has work ready.
Ha ha ha. Troll!
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
I'd say TDD is highly overrated. Writing tests up front is a huge time sink, and on anything non-trivial you end up spending more time refactoring and fixing the tests as you refactor the interfaces than anything else. You should think about testing when you design something, but writing them first is always a waste of time.
I still have more fans than freaks. WTF is wrong with you people?
I was always taught that tests should be written by a QA developer instead of the application developer
You are doing it wrong. Unit tests should be written by the developer, and the class/method/function and the unit test should be written simultaneously by the same person. Code test commit code test commit code test commit.
QA people should focus on high level functionality and usability, not implementation details.
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.
Why should I waste time running tests on my machine?
So that you don't commit buggy code.
I assure you everything I say is the truth. I'm not trolling, though my company may be trolling all of us with their braindead implementation of it.
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'...
I used to think so about unit tests until I read "Why Most Unit Testing is Waste" by James Coplien (https://rbcs-us.com/documents/Why-Most-Unit-Testing-is-Waste.pdf). It caused quite a stir on Reddit and YC in 2014 when it appeared, and Coplien published a sequel (https://rbcs-us.com/documents/Segue.pdf). From time to time is rediscovered and creates the same controversy.
I was very opposed to it in my first reading, but on subsequent readings and checking out arguments on the boards I slowly came to be in favor. Then as an experiment I ditched almost all unit tests and started only writing functional tests and I'm sure I'm seeing a better payoff. Just the other day my functional test caught a very nasty bug introduced by a coworker where the results of some key calculations were off by 2-10%. I'm sure no unit tests of mine would have caught that bug of his. So for the moment I am a believer, and Coplien gives some good empirical and logical arguments in favor of it.
That I still do TDD about a third of the time, making a functional test before I write the code.
Here's a great example of the value of coverage:
function myFunc( arg )
if ( f1(arg) ) call do_A();
if ( f2(arg) ) call do_B();
In your tests, you can call myFunc first such that it only calls do_A(), then call it again such as that it only calls do_B(). You will achieve 100% coverage, and yet a call to myfunc in your app in the field that makes the function call both do_A() and do_B() may cause the app to crash.
This is not to say that coverage is useless, but that often is far less predictive of robustness than it would appear to be, and may lull the developers into thinking they have tested the app enough.
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
Then you are definitely doing it wrong. But in current times it should be easy to find a better job :D
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Why should I not commit buggy code?
It is on my private branch ... it gets merged/pulled into the trunk or sprint branch when everything is fixed.
--trunk--............---------M
\---sprint branch-------------------/
\---- my feature branch---/
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
That's very hand-wavy, not only am I not convinced of your conclusions, I'm not even convinced that you actually offered any logical reason for a person to even start considering what you said. Just pure assertion, and without any concept of which parts are opinion, which parts are purported facts, and which parts are generally accepted truisms.
In fact, I'm not even convinced that you understood that I was claiming that a different field, called QA, might actually be the field with the expert knowledge, and they might have a different truism than the developers have!
You don't seem to have even noticed what I was talking about, but you know you disagree. You know I'm doing it wrong, but you don't even know what I'm doing, what the use case is! Perhaps the answer is different depending on the size of the project? Perhaps it is different depending on the consequences of bugs? Perhaps it varies based on those things, and also the product lifecycle? Your insistence that there Must Be One True Answer proves that you're only considering the least-important categories of concerns, like those that web developers have.
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 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.
Oh, I get it. So the big yellow box will convince the company to hire more quality testers where the hundreds of little yellow boxes on every single product backlog item did not.
Don't be naive.