Although I think Agile methodologies yield better results than serial ones, there are some aspects which are not explicitly addressed. This is my subjective list of these issues:
Mixture of feature development and maintenance
Many companies have large, legacy systems that need both new features and maintenance to address bugs. Most agile textbooks and papers only talk about greenfield software development or new features only. Many companies (in some regions) do not even start new projects and have to integrate agile into the combo of new features and maintenance. For maintenance, I feel agile does not really offer a reasonable alternative in some cases.
Of course, one can use sprints for tackling bugs. However, fixing bugs in a large, complex codebase can be very time consuming. Due to this, two weeks sprints may not be delivering as much value as they should be. Also, when bug fixes are extremely important to ship, two week sprints may be too long. The delivery of emergency patches, in a matter of days, is pretty hard to integrate into the well-known agile universe. Bugs are also hard to plan, they can come at any time, so a sprint planning meeting can not cope with such uncertainty.
One partial solution could be assigning some teams to solve bugs while the rest delivering new features, provided that the bugs are not extremely urgent. This, however, can be problematic, as bug solving teams can be locked up in maintenance work, which can cause early team members’ burnout.
Hire the best talent
The textbook suggests that an agile organization should aim for smaller, but more talented teams. In theory, this idea makes perfect sense, but in real life situations, this may not be possible. Only very well known companies with high reputation can afford to be “picky” enough for this. In my current company (a firm that believes in agile values) we have been trying to fill two positions for more than three months now, without success. However, our case is somewhat fortunate, we can cope with the workload and don’t have to hire someone just for the sake of hiring them.
Finding the best talent is also really vague. Who do we consider talented? Someone with the capability to acquire new skills? Someone knowledgeable in several programming languages, frameworks, and libraries? Everybody understands “talent” in a different way, as it is a relative term.
Customer value. All the time
From time to time, it is not easy to deliver customer value. Let’s take Twitter as an example. Twitter used to be written in Ruby, but after the application became really popular in 2012, massive scalability issues have arisen. As an answer, Twitter’s engineers switched from Ruby to Java to solve scalability and performance issues. As a result, the system managed to cope with the US election in 2012. Changing libraries and languages does not lead to direct customer value. Had Twitter stuck with Ruby, the user experience would have degraded considerably; however, at the time of the switch, there were no issues yet. Hence no direct customer value was provided.
The textbook mentions scalability and performance issues, but only at the beginning of a new, greenfield project. In these days, it is hard to plan for the volume an application has to cope with. Nowadays, every day a few startups take off: some of them may become famous, others fail. However, the most important metric is time to market; there’s no time to plan with millions of transactions per second, those problems have to be sorted out as time goes by. User value may not always be possible to ship.
Agile in large, traditional companies
As mentioned before, agile books usually revolve around greenfield projects. A major problem is how to port agile values into large, traditional organizations so much of these values are preserved. Let’s take a telecom company as an example, like Ericsson. Software development units can be agile, however, from the point of view of network operators it is not desirable to roll out new software every two weeks.
To implement full agile, Ericsson would have to convince all the network providers to be agile enough to roll out every time new features are ready. However, in such organizations network downtime may affect thousands of users, and software upgrade comes with downtime. Also, a fault slip-through may have even more severe consequences.
This might be only my personal experience, but I’ve never seen a transparent, agile project, where not only sprint but a product backlog is kept and updated. In my experience product managers give in very quickly to all the requirements, pushing the work on development teams.
When clients demand new features, many product owners treat those as a top priority, making the product backlog a huge mess. Not to mention that these backlogs are not transparent across the organization: development teams usually know the current sprint backlog only, or one or two sprints ahead, but nothing more.
However, I think this is not an issue in the model, it is a problem in the implementations. The textbook offers several ways of overcoming this problem, but many companies never get any further than implementing two weeks iterations; I personally have never seen an organization where upper levels followed the agile practices too. But again, this is a personal experience and not a fact.