Does not matter the adopted practices, and the Agile claiming: a team will be Agile only if will be able to respect the Agile values and principles in a steady manner, by serving the customer business also on medium and long term. That suppose also having Adaptive Products (see previous post).
Here some scenarios when the product is not adaptive, and that will not qualify that team for real Agile development.
Big Bang Delivery of new product
Similar with that cosmic (hypothetical) phenomenon, you could try to deploy to the market to more customers a completely new product (or a significant part) where the functional and non-functional attributes (performance, usability and others) are not yet subject of a real business feedback (from production usage).
Does not matter if you have Small Iterations, Product Backlog, Self-Organization, or Technical Excellence, because are missing Often Delivery and Close Customer Collaboration. Usually, when you are building a new product will collaborate rather with one customer, that mean you are really close only to that customer. Also there is high probability that both functional and non-functional product proprieties will not fit too well for the rest of the customers.
There is the custom to have a "pilot" deployment, but that it is not enough, because, after the pilot should not be adopted the Big Bang delivery, but, also in this case, an incremental approach.
See Scott W. Ambler solution "An Exploratory “Lean Startup” Lifecycle"
Long projects - Big Releases
It is a similar context with the "Big Bang" delivery to multiple customers. The Work In Progress will be too long, your result will get too late a real business feedback. Many feature could not match with real business needs or could become deprecated.
Anyway, big releases are not Agile also because the Agile solution for complexity of the software projects are the Small Releases.
Spaghetti Code, Big Technical Debt
Poor design , Spaghetti Code, accumulated Technical debt will reduce the product adaptability, the reaction to changes, the overall quality (the list of damages remain open). Such products are definitely destroy the agility.
Just a good design ...
"Continuous attention to technical excellence and good design enhances agility. " that is a great principles from Agile Manifesto.
Well ... That is not enough, from technical point of view, to sustain the Agility!
A real agile product must be an ADAPTIVE PRODUCT, where the business is well modeled, it is decoupled from the technological aspects. The business representation inside the product should have the following properties for supporting Agility:
- must survive with smaller costs, quick adaptation and no quality problems to the technological changes
- must support also quick adaptation, with smaller cost and no quality problems to the business changes
Two design principles will give the biggest help to realize these capabilities
- Separation of concerns - especially to decouple technological aspects from business aspects. Also could be applied to decouple different technological parts from one of other , or business aspects
- Functional cohesion - should be the main instrument in injecting the business DNA into the product, where the software system design should match its functions
An agile product must have a "Business DNA" , realized by functional cohesion and protected by separation of concerns and a good design.
My witness :-)
Well, if you do not believe me, maybe you trust in Robert C. Martin. His design principles are a great "testimony" in favor of Separation of Concerns (Single Responsibility, Dependency Injection). I recommend also these presentations, that promote Functional Cohesion as main attribute of a good architecture.
Clean Architecture and Design-2012 COHAA The Path to Agility Conference
Ruby Midwest 2011 - Keynote: Architecture the Lost Years by Robert Martin