Based on ethnographic study, the following mental characteristics of Aboriginal Australians have been discovered:
(AB1)"By trial and error" method is the dominant way of dealing with problems. Copying someone else's approach to problems (even successful) is not the first choice.
(AB2) There is no competition between people, no need to be as good as someone else in something. It's very seldom that someone wants to rule or dominate over others.
(AB3) The focus is on the present time, thinking about the future does not happen often.
(AB4) The thinking is mostly pictorial, non-verbal.
Isn't it astonishing how much these characteristics have in common with what we strive to achieve with our agile software teams?
Agile emphasizes empirical approach (AB1), where software team's way of working is adjusted based on examining team's outcome and outputs. Theoretically, the team could start from no assumptions or axioms whatsoever and, over time, produce a way or working similar to that based on Scrum. The other extreme is to take an existing, prescribed process and try to apply it in a product team without any modifications. Somewhere between these extremes is where we are with out teams. We have some foundations either prescribed by an existing framework or built upon the experience of the team members. The foundations is enough to get us going. The goal is to adjust the way of working, as we go. Even the foundation isn't sacred: we can modify it, add to it and remove from it based on the empirical process and we are allowed to err. Unfortunately, we are not always successful with the empirical process because of the following dangers:
- the way of working may be too prescriptive, either based on a publication or consultancy or our own believes, esp. in what worked well in the past, often with another team and another product.
- the way of working may remain not detailed enough, either because of the inertia (adjustment actions are generated, but are extremely difficult to implement) or complacency (adjustment actions are not generated, because the way of work feels good enough how it is - it may be the case of "we did it like that with that other team and it worked well")
While no one challenges us to be extreme and not to copy someone else's approach, I think the general trend is to avoid trial and error. This is how we were raised: vast part of our civilization culturally leaves little room for us to use trial and error - even during childhood, not to mention adult life. And that's why we must consciously pursue trial and error, if we want to use it. In a software development team, typically our foundation is a copy of something and it's OK to start by imitating what has been written or what we remember. The problem is, once we start, it is so easy to forget about trial and error. Mostly, we dream about process adjustments that are trials, but with no chance of errors.
Through our general real life experience, we perceive being prepared for something as a value. It means thinking ahead, it means predicting what might happen and be prepared for it when it happens. This characteristic can manifest itself in a damaging way in software development. While knowing what's coming in terms of roadmap or customer needs is a good thing, using this knowledge too early is not. Classic examples:
- because I know the customer ultimately needs a many-to-many mapping between these entities, I will prepare the code to handle this mapping in the future
- because there will be 24 attributes of a customer record, why don't we go ahead and add all of them now, even though 20 of them are not related to this User Story we are working on? That way, we will not need to go back and rework the code to add the missing 20.
First of all, the future is uncertain. We don't know for sure that in a few weeks from now there will be exactly 24 attributes of customer record, nor are we sure that the customer will eventually pursue many-to-many mapping in the coming rollout of the software. Now, even if it turns out to be the case... there is still another problem with the approach illustrated by these two examples: the testing. If we add things "in case" and "for the future", how are we going to test them now? This is where focusing on right here, right now (AB3) is a better value than thinking ahead too much.
No competition between people (AB2) - wouldn't that be a team we all wish we had? No competition, no overruling, no supremacy of more experienced or those with greater mileage in the company... Just a healthy cooperation towards a shared goal.
We all have had enough of formal notations, algebra and written descriptions. In software development, we recognized that while formal descriptions and mathematical abstractions are useful, the use of tangible samples tends to yield better outcome:
- a working software product yield more valuable feedback than the textual description of how it works
- examples of data flows or data structures and more readily consumed and easier to understand than their formal, abstract counterparts (who doesn't jump to programming language example outright, instead of trying to wrap ones head around formal syntax and semantics?)
It is easier for us to think about what we can touch and experience (AB4), than about a theoretical entity.
Balance and Symmetry
Aboriginal Australians believed that the balance and symmetry in the surrounding world is the key value that needs to be governed. They believed that a counteraction, even against something bad, should not be stronger than the enemy's. For example, a viper has the right to bite. People have the right to defend against vipers, but should not try to eradicate them completely, because that would break the world's balance.
Unfortunately, this attitude worked against Aboriginal Australians when, during battles with the Europeans, they only responded to attacks as strong as to protect their land, but never took advantage of a situation in the field to destroy the enemy.
This observation of balance and symmetry is also important in our work. Most notably, the balance between new stuff and refactoring is something many teams would warmly welcome. The separation of responsibilities between "implementation" and "testing" is another example of breaking the symmetry, sometimes going as far as to put these two "teams" at two different locations, with a large time zone and cultural differences. This most often results in high employee turnaround, low quality, defensive behaviors and, at the extreme case, telling lies.
The beliefs and moral system of Aboriginal Australians is mind-blowing for anyone well versed with agility in software.The moral system is based four values:
- Autonomy - every being has its own rights
- Balance - none of the different forces in the world should create a significant advantage over the other forces
- Symmetry - if one of the forces becomes too dangerous, it needs to be constrained
- Action - if someone or something breaks the Symmetry, they need to be stopped (but still without using too much force so that the Balance is not endangered)
With subtle wording adjustment, these four could easily become the values of another successful "Scaled Agility Framework", wouldn't they? 😀 Just imagine a smartly dressed person stepping on stage at your next Agile conference and saying: "Hello, I'm going to present to you a brand new Agile framework that is based on four pillars: Autonomy, Balance, Symmetry and Action."
Aboriginal Australians' religious beliefs assume that the gods had a different ruling strategy than what is typical of Western civilization: the gods did not arbitrarily create a law system. Instead, in the remote past, they experimented and changed the law as well as the prescribed religious rituals, often disagreeing with each other while doing so. Sounds familiar?
Picture used:
[1] Uluru / Ayers Rock - GNU Free Documentation License
[2] A lesson in spinning string, Central Australia. Credit: Wellcome Images.
[3] Didgeridoo - GNU Free Documentation License
Reference:
[1] Wikipedia: Aboriginal Australians (in Polish)