July 21st, 2014
by inflectra
Extreme Programming (XP) is one of the more popular Agile Development methodologies, and for very good reason. It advocates short, rapid iterations, constant customer contribution and frequent testing. But let us consider the foundation of Extreme Programming, which is to identify all the positive aspects of software programming techniques and take them to their extreme; the idea being that you can’t have too much of a good thing. For example, if tests help find defects, why not test all the time?
If we consider Agile methods generally, (not XP specifically) to also be a combination of good ideas, XP would tell us to take those ideas to their extreme; could we do that and create “Extreme Agile Programming (EAP)”? Or would we be trying to swallow our own tail? Let’s consider some Agile principles and find out.
Incremental/Iterative Development
Agile processes embrace incremental and/or iterative development. If a software product is being built up incrementally the only way to increase the ‘incremental-ness’ would be to increase the number of iterations. So, can we take iterative development to the extreme? Increasing the number of iterations would require each of the iterations to be shorter and thus the tasks would need to be smaller. However, tasks can only be so small before they achieve too little to warrant the supporting effort that makes an iteration work. With two to four weeks being the recommended iteration length for most Agile methods, this lower limit of effort to gain benefit has probably been met and so incremental and iterative development have already reached their extreme.
Early and Frequent Testing
Next we have early and frequent testing. The earliest that testing could be performed would be right after the code is written: before that there is nothing to test. However, the tests can be written before the code and then the code written to pass the test – a sort of reverse-time approach. This is called test-first (or test-driven) development and it is already part of XP. So, testing early is already as extreme as it can sensibly be without use of a TARDIS. How about testing frequently? Agile methods require that software is regression tested as part of each iteration, which is how often the code base is modified. To run any system level or integration tests more often would be to run the same tests against the same codebase which would not make much sense. But, individual code elements can change multiple times during an iteration and so unit tests could sensibly be performed multiple times per iteration, in fact with each change. Not surprisingly, this is just what XP advocates.
Customer/Stakeholder Involvement
How about customer or stakeholder involvement? The most extreme expression of this would be to have the stakeholder constantly involved, meaning all the time. And again, Agile methods already require this, in some form or other.
Agile Requirements Management Practices
Can we make the Agile requirements process more extreme? In most, (but not all) methods claiming to be Agile, requirements are expressed at a high level in some kind of user-story form and only evolved into something more definitive as they are selected for the next iteration. Is this already at the extreme or can we take it further? Could the requirements be defined to a lesser degree than is currently the practice? This would probably mean doing no work at all before to understand the customer’s problem before coding begins. While this may have appeared to be the case in some projects, I am sure it was never intentional because to not understand the problem space at all would be to start a project with no idea what is being built; the ultimate black box project!
So, if we still need some degree of user stories to have an idea of the problem space, would it be possible instead, to evolve those ‘sketches’ of the problem later in the process than we do in Agile projects now? In most Agile methods, requirements refinement is wrapped up in the design activities or test creation in the test-driven method, so we couldn’t do it much later without making it part of the coding process which would require the stakeholder to sit with the software engineer as she actually writes the code, (another form of customer involvement to the extreme.) However, this is clearly impractical unless only one software engineer is working at a time, or there is one customer for every software engineer. The requirements process is seemingly as extreme as it can be.
We can conclude from these considerations, with a fair degree of confidence, that extreme programming principles cannot generally be applied to Agile processes because they are already as extreme as they can be and still remain workable. While some of the actual XP practices, such as pair-programming, may not be part of all Agile methods, the basic XP principle of good ideas taken to their extreme already exists in most Agile processes.
You may also be interested in:
Scrum and Kanban - Siblings or Cousins?
Agile Techniques in Maintenance Environments
Agile is Nothing New
Documenting Requirements in Agile Projects
Agile
Extreme Programming
XP
Test-First
Requirements
Iterative
Incremental
SpiraTest
SpiraTeam
SpiraPlan
RemoteLaunch
Rapise
KronoDesk
TaraVault
SpiraCapture
Cloud Services