I first encountered Agile in the 90s when I encountered some programmers from Caterpillar explaining to a jam-packed Birds of a Feather session at the OOPSLA conference about new ‘eXtreme Programming’ techniques they were developing. The concept was revolutinary: abandoning extensive specifications, long implementations and painful test phases in favour of doing a little at a time: a partial design, a partial implementation, a partial test, a delivery, some customer feedback, and back to more design.
And with that idea came some other revolutionary ideas: programming in pairs could be more productive than programming solo; keeping to a focused eight hour day could deliver more than working eighteen hour days; concentrating on effective communication could be more efficient than perfecting specification techniques. To someone who had devoted five years to learning heavyweight design notations, this was heady stuff. And perhaps the headiest point was the idea of self-organising teams. The software delivery team had the power to decide what worked best for their team and their particular project.
And in its early days eXtreme Programming and other forms of Agile did deliver remarkable things. Those of us who adopted them found we really did have competitive advantage over those using more conventional techniques. But to survive, the Agile movement needed to become mainstream; to use the ideas of Geoffrey Moore it needed to ‘Cross the Chasm’ and appeal to people who wanted only an incremental improvement over the formal processes that had gone before. And so entered Scrum. Scrum provides an answer, a single ‘one true path’ for its practitioners. It has a strict set of rules. And it is the same across all projects. Scrum is a flavour of Agile targeted at those who like strict rules they can follow. And Scrum was very successful at making Agile mainstream.
For indeed many people are unhappy with the idea of making their own decisions; they want a set of rules to follow. No matter that the rules may not be suitable for their particular project or situation; if it’s written by an expert it must be right. And many such people use the label ‘Agile’ as a synonym for ‘right’. We hear their words “the agile way of doing it is so and so”, or see them producing a book that has “the right way to do it”. They demand one approach, one process, one way of working for everybody. And many organisations have fallen into this way of thinking. For some organisations – those with just one kind of project – it may even suit very well.
My experience has been very different. I believe that the set of practices that work best for, say, the initial development of a new mobile money product are unlikely to be suitable for, say, the business-as-usual maintenance of a telecoms product with dozens of variants and millions of installations. So I trust the experts in each team I work with to modify and re-invent their practices accordingly. This isn't abnegating discipline, though—far from it. Within each team, and over the course of each project, the team members must keep very firmly to the processes they've agreed, no matter what their personal inclinations might be. Self-organisation means self-discipline as well.
But I learned too that it’s impractical to rethink all practices for all developments. So, I suggest a set of shared practices which act as a basis for all your projects. These are the set based on experience running agile developments, to deliver working software to my clients’ needs reliably, economically and painlessly. They include iterative delivery, task-based estimation and planning, pair programming, issue tracking, time tracking, coding standards, continuous integration, source code control, a release process, project kick-offs, retrospectives, and many other best practices of agile software development (including ones from Scrum).
Individual teams will typically start a new project with these default practices, then vary what they do. In many cases the variation they choose may be successful enough to become the default. And thus we all learn and improve…
So, do I recommend a development process? Yes, in fact I recommend many. To quote a famous poem, "And—every—single—one—of—them—is—right!"
- Charles