Traditional versus Agile methodology

What’s the difference between traditional methodology and Agile methodology? A meditation on the paradox of Agile methodology and what psychologists term ‘locus of control’.

  1. Traditional methodology submits the development process to control by artefacts – procedure, standards, tools, etc. That is, it turns developers from engineers into instruments of the process, and so insists that developers must be
  2. The goals of traditional development are also defined by artefacts – typically requirements, which are simply fed to the development team for processing. Goals are never discussed and developers play no role in setting, negotiating or interpreting goals.
  3. In other words, in traditional development the locus of control lies in the methodology itself.
  4. Agile methodology, by contrast, enables individuals and teams to take It consists not of a machine to process the work, within which the developers are simply cogs, but a toolkit developers can use if they find it useful.
  5. Agile’s goals are also exposed to the development team. Within the development process it defines its goals in terms of high-level stories that include their own purpose, and organises development around a user/developer unit authorised to debate and challenge these goals.
  6. Also, Agile as a whole defines a suite of values (in the AgileManifesto) and overall methods (in the Agile Principles) that place full discretion about how development will take place in the hands of developers.
  7. In other words, Agile methodology moves the locus of control from the methodology to the individual and teams who use it. And it does this at every level.
  8. So in Agile methodology, defining a suite of artefacts (procedures, roles, etc.) amounts only to offering a selection of methods, tools and techniques that have previously proved useful in similar contexts. It is not a demand for compliance or subordination.
  9. Furthermore, a methodology can only be Agile if its artefacts include higher-level artefacts that include higher level activities, culminating in defining top-level Agile goals to which teams can subordinate the methodology.
  10. These include goals such as optimising the content of delivery in terms of value and sustainable pace; and optimising individuals’ and teams’ ability to achieve their goals, such as the development of professionalism, technical expertise and self-discipline.
  11. Finally, an Agile methodology provides tools whereby the methodology itself can be adapted. For example, Backlog refinement provides for challenging the content of delivery, and Retrospectives any aspect of the teams’ working methods.

Ultimately, Agile simply assumes that developers are intelligent beings, because all intelligent activity is goal-directed and all intelligent beings are self-directing and self-developing. As soon as methodology departs from this, it ceases to be either intelligent or Agile.

By |2018-09-14T14:18:16+00:00Friday, September 14 2018|Categories: Agile, All, Empowerment, Methodology & lifecycles, Principles, Process and method, Waterfall|0 Comments

About the Author:

Chief Architect,

Leave A Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Want to do more than just build systems?             
error: Agile201 is wholly copyright and copy-protected.