Tag Archives: Agile Manifesto ignores CIO’s interest

Against misunderstandig Agile


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

If you don’t believe me, there are others who also say:

 

Advertisement

Agile Methods (so far) ignore CIO’s Interest


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).