In my previous post, I shared six reasons for adopting Agile in enterprises. In spite of those reasons, several IT organizations in North America, Europe and rest of the world have not initiated Agile adoption. Why? This is not because they have not heard or learned about the benefits of Agile methods. This is because of factors related to organizational culture and several myths and misinterpretations on Agile. This blog post is to present three barriers that I have come across in several situations.
Our projects are not suited for Agile!
“Our projects are not suited Agile! This is because we document all requirements and get sign-off from business users. Agile is applicable when requirements evolve or change frequently.”
Sounds familiar? This is because of gross misunderstandings on Agile methods as well as software projects. When this happens, I emphasize and share my experience on the advantages of demonstrating meaningful solutions to business users over short iterations. I explain how this helps in eliminating the risks of big bang integration and extended user acceptance phases or huge schedule and budget overruns. Also, I initiate discussions on the ground realities in software projects and establish the fact that requirements evolve even when we document all requirements and get sign-off. In enterprise software projects, requirements analysis phase is not 100% done even after the ceremonial sign-off. We may see one or two exclusions once in our life time!
We cannot say ‘No’ to documentation!
“We create several documents. Some are required to comply with our internal IT processes. The rest are for regulatory compliance. Agile means no documentation. Our document-driven culture does not help us initiate Agile adoption!”
This is also familiar. All said and done, regulatory compliance is mandatory. However, don’t we have to deliver meaningful documents and maintain our documents in order to ensure that they are up-to-date to serve the purpose? Agile does not say ‘No’ to documentation. When we create piles of documents that are never read by anyone other than the author and the reviewer, we end up destroying value. Isn’t it obviously a better approach to create documents incrementally that serves the purpose? It is possible to introduce Agile practices and satisfy both internal and external, or regulatory requirements on documentation.
Testing starts only after development!
“Dev and QA are two different organizations here. We complete the development phase and start testing. QA team has a separate budget. Agile methods and practices make sense but don’t seem to suit our environment.”
This is the third thing I hear. I understand and appreciate this. However, when we resolve to carry on with this status quo, it is going to be tough to sustain. Historically, several months of software development followed by a testing phase deprived project teams from knowing the real status of progress and measure of quality. This resulted in schedule and budget overruns as well. Cross-functional teams working in short iterations provide for high level of visibility, and predictability in software projects. It is worth identifying one or two projects for Agile adoption.
There has to be a concerted attempt to identify and remove barriers rooted in such factors in order to initiate Agile adoption and sustain it in a long run. Have you come across additional barriers? What are those? Let us discuss.
In my next post, I will continue this topic and discuss about what it takes to bring business users and IT teams together in forming cross-functional teams.