Robert “BJ” Reff is the director of Quality Control at Liquent, an organization that creates applications for pharmaceutical companies which enables them to track, research and submit information on FDA approved medications. On Lisa Crispin’s recommendation, I tracked Reff down at STAREast to pick his brain proceeding a session he had just delivered on Theoretical agile practices vs. real-world agile applications. For many organizations, finding new and creative ways to implement agile is welcomed and they are finding unique and intelligent ways to adapt the methodology to fit their needs — even in places where one wouldn’t think agile would be the methodology of choice.
According to Reff, agile can be applied to organizations that are regulated by agencies, such as his. The idea that the agile methodology won’t work in this kind of an organization is a common misconception within the software industry. Regulated industries and similar organizations are usually forced to adhere to restrictions, limitations and intense examination. As a result, these companies often exclusively reside in waterfall territory, but Reff feels there’s a place for agile within them.
Reff describes his session in this video clip from STAREast 2010
“In my experience, one of the major problems with the agile methodology is that people look at the process in line with what they need to accomplish and then they proceed to write it off, they brand it as too drastic a deviation from their organization’s accepted practices.” Management looks at the layout and examines the theory behind agile and decides that the principles are not applicable to what their corporate aim is.
“A lot of times agile is misrepresented as a lean way to create applications. Many believe this sort of construction isn’t suitable for regulated agencies such as the financial sector, government, airlines or medicine. These are all industries that exist in a world built around compliance and strict requirements. What I rarely hear is an organization considering modifications to agile so it can fit into their development.”
Despite often occurring in close quarters, agile and lean are very different. Lean in many cases, is the by-product of well-done agile. Through agile, waste, bottlenecks and other unnecessary hold ups become more obvious and easier to assess and repair. But there is more to agile than meets the eye and regardless of its surrounding hype, agile is not without flaws. There are problems with the methodology and with the people using it.
Reff identifies some of these problems as residing in unrealistic beliefs that many agilists harbor. They believe that agile will solve all of their problems. Others choose to believe that if they can’t facilitate the promise of fulfilled requirements, so the end result (agile or not) will be undeliverable iterations resulting in failure.
Many new agilists get stuck on the underlying principles and frustrate themselves in trying to fit agile into their traditional development process. A process they do everything to avoid branching away from; but that’s just it, agile is adaptive and should be treated as such. However, you shouldn’t just take anyone’s word for it. Qualify it, try it out.
Anticipated success or failure should not be based on what others have experienced, there is no proof without context. Comparisons need to be drawn. Two completed projects, one yielded in waterfall and the other in agile. Examined them side by side, then you can make an educated decision on whether agile is a fix for your organization or just another fad.