Lazycoder

Agile practices do not address technical complexity

So, first go read Ted Neward “Agile is treating the symptoms, not the disease.” and Phill Haack “Software Externalities” then read the Agile Manifesto

At some point that very simple manifesto turned into a set of “must have” tools, technologies, methodologies, and processes. Which I think defeats the purpose. You have to look at each tool and methodology and think “how does this help me build better software for my user?”

There is a very important paragraph at the bottom.

That is, while there is value in the items on the right, we value the items on the left more.

 

So let’s go through each line.

Individuals and interactions over processes and tools

These “story cards” are one way to increase the communication between individuals during their interactions. Gigantic requirement specifications don’t do anyone except other software engineers any good. The daily standup meeting that a lot of agile practioners adopt is one way to keep the team up to date and find out about possible problems as soon as possible.

Working software over comprehensive documentation

No matter what, you’d rather have an application that meets the users needs and helps them get stuff done easier than they could before you wrote their application. Chances are, if you need to write a lot of documentation, you’ll have to maintain it also. Most of the time documentation is only for other developers that will have to come along behind you and change the software to meet new user needs. What better way to communicate what the software is supposed to do than a bunch of executable code, e.g. unit/scenario/integration tests, that ensures the application does what it says it can do?

Customer collaboration over contract negotiation

By adopting techniques and tools that allow you to change direction quickly and confidently, you don’t need to “lock down requirements” before you start developing. If the requirements change, you’re code base and tools are flexible enough to handle the change. That’s where principles like S.O.L.I.D. come into play, they make your code base more flexible and responsive to change.

Responding to change over following a plan

How can you ensure that, as you change your software to respond to changes in the business or requirements, your software doesn’t break? Automated testing is one method. Continuous integration builds are another. These tools aren’t used by agile practitioners  because they want to feel cool, they are used to help them better respond to change. The story cards and backlog also help. You can re-prioritize your backlog to meet the businesses current needs. Since your iterations are short, and your stories are small, the overall impact to changing direction is minimized.

The fact that software development is complex, and that there is a lot of new things to learn. That there is ALWAYS something new to learn about software development, has NOTHING to do with agile practices. You’d have exactly the same problem keeping up if you practice agile or not. You might have an internal process where you work that allows you to respond to change quickly, it may even involve Microsoft Access!

There was a great post that Miguel De Icaza linked to on Twitter. “Every Ideology is Right”

What I mean by "right" is that is each one is responding to a genuine problem within human existence. And their prescriptions for how to deal with that problem "work," at least in the short term in limited circumstances.

Obviously, there are unforeseen consequences because each ideology looks at a limited aspect of reality, and then tries to apply its solution for that part of reality to ALL of reality. The important thing is to try to have your ideology "look" at as much of reality as possible.