2017-10-15

2017-10-15 Sunday - Rabid Agile, A Gentle Criticism

One dictionary includes this definition for "Rabid": "Having or proceeding from an extreme or fanatical support of or belief in something."

This posting is intended to be a placeholder for collecting what I view as examples of fanatical Agile viewpoints held (or promoted) by others - based on my own frame of reference.


Signs You Might Be A "Rabid Agilist":


1. You Believe "The Source Code is The Design | The Documentation"

2. Every Project Team Makes All Architecture Decisions Locally - No Governance

3. You Think Every Project Can Be Forced to Fit Agile
I find the most rabid proponents of Agile (ready-fire-aim for every size project) have no appreciation for scale of when that is appropriate (perfect example of when NOT: fixed price contracts with vendors, massive development coordination between dozens of service providers, fixed deadlines - driven by market and regulatory forces) 
To an untrained eye, and based purely on that external person's observation, one might conclude that the Rabid Agilist revels in flagrant waste. 
Assuming an budget - they fail to recognize that the business has little tolerance for  rework.

4. You Promote #NoEstimates Nonsense
 



You are not being tasked with building a "warp drive" - most software development isn't breaking new theoretical ground - this isn't rocket science - many systems (of similar kinds) have been built (and rebuilt, and rebuilt) over many decades - so it is a poor excuse to whine it has never been done before. 

5. You Believe That The Only Participants That Matter are Developers and Customers

Fred George's "Programmer Anarchy" seems to hit all of the above, and then some:

Caveat: Agile is a goodness, but certain practices/applications of it are not appropriate for every type/size of project.


Finally, I offer you: Meeks Software Architecture Conjecture #1:

The source code may (or may not) be a full implementation of the desired capability needed by the business - but is more likely just an approximation (constrained by permitted time, allocated budget, and available skills/talent of the team involved). Therefore it should not be confused with the actual or desired (or envisioned) design - that may require multiple years to achieve - of which the current source code may only reflect a partial (and incomplete, or inaccurate) representation.

 

Updates:

2024-05-15 Friday

An interesting 2023 post by Michael Küsters


 

No comments:

Copyright

© 2001-2021 International Technology Ventures, Inc., All Rights Reserved.