The State of Agile Software in 2018 (martinfowler.com) 315
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.
A new pile. (Score:5, Insightful)
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
Re:A new pile. (Score:5, Insightful)
When I see things like "because much of what is done is faux-agile, disregarding agile's values and principles", it sounds like the church arguing against reformers and splitters. Agile started life sounding like a religion, and over time that has only intensified. Sure some people do it badly, but Agile is not a magic bullet that solves everyone's problems all the time as long as it's done perfectly.
The problem is the adherents insist that there are only two models - agile or waterfall, nothing else. And then they try to put the two in conflict with each other. But waterfall is mandatory in so many environments. If you must tell your customers what features will ship on a certain date in the future, then you have to have project planning in advance of building or implementing, and that's where waterfall works. Agile is good for web sites where you're just tweaking small things and doing "continuous delivery". But it becomes clumsy with complex systems, and where you need specialists and not generalists.
Sure, I have seen some advocate that you just put the design phase into agile, but you're still stuck with the silly scrum model where you have to have results every two weeks even if a design task takes two months or more.
If a company is failing because of waterfall, they are almost certain to be failing with Agile as well.
Re: (Score:2)
Agile != Scrum.
That's the point, 99% of 'Agile' is actually Scrum or some other stupid, ridgid methodology.
Agile has 'people over process' right in the manifesto.
Re: (Score:2)
Re: (Score:2)
A lot of such people are led to believe that following the process - whether it's Scrum or waterfall or ITIL or something else - is a recipe for making your project or your team successful. Box-tickers, in other words.
Clearly you want some kind of process. Leaving everyone to their own devices tends not to work well. The trick is finding something that works well that you can get the entire team to buy into. Having a process that everyone hates and no one is really going to follow is about as bad as having nothing at all. However, that's no simple feat either. The kind of process that managers would love is the kind of process that developers will hate and vice versa. There's no magical solution that pleases everyone opt
Re: (Score:2)
Agile says explicitly that a good team will succeed despite the process and a bad team is useless, no matter what process is used.
Lack of formal process rituals doesn't mean you don't have authority and responsibility on team members.
Re: (Score:3)
These are not the problems with Agile. The main problem with Agile is that it doesn't scale and when large projects are attempted, it tends to produce dirty snowballs. Those snowballs become too large for any agile project and then the size makes them essentially unguided. They crash, burn, and then the team realizes they should have done a real design first, and then filled it in making accommodations as necessary.
In my own experience, Agile reduces engineers to cogs whose only mission is to add some extra
Re: (Score:3)
You disagree with the authors of the Agile manifesto.
I bet you have _never_ shipped code.
Re: A new pile. (Score:3)
Re:A new pile. (Score:4, Funny)
At some point it becomes necessary to behead all the architects and begin construction.
-- Abi-Bar-Shim (Project Mgr. - Great Pyramid)
Re: (Score:2)
Re: (Score:2)
Is Agile some kind of religion for coders?
Almost right. It's a religion for managers.
Re: (Score:2)
Is Agile some kind of religion for coders?
Almost right. It's a religion for managers.
A Dilbert [dilbert.com] for this sentiment was actually posted today...
Re:A new pile. (Score:5, Interesting)
When done right, it lets managers get out of the way of developers, because it replaces the boss being in charge with the team being self-led, with the "boss" clearing the path and facilitating when things get stuck, and you empower the product owners with real authority to make decisions, empower teams to do real estimation, etc. When I've seen agile fail, it's because the management couldn't give up control to the team, so they basically ran waterfall development using agile terminology. That is, when you make fixed scope and fixed time commitments, because the boss (or product owner) says so, you're waterfall - it doesn't matter if you use story points and sprints to implement your waterfall product, because you've missed the fundamental point of agile.
Call it Scrum, XP, Kanban, etc. - it's all about measuring and optimizing a process by empowering the people who do the work to improve how they do the work. Everything else is just a means to that end. The techniques work, which is why companies who do them tend to outperform the companies who don't. But a bad team with bad management who uses the form of agile without the substance is still screwed.
Re:A new pile. (Score:4, Insightful)
I think the main problem is something else: proper agile requires buy-in from just about any organisational layer above the agile team. Usually the time, attention-spam and understanding to achieve this is almost impossible to achieve. Agile requires trust while company hierarchies are usually organized around distrust; agile requires doing things together while traditional company hierarchies demand clear separation of responsibilities. Agile requires thinking about what to do next while companies revolve around yearly planning. Agile requires accepting uncertainty inherent to software development while companies revolve around containing such uncertainties, usually in a superficial way. Those kind of things make achieving true agile in a commercial organization next to impossible.
Re: A new pile. (Score:4, Insightful)
Agile is a manifesto full of truisms. Nothing to argue with, but PHBs are not the target audience and DON'T GET IT. Only take the parts they like, such as (para via PHB brain) 'specs are useless'.
Scrum is just a bad idea and is often called 'Agile'.
Re: (Score:2)
Except that Agile IS done correctly, many places.
Places that laugh at any scrummy people that apply.
You have obviously never read the manifesto.
Re: (Score:2, Interesting)
Agile is judged by its own metrics. Of course it is done "correctly". Whether they laugh at others' implementation of Agile is irrelevant.
Yes, I have read the manifesto. Unfortunately, extracting my commentary on it from my plain-text document will not look good, and I wrote it a long time ago without fully reviewing what I wrote, but I don't care, since nobody will read it anyway.
Here's the Agile Manefesto, with commentary by me:
> We are uncovering better ways of developing software by doing it and
Re: A new pile. (Score:4, Insightful)
No True Scotsman (Score:4, Insightful)
Just the latest management fad in a long line of management fads, watch as we wave away criticism of our touted silver bullet.
Re: (Score:2)
These fads, like lean production, six sigma mumbo jumbo, are just magic formulas that MBA bots repeat to persuade you they are able to manage real stuff, they know nothing about.
Re:No True Scotsman (Score:5, Insightful)
In reality, lean production techniques are why the Japanese car companies outperformed US car companies for several decades, until the US car companies copied their management techniques and (somewhat) caught up. Very real stuff, worth $billions.
If MBA's don't understand lean manufacturing and copy the form without the substance, the problem is the MBA's, not lean manufacturing.
Re:No True Scotsman (Score:4, Funny)
Just the latest management fad in a long line of management fads,
Agile will soon be enhanced to create Freestyle Recursive Agile Software Development, known by its short form, Fragile.
Similarly, the imprecision of integer DevOps will be improved by implementing floating point operations, to gift us DevFlops.
watch as we wave away criticism of our touted silver bullet.
watch as we wave away criticism of our touted Bitcoin bullet!
Re: (Score:2)
Every development project that I've ever seen that ran into trouble had the same thing in common: over promising what they can deliver.
That is what Agile methodologies (such as Scrum) are supposed to fix. Simply put: it doesn't promise anything. Stakeholders come up with an ordered list of work to do, and the engineers will work on them in order. Don't like what's getting done? Change the order. Want it done faster? Add more people, but don't expect to see improvements until a few months down the line.
The problem, as explained in the article, is that most people embrace all of the procedures, like playing games with "points" and doing d
YMMV (Score:5, Insightful)
Re: (Score:2)
The flip side is that you never do any of the work that by nature is too big for a sprint. Projects get interminably delayed and finally cancelled because they are too big and can't be split into smaller pieces. Or you try and fail miserably. Sometimes agile is like attempting to jump a chasm in three small leaps.
I'd like to see more upfront evaluation of what would be the best approach for any given task. Sometimes agile fits the bill, and sometimes not. Uncritically going for agile as a panacea that so
Re: (Score:2)
The flip side is that you never do any of the work that by nature is too big for a sprint.
But that's the point. If you follow the rules, you have to break down the project into discrete, manageable chunks. In the old waterfall days, we could have a nebulous, unplanned project take a year and have to be rebooted because the approach was not thought-out beforehand. The iron-clad story size limit forces a bare minimum of pre-planning.
And in my experience, there's no such thing as "a project too big and can't be split into smaller pieces." I absolutely do not believe such a thing is possible, unless
Re: (Score:2)
Well, we hit situations where the "story" goes on for months, because it's too difficult to split, or because it turns out to be vastly more difficult than intended. Yes, the team and members may be newish to Agile, but ultimately the two week limit is 100% artificial. The driver will take 3 weeks say, you can't split into sub-parts, you can't "demo" a driver that isn't finished except by artificially adding more work (adding simulation bits, a framework to demo it in,etc).
Project planning is HARD, and Ag
Re: (Score:2)
And in my experience, there's no such thing as "a project too big and can't be split into smaller pieces." I absolutely do not believe such a thing is possible, unless the project is to write a single algorithm in a single method, and spend 3-months sprint doing it.
The easiest example are external resources that have longer delivery time. But also internally, if you have to e.g. run a 4 week test for regulatory reasons, or prime a machine learning algorithm with real-time data that happens in a particular time frame. The agile answer is then "sorry, we cannot commit to this", and the corporate answer is then to hire or contract to someone who will get it done, and wonder why they pay you.
Re: (Score:3)
areth, with all respect, you are wrong.
The easiest example are external resources that have longer delivery time.
Then adjust your sprint length or mock them away till they are ready.
But also internally, if you have to e.g. run a 4 week test for regulatory reasons
Then adjust your sprint length. The original recommendation for sprint length in Scrum and in XP is 6 weeks to 12 weeks!!!!
Not one week, not two weeks!
or prime a machine learning algorithm with real-time data that happens in a particular time frame
Re: (Score:2)
Projects get interminably delayed and finally cancelled because they are too big and can't be split into smaller pieces.
Everything can be split into smaller pieces. It is called a task that needs to be done. You don't need to make your sprints on the level of a use case, story or subsystem.
The question is: does it make sense to split a "milestone" into 100 tasks taking 4h - 16h (in original Scrum a task should not be longer than 2 work days). It might not make sense, because obviously you can not really pr
Re: (Score:2)
But a task in Agile is supposed to involve being done with it and being able to demo it. Most places don't follow Agile that rigidly, but it is what you're supposed to do. So at some point you can't subdivide further because what you have is unfinished work that can't be demoed except by doing even more work. There is overhead to each and every story and if the stories are too short you end up doing more overhead than actual work (ironically this is the paradise for many programmers I've met).
Ie, one line
Re: YMMV (Score:2)
If I write a new module for working with XML files, I don't need to demo it to the sales team, I need to demo it to the other developers. It sounds like you're just not targeting the correct end user for your demo.
Re: (Score:2)
But what if it takes longer than a sprint to write it?
Re: (Score:2)
I agree that splitting a 6 month work item into 4-16h sub-tasks is retarded. That's a classic example of putting dogmatic adherence to methodology before common sense. I worked for a videogame publisher that insisted on a super-detailed schedule like this at the very start of the project - before the game's design was even finalized. Idiocy.
At most sane places where I've worked, the rule of thumb was to avoid tasks longer than 5 days, and preferably shorter, but it's ONLY a rule of thumb. Sometimes you'
Re: YMMV (Score:2)
General rule of thumb is unit tests should be written. 100% code coverage of peer reviewed code is a sufficient "demo".
Re: (Score:2)
"The flip side is that you never do any of the work that by nature is too big for a sprint"
I think we all see the problem about corporations trying to sell their "agile tools", management that go the "cargo cult" path without understanding what are they doing... But still there's something on this news and your comment clearly exposes it.
What the hell have "sprints" to do with agile so what you say could possible be true? Go, find the word "sprint" within the entire "agile manifesto", I challenge you*1.
So
Re: (Score:2)
Who cares where we're going, just start laying track in any direction, we can always put u-turns in later!
Re: (Score:2)
What's worse, ignoring a project's potential for failure (sunken cost fallacy) or insuring it (Agile)? Nothing damages long term potential more than shortsightedness and Agile's guiding principle is, essentially, shortsightedness (slavery to short term measurables) along, of course, with the mythical man-month assumptions than enable it.
Re: (Score:2)
You got it completely reversed.
Agile means: you realize after 3 sprints, the project is to big, the team is to slow, the team is to bad. You have sunk three sprints, you can decide if the project is worth it. You can decide if you invest into improving the team. If you are not agile you have spent much more money when you finally admit that you have failed.
That is not short sight. That is checking the map and the heading at the end of each sprint. Just like the pilot or captain on a ship checks every hour i
Or.... (Score:2)
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
Re: (Score:2)
Most people do exactly the same thing with waterfall. There is continuous reporting of status in every well managed project regardless of the process. Your manager wants to know how you're doing, the director wants to know how well the teams are doing, the product manager wants to know how things are going, the project manager wants to know how different organizations are syncing up (boards arrive next week, are you ready for them), and so forth.
And it takes more than 3 sprints usually to even get some in
Re: (Score:2)
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.
Bingo.
Re: (Score:2)
Why two months? If a project takes two years and you're agile the whole time... Upper management that is anxious about cancelling a project will feel the same way whether it's agile or something else. Agile is also being done by the people at the bottom unusually, not by the executives certainly, rarely by middle management, and the team at the bottom can never say "dumb project, let's cancel it".
Of course some say that the entire company needs to be Agile, but that's like insisting upon a state religion
Re: (Score:2)
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
Every "death march" I have been part of always end up with the managers getting large promotions and the developers get blamed
I hope agile will stop that behavior
Re: (Score:2)
Yeah waterfalls are great when the water runs up instead of down.
Re: YMMV (Score:2)
Re: (Score:2)
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.
Well I suppose that's how it could work if all projects were optional and we could simply halt them or if we weren't doing projects at all but more like continuous improvements. Unfortunately around here projects are given an overall scope, budget and delivery date. Unlike waterfall projects where we'd actually have an overall plan and milestones we instead do whatever the product owners feel like is important the next two weeks, even though it doesn't matter except for their project plan. So we're making s
Re: YMMV (Score:2)
In my experience, this is usually because of poor deadline communication. In agile, there are no deadlines. The idea isn't to create 2-3 week deadlines every "sprint", but to limit wasted time to 2-3 week chunks before pivoting at the next "sprint".
If you treat agile like weeks long mini projects, you likely won't have success. If you use it to help allocate resources for an ongoing project that is never done, never expected to be done, but will deliver features when they are done and only when they are don
Re: (Score:3)
If you have a strong team dedicated to making a process work, any process will work.
Re: YMMV (Score:2)
Oftentimes that strong team will make a process work by ignoring or circumventing the process. Agile is sort-of the distillation of how that looks when it's successful.
Handy cross-reference for job seekers (Score:5, Funny)
“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
Here's a better tip... (Score:2)
“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.
Re: (Score:2)
Re:Handy cross-reference for job seekers (Score:4, Insightful)
My old scrum team of 10 years had a policy of only considering half the available work hours when placing hours on tasks. More often than not, it was spot on. After 6 months our velocity projections were spot on, every sprint. After that I worked on a "scrum" team that packed everyone's sprint board with 40 hours/week of work.... but sprint "planning" ate one of those days.
Underestimating work availability and overestimating needed work was pejoratively called "sandbagging" on that team, and yet the former delivered project on the estimated date, and the latter never did, even once.
Re: (Score:2)
We never do full day sprint planning. But we do have project planning. There's already enough meeting overload with with everyone on five projects and three sprints (yes, we're doing it wrong but we can't hire more). So with the project plan we know what upcoming stories need to get done for several months out, and we get a lot of "I'm continuing my ongoing task so I'll add a new story for the next sprint" stuff.
Re: (Score:2)
Double the number and switch to the next larger unit.
1 week = 2 months. etc.
Re: (Score:2)
I call it the Scotty Principle, explained in Star Trek 3:
https://www.youtube.com/watch?... [youtube.com]
Re: (Score:2)
I often felt that putting points on stories would be the same as committing myself to a promise. Thus if I was behind, I felt that I had to work longer to keep my promise. So Agile was making me work longer. Over time I learned to do more sandbagging so that I was never over-committing.
After all the goal is NOT to do Agile, the goal is always to build the product. So if Agile is getting in the way, then be dextrous and sidestep it.
The only thing wrong with Agile is... (Score:4, Funny)
...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.
Re: (Score:2)
"If your company has a technology or product related vision - you should not use Agile."
So which part exactly should this kind of company ditch out?
"Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software."
This one? "Minimally Viable Product" is not a fit concept for a product or technology related company? Really?
"Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage."
Do you really thi
The real problem is... (Score:3)
... 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.
How customers and managers see "agile" (Score:5, Interesting)
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."
Re: (Score:2)
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.
Exactly. From what I've experienced, Agile is just an excuse to not think about requirements until it is too late.
Customer: I want a house...
Development team designs and builds a house.
Customer: ...that I can drive to the lake.
That is absolutely Agile (Score:2)
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 wou
Jebus HB Crickey - What a load of bollocks! (Score:2)
[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
Re: (Score:2)
I would like a clarification on your opinion on
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),
It is not clear if you think rigid processes are good or bad.
Agile can't fix broken companies.... (Score:2)
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
Agile is like Communism (Score:2)
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 ain't (Score:3)
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.
ah (Score:2)
They should have called it conversational dev (Score:2)
Teams are voting with their feet (Score:2)
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.
The big problem will still be agile lawyers (Score:2)
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 la
Can you say fad? (Score:2)
What has "programmer" Martin Fowler actually done? (Score:2)
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).
Easy way to tell if you're doing real Agile (Score:2)
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 [wikipedia.org].
Who is agile IRL? And how did they get that way? (Score:4, Insightful)
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
Re: (Score:3)
*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.
Re: (Score:2)
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
Re: (Score:2)
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.
Re: (Score:3)
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?
Re: (Score:3)
...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
Re: (Score:2)
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.
Re: (Score:3)
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.
Re: (Score:2)
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.
Re: Agile is like communism... (Score:2)
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.
Re: (Score:2)
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
Re: (Score:3)
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.
Re: (Score:2)
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.
Re: Agile is like communism... (Score:2)
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?
Re: (Score:2)
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.
Re: (Score:3)
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 f
Re: (Score:2)
Re: (Score:2)
... 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."
Re: (Score:3)
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.
Re: (Score:3)
...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.
Re: (Score:2)
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
Re: (Score:2)
"I'd say currently about 90% of the industry has no right working in the field"
And I bet you belong to the blessed 10%, am I right?
Re: (Score:2)
"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.