Posted on February 17, 2012 by Arnaud BAILLY
Be agile. Or be Agile, with a capital A. What does this mean? Isn’t it just another “buzzword”, very much loved by the software world, a way of drawing the line in the “specialized” press, like they say? What does it really mean when all the big software houses declare themselves “Agile” and recruit many “ScrumMasters” and “Coaches XP”? What could this mean for a small company like PolySpot?
I have no definitive answer to this question, of course, but I would like to try some partial and highly personal answers, rephrase the question: what should an Agile method of development be for me, and how to apply it for PolySpot?
Being agile is not a final statement
This is not something that one acquires once and for all, like a diploma or a marshal’s baton. It is a state of mind, the acceptance of a permanent process of transformation that changes, radically and forever, the vision that we can have of what is software, what is the code, what is a team. It is not about something mystic, a revelation only for a chosen few, of course, but it is one of the first myths that I must destroy: no, the agility, the agile methods are not reserved for an elite group of developers; agility is for everyone. Just choose the change, a simple change in perspective that Jerry Weinberg describes, in his Systems Thinking, as cultural transition: moving from a culture of hacking or routine, to a culture of conscious reflection on the product and process.
At the broadest level, that of the behaviour of the product development, this means understanding our fundamental inability to control the process of development, simply because this process is far too complex. Instead of this model – Command & Control – which is perfectly embodied in the abuse of Gantt and Pert charts by some planning tools – ah! the exhilaration of the project leader detailing daily the project schedule involving 100 persons on 3 continents – we find the Inspect & Adapt paradigm, “popularized” in certain circles under the name PDCA (Plan-Do-Check-Act) from the work of E. Deming. A common comparison (I think having read it the first time in a book of Poppendieck) is that of a journey from Paris to Marseille by train and by car: developing software, and even a product, is a very nonlinear process, with obstacles, necessary stops, workarounds, surprises that require the driver to adapt permanently all through the journey.
But this being said, actually nothing was said: it is through actual practice, on a daily basis, in the team, that the Agile approach comes into its own, becomes a reality. A reality and credibility which fades away rapidly in the absence of tangible actions. And for me nothing can replace the return to the roots of agility, i.e. eXtreme Programming such as Kent Beck pioneered in the early 2000s. It is these practices that form the true foundation of agility, rather than methods of project management, because these practices are the ones that go to the core of the matter: the software, its code, the relations between the people who write it. Thus, I allow myself a brief overview of these practices, before concluding what PolySpot, its clients, partners and community can expect from this.
Kent Beck identifies 12 practices (13 according to sources) that make up XP and form a coherent group. Here is a brief catalog:
- User Stories: Detailed cases of use or specifications, XP aims to identify the stories from the needs expressed by actors involved in the system. A story is, in the famous words of Beck, “the opportunity of a conversation” between the user (or his representative) and the developer(s), conversation that will lead to the definition of cases of automated test defining precisely, by way of examples, the expected features of the system;
- Pair Programming: Probably the most controversial practice of XP, but certainly the most fundamental one. All developments are made in pairs, which leads to improving code sharing in the team, communication between its members, removes the need to do code reviews, and more generally improves the quality the product and the process through constant interaction and scrutiny by pairs;
- Planning game: A meeting that takes place as necessary and involves all team members. The stories are discussed, assessed and ranked in order of priority and/or risk;
- Collective Code Ownership: All the product code belongs to the team, there is no reserved area and everyone has the opportunity to comment and modify any fragment. This is possible because the code has versions and the pairs switch often enough to become acquainted with every part of the code base;
- Whole team: The team that is formed not only of developers, it includes also testers, users, system administrators and generally all persons needed for the successful completion of the product, up to and sometimes including production;
- Continuous Integration: The code is continuously compiled, assembled and tested so that at any point in time there exists a working version of the product, removing the need for a dedicated integration process (code freeze, QA gates) done urgently at the end of cycle development. This process is automated by default;
- Retrospective: Regularly, the team reflects on the way it works and try to improve;
- Deliveries in small increments: Because the code is integrated regularly, its quality is checked by tests, stories identify clearly its features; the product is delivered regularly in small increments, rather in big batches involving lengthy and complicated migration processes;
- Coding Standards: Team shares and maintains coding standards that everyone understands, monitors and try to improve, in order to ensure maximum quality of the code and to facilitate the understanding of all its parts by all members of the team;
- Simple design: The code is designed in the simplest way possible to facilitate its understanding and its evolution;
- Test Driven Development: Another controversial practice of XP, all written code must be preceded by a test (automatic test) expressing the expected functionality, a test that evolves together with the code, ensuring that it will not regress and facilitating the refactoring;
- Refactoring: The code is permanently reviewed, modified, reworked in order to simplify, clarify it and eliminate the duplication that it could contain;
- Metaphor: The product is built around some key concepts and relationships that facilitate the definition of derivative concepts and the implementation, this metaphor is shared and understood by all;
- Sustainable development: The pace of work must be such that the team can continue indefinitely without wear.
Better adapted software, improved working comfort
Clearly, these practices are not universal, we are not talking about a recipe to apply for success in everything (remember: “There is no silver bullet!”). But I know that these rules work for me and that they work for others, that they allow, when applied with open eyes and brain on alert, to produce faster a better adapted and better software while significantly improving the working comfort of the team.
The key here is discipline. If it is another myth I want to fight, it is the one who identifies the agile methods, at best a happy mess and at worst a dangerous chaos for hackers. Agility requires more discipline, not only individual but also collective, more self-sacrifice for the group, the rejection of the hero culture, constant and relentless pursuit of excellence, the reconsideration of its beliefs and the acceptance of its limitations, the assumption of responsibility and team spirit.
This is an ongoing effort, and moreover for those who are themselves their price because most of the time these offers are hidden, concealed under an apparent simplicity and ease.