Skip to content

Agile 2.0

An reflection on agile (post-agilism).

ℹ️ Agile 2.0 (aka Smidig 2.0) was an initiative a few years ago where we (Objectware) attempted to counter the negative reactions around failing agile projects. In essence, Agile 2.0 is actually just as agile as "agile 1.0", but we attempted to distance ourselves from the cargo-cult atmosphere in various organizations. The message remains the same though: Be wary of fake agile.

Today, the agile community faces threats from non-agile communities by failing to deliver good solutions with regards to TCO, enterprise requirements and team skill and/or Cargo Cult. This is by itself not a weakness with the Agile manifesto, but if the community fail to address and solve these challenges, we fear that software development is forced back to non-agile practices. We are therefore motivated to do our part to ensure the continuing growth and success rate of agile software projects.

How to gain the most from Agile 2.0 in conservative organizations?

Questions

  • Which prerequisites must be in place before undertaking a job in a conservative environment?
  • The most important prerequisites have been met, and we strive to convince the organization to adopt new tactics/practices. What should we prioritize?|What should we prioritize
  • Gradual evolve a conservative organization or go straight for revolution?

Post-Agilism

We are not the only community that have seen these challenges. The following links are examples of other people which thinks as we do. Many call it Post-Agilism. We call it Agile 2.0, since we try to document what works and what does not and formalize this knowledge.

Collaborative Software Testing: Post-Agilism: Process Skepticism Collaborative Software Testing: Post-Agilism Frequently Asked Questions Paul Gerrard: Pretentious? Moi?
Are you part of the Post-Agile Movement? Post-Agilism Explained (Pretentiously) Post-Agilism - Beyond the Shock of the New

Introduction Tactics

  • Pain-driven approach (bottom-up) - illustrate why something is pain and suggest a solution that adheres to the Agile 2.0 principles.
  • Intellectual approach (top-down) - convince architect(s)/lead developers of the value of Agile2.0 principles by comparing pros and cons with the alternative approaches.

aka. Agile 2.0 when the organization doesn't even know Agile 1.0

Many developers lack the basics of agile development. Our customer are usually in this case, but also consultants are also victims of ignorance. We must be obvious of this problem. Many of the Agile 2.0 practices can not be comprehended before one has a basic understanding of Agile. Changing a plan/document-driven organization into a fully Agile 2.0-enabled environment is not usually within the time scope of our projects.

One possible solution is "controlled project". If we count for the architects, technical leads and/or project manager as well as at least one developer, we can educate the remaining part of the team. The ways of Agile can thereafter, slowly but surely, spread out to other parts of the organization when the infrastructure is in place and results and benefits are already documented.

Cost Efficiency

  • Return of investment within the first three sprints (2-3 months) of the first project, so you do not have to stretch the project cost or time line
  • Proven increased productivity and quality

Resources

  • Anything you can find on on post-agilism
  • http://www.exampler.com/blog/2008/11/14/agile-development-practices-keynote-text/
  • http://jamesshore.com/Blog/The-Decline-and-Fall-of-Agile.html