For many years wearing developer, programmer, and product manager hats within various software companies or within companies that required software solutions, the idea of Agile and SCRUM just seemed wrong. Of course after the massive overruns and poor end products resulting from the hierarchical UML based ‘waterfall method’, a new flexible methodology was needed. The name ‘Agile’ was given because it needed to be flexible enough to suit the UNIQUE demands of any and every project. Any strict rules-based methodology, even SCRUM has to be wrong because such rules are always contextually based. Each company, project, team, situation and their resources are completely unique. So if the rules have to be created for each ‘project’ and not follow some predefined ‘rote’ system, Agile Methodology therefore should have as few rules as possible. What’s more, the rules can only be created effectively and be applicable and useful by looking at each project holistically. You can’t just follow a prescriptive path.

Agile as a process control technology is simply analogous to a biological or electronic feedback mechanism or even Stimulus-Response behaviour in learning theory. So..

• 1. Find out where you are
• 2. Take a small step (action) towards your goal
• 3. Measure the result (response)
• 3. Adjust your understanding (behaviour) based on what you learned
• 4. Repeat

But, for this to work we need to know our clearly defined goal.
If the result of our action is an error then:

• what is its proportion
• How do we re-integrate the error into our existing knowledge (paradigm)
• What is the differential step required to bring us back to our goal

In software terms, rather than biological, behavioural, or physical, how do we proceed:

• When faced with two or more alternatives that deliver roughly the same value,
  Take the path that makes future (code) change (and development) easier.

That’s it, nothing more… Nothing else is needed other than the necessary common-sense execution skills (design, planning, programming and communication).

There is no need to make an industry out of AGILE and SCRUM and complicate it with rules and diagrams, with certification, training programs and other controlling and money making ‘needs’ of the software ‘industry’. AGILE is not a state but a process. You can’t apply a generic state to a fluid process.

Dave Thomas’ lecture spells it out nicely…