Most people — Agile evangelists are no exception — tend to define Agility via a specific way of working (e.g. via SCRUM) or via the Agile Manifesto (which is a set of too easily – and by far too often – misunderstood principles totally ignoring the CIO as one of the most important stakeholders).
But to really understand what it means to become agile as a software developer (or a developer’s client) in some positive manner
- we have to understand Agility as a Necessity to survive in today’s fast changing environment,
- we have to adopt the right Agile Attitude,
- and we have to accept Agile as a Best Practice.
If you don’t believe me, there are others who also say:
- We are tired about reading misinformation about Agile,
- Agile is certainly not SCRUM (or some other specific process), and
- Agile is often used for an excuse not to work professionally enough.
Gartner as well as Cutter Consortium tell us about more and more clients who realize that agile methods — if defined by XP, SCRUM, or the Agile Manifesto — let developers forget that they should also think about product features that are to guarantee maintainability of the software in the long run.
And indeed: So far the problem is that in contrast to a Software Owner (a CIO), the typical Product Owners in the sense of SCRUM do not think beyond the development phase of the software life cycle.
After trying out Agile for some years, CIOs more and more realize that teams doing agile software development left chaos: software that is neither well defined nor easy to maintain.
Evangelists of Agile should accept that Software Owners are stakeholders quite different from Product Owners and that therefore Agility as defined by the Agile Manifesto is far from being professional enough.
This is why we need
A process model for software development not ignoring CIO’s interest is Specify, Subcontract, Test (SST).
ggreiter 