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
*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
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."
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)
...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.
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 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.
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.
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
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.