What Agile Software Development Really Means

The true Definition of Agile Software Development

Agile software development is an often misunderstood term because

the Agile Manifesto is a far too specific definition of how to be agile.

For defining Agility in Software Engineering we should focus on the goal of Agile rather than on the misleading way suggested by the Manifesto: Please read

and work according to the following definitions:

Developer's Definition of Agile:

Agility means to have a process in place that will allow us (and urge us)
to react on changing business requirements as soon as possible:
Accept that the project's goal is a moving target.

Project Manager's Definition of Agile:

Agile Project Management means to have a process in place
that is to maximize team efficiency,
user satisfaction,
and maintainability of the product independent of specific persons.

Only Agile Software Engineering in this sense

can reduce TCO, satisfy the User,
and bring about commercial success for the developers.

NOTE: To accept that the project's goal is a moving target is no excuse for not to have an always up to date requirements specification. To have it is mandatory — especially if you promised a fixed price for the product to develop.


To accept that the project's goal is a moving target is going to cost money.

Only accept a contract where this money will come from your client.

Clients should understand that the developer's promise to promptly react on updated requirements is a value well worth to be payed for.

Suggestions to re-focus Agile in this sense are Agile Principles 2011 and the SST (Specify, Subcontract, Test) process for software development.

You may ask yourself how the above definitions of agile transform to a specific type of development process. A most appropriate answer was given by a taskforce advising the British Government:

Agile means adopting an approach to IT that emphasises flexibility, responsiveness to change and innovation. This is achieved through modular and iterative development based on user involvement and feedback:

Compared with traditional tools and methods, agile offers a fundamentally different approach to tackling business problems (see the picture below): Where the traditional approach favours complete solutions developed in a linear fashion, agile encourages a modular approach using short iterations to learn and adapt. Instead of trying to lock down requirements and minimise changes up-front, agile encourages continuous experimentation, improvement and reprioritisation. The approach to user involvement also differs fundamentally. The traditional approach favours heavy user engagement up-front to determine and lock down detailed specifications and at the end to test the final product. In contrast, agile embeds users in the process for the duration of the project, making them an integral part of the development team rather than a constituency to be consulted.

Always keep in Mind:

The Agile methodology is meant to deliver IT projects flexibly, in iterations.
It's meant to involve customers more directly and adapt quickly to their changing needs.
This means the final system only emerges gradually.
It means customers don't pay a fixed price for a complete project:

They pay for a commitment of resources.

Gone are the days when we contracted to develop a large piece of software and then had to wait months or even years for a fully tested and fully functional application to be implemented. Agile design, that is designing software in smaller pieces, is rapidly becoming the standard. In an age where technology and also requirements change so rapidly, itís vital that an application be implemented quickly and can be adapted as it grows. In the information age, a year can be a lifetime.

Becoming agile isnít about using this method or that method.

Its about creating solutions to guarantee a businessí leadership.

And never should agile development be confused with a specific project management technique (e.g. SCRUM, KANBAN, etc) or with specific techniques (such as those described or referred to in most books or blogs on Agile or in Joel's list of 14). The fact that most programmers do confuse Agile with agile techniques — especially with techniques recommendable for small projects only — is a serious problem.

Agile is not a specific process. Agile is about the collective state of mind of the team and an organization as a whole:

Being Agile means that you are open to change. That you embrace change. That you promise to be flexible.
The true Definition of Agile The better Definition of Agile

Software Projects Uncertainty Relation — Why we need to be agile.
Wissenswertes zu "Agile Software Development best Practice" zusammengestellt durch Gebhard Greiter.
tags: Agile1gegreit Manifesto1gegreit Definition1gegreit

Agile . Manifesto . Definition  :  News?


Use SST to guarantee Success

Comparing two Process Models for Software Development
Agile Software Development — the SST Version

Best Practice Software Development Process is SST — avoid Extreme Programming

Agile Software Development (as defined by the Agile Manifesto) is both: a step forward, but also a step backward (see e.g. what Gartner found). Though it is — without any doubt — true that the classical waterfall models for the software development process are too rigid for the fast moving world of today, implementing agility as suggested by the Manifesto or by XP is not the right thing to do. Better ways must be found, and so more abstract definitions of Agility came up: [en], [de].

SST can implement them without throwing away what we learned up to 1995, i.e. before the need for agility became more and more obvious:

Comparing two Process Models for Software Development

SST is the one we recommend

Please note: SST is to be understood as a spiral process (rather than as a strictly waterfall model) because Requirements are allowed to change (though strictly controlled by change management). To have a change management process in place is necessary at least in projects creating software for a fixed price.

What in XP is achieved by Pair Programming, SST achieves by stipulating that Design and Code should be created by different persons: The programmer is seen as the designer's subcontractor.

SST also recommends that code implementing a given design should be tested – from a black box point of view – by the author of the design (he or she will know better than any other person whether the design was implemented correctly, and so there is no need for a third person to learn the design). By the same principle the Requirements Manager — who in SCRUM is called the Product Owner — should be responsible for acceptance test.

When choosing a process model for your own project, please convince yourself that you know precisely where in the spectrum between XP and SST you want it to be (and for what reasons exactly). I recommend:

XP is dangerous — always use SST

Combine SST with FDD (to have results as soon as possible).

Extreme Programming (XP).1Specify, Subcontract, Test (SST).1
Extreme Programming (XP).2Specify, Subcontract, Test (SST).2
Extreme Programming (XP).3Specify, Subcontract, Test (SST).3
Extreme Programming (XP).4Specify, Subcontract, Test (SST).4
Extreme Programming (XP).5Specify, Subcontract, Test (SST).5
Extreme Programming (XP).SummarySpecify, Subcontract, Test (SST).Summary

Note: The benefits of Pair Programming in XP
are achieved in SST by stipulating that Designer (= Black Box Tester) and Coder should be different persons.

Each SST cycle is to produce

one single, specific Software Release

consisting of at least the following — always up to date — deliverables:
  • Requirements Specification (responsible: Product Owner and/or Requirements Manager)
  • Architecture and Design Specification (responsible: System Architect)
  • Code
  • Test Result Documentation (responsible: Quality Manager)

Please note:
  • What we call a Product Owner is a Requirements Manager representing the customer.
  • More competent System Architects also guarantee

    • a high degree of testability
    • a high degree of test automation
    • and therefore a high degree of maintainability (for code as well as all the specification documents).

  • Documents should be acessible in (automatically generated) HTML presentation, so that consulting them is as easy as possible.
  • Quite an important part of the environment needed to maintain the product is a suitable Issue Tracking System.

Interesting is also the following picture (published 2002 by Barry Boehm):

In the sense of this classification, the FDD SST process is aiming at a Milestone/Risk-driven model.
Wissenswertes zu "Avoid XP: Be agile with SST, Process Models for Software Development" zusammengestellt durch Gebhard Greiter.
tags: SST1gegreit Requirements1gegreit Process1gegreit

SST . Requirements . Process  :  News?