Agile development is all the rage. Teedy Deigh introduces a popular variant.
The world of agile development can be an exciting and varied place, especially for a consultant. It can, however, also be a dull place prone to stasis, groupthink and no small amount of tree hugging. It is time to rediscover some of the hidden core values.
To assist in this brief journey of rediscovery, we can also break away from the hegemony of Scrum and XP by examining a new process for very small teams: WRESTLE. Like the common miswriting of Scrum as SCRUM, WRESTLE is not an acronym. However, it looks that little bit more impressive and slightly more technical for having the suggestion that it might actually stand for something. As we shall see, WRESTLE doesn't stand for very much, whether in terms of spelling, principles or patience. Indeed, it has an impressively low tolerance for anything.
WRESTLE fills an important and, of late, neglected niche in the world of software development process: the very small team. In the past, the soft spot for agile development processes was considered to be small to medium-sized teams, ideally collocated, and the question used to be whether it could scale beyond this. These days it seems that agilistas spend much of their time focusing on large-scale distributed development - so much so that some have been prompted to ask whether or not agile development is relevant to systems that are of modest size and teams that are not geographically scattered! The overlooked scenario in all these cases is the very small team of two developers. What agile processes are relevant to these teams? This is the question that WRESTLE struggles to answer.
WRESTLE's default team size is based on the fundamental unit of development, the pair, although it can be scaled up to four by using two pairs. A full house and beyond is seen to be the preserve of other less resource-constrained agile processes. But rather than treating a pair as a co-operative unit, WRESTLE believes that you get the best from developers by establishing rivalry and heightened tension. To this end, essential techniques such as mocking find a new and alternative expression in WRESTLE. Confrontation is normally carried out in a daily stand-off, but can also occur at other times, such as by the coffee machine, at the water cooler or in front of the taken-to-task board.
Embedded within WRESTLE is a deep respect for values of simplicity in design. For example, WRESTLE borrows and distils the central theme of 'patterns are an aggressive disregard of originality', simplifying it to just 'aggressive disregard'. The notion of merciless refactoring is generalised, so that broader decisions beyond basic refactoring are also taken without mercy or consideration. To get things started, developers are encouraged to do the simplest thing that could possibly irk.
Where some development processes are said to focus on exposing organisational dysfunction, WRESTLE is a little more resilient and seeks to distract from organisational dysfunction by providing a focus for the natural pent up dissatisfaction often felt in such environments (as well catering as for the general cynicism common among development types, regardless of the surrounding organisational mood and temperament). The traditional model of a developer as a solitary individual is also respected, with plenty of time given over to introspectives, email and code tweaking. Testing is most definitely left to other people and testers have no place on a WRESTLE team.
The heavy but dull focus on business value and the customer that seems to weigh down many other so-called agile processes is not present in WRESTLE. Instead, WRESTLE is truly agile because it liberates the developer from such constraints. Developers are free to tell the customer stories about what they may or may not have developed, and customers' schedules are pleasantly unburdened from frequent demos and discussions of requirements, so they are free to pursue other activities and don't have to hang around on-site.
WRESTLE is a young process, so some of the terminology has yet to settle. For example, timeboxed developed is said to be carried out in rounds, bouts or matches, depending on personal disposition and organisational culture. There is also a question of whether it would help to have some kind of dedicated organisation, such as a federation, to standardise terminology and to certify RingMasters, the official designation for project managers in WRESTLE. That said, the question has also been raised as to how much standardisation is needed of a process, especially given Parnas and Clement's insight: 'A rational design process: How and why to fake it'. It is indeed likely that most applications of WRESTLE will be staged for the benefit of others. If you know how it's fixed, it's a process you can bet on with confidence.
