When AGILE may not work
Ok, ok, I know what you may say: AGILE works all the time, anyway it’s way much better than this old grandpa WATERFALL. And you’re right in most of the cases, however…
Here’s what AGILE Manifesto, the cornerstone of this methodology, says:
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
And what if you deal with company or business process existing in regulated environment? What do I mean by regulated? It means that somewhere there governmental agencies or financial institutions are tracking everything is done within the area and they want to make sure that what is being produced complies with very strict (or not so straightforward) quality criteria?
Example? Pharma industry. In the US it’s regulated by FDA (Food and Drug Administration), in the EU by EMA (European Medicines Agency) etc. They control a lot of the aspects of R&D (Research and Development), Manufacturing, Supply etc. And when I say “control” I mean that they have a list of recommended practices (related to documentation, organization of employees’ daily routine, segregation of duties and so on and so forth) which companies selling products on certain territories must follow and they can inspect them any time to make sure that everything is done in accordance with their codex. If not, many bad things can happen: penalties, products calling off from shelves, reputational damages, prosecution, you name it. The reason for that is clear: one mistake in formula or wrong temperature regime during distribution and you can get a poison in your vein instead of a medicine.
“So what?” you’d ask… “Why AGILE is no good for it?”
Well, I’m not saying it’s not, I’m saying that implementing it in such companies might be challenging and definitely before doing that management needs to dot the i’s and cross the t’s. There are several main reasons for that. Otherwise, you risk to get this:
Documents, documents, documents
Regulators (those guys from FDA, EMA and other organizations) require very thorough documentation to be created covering of what you do (not 100% of what you do, but in certain areas for sure). And that is also true when it comes to creation of IT solutions which supposed to work with critical data, automate your tasks in regulated processes, manage factory equipment, visualize data which may impact safety of patients or quality of product etc.
Some people in PHARMA IT saying that 1 day of development requires 4 days of documentation. Read it again… Now, let’s look at AGILE Manifesto one more time, precisely at this point:
Working software over comprehensive documentation
It’s a bit controversial in situation I’ve just described, right? Can you imagine 2 weeks sprints where you spend 20% on actual product development and other 80% for documenting, testing and other validation activities?
​
More attention to toolkit
Not all areas are regulated so rigorously, even in PHARMA, but if they do, then you need to be very careful with tools you’re using there. For example, if you want to apply certain cloud solution to automate, let’s say, capturing and cleaning of data in regards to your products distribution, you need to make sure that vendor, providing you with this solution is compliant with regulators’ requirements. Often it means there must be an audit made on vendor’s side. It may complicate, delay or even stop the project (in case vendor is not willing to get though audit and share with you some internal documentation on how it stores and backs up data, for instance).
And let’s look into AGILE Manifesto again:
Individuals and interactions over processes and tools
I wouldn’t say that tools could be put on second place in regulated area. It doesn’t matter how good vendor is, if audit will start checking your IT infrastructure and it will be found that vendor storing and processing your data does not meet specific requirements, then it will be a finding…
Those are just some thoughts from the top of the shelve, but there are much more potential risks than I mentioned.
So, no party?(((
Does it mean that we’re doomed to sacrifice all benefits AGILE brings due to industry specifics? Nope.
Implementing AGILE in regulated environment is possible, but requires VERY accurate and reasonable approach.
AGILE evangelists must work with people who are responsible for quality of processes, including ensuring of IT solutions implemented comply with regulators’ demands. Historically, those quality guys are working with WATERFALL, they might not like a lot of changes AGILE will bring to teams’ routine (because all of those are to be controlled and its conformity to standards is to be ensured, you must be ready to advocate new way of doing things in from of auditors), so that might be a hell of a ride, but it worths it. On one hand, AGILE guys will optimize delivery process, make it more effective, but on the other hand, quality guys will balance it with secure level of formalization needed.
As an example, delivery might still be organized in iterative way (sprints) giving tangible results to business stakeholders to provide their feedback upon, but formal documenting and testing is not happening in the end of each sprint — for that you have special preparation sprints after development is done. So, it’s kind of hybrid between AGILE and WATERFALL: people see chunks of delivered functionality every sprint and you’re flexible enough to incorporate their feedback quickly, which guarantees that result will meet their expectations, but at the same time you’re still documenting and testing everything thoroughly to comply with industry recommended practices.