Phy-gital Roundtable: Breakfast Roundup from Germany and Netherlands

02 May '15 | Debjyoti Paul

German Shoppers: Meet Them in the Fast Lane to Phy-gital

15 January '15 | Ralf Reich

Shoppers Will Share Personal Information (But They Don’t Want to be “Friends”)

15 January '15 | Anil Venkat

Modernize or Perish: Property and Casualty Insurers and IT Solutions

14 January '15 | Manesh Rajendran

Benelux Reaches the Phy-gital Tipping Point: Omnichannel Readiness is Crucial

13 January '15 | Anil Gandharve

The New Omnichannel Dynamic: Finding Core Principles Across Industries

13 January '15 | Debjyoti Paul

Technology does not disrupt business – CIO day 2014 Roundup

02 December '14 | Anshuman Singh

Apple Pay – The Best Is Yet To Come

02 December '14 | Indy Sawhney

Digital transformation is a business transformation enabled by technology

01 December '14 | Amit Varma

3 Stages of FATCA Testing and Quality Assurance

06 October '14 | Raman Suprajarama

3 Reasons why Apple Pay could dominate the payments space

18 September '14 | Gaurav Johri

Beacon of Hope: Serving Growth and Customer Satisfaction

05 August '14 | Debjyoti Paul

The Dos and Don’ts of Emerging Technologies Like iBeacon

30 July '14 | Debjyoti Paul

What You Sold Us On – eCommerce Award Finalist Selections

17 July '14 | Anshuman Singh

3 Steps to Getting Started with Microsoft Azure Cloud Services

04 June '14 | Koushik Ramani

8 Steps to Building a Successful Self Service Portal

03 June '14 | Giridhar LV

Innovation outsourced – a myth or a mirage or a truth staring at us?

13 January '14 | Ramesh Hosahalli

What does a mobile user want?

03 January '14 | Gopikrishna Aravindan

Agile methods in stage-gated IT environments – Barriers

Posted on: 05 June '13

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.