Agile is Bulls*%t

Thank you Dan Greenberg for another great guest post!

A fantastic 2016 post from Agilist Jasmine Adamson. Sourced from this Quora story (and to find the original comment, you'll have to scroll about 3/4 of the way down the page)

Full text reprinted here:

Agile is bullshit, that's why. OK let me qualify... The Agile Philosphy is perfectly fine, and it addresses the physical and psychological aspects of managing software development teams quite well. The bullshit comes in when a team or company makes the statement that "we are doing Agile" because they aren't. So, to clarify, Agile itself is a good idea, but when someone says they are "doing Agile" that statement is bullshit. Always.

Programmers like things well-defined. When you tell me we're going to "do The Agile Process" (it's not a process), I expect an organization that follows these principles: Principles behind the Agile Manifesto

Those principles are well defined, even beautiful. When all of those principles are taken into account and lived every day, you have a well-defined, even beautiful process. When you leave out even one of those principles, it all goes to hell, you're not doing Agile any more, and people who know Agile will recognize that immediately, as I have done in every single shop I've ever worked.

I've worked in "Agile" development shops for the past 8 years, so let me tell you the reality, with relation to the principles, and I think you'll understand why "Agile" is bullshit...

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. - My customer right now is another business unit. I have never met them and I have no idea what they do. This is the reality in most companies. We don't even know the customer well enough to "satisfy" them, and certainly not well enough to make it job one.

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. - LOL! Nobody accepts changing requirements. It is universally hated, but it's the second Agile principle!

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. - Some companies do this quite well, but most teams aren't managed well enough to break software up into reasonable chunks for Agile time-scales. Delivery schedules are often based on large updates rather than small ones. Big updates isn't Agile.

4. Business people and developers must work together daily throughout the project. - LOL! Again, this isn't really done. I don't think I've ever spoken to any of my customers on my current project. In past projects this has been hit and miss, and mostly based on organizational structure rather than anything meaningful. I can't talk to my customers because "they are above me" or "they are in another state" or whatever. Developers and business people working together is extremely rare. Most companies have a go-between who is supposed to facilitate this relationship, but it never works very well. I need to talk directly to the person using the application, NOT their manager, who doesn't really use it, and certainly not to the manager of their manager, through my manager - which is the typical case. Requirements are often determined by a person two levels up from the actual users and communicated through representatives, never directly from user to developer.

5. Build projects around motivated individuals. - Most people don't know what this means. What it means is low level employees typically have the best ideas for software, and they are typically motivated to solve those problems because it will make their lives easier. Projects should be structured around those desires, which will affect the company bottom line directly by making workers more effective. Have you ever worked in a company where the lowest level employees are deciding what software should be built? Don't make me LOL, again.

5a. Give them the environment and support they need, and trust them to get the job done. - This is about developers here. Have you ever worked anywhere that you had all the tools, all the access permissions, and all the gadgets you needed to be most effective? Getting a good set of monitors is worse than a trip to the dentist in most companies. In one of my recent positions, it took three weeks to get me a computer that could run Visual Studio, and that was after I had told them two weeks before my start date, the exact specs of the computer I would need. Developers are rarely "trusted" either - usually we are told exactly what to do and when to do it rather than being given a job and a deadline and left on our own.

6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. - You mean to tell me we can't do everything with IM and email? Seriously? Yes. Seriously. When a team is spread out all over the world and never looks each other in the eye, it hurts. This is particularly true for interaction between developers, but also important for interacting with customers. My most effective method of improving existing software was to stand behind someone and actually watch them use it. In many companies you just can't do that, even if you know who the customers are, they are "too busy" to talk to you, or it's impossible for some other reason. In-person interaction just isn't what it used to be. Companies don't think it's valuable.

7. Working software is the primary measure of progress. - And yet, nobody measures that. What do we measure? Defect rates, hours worked, things like that. We almost never measure the thing that matters - did the customer get a working feature? How many working features did we release? Were they big features, medium ones, or little ones? Nobody knows.

8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. - What this means is everyone works 30 hours per week on development and 10 hours on managing themselves and their workload, communicating with others, administrative stuff, etc. This can go on forever. What many companies do is demand overtime occasionally, and what some companies do is demand overtime quite often, and this is not sustainable. An Agile team rarely goes into emergency mode and pulls all-nighters. (You're kind of always in emergency mode)

9. Continuous attention to technical excellence and good design enhances agility. - Most companies do an ok job of this, but technical excellence is often pushed to the side in favor of software that works. This is, in my opinion, the correct trade-off (principle 1 and 7)

10. Simplicity--the art of maximizing the amount of work not done--is essential. - Most teams simply don't spend enough time on this. A sense of urgency often overrides careful planning. The problem here is careful planning makes things get done faster. During the planning stage it feels like you're not getting anywhere, but you are setting up for a quick sprint. This setup is often overlooked, and we end up with not only complicated software, but complicated development habits, complicated code, and generally poor software design. This slows down maintenance and new development, as we try to fit into poorly designed structures that become ingrained and impossible to improve. "This new feature is poorly designed because the application it integrates with is poorly designed" can go on forever.

11. The best architectures, requirements, and designs emerge from self-organizing teams. - Teams are organized by management, almost never by themselves. This is just a corporate culture problem, and it's very hard to overcome. Sometimes in startups and younger companies you can promote this idea and have it work, but in most companies it just doesn't work.

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. - Many companies do an ok job of this, but it's often in the form of "performance reviews" and it doesn't have the flavor we really want. What Agile wants is "lets all sit down together and look at what we did and how we can be better next time, AS A TEAM" - but what usually happens is individuals are evaluated against arbitrary and subjective measurements, and teams almost never implement any process improvements based on those evaluations.

So, Agile is bullshit because nobody embraces the principles and puts them to work, but they still say they are doing Agile. This is extremely frustrating because developers know that if we did these things we could be way more effective.