The Three Feedback Loops of eXtreme Programming

With all my talk about Kanban, people might think thats all I use to help clients be successful.

Nothing could be farther from the truth, whenever I run delivery projects I whip out the technical practices in full force.

eXtreme Programming becomes my reference in these cases. I certainly dont think I'm doing anything to move eXtreme programming into new places, but thought Id share some visuals I use to communicate XP to unfamiliar audiences (yes they do exist).

The Three Feedback Loops of eXtreme Programming

For me eXtreme Programming is all about feedback. When done well, everyone on an XP team knows when something is broken, and they can immediately fix it.





Pair Programming
Feedback loop one is accommodated by pair programming, and by switching pairs. As a team lead I've never had more confidence of good technical quality then when I saw my entire team using this practice, its just so much easier to keep the style of the code consistent, the metaphors aligned, and to spot code cruft.

As a program lead, I am much more comfortable leaving daily decisions to teams that use this practice, I know my product is getting the benefit of the wisdom of the crowd. Critics point out that Pair Programming takes longer. I tried it for myself three years back. I conducted an experiment where The Observer had to ring a bell every time the Observer helped the Doer overcome a hurdle or make a decision faster than the Doer could have done on his own. The Observer was ringing the bell every 10 - 30 seconds. while not exactly science, it convinced me.

Test Driven Development

TDD is another agile practice that took me years to appreciate. While I started my agile journey with agile tools like JUnit and Cruise Control way back in 2001, I really was not following the TDD mantra.

I built lots of tests, after I coded, I often abandoned the tests half way through the project, and then started agian on the next project hoping to do better.

It took me years to evolve from Plain Old Unit Testing (POUT) to appreciating Test Driven Development (TDD). Once I got immersed I could never imagine going back



What makes TDD not just another test automation approach is a few key innovations:

1. Write the Tests first, they are your design spec and fine grained requirements all in one
2. They work because they are small, and match the design of well factored code, in fact TDD demands it or you wont keep up with your tests
3. You need to code, good tests demand SOLID OO engineering, not WYSIWG generated tests
4. Test, Code, then Design. TDD backed code is truly faster to redesign than most up front design work, code becomes like clay in the hands of a good TDDer.

TDD works becaus the majority of testing effort is applied at the micro level. Like all good architecture, reuse is enabled by creating fined grained tests that test fined grained code. When something breaks, you know what and where.

While high level tests have a purpose, they should be thought of as extra insurance, most errors are caught well before a macro test could fail.


Higher level tests can take advantage of Behaviour Driven Development, and extension to TDD that focuses on expressing requirements in a testable and automatable format.


Continuous Integration


Continuous Integrations helps synchronize across team members. Provided that TDD is working well, CI ensures that when code is checked in it is tested against the entire code base, packaged, deployed,etc. Any errors are sent to interested parties so that the team can swarm on the issue and fix it right away. Setting this up can take some doing, but i have always found it to be worth the effort.


In order to be successful with things like TDD and CI i found it necessary to focus on a parallel testing and build architecture. One that focuses on what tools to use, what level of tests will be built, how mocking and stubbing will occur, where automated runs occur, and other critical details. A good testing architecture is one that promotes the building of fine grained tests that can be executed quickly.