By Brian Lucas
At a recent social gathering a friend of mine, who works in the COBOL world, asked me, “So what is agile? Is it a methodology or a framework?” It gave me pause. I am always stunned in these days of agile’s popularity – coupled with the internet’s ubiquitous free information, when someone asks me a square one question. Instead of rattling off a standard answer, I looked for a deeper underlying meaning to his question. He is in fact a very good and intelligent person and deserved a thoughtful answer.
“Agile is, in its deepest and most profound sense, a philosophy of intelligent adaptation to constantly acquired knowledge and changing circumstances. Agile is solely driven and measured by business success. Agile is NOT simply a development methodology. Ultimately, all aspects of the enterprise from strategic planning to the most atomic level tasks must embrace agile for optimal effect.” People that are looking for a fixed methodology or a heavily controlled process for agile will always realize less benefit – if not experience downright failure. The key words here are adaptation and success.
I know a case of an agile team effort that rigidly followed a scrum methodology. Despite the fact that they actually achieved greater productivity, reduced development time and cost, improved user satisfaction and quality; this effort was cancelled by the CIO. He found that stand up, short, daily meetings without minutes, the lack of detailed user signed off requirements and everything about scrum, an anathema to his existence. So, even though the team executed the scrum method precisely, they and the enterprise failed to be agile. They simply didn’t adapt enough to be successful. In this instance, adaptation meant coddling an executive’s emotional needs for political reasons, an unfortunate reality, but a reality none the less.
What this experienced scrum master should have done was adapt her process. She should have taken it upon herself to create documentation and meeting minutes for the CIO. This would have satisfied his need; even though it was illogical. She could have done this while she insulated her team from the kind of inertia that this level of documentation generally creates. Eventually, the CIO was let go, but the company’s agile effort was set back years and they are still struggling with it today. The goal of agile is to get from point A to point B in the quickest, most effective and efficient manner. To GET from A to B, you need to adapt to whatever the circumstances and environments you find yourself in – even obnoxious and difficult, but politically powerful people.
Research shows, as seen in the following diagram, that agile has left its infancy where initiates prosaically follow an idiosyncratic process. It has graduated to a level of mastery, where practioners are comfortable enough with the concepts to customize and improvise agile methods to meet their own individual needs.
For example, one adaptation to extreme programming that I have suggested to several companies and they have enjoyed success with, is a concept for paired programming I humorously call, “RAT”. This stands for Responsibility Assurance Transference. (RAT was a moniker suggested to me by a friend, who is a “master” agile developer, during a scotch tasting event where I was a guest speaker. On general principles, I am opposed to derogatory terms, but the scotch won out that day and most others find it funny). In RAT, developers are paired by similar experience and expertise. Each developer in a pair is responsible for the quality of the other developer’s code. This forces developers to get religion and seriously review the other person’s code and make sure they understand it thoroughly. If a bug occurs in production, it is marked against the reviewer and they are known as a RAT.
One company even made up RAT signs and clipped them to the offending reviewer’s desk until the bug was resolved in production (I am not advocating this – just reporting it. This company also “gongs” team members during daily scrums when someone drones on, which is a practice I am also not sanguine about, but it works well for them.) Companies that have taken the “RAT” concept to heart have told me, not only do they have substantially fewer software defects, but the coverage for development work over vacation or illness has become incredibly smooth.
Strange as it may seem, none have reported that this concept is time-consuming to implement. Developers end up working more closely with each other. RAT encourages them to continuously review and share information. Normally developers wait to the end of a program’s development cycle, when the complexity is the greatest, to become acquainted with someone else’s code during a formal review. In RAT, when junior developers are paired, a senior mentor from outside the team is assigned to work with both of them. This concept can be applied equally as well to my friend’s COBOL world as to a C#/Internet or any other environment.
So for all you purists out there, remember that an impure, successful agile effort is better than a pure, unsuccessful one. The important thing is to gain an agile foothold by adapting to whatever environment you find yourself in and level set management expectations appropriately. I am not saying you should do a waterfall process with a set of brief meetings each week and call it agile. There is no point in that, but there are a number of adaptations and combinations you can make to agile to meet limitations that exist in all enterprises. In agile, one-size-does-not-fit-all, nor is it intended to. Well, let the blog begin and remember to keep agile!
 As a colleague of mine, Brad, who just happens to be an amateur military historian noted, the idea isn’t original. It’s a concept from basic training in the military, and goes back at least to Frederick the Great’s army. The Prussians would pair off soldiers, a veteran with a new recruit, so the vet could pass on everything he knew. Also, reliable soldiers were paired with those who might be a desertion risk, under the idea that the reliable one might prevent the other from leaving. RAT differs however, in that it takes this concept and turns it on its side to promote the best possible quality out of a pair of equally proficient experts. A tried but true moral here is that history can teach us quite a lot, even in a technical age.