All too often, proponents of certain methodologies want to claim that their methodologies are the reason for success, when in reality, the deciding factor was the skill and tenaciousness of the people involved, the presence of a clearly articulated vision that could be changed as needed but that was not written in Jell-O, and on recognizing the distinction between providing flexibility and fueling failures.
Agile is not, by itself, a methodology. The Agile Manifesto is a wish list, written primarily by programmers, in response to the incessant micro-management by non-technical managers who were in general too incompetent to learn about the technology that they managed. I cheered when I first read it (when it was published), nearly twenty years ago, even though I'd had enough experience in the field to question some of it. That's because I worked in the game industry, where a lot of the agile manifesto was self-evident. It was only later, as I worked with ever-larger organizations, that I began to see that, where agile was implemented in practice that it failed to take into account human nature in critical ways.
Agile proponents who contacted me after my most recent article frequently made the argument that Scrum, the most widely used Agile framework and one of the earliest, was not representative of true Agile. That may have been the case, though it's a weak argument that if anything lends more weight to the view that Agile is almost a religion. What I've seen in general is that a lack of a consistent vision, poor design early on, going for bargain-basement talent and the tendency to want to work towards a minimum viable product throughout the process has done more harm to projects than whether Scrum, Kanban, Spiral, or even Waterfall was used.
This is not to say that Agile is worthless. Agile legitimized the idea that all stakeholders must be involved in the process of shaping the product's constraints and parameters (something that even now is still more preached than practiced). It gave a voice to developers and (some) others in the production process who up until then often had little say, and its message to managers in particular about the need to trust in the competence of the people they manage is one that cannot be stressed loudly enough. Its emphasis on change management has spurred a lot of thought about the nature of change, experimentation and development costs in the field. And for all that, I think that certain Agile tools are a bit on the cheesy side, the idea of formalizing the process of development in such a way as to give creatives both the opportunities and the tools to shape and push back on design decisions is invaluable.
Yet, there are two key sets of problems that the Agile community faces. The first, and foremost, is that it decentralizes responsibility too much - it essentially punts on the whole issue of governance or editorial guidance. This is that whole vision thing all over again. Most people see editors as quality control people, but editors are stewards - they are people who serve to establish, preserve and modify a particular vision, and their role in that regard is roughly analogous to the movie director or software architect as given above.
Creatives, in general, have a love/hate relationship with editors, because editors by their very nature limit what a creative wants to create, but a good editor is necessary to make sure that multiple creatives are working towards a broader vision. In the media world, this means telling the broader story, in software, this means thinking about integration and protocols of communication. Agile empowers autonomous teams, but those teams still need to be able to pull together towards a common set of goals, and this means that sacrificing some autonomy for cohesiveness.
Agile also does not (ironically) distribute very well for precisely that same reason. Finding the balancing point between centralization and distribution is a difficult process. Organizations are becoming increasingly virtual, both at the individual and at the team level, and this is a trend that is only going to increase with time.
This is not a failing of the Agile Manifesto. It was very much a product of its time, fairly early in the history of the Internet, and after nearly twenty years, many of its expectations are beginning to seem ... quaint. Instead, it is simply a reflection of how much our way of working has changed in twenty years.
For instance, one of the key aspects of software development in the first place is in the realm of service application programming instructions (APIs). Documentation in the context of the manifesto was primarily focused on explaining intent - why was a certain function written, what was the developer attempting to do and so forth. Increasingly, however, such APIs are now written using the concept of self-documenting features, and the next generation will likely be considerably more discoverable than they are today. This opacity of how the application works today may seem to be a detriment, but in reality, the kind of deep-level documentation was done so seldom (and done so poorly) in the past that it didn't matter that the function was transparent. The next generation of APIs, likely built around knowledge bases, will be even easier to document automatically.
Similarly, git repositories and semantic knowledge bases also serve as a way to provide a capsule of the state of a project at any time, and not surprisingly, project management tools are now chasing after those repositories to better provide a more comprehensive snapshot of how a project is progressing. Additionally, these tools are extending out beyond code and into digital assets to such a degree that a natural form of integration seems to be taking hold in most organizations. Moreover, you're seeing the increased use of Machine Language-based classifiers and summarizers to better ascertain, for a given piece of content, how best to classify that content and provide some form of human-understandable description. This shifts the role of stewards to one of quality control and clarification of edge cases.
Finally, you're beginning to see the rise of context-free data, where the data contains its own descriptive metadata, which in turn translates into the ability for data to build its own UX and UI dynamically. To put this into perspective, when the Agile Manifesto was written, Google was a year old, Facebook, Twitter and YouTube were still several years out, and "the Cloud" didn't even exist as a concept yet. Cell phones existed, but were very slow and primitive, with the first SmartPhone (the iPhone) still ten years in the future.
This means that you're going to see the number of big integration projects peak as data hubs and knowledge bases become more commonplace within the next two to three years, and then a fairly dramatic drop off as this process becomes one of setting up a configuration file (likely with a context-free tool) then letting the databases do their magic.
This doesn't mean that this will wipe away all need for programmers, but it does mean that increasingly those programmers will be creating applications that are more studio-like than they are corporate.
This was actually the point I wanted to make about the end of Agile in my previous post. It's time to move on. Agile may be everywhere, as several readers suggested, but scratch the surface a bit and you'll find that most of those successful agile projects were ones where you had a strong architect or steward, a culture that was already primed to work in a more Studio-Model like manner, a strong design in the first place as a foundation, and exceptional team-members that used agile in the way it should be used - as a scaffold, rather than a crutch. There are good things to take out of the last twenty years of Agile, but this is not 2000, and it's well past time to acknowledge what's worked with Agile ... and what hasn't.
Read More at Agile World