Should Developers Abandon Agile? (ronjeffries.com)

An anonymous reader quotes InfoQ: Ron Jeffries, author, speaker, one of the creators of Extreme Programming (XP), and a signatory of the Agile Manifesto back in 2001, shared a post on his blog in which he advocates that developers should abandon "Agile". The post further elaborated that developers should stay away from the "Faux Agile" or "Dark Agile" forms, and instead get closer to the values and principles of the Manifesto. The terms "Faux Agile" and "Dark Agile" are used by the author to give emphasis to the variety of the so-called "Agile" approaches that have contributed, according to him, to make the life of the developers worse rather than better, which is the antithesis of one of the initial ideas of the Agile Manifesto...
Jeffries writes that "When 'Agile' ideas are applied poorly, they often lead to more interference with developers, less time to do the work, higher pressure, and demands to 'go faster'. This is bad for the developers, and, ultimately, bad for the enterprise as well, because doing 'Agile' poorly will result, more often than not, in far more defects and much slower progress than could be attained. Often, good developers leave such organizations, resulting in a less effective enterprise than prior to installing 'Agile'...

"it breaks my heart to see the ideas we wrote about in the Agile Manifesto used to make developers' lives worse, instead of better. It also saddens me that the enterprise isn't getting what it could out of the deal, but my main concern is for the people doing the work..." He argues developers should instead just focus on Agile's good general software development practices -- like regularly producing fully-tested software and consciously avoiding "crufty" complex designs.

But what do Slashdot's readers think? Should developers abandon Agile?

Comments

One problem: no normative definition of "Agile"

[david.emery]

This makes it really difficult for an organization to determine if they're truly doing "Agile" or some bastard form. It also calls into question methods and even formal standards built on 'Agile'.

But when I've pressed Agile Evangelists on this, usually when we've had problems and I've asked, "So are we doing Agile", all I've gotten in return is, "If it's not working, you're not doing it right."

Re:One problem: no normative definition of "Agile"

[Hognoxious]

I initially read that as "If it's working, you're not doing it right."

I'm on the fence as to which is more accurate.

Re:One problem: no normative definition of "Agile"

[93 Escort Wagon]

Problem is -“agile” is often used as a management code word for “understaffed, overworked, and unsupported”.

Re:One problem: no normative definition of "Agile"

[HornWumpus]

There is not much to argue about in the Manifesto. Pretty much truisms. My only criticism is: 'Management won't get it, will only see the parts they like. If they got it, they wouldn't need it. If they need it, they won't get it.'

IMHO the key part of the manifesto was 'hire competent enthusiastic individuals'...which can be used to validate claims of agility. Those people DON"T work for industry average. If an organization is paying industry average, it _cannot_ be agile. Most likely it's 'agility' amounts to management's ability to maintain a bidirectional circle jerk.

Re:One problem: no normative definition of "Agile"

[phantomfive]

There is, though. Right there at the top it says, "We value individuals and interactions over processes and tools." Is Agile a process? Primarily it's not. Ask your consultant what they are doing to value individuals over processes. Watch the blank look of fear, followed by a stream of BS coming out of their mouth.

Re:One problem: no normative definition of "Agile"

[turbidostato]

"Problem is -âoeagileâ is often used as a management code word for âoeunderstaffed, overworked, and unsupportedâ."

Problem is, as always it is, that managers are morons.

Well, in fact they are *not* morons, but clever people that cleverly respond to their environment -that's the fundamental difference with the minions. Minions see -and look for, what is needed. Managers offer what is wanted -at face value. Do you want me to shoot you on your head? There. Done.

But, anyway, managers are always and without possible dispute, the real and absolute culprit.

Now, back to the main issue: this is no news. It's been known for ages that a good team will offer a good result even against the methology imposed by (fucking moronic -all of them, that is) managers. On the other hand, on not so good teams (aka, most of them) no amount of methodology (fucking moronic -all of them, that is) managers throw at them will work.

To compose the problem, "the system" has perfected itself on past decades so, while, say, back in the 80's, you might end up with a performant team basically by sheer luck, nowadays "the system" makes that impossible.

Re:One problem: no normative definition of "Agile"

[alvinrod]

Yeah, this has been known for a while.

Re:One problem: no normative definition of "Agile"

[arth1]

The "No True Scotsman" fallacy is one of the most annoying things about Agile. "You're not doing it right" has become a mantra for explaining away any shortcomings, of which there are more than a few.

Re:One problem: no normative definition of "Agile"

[Anonymous Coward]

One sign of trouble for Agile is that PMI has worked it into the PMBOK, which ensures that poorly trained (but PMI certified) hacks will be destroying its effectiveness for years to come.

Re:One problem: no normative definition of "Agile"

[HGG]

Why is Agile a moving target? I think it goes like this:

The original vision was great: Many projects are hard because they require high-quality human interfaces. Humans are lousy at pre-specifying what they want for interfaces, so waterfall specs are slow and useless. The better approach is to just prototype stuff and have the user try it out. If your development cycle is vastly faster than users review cycle, you do real code instead of prototypes. Continue to grow the app as users' understanding of their needs evolves.

What's missing? Agile is all about doing one new app very well/quickly. Often (in my experience ) the app shouldn't have been done in the first place -- it was a workaround to a workaround, adding one more plop to the enterprise steaming heap. Instead we need to do systems (portfolio-wide) architecture at the start of a project to determine business case go/no-go, impact to data model, impact to data allocation to logical resources (which apps handle which data?), and external interfaces. Then use Agile for evolution of the user interface.

Isn't architrecrture too slow -- defeating the purpose of Agile? On a small project the architecture phase is 2 days. On a serious project it is maybe 2 weeks. Anyone doing 2 months of architecture either a) doesn't know what they are doing, or b) is dealing with a topic too loose to architect much less code. Assuming the project proceeds, revisit the architecture when the data model, data allocation, or external interfaces change

So why does Agile itself change? Agile gets in trouble when its true believers claim it is the revolutionary solution to everything software engineering. And then has to jump and jig to handle what it calls special cases. “Uh, we meant of course to include interface control governance; we just forgot to mention it". Calling something "Agile Enrterprise Architecture" doesn't make it so.

Re:One problem: no normative definition of "Agile"

[Anonymous Coward]

Does this remind anyone of the "No True Scotsman" falacy? https://en.wikipedia.org/wiki/No_true_Scotsman

No true implementation of Agile fails. ... but my organization's implementation of Agile is failing
Then your organization is not doing a true implementation of Agile.

(Personally I find agile, even when done well, is much better than any alternative I've worked with so far... I just found the logical fallacy interesting.)

Re:One problem: no normative definition of "Agile"

[Maxo-Texas]

Yea, but even as a non-agile developer you can see when the agile team has decayed to waterfall method, has stopped timeboxing, and abandoned other core behaviors and features.

I always preferred RUP. It seemed to work better with business partners.

It was very clear that you identified risk and eliminated it *first* before starting generic ("construction") coding, that you *always* timeboxed, you never delayed a release for a "really important feature that wasn't quite ready yet", you had regular updates on the status of each feature point.

It was similar to agile but it wasn't agile. I like the theory of agile, but in practice it usually collapsed to waterfall under pressure.

Re:One problem: no normative definition of "Agile"

[tlhIngan]

I've never gotten Agile.

Our company doesn't use Agile anything. Strictly speaking, it's waterfall - we get a project from a customer, and we (engineers, sales and customer) work hard figuring out a list of requirements (we have to know what we're building, after all). This can take a little while - often engineering will scrap a list of requirements, step back, and ask the customer "what are you REALLY wanting here?"

As in, the customer gave us a list of stuff, but we stepped back, asked what they really wanted in the end (i.e., we go from the detailed view to the 10,000 foot view) This makes it possible to see if there is a better way to accomplish what the customer actually wants.

Then once we have requirements, we start building. Weekly, we'd meet with the customer and provide status updates, and the customer can redirect our efforts - perhaps a priority changed, or it turns out the customer doesn't want something anymore, and we work on new stuff. When something is complete, or a milestone reached, we cut a release and give the customer time to play with it and redirect our efforts again. Lather rinse repeat.

We have no "sprints" or tasks to do in a sprint - we have a list of what the customer wants done, and for the most part, those tasks take far longer than most sprints. (We have had many customers who do Agile and asked about what we'd do in the sprint, and we'd have to explain that the feature they want can't be broken down into one week work periods - it's a task that will take 3 weeks. We could break it into meaningless subtasks but that makes a huge assumption that you can work on a subtask alone - most of the work in a task is closely related so you may work on subtask A, switch to subtask B because A needs a modification in B, then go back to A, switch to C, etc.).
'
For the most part, it works - customers are generally quite happy, they know where the sore points are and we fix them immediately, and it's happened that many projects start out as a tiny little one that grew into a huge multi-year thing as customers want to try us out, are satisfied and impressed with our work and then give us more bits and pieces to do.

And no, our releases are on the order of once a month or so - the systems are complex enough that builds can take a day or so (often customers get source code, but some parts they can't because it requires licensing they don't have, so we have to make partial binary builds. And yes, we test to make sure those actually build). And there's also a QA process too to ensure no regressions. Customers cannot skip QA (builds often signify milestones), but they can get "early releases" which mean they get builds as soon as they hit QA with the caveat that some things may be broken And it does mean sometimes we've halted the release because of a showstopper and take time to fix it and re-release.

Re:One problem: no normative definition of "Agile"

[Anonymous Coward]

If you are implementing features incrementally, showing the customer on regular intervals and then allowing the users to provide feedback and then re-prioritize stories during the project, you are pretty much following the "spirit" of Agile. I see the most important part of Agile as delivering the most valuable features to customers in an iterative fashion so you can constantly make sure you are on the right track. The problem with the old, pure-waterfall approach was the fact teams would take a huge amount of time up-front to come up with requirements (which are often poorly captured and change over time) and then go on to design and build a system for many months/years before actually showing the customer. This results in building something that really doesn't meet the users' needs due to the fact the customer may not have articulated the requirements properly, their actual needs changed over time, and your analysts may not have captured the requirements properly.

Re:One problem: no normative definition of "Agile"

[Cytotoxic]

This is the nut of the problem. It always comes down to people, and the most productive teams are going to rub some people the wrong way because often times the most productive way of getting something done is to say "no".

I've worked with the "just give them what they ask for" crowd. It is just awful.

It works for a while. They are sooooo happy! You gave them that stupid thing that will never work in a million years! Then after a while, things are a mess and they still blame the dev team.

The only way that I've found to work with them is to have the backing of their superiors when you look them in the eye and tell them no. Anything less than the full backing from the top levels ends in disaster - methodology be damned.

This is why outsourcing can be so bad. You need the institutional knowledge that a good group of developers will have. And you need an executive team that has confidence in their developers so that when they push back against some dumb initiative they will have their backs.

I can't tell you how many times I've had near mutiny when I explained why something was stupid and had the CEO tell me to do it anyway, just to keep someone happy. No competent developer wants to waste his time building something he knows isn't going to work. But at least I was able to tell them that their concerns were heard and why they were dismissed. (and at least they knew I wasn't crazy, and their CEO wasn't crazy... or stupid)

Absent that connection, I don't know how things can work, long term. With good managers and executives, you could make outsourcing work. But eventually that guy who just doesn't get it is going to come along and insist on his vanity project. And the guys from India are just going to say "Ok, here's the bill". Maybe they fire the local PM when the whole things goes to crap. Or change development companies. But will they even be able to see that the problem was the idea behind the vanity project wasn't any good from the start? Often it is the dev team that is uniquiely positioned to know this, because they've had years of experience with all of the company's business rules and past mistakes.

So if there is no mechanism for continuity of business knowledge and no respect for that knowledge at the top.... well, I don't see how it could possibly succeed, long term.

Re:One problem: no normative definition of "Agile"

[sphealey]

= = = The "No True Scotsman" fallacy is one of the most annoying things about Agile. "You're not doing it right" has become a mantra for explaining away any shortcomings, of which there are more than a few. = = =

Yes, but of course the Waterfall and One True Spec adherents said exactly the same thing for 30 years in the face of evidence of failure rates over 50% as well. So perhaps there is no perfect method?

The wisdom of the industrial organization I once worked for that split any division that grew larger than ~ $100 million US/year into two divisions or product lines, each with an on-site and engaged general managers, appears greater to me as the years pass.

Re:One problem: no normative definition of "Agile"

[ath1901]

Yes! It is booth Straw Man and No True Scotsman.

Waterfall does not mean "capture requirements poorly and charge ahead blindly" and it isn't Agile if and only if it works.

It really bothers me that these kind of insights come so late. Obviously, different problems are best solved with different processes. If you're building a pacemaker, you do NOT wait for customer feedback. "So, how was your heart last week? Need any changes to it? ... Hello?"

Also, he does not address one of the major limitations of agile: The sprint. Not all problems can be broken down into 1-3 week jobs. I spent months working on a new model, probably not more than a few hundred lines long. Writing the first "version" took 2-3 days. Testing and proving it works as expected for thousands of test cases took months. Some of the tests revealed bugs in other parts of the system which was a nice unintended side effect.

  It was at no point "ready" before I could show with confidence that it worked with no unexpected side effects. I really don't see how that could be "sprintified". Agile seem to assume the task is easily dividable and the "atoms" are small and simple.

The best advice I ever read about design was along the lines of "Just do it. Try many methods. The more you think about it in any way, the more likely you are to come up with a solution". I think the same applies here.

There are good practices within TDD, XP, Agile, Waterfall etc and you should think about them and try the ones that MAY fit your project .

Betteridge's law

[rsilvergun]

No. What make agile work is accountability. The agile shops I've seen have what's basically a case system that tracks User Stories which describe small amounts of work. That's used to manage the teams and make sure they're move forward to some definite goal. That's the reason agile works. You can keep tabs on what your devs are doing and if they go off the rails fix it in 1 sprint.

Re:Betteridge's law

[murdocj]

And yet, you can do lots and lots of stories, and in the end you have a big steaming pile, because the stories don't add up to anything. I recently worked on a product like that. There was one "feature" that I backtracked to about 8 different stories, each of which incrementally added a sub-feature that, ON ITS OWN, sounded like a good idea. But the sum total was almost impossible to understand, and I'm sure people blamed the devs, not the managers who insisted on the "stories".

Re:Betteridge's law

[cruff]

Supposedly that is what a software architect should be doing, the high level design, outside of the pressure of the agile sprints. Ideally then you have a roadmap to where things need to go, with an initial set of stories defined for the sprints. Yeah, that doesn't seem to happen where I work either.

Re:Betteridge's law

[alvinrod]

Too often agile skips (argue that this is doing it wrong all you like, it's often reality) trying to do an extensive requirements analysis to nail things down to the point where you can do a high-level design that will be useful for more than two sprints. The real failure is probably that no one really wants to do the hard bits first, so those tend to get left until too late into the development process and invariably lead to throwing out or seriously reworking a lot of the earlier effort that failed to account for something important.

Re:Betteridge's law

[murdocj]

Ideally, yes. My first 20 or so years as a dev I worked in environments where we were "self-organizing" but we weren't delivering small increments. Instead we have fairly long term goals (usually for a yearly release) and then each dev or small group of devs figured out how to get it done. And amazingly enough the work got done and the product was coherent.

Since I've started working in Agile groups for a number of years the development has been way more subject to "here's a feature that can be added in two weeks, let's go for it" w/o a coherent overall view of where we were headed. And this is at 3 separate companies.

Agile (whether Scrum, Extreme Programming, whatever) just seems to be one of those things that sounds good, that has some good ideas, but ultimately comes with its own set of problems. As Fred Brooks said, there's no silver bullet.

Re:Betteridge's law

[Dutch Gun]

From what I've seen, my entire industry (videogames) has more or less adopted agile/scrum, and it's not really a bad thing. Frequent short stand-up meetings can be useful, although the idea that you CAN'T sit down seems childish to me. In my current job, we cluster around hallway whiteboards, so I don't mind that so much. If you're forcing everyone to stand when there are chairs in the area, it just feels silly. You should be able to gently enforce time rules without that.

The language regarding "user stories" and "sprints" is also seems a bit silly to me in its rigid adherence. But I'll admit it does help to focus on who the "customer" is, and forces the developer to deliver reasonable progress at reasonable milestones, something that should occur in any sane system. It really doesn't have to be agile/scrum, but it seems like that's what we have, so it's the framework we use.

Generally speaking, I'd say the one benefit agile tends to bring is that it officially discourages developers from hunkering down into a huge project and simply "going dark" for a year, at least if done correct. Those types of going dark periods often don't end well. I've always thought that was common sense anyhow, but it's probably better for leads and producers to be able get a bit more visibility into those sorts of projects.

Like all methodologies, it's not going to turn a dysfunctional institution into a well-performing machine, while it will probably just help an otherwise competent team to stay on top of their project a little better. You can even see it failing in one department and working well in others, even in the same organization. In a sense, it's sort of like coding standards. It's far better to have a coherent coding standard, regardless of which arbitrary stylistic decisions it may make, just to keep the code looking like it's all part of the same system.

I think the arguments that they can't help the overall vision of a problem is fundamentally correct, but it's a bit misplaced to blame that on agile. In my opinion, NO system or methodology can polish a turn. Getting your developers behind the project vision and sticking to tasks that help reinforce that singular vision is up to the team leadership. If that doesn't happen, then, simply put, it's a massive leadership failing, and no "system" will fix that.

Re: Betteridge's law

[MadKeithV]

The parent post is a great example of the "You're Not Doing It Right" fallback of Agilists. Agile is something that works in teams that would have succeeded just as well with any other methodology that isn't downright insane, and something that is pretty damn difficult to actually get to work in most real-world situations. There's always a litany of excuses of how you're not doing it right, but no Agile proponent can ever quite exactly say how to make sure you *do* get it right either.

Re: Betteridge's law

[murdocj]

Except that the Agile Manifesto specifically says that it values "Responding to change over following a plan". Which tends to lead people to simply not plan at all. At my last company, my boss tried to plan, tried to groom, etc, but it all got thrown out the window then company owner zig-zagged. So we were "responding to change" but the end result was pretty random development.

Re:Agile is bullshit

[fluffernutter]

I disagree. I think it has a lot of good theory behind it. The problem is, the 'do more by doing less' concept *really* has to be embraced by the entire organization; especially those at the top. Too often it isn't. If you work in a place like this, removing Agile probably won't help much.

Agile is like Communism

[Anonymous Coward]

It's got a manifesto.
Those who have to live with it want to escape it.
It slowly destroys organizations that use it.
Despite always failing "real Agile has never been tried right".

Maybe?

[apoc.famine]

I've worked in both a small shop (under 20 developers) and a decently large organization (more than 400 employees) although outside the dev shop. I had positive agile experiences in both places.

What I've found is that agile works given a few conditions:

1) The organization actually adopts agile, and embraces it.
2) The owners of the development both understand agile and have the political power to enforce it.
3) The devs understand agile and can thrive within it.

When all that happens, and I know that's not often, Agile can shine. I've seen it, and I've really appreciated it. I get how it can go terribly wrong, but it can and does work, if the environment allows it.

Abandon all magical methodologies

[Anonymous Coward]

Stop believing that if you could only find that one perfect methodology, your mediocre team of developers will create greatness. It has never worked in the past, and "agile" (however you define it) is no different. Project managers and business types are addicted to this fantasy, because accepting the reality would lead to extreme cognitive dissonance.

As always, there are no silver bullets. Hire smart people, give them autonomy (they will adopt their own methodologies as needed), keep teams small, and design solutions that are as simple as possible (but no simpler). Domain knowledge and close communication with the end users helps. But all that is no guarantee of success either.

Two cases

[sjames]

Part of the problem is the idea that with sufficiently detailed procedures, the village idiot can do theoretical physics as well as Einstein. In fact, no amount of procedure will make that happen. Quite the contrary, all that procedure means that if you ever do hire Einstein, his output will closely resemble that of the village idiot.

Consider one of the popular union tactics, the "rulebook strike". That's where they destroy productivity and punish the employer by having their members actually follow all the workplace rules and procedures rather than doing the right thing (TM,. pat. pend.). It works.

Re:Two cases

[sjames]

The thing is, if the staff are competent, they don't need to read about Agile, they'll do the right thing IF management does it's job by keeping things out of their way rather than getting in their way themselves. (that is, management needs to be competent as well).

If they're not competent, nothing can help them anyway.

Re: Two cases

[denis.goddard]

Amen. Iâ(TM)ve been managing software development teams for nearly three decades, and IMO the single most important job of software management is to leave developers alone. Shield them from the Drama/Hot Feature/Management question of the Day. Keep their time in meetings to the barest minimum. Make sure their support responsibilities can be planned for, so they are not jumping into one emergency after another. Make sure customers arenâ(TM)t wasting their time with emails and chats. Absolutely resist the âoejust spend an extra few minutes documenting what you did the last 4 hoursâ/clicking pointless checkboxes/justifying every 30-minute interval of their day. Software requires THINKING. Concentration, in long uninterrupted blocks. Thatâ(TM)s the secret to making the secret sauce: let them think and program.

Re:Two cases

[swb]

The best part about the rulebook strike is that you don't need to strike or be a union member to get mileage out of it.

We had a come-to-Jesus meeting about slow time entry (our system sucked, was cumbersome, and management's general expectation was that time entry should be done on your own time).

During the meeting where we vented at some of the dumb misfeatures of time entry that required multiple steps due to bad field interactions, it was suggested that total time mattered, but start/stop fields didn't need to be accurate. Of course I raised my hand and asked why we collected them at all, and what other fields we collected data on were ultimately irrelevant.

Of course my manager was tongue-tied, trying to explain how none of it was really irrelevant but that we should consider some of it irrelevant because it got in the way of the main goal, collecting time for billing.

I love to exploit these situations from time to time, following their rules to the T until they tell me to stop following their rules because its getting in the way. You keep enough of these emails and suddenly no rules matter because it becomes apparent that they're as interested in convenience as anybody.

Re: Two cases

[ath1901]

A friend of mine who runs a small company once asked what I thought was the most important job of a boss. I said: "Removing obstacles for their underlings". He really didn't like that and started talking about vision, planning, goals and such. I didn't reply and mentally excused him a bit since he's running a really small company and may not have experience with the kind of problems that arise in larger networks of people.

Absolutely!

[chromaexcursion]

Because most don't actually do agile.

Supposedly been doing agile for years...

[srichard25]

I've supposedly been doing agile for years, but I've never once worked on a self-organizing team who could build software without working with several external groups. And all of those external groups are set up to work waterfall. You've got the UI designer who wants to design the whole experience up front. You've got the data modeler and DBA who both want to know exactly what data you will be using up front. You've got the architect who wants the full design documented so they can spend 10 minutes looking at it and give you an approval. You've got the project manager who wants to know exactly how long all the development is going to take. So you end up having to do big-design-up-front in order to work with all these external groups.

A lot of companies say they want developers to do agile, but they need to realize that agile requires changes throughout the organization. It's not something that developers can just do by themselves.

Re:Supposedly been doing agile for years...

[Antique Geekmeister]

> And all of those external groups are set up to work waterfall.

Or, in my experience, they are often set to work only through a manager. Tasks must be explained to one manager, who has the status to talk to another manager, who has the status to speak to their team, and _each_ layer must be completely convinced of the priority and feasibility before a question can even be asked about the available tools. Attempting to do "agile" in this kind of structure is disastrous, because even if a team accomplishes its designated tasks, nothing else is ready. And by the time the other teams are ready, the original work is no longer relevant.

I've no overall solution for this. I and my colleagues have, on occassion, been able to coordinate multi-department work under the guise of "external consultants", and been applauded for helping.

Already did

[Philotomy]

I was on a team that "used agile" for while. The thing is, our development workflow "before agile" already addressed the main ideas in the agile manifesto, so in practice what happened is that our development workflow was unnecessarily modified (disrupted?) to include more "agile practices" like pair programming and other buzz words (user stories, rigid application of TDD, et cetera). We didn't see much (any?) real benefit. It eventually got abandoned. Can't say I miss it.

I've got no problems with the ideas in the agile manifesto. I'm just not convinced that the practices and culture that often gets included are always worthwhile.

I Haven't Seen Developers Actually Choose

[brian.stinar]

At every place I've worked, including the company I now own, the developers haven't been the ones that decided on the development process. The fact that they haven't decided has either been because no one actively decided, and management provided a default choice, or because management actively made a decision regarding the development process (either due to business needs, or basically arbitrarily.)

So, I believe the question of whether or not developers should abandon Agile is based on the false pretense that developers typically are able to make a decision. I don't believe that they are able to decide which development methodology they subscribe to, in general.

Can't force a square peg into a round hole

[Kjella]

Agile doesn't deliver what the business wants which is to turn coding into non-creative work where you know almost exactly how long it takes to get from A to B and exceptions have explanations like traffic accidents or construction work. Nothing ever will but it won't stop them from trying so the best Agile can do is shield the developers from impossible tasks and meaningless meetings so they can spend time on actually doing development.

The first shield is the product owner, a ton of people want things and they'll go through all sorts of channels with competing priorities and sneaking in pet features. Shut them down, make that one channel in and one non-developer resource they can talk to if they're not happy with what they're getting. And no, there's no point in re-prioritizing things daily once every two weeks is fine for everything but hair-on-fire emergencies. The second shield is the scrum master, I'm currently one and my main job the way I see it is to maximize the number of hours my team members actually get work done on the things they're supposed to be working on. Particularly all fuzzy meetings called to discuss things where I say "You figure out what you want first from a business perspective, then let's talk solutions" or that are more or less status/re-planning meetings where I say "The quickest way to get it done is to let the ones working on it work on it."

It's not particularly Agile-specific, reality it's about two simple things, what should I be working on and let me be so I can do my f*cking job. Whether it actually works better for planning than iterative waterfall, meh... I've always said you should try to think and explain as far ahead as reasonable, like is this part of the functionality/structure you'd like to have in the end. You don't build a skyscraper by building a one-story building and then building one more story on top, if you know it's going to need to support 50 stories then tell us now.

Avoid "crufty" complex designs

[PPH]

Poettering! Don't try to sneak away.

Re:I have a great deal of experience with Agile

[Anonymous Coward]

Agile undermines ownership of the project. When, in the process of building a product, a programmer is expected to do their work in 2 week chunks exactly as (usually someone else) has decided with very little room for deviation (gotta maintain that velocity!), it's hard to feel invested in what he or she is building. It's hard to feel like your human judgement means anything at all. You feel like an underappreciated cog (and at many companies, you are!). You certainly don't care if the project succeeds or fails. You just want to get your sprint finished as quickly and easily as possible so you can go home. And, agile in practice reinforces that, because that is how management sees it. It should come as no surprise that taking your expensive developers and turning them into what feels like an H1-B code mill will reduce quality and long-term efficiency. Programmers often do the job of a programmer despite being able to do the job of the manager who cannot do their job because they love building shit. If you take that passion out from under them, you will drastically reduce their output in the long term if you ask me. It might look like great velocity, but that's just a comforting lie management tells themselves (because I've never worked for a manager who had any experience programming... which is sad in and of itself).

Re:Agile is bullshit

[phantomfive]

Beyond the headline, here's what he says:

1) The team itself should choose the process because imposing process company-wide by business execs is bullshit. If you have a consultant come in and impose a method, that's reverse of what should happen.

2) The agile manifesto is good. (tbh it's actually kind of funny how many people are "doing agile" without ever having heard of the manifesto itself. Kind of hard to keep the core principles of the process if you don't even know they exist.)

3) All you need are three principles and those are, "release code often" "keep your code clean," and "push back against managers imaginations" by focusing on reality: what state the code is in now.

Again he reiterates, if process is imposed from above instead of chosen by the team, things will go wrong. He's kind of echoing Fred Brooks here, who said, "The teams need a process, but they choose it on their own."

Never done agile

[Snotnose]

But I've been on 3 projects in the last 40 years (I'm retired now) that had daily meetings. All 3 failed for different reasons (hardware issue, company died before project was done, what I just said except for a chip, not a printer).

What did these 3 have in common? The daily meeting absolutely killed morale. For the first, us software types had a daily meeting where the hardware guys would mumble, the second was at 7 AM daily, even on a Saturday morning (I was in my 20's and still half drunk from the night before, and got sucked into the project when it was failing because "you understand this Unix stuff"), the third was flat out an incompetent manager who could not remember anything day to day.

For the first, no reason for us software types to be there as there was no hardware.

For the second, 7 AM on Saturday morning? You'd have been better off letting me roll in at 9.

For the third? There was no fixing that. The manager was 100% incompetent and could not be fixed.

Cargo cults

[The Evil Atheist]

Developers should abandon their tendency to be cargo cultists. Don't do things just because that's the way it's always been done. Don't do things just because someone labelled them Best Practice. Don't do things just because other people have done it and it worked out for them.

The only method that works is to try it out and see where it leads, be super observant about where the pitfalls start appearing, and give yourself enough leeway to try something else if it isn't working out.

Re:I have a great deal of experience with Agile

[Anonymous Coward]

That's it, that's it exactly! I recently retired from 30+ years in IT, doing programming in all kinds of environments and all kinds of businesses, and I retired mostly because I felt I'd had all the joy finally beaten out of me. When I started, it was fun to make things that worked, that actually made the daily working grind better for the people who used the software. By the end, it seemed like the goal was to slurp down the buzzwords of the week, rather than making things that worked!

All the passion is gone from the industry, at least the parts I worked in. No methodology will make the soul-dead zombies, that are the programmers these days, able to build good things.

Re:Agile is bullshit

[geoskd]

I disagree. I think it has a lot of good theory behind it.

Agile is no better and no worse that any other way of doing business. In then end, good devs produce good work as long as management isn't totally inept. Bad devs produce bad work no matter how good the management is. The simple reality is that 50% of the software developers out there really should not be developing software because they just plain aren't good at it. Trying to somehow magically get good work out of them by "empowering" them is just putting lipstick on the pig.

OK, one more time. Agile is an adjective.

[plopez]

https://www.youtube.com/watch?...

Corporate faux-agile is better than waterfall

[Tony Isaac]

I've lived through the waterfall era. Now I work in a large corporation that uses what Ron Jeffries might call faux-agile. It's Scrum, "imposed" by management. It actually works, the team is happy, and gets a lot done. I'll take this faux-agile any day, rather than go back to waterfall!

Re:Agile is bullshit

[Z00L00K]

I see that on the high level in a very complex environment waterfall is probably giving the most structured way of working. I deliver a car to be tested on the road and get back the problems found.

On the low level where I work with software or hardware components then a flexible approach is better. But it requires that the whole team works in a coordinated way and that everyone knows what the reason is for what their part is developed for and what it shall interact with. A drawing of a door hinge drops down to the person making that hinge - if he can see where it's used and knows by hand the history of previous hinges made and what limits he have he can look at the drawing to see if previous problems have been addressed and then make a prototype - or even more than one prototype with suggested variations to address certain historical problems that can be tried out in test fittings. It can be subtle changes like increasing the length 10 mm to make it more stable. It will of course have to go back to the person making the drawing that the longer hinge is more stable so it won't cause other pieces to be moved that will come later.

An organization should firsthand try to avoid the situation "Jack of all trades, master of none" - everyone knows a little about everything but lacks complete specialists on any subject. Especially in large organizations. A newbie may not have much knowledge of how their part fits in, they may be fresh out of the university and have a very general and generic knowledge, so starting somewhere would give a good start, then build up competence over time and move around if they find that another part of the organization is better for them.

Good management vs. the latest buzzwords

[bradley13]

Agile is a good concept - I've included the Agile Manifesto in my courses for years. The problem is: Agile is no better than the people implementing it.

I've just witnessed this (again) in a recent project. The PM had just gotten a promotion, but he had to finish this project. He used Agile as an excuse to basically abdicate (or maybe he was always a lousy PM), and he let the developers and the customer talk together directly. The customer thought this meant that all of their ideas were flowing into the project every two weeks. The developers thought the customer was changing requirements every two weeks. The result was inevitable: a project that is 3/4 finished everywhere, totally finished nowhere, and is now likely to land both companies in court.

Crappy management is not saved by Agile. Given good management and a good development team, any methodology can work - pick the one best suited to the project and the people.

Re:Agile is bullshit

[bsolar]

Actually how the dev cycle reacts to the workload is a very good signal for the team "agility": basically, truly agile teams will shorten their dev cycle under demanding workloads, "faux agile" teams will lenghten it.

I worked in a "true agile" company with a 1-week release cycle. Under demanding workloads like rewrites or new big products, dev cycle went from weekly to ad-hoc, which basically meant "every day".

I worked in a "faux agile" company with 2-week release cycles. Under demanding workloads the dev cycle went monthly, or worse.

"True agile" developers have to master how to implement changes in small steps: increasing throughput means implementing more small steps in the same time. "Faux agile" developers don't master that and increasing througput ends up meaning increasing the steps lenght, defeating the whole idea of agile.

Said that, very easy to say, very difficult to master, especially if you depend on choices which are counter-productive to agile, which is very often the case in large enterprises.

TL;DR: if the dev cycle under demanding workload shortens you are doing agile right, if it gets longer you are doing it wrong.

Re: Agile is bullshit

[phantomfive]

What rules are you talking about? The agile manifesto specifically says, "we value Individuals and interactions over processes and tools." It sounds like you are too focused on rules, and have lost sight of what Agile truly is.

Re: Agile is bullshit

[Cytotoxic]

I agree.

I think what he might be referring to is the old problem of "urgent but unimportant" stuff getting done before "not urgent, but important" stuff.

I had an executive who was particularly "imaginative" in his development requests. He was enamored of whatever he saw elsewhere an wanted one for himself. His requests were so fast and varied that he became frustrated that he couldn't have everything... so I made him give me his "top 3" list. Give me 3 things, and we'll work on those first.

So his team gets together and after more than a month of planning, they come up with a 7 item "top 3" list. And we start work on the top 3. Every week we were going to have a progress report. So they come to the first progress report meeting all excited. They have a new project... the most important one. It needed to go to the top of the list. So I named it "project zero", since it came before project number one.

A year later the executive was under some pressure and was angry that none of his "top three" requests of a year earlier had been finished. So I showed up at a meeting with the CEO and COO with a stack of change requests... 50 of them, one from each weekly meeting, where he signed off on "don't work on those things, work on this new request". Somehow he still didn't understand that he was the one makeing the decision not to work on his "top three" items.

He was the embodiment of the "ooh, shiny" approach to decision making.

Working with that guy in an agile environment really didn't make any difference. The only thing that would have worked for him was to have unlimited resources. That way he could have a whole new CRM every month, new websites on a weekly basis, new accounting packages every other month, etc. Surely that would have worked out for his team, right?

The manifesto was correct..

[Junta]

The problem was that the manifesto was common sense and stating plainly how good teams already behaved.

The problem is they and a whole lot of people *thought* that with a plainly spoken set of words, it would be possible to go out and fix the whole industry, which was and still is beset by a whole lot of nonsense in processes and tools.

They were half right, the short document that was easy to understand did resonate with a lot of people and the idea that the way things are being broken resonated with a lot of people, thoughout these organizations.

Two major problems happened. One is that the same traits that drove those teams to create terrible processes and abuse tools are still there, and to some extent doom those teams to always landing in the same place, perhaps changing terminology to comply with the fad (big-A Agile). Call their "status meetings" "Scrum", call their "requirements" "stories", "milestones" becomes "sprints". Change the words and 'poof' they are "Agile".

The other complicating factor is the tools and consultancy business. "Individuals and interactions over processes and tools" is not something that is a profitable stance. So that goes by the wayside and consultants revel in making money reinforcing the above behavior. Consultants know these companies ultimately are spending the money to feel better about the way *they* want to work, and they are happy to oblige. Enough change to be annoying and feel like *something* has changed, but leaving that organization structurally the same, the way management clearly had made it in the first place. On tools, well that is a mess. When asked if my team was "Agile" I replied "yes" (mainly in hopes to deflect the 'transformation initiative") and they asked "Oh, so your team has been paying for Atlassian software then?". Because we didn't happen to be using Atlassian, it was deemed we *must* not be 'Agile' and we had to undergo the bs training and migrate all our stuff to Atlassian tools and in general waste a whole bunch of time. Worse than that, they assigned folks to "help" us be Agile in an ongoing capacity, and demanded we declare 6 months worth of plans for Sprint content and get mad at us when we prioritize responding to a customer request over made-up dates for 'nice to have' backlog items,. When I point out "Responding to change over following a plan" was part of the manifesto, the ostensibly Agile-focused helpers say that's not part of Agile, it wasn't in any of their training, and that they got Agile certification so they should know.

Re:derails because of laziness and job protection

[Junta]

Developers will write some unittests, but just enough to test some new functions here and there in different components.

Also will say that teams have a very bad habit of saying "100% coverage" and then saying "we don't need a QA team, auto testing takes care of all of it". To the extent that my team does unit tests, I don't claim that to management for fear that management will can the QA team, which is comprised not of programmers but people from the target industry, that give functional as well as "this was a dumb idea" feedback.

As to the rest, it doesn't really matter if it's called "Agile" or not, it's the same sort of things you would see in software development before Agile came along. It's the hellish behavior that the folks originally wanted to "fix". The reality is that a bad team will be a bad team, and no matter what they are told, they will find a way to create that same horrendous dynamic using the terminology to fit the "project management fad of the day". When someone sees this and tries to fix it with another promising sounding fad, it too will degrade to what you see today.

The original Agile was simply:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Which has always been pretty obvious to anyone.
The problem with the first point is *not* was company leadership wants to be true, they want processes and tools and to be able to toss aside one person for another at will. Also, as a consultant there's more money to be had selling them "Agile tools" than just telling people to work together. So branded-Agile tosses that.

The problem with the second point is that it requires developers intimately understand the user situation and to not be so lazy as to avoid doing the work. In practice "it can be fixed in documentation" remains the "easy way" to cheaply meet schedule.

The third point is simply unrealistic, sadly. Yes from getting a quality product, this is important, but that collaboration taken to the extreme will cause the scope of needed work to grow endlessly. This is of course ok for engagements that are also effectively "limitless", but for project-driven engagements this sadly doesn't work.

Responding to change is the one point everyone would *love* to claim to be a champion of, but managers are accustomed to forecasts, and deviations from plan break forecasts, and as such management really hates this. Of course so do many developers. It's distracting to react to changes in plans and some people just aren't wired that way.

Re:Self-organizing teams are over-rated

[Junta]

Hire the right people, and they'll usually have no trouble convincing management to go along with their proposed process changes.

Part of the problem is that management is always hoping that the right methodology will mean they don't need to hire the right people. That there exists some methodology that reduces software development to have employees as interchangeable as fast food workers.

Good management will always seek out the right people, and generally trust those people to do what they need and are happy so long as the results mesh with their ambitions. These teams are less likely to fret about compliance with buzzwords, so even if they are in practice honoring Agile principles (knowingly or not), they will be less likely to bother to claim it.

Bad management will always buy into the hype and label what they want according to hype and run it into the ground. These people will be obsessed with the Agile label and so Agile looks terrible.

Agile in reality isn't really much of anything at all. You spend less than a minute reading 4 phrases, that's it. Those phrases are not miraculous insight, they are just common sense, so if you're good, you don't need to even know those phrases are written down or labelled "Agile" or anything, it's just naturally your reality.

Re: Agile is bullshit

[Anonymous Brave Guy]

For example, it could mean having to say no to a CEO that wants to change things, to creatively handle certifications and audits without imposing a detailed process...

And this right here is why a lot of "Agile" efforts are misguided.

Yes, for sure, hire smart people and let them be the experts at how to do their thing. Let them automate, test, develop in small steps and integrate often, if those things work for your organisation. Don't micromanage or dictate policy unnecessarily.

But remember that developers are usually not operating in isolation. They are part of a wider organisation, and the software they build serves a purpose as part of the organisation's wider strategy. That strategy is senior management's responsibility, and the idea that the developers should be fully aware of that strategy or have final authority over anything affecting the organisation is no more credible as the idea that the CEO should understand every line of code.

Re:Agile is bullshit

[arth1]

"True agile" developers have to master how to implement changes in small steps: increasing throughput means implementing more small steps in the same time.

A problem is that some work is monolithic in nature and cannot be partially released. This is particularly true the closer you get to the hardware side of things.
Agile fails when it tries to jump a chasm in three small steps.

Attempting to divide it into even smaller pieces isn't going to solve the inherent denial that some things cannot be split.

Nor that when something can be split, it doesn't mean it should, even under pressure.
Getting certifications for N components one at a time, for example, takes longer, costs more, and at the end, should you reach it, you need to get a certification for the whole anyhow.
Or you should not split security into a separate task that risks not getting done until there's been a release without security. That's bad. And I've seen it happen more than once.

Re:Agile is bullshit

[Gr8Apes]

First, this is the first headline I've seen where the answer is an unmitigated "YES!!!!"

2) The agile manifesto is good. (tbh it's actually kind of funny how many people are "doing agile" without ever having heard of the manifesto itself. Kind of hard to keep the core principles of the process if you don't even know they exist.)

What's funny is how Agile took notes of people that were successful in releasing software projects and got the message so entirely absolutely wrong. It never was "Waterfall" or "Agile". Strict waterfall works, but it is expensive. You may have heard some of the success stories, anything done for NASA for one. Working on such a contract can be excruciating and boring, and truly leads to the misconception that all programmers are merely cogs, because in such a project merely being a medium level syntax proficient programmer is all that's required.

But back to the point - truly successful projects in the internet time-based world required faster turn-arounds than waterfall allows. It requires active management leadership, and quicker feedback loops to make up for the removal of the heavy front-end design and specifications phase. The guys that wrote Agile seem to have glommed onto a few of the traits from successful projects without paying attention to the context within they were used. Just IMNSHO. (while I respect Dave Thomas, he was so so so wrong on Agile and from what I gather he seems to concur more with the underlying basis of what I stated above) So now we're going back to a more sane project leadership based system, or at least those that are successful have done so.

Re:Agile is bullshit

[angel'o'sphere]

Agile is no better and no worse that any other way of doing business.
Waterfall: I analyze 3 month, I design 3 month, I implement 3 month, I test 3 month. After 12 month I deliver a product that is no longer adequate for a market that has changed over the course of said 12 months.
Agile: I deliver after ~6 weeks a working, tested, approved, subset of the project. Every ~6 weeks I can change course, change the scope of the project, change priorities of features. Heck, I can cancel the project after 3 sprints because I realize: the team is to slow, it will take them 18month, which takes to long, or is to expensive.

First approach has the risk of sinking a HUGHE amount of money. the second approach has the risk to sink a considerably smaller amount of money. That is the reason why most modern SD is done agile (or abuses agile by 'doing it wrong').

The simple reality is that 50% of the software developers out there really should not be developing software because they just plain aren't good at it.
That is unfortunately true for every job.

Re: Agile is bullshit

[Nocturna81]

And you yourself fall for the faux agile: that you value one thing over the other doesn't mean the other thing isn't important anymore. But if you have to choose you choose interaction over processes and tools. In practice this means you stick with a process, unless it means it stands in the way of progress and / or interaction between people. Then you dump it. A process isn't inherently evil, see also: the scrum process

Re: Agile is bullshit

[Hognoxious]

Theoretical principals

As opposed to practical headteachers?

Re:Agile - no planning and we'll get great results

[Frobnicator]

Partly true. That's the fourth agile pillar of responsiveness is more important than strict adherence.

I try an analogy of travel plans for a large group event. Building a big travel plan for everybody to get to the party won't work: people are coming from all places, some from home, some from work, some from distant cities. Instead, clearly communicate the destination and let each traveler be responsible for getting there.

Agile software DOES need planning. Everybody needs to understand what the destination is going to be. However, the plan needs to be flexible, responding to changes versus following the plan.

When you're driving and you encounter construction you don't follow your GPS's directions to drive through the construction barrier or off the cliff. You reroute because you value responding to change over following the plan and you understand that sometimes you need to deviate from the plan. But that doesn't mean you ignore your final destination. You may not follow your planned route but your destination remains the same.

Going through the manifesto... (1) We want everyone to be at the destination, and we care more about the fact that the people are treated as people than that they be there; if someone needs accommodations we make the accommodations because people are more important than process. (2) We want to make sure we have the destination. If the event were a big party it would suck if everyone got there and we discovered a a bunch of todo items like "rent the venue" and "hire the caterers". The plans are nice, but we need to actually make progress toward the destination rather than just making progress towards plans. (3) Helping people get to the destination is more important than details of how they get there. If individuals have different needs in order to get to the event, try to accommodate those needs. (4) We should help people reach the destination following whatever route works for them. If they need to change their route to reach the destination we should help them.

All of this is predicated on having a clear destination that everyone understands. When I've seen Agile fail that's been the biggest failing, there was no shared understanding of what was expected. When I've seen Agile succeed it was when everyone (or at least the key people) had a clear shared vision of the destination.