Have big software firms been able to embrace agile methodologies for software development?

Agile methodologies for software development have become the buzz among most of the software firms. Teams working in agile, work in close collaboration with the customers, product managers or owners. Typically in an agile setup, there are user stories which should translate to a workable and deliverable piece of software at the end of the sprint cycle (sprint cycle is typically 3 weeks). The pieces of user stories which are not delivered as a part of the user story are classified as technical debt and are either carried over to the next sprint as another user story or classified as software bugs. There are demonstration days when the functionality of the software delivered over the sprint is presented to the customers or product owners. The customer or the product owners provide their feedback to the development teams  which need to addressed in the subsequent sprint cycles. Agile methodology has many great features like small cohesive teams, greater collaboration among teams & individual contributors and pair programming. Most importantly the end consumer gets to see the incremental progress to the final product more frequently rather than wait frustratingly over months (sometime even years) to see the finished product. 

The benefits of agile methodology are many. The emphasis of agile to involve customer feedback throughout the product development is its key salient point. Involvement of the end user's feedback leads to realization of software features which are more valuable in long term. The software developers, who are traditionally hidden behind their archaic cubes away from the customer interactions, are now involved more with customers or product managers which leads to creation of better solutions for the end customer. Also, the workflow of agile methodology is simple enough and there are plethora of tools available to make agile methodology easier to realize. Some of the tools like Trello (software project  management tool) and Yammer (discussion forum for greater collaboration) are open for use to general community and greatly facilitate agile software development. 

But has the software industry been able to migrate to agile methodology even after knowing its benefits?  In my experience, many software firms have not embraced agile in true sense. I have worked as a software engineer in Cisco systems Inc and Hewlett Packard Enterprise. In my experience such big software firms have not been able to embrace agile completely and comprehensively. I have seen agile methodology been practiced in smaller and more focused groups at these large companies. Embracing agile throughout the company has proved tough for larger software companies. Following may be some of the reasons for this:-

1. Moving to agile methodology to software development has proved difficult because of inability to train very large number of people and changing the tedious workflows which are more suited to waterfall model. Both Cisco Systems Inc and Hewlett Packard Enterprise are very large companies and training personnel and changing the archaic infrastructure , which is suited for traditional waterfall model, is months worth of effort. Given the competition in market, making such a shift  may not be a feasible move of these companies in terms of time and resources.

2. Cost to drive the changes in infrastructure to align to continuous integration is also sometimes challenging for big companies where one method for software development has thrived for so long. Agile practices like continuous integration requires many tests to be run for each code check-in, which may be difficult to support for a large software development teams. 

3. Inability to find the optimum number of weeks for a sprint cycle. I work in software development of network operating system. Industry standard of three weeks of a sprint maybe less for this industry as testing and refactoring on actual switches and routers takes more time than testing software for web applications. On the other hand having longer sprint cycles will eventually lead to larger time frame for customer deployment. Hence finding a workable and optimal sprint cycle time is difficult for the product managers.  

4. Dependencies across many feature teams leads to slower response time in larger companies. Since in a larger organization collaboration for developing features may involve a lot of teams, responses time for queries from the teams may be slower. This is counter productive for agile development where collaboration on daily basis is an essential requirement.

5. Inability of people working in traditional waterfall methology to change their mindset to adopt to newer agile practices. This point may sound hurtful to many people but that's the truth. The mindset of people, who have worked in one methodology,  is difficult to change when it comes to embracing newer workflows and methodologies. People usually get comfortable with the existing style of their working and usually resist the change which is influenced by the management on experimental basis.