Prerequisites to understand the material bellow is to read my story of overcoming my obstacle of contributor dissonance. The executive paradox book in some sense talks about leadership, which is usually modeling a contributor cognitive style. I try to assimilate the similarities with the theory of mental symmetry through this blog: introduction to contributor dissonance. It is also advisable to see one of the diagram of mental circuit flows I drew which the book doesn't cover and I created it from insights of the theory of mental symmetry (Ironically, later on, I found a book called Black Box Thinking by Matthew Syed that describes that exact circuit flow I drew paraphrased as "that only if people followed that circuit, they could find their own true success".). Last but not least, I recommend after reading this use case, to read as a reader digest, my translation of an author's essay definition of being empowering. Empowering, in some sense, is creating a platonic form out of a great ideal vision, which is easy for any individual to stray away from the vision and dilute the platonic form to be different from its original source.
After some time digesting the theory of the paradigm diagram from the executive paradox book, it seems that it can solve a lot of solutions with our current stack of situations. Although the way its sketched out, it will not integrate the tasks and people, or to put it more clearly, integrating our what we do as opposed to the content that comes out of our natural motivations on what is empowering "right", it still solves a lot of problems, that although they are not my main motivation, it is good to discuss them as:
1. It seems that although we are already in a mature stage to appreciate the importance of research and innovation, some people have not found how to apply it in balance with the pressure of our external energy forces that are pulling us out here and there.
2. The tools of research and the outcome pitfalls of heavy research have made some to use it as a "hammer and all look like a nail" or use "hierarchy to control the agile methodology" correspondingly. Both make agile ineffective as it was never yet to take over control everything, yet it looks paradoxical to have all hierarchy to the few and no autonomy to the many when the agile methodology is all about giving a starting and ongoing equal opportunity to earn value through their accomplishments (the solution is instead to have a balance of autonomy and control).
Because of these reasons, having no correct models of people to embrace a balance according to the executive paradox model, we cannot have the next path of evolution for society to step into integrating the content of our lives match with what we do. It seems that this path of evolution needs a series of steps, that before you can go 2 steps forward, you have first to make the first step forward before the next second step is open to you.
Furthermore, the malpractice use of not balancing research and development for the majority of people and organizations have made a society that has too much chaos where people do childish irrational acts or a society that embraces traditional hierarchical rules where most of the agile value gets lost when it doesn't run to its default Eco-environment it thrives to its advantage. And no matter what, hierarchical organizations are not empowering. They give less value to people and leave people keep natural motivation to have childish mindsets. This is not problem as the people that have childish mindset will never perform an action that is childish because they are controlled by hierarchy. They are controlled to perform the action well and they don't care much about the background of the person. In agile methodology, this will never work to flourish its true colors where all people participate and learn to embrace an adult mindset. In result, if people want to focus on embracing and integrating the content and actions of people, it is impossible with such anti-supportive environment existing in both of these cases.
For that reason, it is important to take a step and balancing our people and task skills through other perspectives of our mindset. I.E. A rational person that focus on Perceiver Mode should see the big picture through the Server Mode (Visionary). Or a Server Person should see the big picture of the Perceiver Mode (Embracing). These blind spots are the thing that do the trick of making Agile "be really alive" instead of just an " artificial tool".
I read some books and lived in organizations that practiced the Agile methodology. All focus on "Empowering" mode where we focus our main attention to customers. The SCRUM methodology is to take into touch with "people": The story points are so developers are in tune with the business needs. The KANBAN methodology is also about tuning people on giving deliverables to the business needs to users as fast as possible and attain back feedback as fast as possible. You don't need to read those as much as much as to get insights. Any empowering action embraces more being agile. However, that is just one part of everything of what agile is all about. What agile is really all about is balancing the rational (research) and commanding (development) parts that are wired in our brain.
What I experienced in my previous company I worked for, as I described in one of my essays , it is the pitfalls of one of the best examples of being too agile. Because that article was too personalized, let me iterate it in a way how much being agile can go wrong:
Too agile is the focus of paying attention to people needs only. What happens is you re-enforce a habit or a mental network to people that you can meet deliverables at a fast pace on any situation. So when people have expectations based on that habit and you have a situation that it is more important at that point to understand or refactor the code to make it more clear, which path will you take? If you take the path of people and keep taking the path of people then you are breaking the balance of people and tasks. You also re-enforce more the mental networks that you don't have any interruptions to solve your technical debts that are accumulating. So the first problem that comes is the following:
1. No deep understanding of the source code (at least within the scope you are accountable for the assets your stakeholders consume).
This is the first action that will create the chain of commands while still being in the mode of "too agile" that will create a domino effect that will sink a ship slowly like the ship of Titanic by a hit of an iceberg. After all, we know that one of the counter positive parts of agile is that it creates a lot of features and components for the stakeholders to use. But that is counter-intuitive in this case, because if you think about it, even in the case of testing in a black box environment, the amount of combinations and possibilities all those features added make a complex tool that is not able to bring a proper solution. And if you ever think about white boxing, it would have been possible, if not there was a deep understanding of the source code in the first place. So the next problem that hits us is the following:
2. No unit testing (black boxing becomes more of a waste of time while white boxing is out of the question)
Now, after there is no unit testing in proper sense, the accountability or responsibility of developers "shift" in big magnitude. It is not more the responsibility of developers to take control of the tension of the tasks, but instead, take control of the tension with people. They can do any alternative solutions or patches that keeps the people happy while their deliverables being more on time, even working on night, because trying to test the original issue or understanding the whole code, is out of the scope, because before they spill the beans how much time and development cost it needs to refactor everything, they may just fire you and get a fresh pack, after all, anybody "can start from scratch". Because of that fear and the obvious reaction to stakeholders, the next step is taken:
3. No much accountability on the task (but more accountability to people instead)
Okay, so if you don't handle people needs, you create a business debt (never heard it? Well I made it up). If you don't handle task needs, you create technical debt. So after having no accountability of tasks, technical debt increases exponentially with the focus of fixing the business needs with accumulating technical debt.
4. Not handling technical debt
But the technical debt will make the tasks so rigid, so not flexible, that the daily operations business needs will not be able to be met on a daily basis at some point. That is where too agile FAILS.
Once a "too agile" sprint comes into organization and sees it pitfall, the most people will react to this outcome is see the effect and not the origins of the issue. The reason it failed is because there was not a balance in place with the tasks and people at the correct timing or scheduled to be solved later at a point where it was not too late. And also, you cannot let people be free without a paradigm to follow. Don't let childish mindset to control in your business. However, that does not mean, by all means, that people, no matter what, are childish on all or most occasions. What it really means is you didn't put enough effort to place a paradigm that keeps in control with people's mindset to act ethically and accordingly to whatever is appropriate based on the situation.
So once, that happens, people go to the next step, going to the old ways, being too structured while incorporating some agile elements which is of course, putting an element into an environment that is weak to thrive. Will this work out when other organizations have practiced agile "right" with an environment that thrives without any hiccups as waterfall methods do? When we know that waterfall models give less business needs on time? When an organization is too chaotic maybe a waterfall method is need it. But will it be effective in the long term? In a competitive world, when we measure how much business needs we can output, can we perform in a competitive environment well in such circumstances? And the answer is no, and hopefully it is, for really earning being the next success in this society, it ought to be by earning it rightfully by doing the next right step in thinking better strategically. Being structured works because it is simple, it has no chaos, but its less engaging, creates trust issues, high turn over rate, and so many more. Its more like a lonely mindset game where the only success stories are few, and that will not be enough to keep up when other organizations bring more success stories with a "right" agile methodology. In my twitter account, I expressed my feelings that trust and engagement is at the lowest levels I have seen for a long time and the main culprit is the hierarchical model followed in organizations.
Let us explain how a hierarchy model works. Hierarchy focuses more on tasks than the people. It does not care about the people or the background of the people. It does not care about the ethics, personality, or culture of the people behind. It only cares that the task is done by the people and proper control is put into people to not do anything, as they are not trusted, as most likely, the next thing will do is a childish act. The notion of people being childish act comes as our real default nature from the time we were children. As small children, we only have attention of our own selves, that when circumstances do not meet to our own end, we will not care about the externalizations of others, and cry for our own desire. Nevertheless, because of this notion and perception of the natural behavior of people, authority is enforced. Remote working is less embraced. Social tools are less used where provide an environment where everyone can have equal face value. Instead, people either use face to face communication to show authority or use some special facial, verbal, non-verbal expressions to show authority. So the first thing we see is:
1. Enforcing authority (in any way possible i.e. face to face, etc.)
Because of this authority, there is no space for people to do whatever they wish to do, especially meeting business requirements. For many who use this hierarchical model, the requirements that they implement are not aligned with the real stakeholder needs. They do not have much of a voice as they can only speak to few people in chain of command instead of being a flat hierarchical organization. What business needs are defined in this case are mostly what developers think is right for them to have instead of what the stakeholders really want. There is no consensus in place to take a hit into some technical debt for something the user really wants quick. Technical debt is bad if its not manageable. But technical debt is need it, in the hopes the growth will cover the technical debt (like in our economic system). Many agile books follow the same proverbs: "People who do not practice agile is not what people in the end will really want". Some organizations, especially some departments, their business needs change every month, to such a point, a deliverable that is brought late or not accepting more open collaborations with the stakeholders as members of the development team, will make a business need cut short to what it was actually desired.
2. Authority creates a detachment with stakeholders, that in turn creates a business debt
Because they don't understand what the stakeholders really need, they will make up of what people really want (when they never asked what they really wanted). They in such case try to learn overall on all the system how it works. However, understanding the system is an infeasible task. If you were a client and had a special issue, who do you want your final deliverable doctor to be? A generalist or a specialist? Although I am against for specialist to be specialist all the time (they should be generalists too), it is hard to doubt that specialist can be more effective to meet your business needs. Think about united states having so many states. Each state has its own special rules. It is no doubt many people hire lawyers that correspond to a specific state for a specific case cause each state has different rules on how things are done.
3. Understanding stuff "beyond" is not something that will meet the real business client needs effectively as much knowing what specifically your client needs "more broadly"
Because from point #3, we know that a lot of the stuff is not what the client will really need, we expect in a waterfall development that there will be a lot of features that will compliment the client, yet some features that do not compliment the user. The end result will be a product that will be like that:
+++-----++-+++--- turns out to be a -
However, in prototyping where agile methodology follows by virtue, it turns out to be like this
+ => good, put it into the main product and expand it
- => can't scale up, remove it and don't continue more expanding this
Which comes to our final point
4. The final deliverable customers really wanted is not expected to their business demands. Secretly, they create their own business demands in the most chaotic environment possible.
So the end result is that agile hybrid methodology incorporating hierarchy will not work out. And many people bluff they do "right" with this model, when speaking honestly they have no idea the cause of things not working at all. Many will contemplate that there was no much effort into it instead of being denial that such methodology is ineffective in this changing and dynamic environment. Even worse, this structured hierarchy creates agile models on the background to meet the business needs with tons of technical debt to meet the business needs of users before they run out of business. What was ideally visualized to follow, ironically, can embrace on the background an environment that becomes too agile.
Unless management finds a balance of agile and structure with a model that enforces accountability to all people while all being autonomous, these will be definitely an endless loop, people creating new ways of keeping things on control while others trying to keep the ship still float at the sacrifice of making some small mess.
So now that I talked about the pitfalls of structured and agile methodology, let us review what we discussed and digest it thoroughly by looking at some diagrams:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over Processes and tools
Working software over Comprehensive documentation
Customer collaboration over Contract negotiation
Responding to change over Following a plan
What it says there is that we put more priority to "people" or "business needs" instead of "full scalable software solution" or "handling technical debt". But that was in relevance to the time where no much attention was paid to the business needs at that time. If this was followed in practice today, we would be too agile and fail. For that reason, we should take the writing in the context of the time it was written, while also noting down that the above manifesto may have not followed the unexpected turnover on being too agile. For that reasons, if we follow executive paradox model, by using the "while" word, then we have the correct model:
Individuals and interactions while Processes and tools
Working software while Comprehensive documentation
Customer collaboration while Contract negotiation
Responding to change while Following a plan
Now let us see why the too agile and too structured didn't work out, because they didn't stretch out to see the other mode of thought (Now we can uncover the original cause!)
This is a sketch of how a "too agile" methodology looks like if it could have its own expression (note that the red x marks are like staples restricting to have its own freedom)
And here is the sketch of "too structured"
What we see is that when we are "too agile" and when we see how we perform our Rational tasks (Perceiver mode), we have to stretch to our Server mode and create a vision out of how we are doing. What server mode will do in that high level mode is get the vision out of the different perceiver blocks. Think like forming an image out of puzzle pieces. If the puzzle looks good, keep on moving. If the puzzle looks ugly, STOP , and see what can you do about it, especially if that is the main pipeline of the product and it is not that is about to go decommissioned soon.
We also see that when we are "too structured", we perform on our Commanding tasks (Server mode) in an inefficient way. Instead, we have to stretch being "Empowering" (Perceiver mode). What perceiver mode is gathers facts and see whether we treat each person ethically or not. Do we treat people according to their needs appropriately or are we ignoring them too much that we create an environment that there is no trust and less engagement from the average you see in a right agile methodology?
I hope now that you all get the clear picture that agile is balancing those both traits and it needs us to stretch in "high level" views in different "type of thoughts" or else we think too narrowly that we don't create the appropriate balance to scale our environment that others outperform us with their competitive advantage of being "rightfully" agile. Although following practices that are not in alignment with the agile methodology, can still keep us broad afloat for a long time if we are backed up by funds or its a department that is not the main pipeline of the organization, for our career in general, it is not something that in the long term that will keep us in pace being professional.
Now let us review the weak main traits of being too agile or being too structured:
Being too agile negative traits
Due to: Focus on people instead of tasks (Break Point for a series of combo chains that we are susceptible to take a hit)
1. Not understanding the local scope of code that our direct clients really need
2. Not performing proper white box testing/Black box testing does not yield any positive results
3. Managing all types of tension by handling the people in hand instead of the tasks at hand
4. Not handling technical debt
Being too structured negative traits:
Due to: Focus on tasks instead of people (Another "big" Break Point)
1. Not using social technological tools/Remote work environment
2. Destroying moral of stakeholders by the use of authority
3. Stakeholders not able to engage much
4. There is no trust or respect between developers and stakeholders
Instead the right agile methodology that will solve any of your issues is the following:
Give as much authority to any person when he demonstrates he acts in accordance with an action that delivers a project as long he understands the scope of the source code and does not create a technical debt. Give less authority when he revokes any of those. Explain the reasons in an empowering way with facts at hand. Once he solves it, give again authority to the individual as originally meant to. Never ever demonstrate authority without any reason or motivation expressed explicitly. Learn to get feedback from others and give feedback to others where both developers and stakeholder needs can balance to something that both have a win-win situation. Let authority play roles where they switch to anyone who is an expert on their field.
The above paragraph is too long, but lets go to the main points:
Supports Tasks
1. understands the scope of the source code
Instead of understanding the full source code, only what directly impacts him is what matters. This will make him think more broadly on what he is more specialized at and perform better on his business needs.
2. does not create a technical debt
We expect that if he understands the code, he will not create technical debt. Some people are good liars, so if you see technical debt from the effects of your daily workflow dragging down while they tell you that they understand the code, give them an explanation of why the technical debt is there. He should solve the technical debt immediately or see some progress out of it. If not, then he may be too confident or a good liar. However, at the same time, we give them the users the ability to do anything, as long while we verify from the effect of the system still being stable.
Supports People
3. Give as much authority
As long they can perform #1 and #2, we can give them as much authority. The point is we couldn't do business needs because mostly #1 and #2 were the ones that made the whole agile manifesto to work out. #1 and #2 are tasks related or technical debt related. On the other hand #3 in here is people related. Here we don't need to use hierarchy, cause people have learned the paradigm to be adults instead of children respecting #1 and #2. For that reason, as opposed to the hierarchy model where we enforce people to their lowest capacity possibility, we lift them up here as long they are mature adults. This creates a trusting community with a lot of engagement bringing business needs outputs in large scale.
4. Explain the reasons in an empowering way with facts at hand.
Although this does not look an important detail, it is very very important. It is the difference between opposing control over blind faith over instead using facts. Decisions should be made by facts, not by arbitrary hunches! No matter how sensitive the topic is to you, here is the freedom to keep people empowering instead of being afraid to do the next action because of blind faith. With facts, instead of not knowing how to solve the problem and being stuck with not being able to solve #1 and #2, he has the ability to solve it in this case, because he has the facts of what went wrong, and as long he avoids the circumstance again and sees the benefit that this occurring pattern yielded negative results instead of positive results, he can be a believer and transform itself to the correct path. At the same time, this is important for people that are too structured to not abuse the use of #1 and #2 because sometimes they want to enforce control that does not have an enough good reason or with high confidence that the following act was wrong or not.
And that is ladies and gentlemen, the getting agile "right". Hope you get it "right" this time. I will stand to this principles, to have a balanced mindset, to avoid the negative traits at all costs, for what is worth, I want to be a productive and professional member in this community long term's vision.
Last comments: I have to add that many organizations have a mix of agile and structured methodology which express weak traits of both side. For example, being hierarchical while trying to understand everything and keeping the demands under peer pressure of clients. This is where one "mode" hits the "other" in a few components of the other. And of course, that is also ugly as being too agile or too structured (because there isn't a respect of both modules appropriately with a correct paradigm)
In the above video, I express two personal stories of my workplace environment: One of them was too agile while the other one was too structured.