Scrum, Kanban, pair programming, XP: 10th anniversary of the signing of the Agile Manifesto
This week marks the 10th anniversary of the signing of the Agile Manifesto.
During the intervening decade, agile has gone from a disjoint group of practices taken from extreme programming (XP) to a mainstream approach of software development — if not the mainstream approach. Its success was due to several factors, the most important of which was that in embracing change, agile directly addressed the principal limitation of the waterfall model. In addition, the manifesto’s signatories were all established teachers and trainers and so they were accustomed to reaching large audiences to spread their message. These exponents infected their students with a kind of religious enthusiasm for some techniques that became the hallmark of agility and the bane of professionals using other approaches. Little by little, however, the core practices that underlay the principles — frequent releases, significant customer involvement, early and frequent testing — became part of how most developers approach their work.
During early part of this first decade, the focus of agile was on developer practices: pair programming, TDD, frequent check-ins, and continuous integration. These practices targeted the individual programmer’s role in the development process.
Then, towards the end of the decade, agile began to evolve to a more encompassing target: the process. Scrum and Kanban emerged as key practices and the qualities of lean manufacturing became the guiding values going forward. Agile now referred to team processes and the way the team interacted with the technology. The most recent step in this direction is surely the migration of continuous integration to continuous deployment,.
This was a natural and necessary evolution. The early programmer-centered practices were good, but not good enough to extend the revolution. Moreover, the practices were being corrupted or insufficiently applied. Among other practices that were unraveling was pair programming, in which two developers work side by side on the same code. Only one has a keyboard. The idea was that two programmers working together in this way would produce more, better quality code and so the cost of two developers working as one would be offset by the results. While there appears to be benefit to pair programming, it’s hard to quantify; and most sites that try it, ultimately give it up.
Process-based agile, however, looks like it’s here to stay. Organizations that try scrum, stay with it. Likewise, lean project management generally results in practices that are sticky; that is, once exposed to how lean works, organizations stick with it. These new directions must be expanded if agile is to break into one arena in which it has gained little traction: large projects with multiple large teams (more than 500 total developers). Five years from now, I suspect, we’ll know whether agile has breached the last redoubt of the waterfall model successfully.
Extract from Dr Dobbs.com
Last comments