After reading the post from javacodegeeks 4 Warning Signs that Agile Is Declining, I started writing a comment and then noticed I had too much stuff to say, so decided to write something about it instead. I think that agile is far from declining, but that it’s starting to evolve and will keep growing.
Agile principles have stuck
For the last couple of years many people and companies have taken the time to get informed on what agile is or even get coaching on a particular method such as SCRUM or Kanban. Even if they might not be applying a specific method at its full scale, or don’t remember all the things they learned, they do remember some of the main key agile principles:
- Iterative and collaborative approach
- Adaptation to change
- Focus on individuals
- Working software / approved concept
With these key agile principles and with the methods in mind, teams are then able to find the agile way that works for them. Information age mentions that “organizations are using Agile in all manner of different ways: more mix it with other methodologies (35%) and combine elements of the various forms of Agile (39%) than stick exclusively to one particular variant (27%).”
Agility has created new agile methodologies
Those who have fully applied an agile method such as SCRUM or Kanban, may have realized that it’s not perfect for them. And that’s ok. It’s normal that after a couple of years, people start looking back at how they’ve been working and noticing that it’s not all perfect. They need to evolve and by doing so they are being agile. That’s why we are starting to hear more and more of these: Scrum-but. Scragilefall, scrumban, waterscrum, wagile… People are taking what they’ve learned from various methods and being agile by simply keeping agile principles in their new adapted method.
Agile is getting so popular that it’s even being labeled as mainstream. Forrester research states that “in the past few years, Agile processes have not only gained increasing adoption levels; they have also rapidly joined the mainstream of development approaches. And while more organizations are adapting to Agile conventions, Agile is also adapting to the workplace. Perhaps the clearest sign of the mainstreaming of Agile is the abandonment of orthodoxy: Teams are puzzling out the mix of methodologies and combining them to fit within their organizational realities, blending Agile and non-Agile techniques and practices to create a hybrid methodology that fits larger organizations.”
IT Agile idealists might be frustrated to see agile methods being transformed, thus making things less ideal for developers. Instead, shouldn’t they be longing for it to become mainstream to have agile principles influencing other areas of the business?
The future: Agile also outside of Software?
I believe one way agile will keep evolving and getting better is by having non-IT groups adopt agile values in their work.
Mike Griffiths, wrote that “Agile adoption outside of software is nothing new–it dates back very close to the origin of today’s agile methods, predating the term ‘agile’. However, what is new and noteworthy is the rate and scale of non-software agile adoption being witnessed today. Now–as more companies than ever are exposed to agile methods in their IT practices–these methods are being employed beyond the regular IT domain.”
Also, Information Age notes that: Other organisations are even adapting Agile for use outside IT. British Airways, for example, which adopted Agile for software development in 2008, has since applied elements of the methodology in developing ideas for new revenue streams
Instead of being upset by the fact that agile principles are being altered, today’s agile practitioners should be the ones to lead the way in making agility a norm in new types of teams and organizations. That’s why Planbox has tried hard from the start to promote this philosophy, by making the tool not only useful for IT teams, but also for groups outside of software. If we all push in this direction, and try to make agile mature, diversify and solidify instead of fighting for methods to stay as they are, we’ll make sure agile thrives as a way of doing things that focuses on people, collaboration, adaptation and purpose.
So what do you think: Decline or Evolution? Let us know in the comments!
Interesting article. I think that one of the challenges is that people often take a tool, decompose it, and then try to use pieces of the tool. Scrum is a tool. The Daily Scrum Meeting is a piece of the tool. It might be useful on its own, but combined with all the other pieces of Scrum it makes a very powerful tool. The “evolution” of Agile is in some ways just a watering-down. Sometimes that’s okay. But success with Scrum is different than success with watered-down-Agile. Success with Scrum often means quadrupling productivity. Success with watered-down-Agile often means 10 to 15% improvements in soft measures such as morale or customer satisfaction. That’s still useful and meaningful, but it’s really beside the point of most Agile methods which are meant to provide revolutionary improvements.
Thanks for the comment. Are you sure that “Success with Scrum often means quadrupling productivity. Success with watered-down-Agile often means 10 to 15% improvements”. I’ve seen a lot of teams that work with agile principles, some 100% SCRUM and some totally custom (but they may have started 100% SCRUM), and I wouldn’t say all the latter were less productive. Some teams try so hard to be 100% SCRUM and then abort because it’s too much for them, so in the end they are 0% better off. The motivation to stay agile, even if it may mean a 70% improvement instead of 100% is much better than 0%. I believe successful agile teams are the ones who know and value the agile principles mentioned above, and who truly share a common goal.
Hi, nice article and thank you for bringing it to my attention via Twitter. I agree with your assessment and believe this is a balanced response to the original article at JavaCodeGeeks.
I’ll add that most work environments (not including software development) suffer a significant amount of inertia and orthodoxy so a tool like Scrum cannot be superimposed because the people involved aren’t capable of such a radical, instantaneous shift. But “watered-down-Agile” as Mr. Berteig called it above can help otherwise immoveable and unrelenting business models BEGIN to see that agile principles and practices can help them become more efficient and adaptable (I’m referring to the massive command-and-control structures that exist in higher education, medical institutions, government, etc.)
Here’s a metaphor we might explore:
- By the mid-19th century there was “Classical Music” epitomized by conventional structures, strict procedures, risk-averse composition, and codified by hundreds of years of practice.
- Then JAZZ happened!
- Then the principles and techniques of jazz were studied and appropriated by conventional music institutions like universities.
- The result: jazz has had widespread and significant influence upon every known musical form throughout the world.
I believe that metaphor describes the future of agile. “Agile” is to business administration what “jazz” was to musicial composition.
Thanks for the great metaphor. I’m actually a very experiences classical music player. And as you say, you need to start with classical knowledge to be able to understand and play jazz (even thought that is still quite hard for me). Since agile is initially “meant for” IT teams, it will be harder to make it spread in other business areas, but I do think it will get there.
Very awesome article.
I really agree with Mr.Mishkin Berteig that The “evolution” of Agile is in some ways just a watering-down. But success with Scrum is different than success with watered-down-Agile.
Thanks! If watered down means any method that isn’t “validated” like SCRUM, then yes. But I don’t believe we can state that all teams doing 100% SCRUM are better off than teams that may have a great custom agile process. These teams may have started with SCRUM and evolved from there as knowledgeable agile individuals.
Wow. Nice response and summary. I couldn’t agree more with your thoughts and the sources cited. I particularly like the quote from Forrester research:
“in the past few years, Agile processes have not only gained increasing adoption levels; they have also rapidly joined the mainstream of development approaches. And while more organizations are adapting to Agile conventions, Agile is also adapting to the workplace. Perhaps the clearest sign of the mainstreaming of Agile is the abandonment of orthodoxy: Teams are puzzling out the mix of methodologies and combining them to fit within their organizational realities, blending Agile and non-Agile techniques and practices to create a hybrid methodology that fits larger organizations.”
That seems to sum up my thinking on the topic as well.
Thank you.
Thanks for the comment.
Many of the agilists I’ve spoke to often talk about “Scrum, but”, and I’ve lately experienced a tendency toward “Kanban, but”. These customizations of proven methods are often driven by great intentions: “I need to make this understandable to my team”, “that practice would never work here”, “I need to change a little bit at a time”, etc. But they often have dramatic impacts that erase some or all of the potential gains. In “Management 3.0″, Jurgen Appelo likens agile methods to “memeplexes” of ideas that are able to take hold and amplify themselves because of the way they relate and reinforce each other. When you start shaving off practices, you start to lose this effect.
Part of the failure comes from not understanding the ideas we’re working with with sufficient depth to really know what you’re modifying. Modern chefs are still trained in the classic French methods laid down by Escoffier, even though most of us would reject that style of cuisine out of hand. They’re able to create the modern dishes we crave because they have a solid foundation in a classical technique and understand the rules well enough to know when and how to break them.
In software, we have a very small percentage of our workforce trained with a deep understanding of technology, let alone exposed to the theory and practice of how organizations work and people collaborate. Without a solid foundation, we’re not in a very good position to branch off and improvise. Starting from that point, most shops would be best off adapting an existing approach until they can establish a high level of competence. From there, they can branch off and optimize for their own environments.
Thanks for the great comment. I like the analogy with cooks (I LOVE to cook). It could also apply to painting – before you can go and paint original and innovative pieces like Picasso, you have to totally master the basics. That’s the ideal scenario.
Hi Magali,
I have to agree with the post from JavaCodeGeeks… The problem with Agile is that when the Agile fathers built it they didn’t create something like the PMBOK, they just said here are the guidelines and figure out the methodology yourselves. This has led to an innumerable number of Agile flavors.
PS: Take a look at this question and answer: Is Agile Snake Oil?. In my opinion, the way Agile is sold right now to companies, it is definitely snake oil.
Thanks for the comment. The agile fathers came up with a great Agile Manifesto: http://agilemanifesto.org/. I don’t understand why it’s bad to end up with a number of agile flavors… Isn’t that in itself the proof of agility? It’s true that “agile” in itself is not a methodology, but agile coaches normally train companies on agile methodologies such as Scrum, Kanban, xp… When you say that coaches and consultants are selling snake oil to companies, that’s a totally different subject. Like in every business, you have people who do a good and bad job.
Hi, great article.
However, I’m somewhat concerned about different flavors and adaptations that give rise to countless new methodologies. Scrum, Kanban and others are tools, frameworks; but Agile is more. Agile is a culture based in values and principles. When we want adopt an agile methodology inside our company and teams, we must analize our enviroment and decide what elements are usefull for our work and consequently build our own methodology; but -and this is most important to me- keep intact the values & principles of agility.
More articles please. Thanks.
Thanks for the comment Johnny. What you say is true and what I believe. Agile values and principles are the essence of being agile; and should be the core of any agile process. Knowing about frameworks such as Scrum and kanban will make it easier and quicker to define a successful agile process defining.
To me both your considerations and the ones from javacodegeeks seems corrects.
What to do next, how to keep the good things and let Agile evolve instead of disappear diluted and misunderstood ?
After 10 years of Agile Manifesto, now that agile is mainstream, maybe the time has come for the next generation. And we could start to think what can help : http://blogs.ugidotnet.org/luKa/archive/2012/01/26/after-10-years-of-agile-manifesto-agile-is-mainstream-maybe.aspx
Continuing in the path of getting a deeper understanding of Agile in order to preserve the key values of Agile and make them resilient to the ongoing Mash-up and crossover, I’m trying to figure out what are the key dimensions of agile: http://blogs.ugidotnet.org/luKa/archive/2012/02/03/the-dimensions-of-agile.aspx
Can you also suggest me some reading to deepen the understanding of Agile practices behind the rule, understanding the purpose and how the practices and the internals of the synergy between them?
Thanks for the comment Luca. I think the next step would be for today’s agile practitioners to lead the way in making agility a norm in new types of teams and organizations.
Far from declining. I know this post is 7 months old but in my opinion, Agile is ever evolving like anything with a solid foundation. The most basic example is the “Scientific method.” After centuries we still use the core values of the scientific method due to its process concept.
I certainly believe that agility should be adopted outside the IT domain. One point about agility is that it is actually the unwanted practice that we try to avoid in conventional organisations, instead of realising that this is what we are doing anyway, so this lack of accepting the reality creates frustration. However, it is still an issue to land a project between chaos and restrictive order. The scientific method is submitted to the same irregularities even more so because it intends to provide new knowledge by doing something that has not been done before this is even more prone to create unexpected situations that need adjustment of the project details. With (research) project staff’s it can sometimes be difficult to be fuzzy about working procedures, because this will be conceived as weak leadership, so it requires awareness and non-routine behaviour.