Did you know that Neanderthals might have been the world's first agilists? And yet, they went extinct. Could Agile suffer the same fate? Are there eerie parallels between the decline of Neanderthals and the challenges faced by Agile in today's world? This article explores these questions and more, inviting you to reconsider what we can learn from the past about the future of Agile.
 
In an article titled "What Neanderthals Got Right About the Agile Mindset"(1), ​Howard Sublett says that the Neanderthals might be among the world’s first agilists. The article goes on to discuss how one can develop an organizational design that is responsive to the needs of their customers. I highly recommend reading the full article - it was an extremely valuable read for me.

While I concur with all the points he raises regarding the characteristics of Agile, I find it intriguing to see the parallels between the Neanderthals and Agile. Such a perspective is indeed thought-provoking, particularly in light of some fascinating facts about the Neanderthals and their eventual extinction. The Neanderthals are an extinct species, which begs the question - is there a hint there? Could it be that Agile, as we know it, will go the same way as Neanderthals?
 
It is also worth noting that not all of the Neanderthal’s features disappeared - in fact, their DNA can still be found in modern humans(3), making up approximately 1-3% of it. This raises an intriguing possibility: could it be that while Agile as we know it may vanish, some of its defining characteristics will remain? Additionally, it's widely believed that Homo sapiens - us - played a role in the eventual extinction of the Neanderthals. This begs the question: who might be playing the role of Homo sapiens in the case of the disappearance of Agile?
 
The comparison of the Neanderthals to Agile, reminded of my previous research into their extinction. As I delved deeper into current scientific theories, I couldn't help but notice the similarities between their demise and the current state of Agile. Here are some of the parallels that stood out to me:

1. Coexistence with a more dominant group: Contradicting earlier assumptions, a 2014 paper(4) revealed evidence that Neanderthals and Homo sapiens coexisted for up to 5,000 years. This coexistence of dominant and subordinate groups parallels the current relationship between Agile and traditional plan-driven approaches. Plan-driven approaches typically follow a hierarchical and structured way of working, whereas Agile movements prioritize collaboration and flexibility. However, the widespread use of plan-driven approaches in many organizations has limited the adoption and success of Agile movements.
   
2. Interbreeding: A paper(5) published in 2022 showed that the Neanderthal DNA entered the Homo sapiens gene pool, but not the reverse. If fertile Neanderthals were regularly absorbed into Homo sapiens groups, they were effectively being removed from Neanderthal gene pools. We also know that about 2% of the DNA remains in the gene pool of Homo sapiens.  Like in the case of the Neanderthals and Homo sapiens, Agile movements often hybridize with plan-driven approaches, leading to the creation of hybrid and cumbersome processes. These processes tend to dilute the core principles of Agile and lead to confusion and complexity. In these cases of hybridization, we typically see two outcomes. One, more of the dominant group survives leaving only little traces of the other group remains. Two, the hybrid methods do not become successful leading to a blame game and of course all the blame will be assigned to the smaller group.  

In the same vein as Neanderthals, the hybridization of Agile with larger and more traditional organizations could trigger its decline. These organizations' significant size and power could create an unsupportive environment for Agile teams, which could impede their growth and development. In such an environment, Agile teams may be at a disadvantage, as they may not have access to the same level of resources, support, and opportunities for collaboration and knowledge sharing. The Prescott's Pickle Principle from the book Secrets of Consulting(6) by Gerald Weinberg aptly highlights this point, stating that "Cucumbers get more pickled than brine gets cucumbered". This means that the Agile teams' inherent agility and flexibility may be diluted, compromised, or even lost entirely in a more rigid and traditional organization, much like a cucumber being overwhelmed by the pickling process. Therefore, it is crucial to pay close attention to Agile's principles and values while adapting to the larger organization's needs to achieve success.
 
What are your thoughts?

PS: Please note that none of these possible parallels were hinted at in the original article by Howard. I had the opportunity to briefly speak with Howard this week. He stated that the idea of Agile going extinct was not in his mind when he wrote the article. It is entirely my own conjecture and speculation. All blame should be directed towards me alone.

References

1. What Neanderthals Got Right About the Agile Mindset. Published on March 3, 2023 on the Official PMI blog. (search for the title of the article and you will find it)
2. S. Gaudzinski-Windheuser, L. Kindler, K. MacDonald, W. Roebroeks, Hunting and processing of straight-tusked elephants, 125.000 years ago – implications for Neanderthal behavior. Sci. Adv. 9, eadd8186 (2023). https://www.science.org/doi/10.1126/sciadv.add8186
   
3. Vernot, B., & Akey, J. M. (2014). Resurrecting Surviving Neandertal Lineages from Modern Human Genomes. Science, 343(6174), 1017-1021. doi: 10.1126/science.1245938.  
   
4. Higham, T., Douka, K., Wood, R. et al. The timing and spatiotemporal patterning of Neanderthal disappearance. Nature 512, 306–309 (2014). https://doi.org/10.1038/nature13621  
5. Stringer, C., & Crété, L. (2022). Mapping Interactions of H. neanderthalensis and Homo sapiens from the Fossil and Genetic Records. PaleoAnthropology, 2022(2), 130. https://doi.org/10.48738/2022.iss2.130
   
6. Weinberg, G. M. (1985). The Secrets of Consulting: A Guide to Giving and Getting Advice Successfully. (1st ed.). New York, NY: Dorset House Publishing Co., Inc.

The Daily Scrum is the 15-minute huddle where the developers come together to check if they're on track to meet the Sprint goal. It's been around since the first version of Scrum, and while description of Daily Scrum and the questions asked during the meeting have changed over the years, its purpose has remained the same.

In the older description of Daily Scrum, it specifically started with saying “Each Scrum Team meets daily for a 15-minute status meeting called the Daily Scrum. The Daily Scrum is at the same time and same place throughout the Sprints. During the meeting, each Team member explains: (formatting of the word "status" and "explains" are mine)

1. What have you accomplished since the last meeting?
2. What are you going to do before the next meeting?
3. What obstacles are in your way?

And then in the later part of the section it stated “The Daily Scrum is not a status meeting.” It also stated “The intent is to optimize the probability that the Team will meet their Goal. This is a key inspect and adapt meeting in the Scrum”

As you can see the intent of the Daily Scrum from the earlier version of the definition of Scrum is to inspect if the team can meet the Sprint Goal or not.

In 2011, the language changed a little bit, I think, towards the worse side. The change in the first line looked really good though. It stated “The Daily Scrum meeting is a 15-minute time-boxed event for the Development Team to synchronize activities and create a plan for the next 24 hours.” The status part is gone and it is not for the Scrum Team but for the Development Team. However, the questions remained the same. But the worse thing was what it said in the later part. It stated “Every day, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work together as a self-organizing team to accomplish the goal and create the anticipated increment in the remainder of the Sprint.” Doesn’t that sound like a status meeting every day to report not only to the Product Owner but to the Scrum Master too?

In 2013, the description of Daily Scrum got much better. It still had those three questions. But the questions were tweaked to emphasize the team meeting the Sprint goal.

1. What did I do yesterday that helped the Development Team meet the Sprint Goal?
2. What will I do today to help the Development Team meet the Sprint Goal?
3. Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?

Also disappeared the statements that sounded like the developers are “explaining” to the Product Owner and Scrum Master on a daily basis.

In 2020, the three questions were dropped altogether.  This was a good move to make the framework in line with Scrum being a minimally sufficient framework. Removing this prescriptive language finally recognized that the three questions are not the only way to accomplish what we want to accomplish in Daily Scrum. Another welcome change is that, the guide do not say, as in the previous versions,  that “The Development Team or team members often meet immediately after the Daily Scrum for detailed discussions, or to adapt, or replan, the rest of the Sprint’s work”. It may sound like developers need to have scheduled meetings in order to collaborate.  In the latest version the statement is “The Daily Scrum is not the only time Developers are allowed to adjust their plan. They often meet throughout the day for more detailed discussions about adapting or re-planning the rest of the Sprint’s work.” This is line with the intent that the Developers are a team and they collaborate all the time.

The good thing is that the purpose of the Daily Scrum never changed. It has always been “ to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work.”

It is a good thing that the Scrum Guide itself continued to evolve - by inspecting and adapting and making changes. Unfortunately the world haven’t changed. I still meet a lot Scrum practitioners who think that the Scrum Master is to ask those three basic questions and that the Developers are to answer those so that Scrum master can make decisions - just like a status meeting with a team lead or a manager - every day, while standing up, possibly even before having a coffee. That sounds horrible. Shouldn’t we treat our team members as responsible adults? These people voluntarily signed up to work toward the spring goal, supposed to be self organizing.  Hum.... what did the Agile Manifesto say?