Featured Post

Friday, December 18, 2020

The Agile Dichotomy

WARNING: There is an immense dichotomy in agile, and it is infiltrating companies throughout the world! C-Suite executives perceive agile adoption as a means of delivering quality software solutions faster for customers and business partners. Whereas, engineering teams point to the cornerstone principles of the agile manifesto, especially, the emphasis on delivering working software.  The obvious problem here is that delivering working software in no way means that software solutions will be produced faster.  Hence, the dichotomy is between corporate executives who interpret the Agile Manifesto as promising something for nothing, whereas the engineering organization is focused on strategies that mitigate risk, reduce project failures and ultimately benefit the engineers.  The fundamental problem is that C-Suite executives need to justify the cost of their agile initiatives to their investors.  There is a significant bottom-line cost to transition to agile and stakeholders are interested in the return on investment for the "Agile Adoption" thingy that the company is spending so massively to adopt.  

In concept, Agile adoption may lead to greater velocity; however, it is noteworthy that the word "velocity" appears nowhere in the agile manifesto.  There are also 12 principles that the Agile Alliance adopted and  "velocity" is not found amongst those principles.  The principle that most closely suggests anything that may be interpreted as "velocity" is the following principle:

Simplicity--the art maximizing the amount
of work not done--is essential.

This notion of simplicity is anything but simple.  There is tremendous art in simplicity. By analogy, simplicity cannot be achieved by simply speeding up a conveyor belt.  Each of the tooling stations in the assembly line must be capable of adapting to the underlying velocity.  Perhaps we can eliminate or combine assembly operations to improve the efficiency of the product assembly?  In some cases this is feasible, but in software engineering, removing steps from the process can be catastrophic.

There is an underlying premise that much of the assembly-line process can be automated to ensure that the software is produced more efficiently and that less work is done to achieve quality software.  But will this result in greater velocity, and is that velocity improvement quantifiable?  This is an important question!  

Thus the dichotomy between Executives or managers and software engineers may persist for a very long time, thus undermining the agile adoption.  This dichotomy is insidious and even dangerous to the adoption of agile. In fact, all of the questions that surround agile adoption must be vetted within the teams within an organization that have decided to adopt agile.  We must ask the following questions as well:

1) What operational processes within our organization tend to derail agile adoption?

2) What organizations have successfully adopted agile and what choices helped  in their adoption?

Finally, we need to consider this question: 

Does agile actually produce velocity, or higher quality software or both or neither? 

If it doesn't produce velocity, is there still a value proposition for agile adoption? If it doesn't produce higher quality software is there still a value proposition for agile adoption? If this analysis appears as syllogism, it is not trivial or wasteful.  Agile adoption must be done with stated objectives and the adoption must adhere to the identified set of objectives.  Otherwise, what priorities shall we use to guide us in determining how exactly to maximize the work not done? A bottom-line question is: How can we measure if agile adoption is successful? Only if we have a specific criteria for success can we tune agile adoption to meet the success criteria.


Thursday, November 5, 2020

Attention Teachers: Do not teach socialism or hate for the USA

In my first career, some 33 years ago, I was a school teacher in south -central Los Angeles, CA. Having had a progressive indoctrination in college, I was ripe for the increased indoctrination that the Teachers at my school tried to feed me, but somehow, the radical politics that I was asked to digest just didn't go down very well.  I realized that communism wasn't going to make the lives of these inner-city children (mostly Latinos and African Americans, in my city) any better.  I also learned that I had the wherewithal to inspire children to learn and to make learning personal for each student, in Spanish or in English. 

One of my communist fellow-teachers mentioned to me that, among other things, he would make visits to his students homes to strengthen his bonds with students who were struggling.  Although the lesson came from a self-avowed communist, it was not a concept that required me to adopt a revolutionary mindset - only a pragmatic mindset - so I added the practice to my toolbox and began meeting my students at the homes of their parents, in the heart of gangland. I became one of a very small number of white men who could travel freely in that part of L.A. after dark without becoming a victim of the gang wars.
I also developed other ways of connecting with my students and their grades ascended through the combined techniques that I developed. 

Regrettably, the jealousy that I provoked due to my extraordinary success with my students made me quite the target for many of  my less successful colleagues.

Over time I began to feel ostracized and started to lose enthusiasm for teaching. I ultimately made the choice to pursue another career and left my cherished students a good deal better off than when I first met them.

I could share hundreds of touching stories about these delightful 7th and 8th graders, and also a few heart-breaking stories, but the most important lesson that I can share is that socialism and teaching hate for the USA does not help our inner city youth. It simply pushes them fully towards the gang life which is already present in epidemic proportions. I guess that my years of teaching were really the start of my #walkaway experience, and prepared me to leave the Democratic Party.

In short, there is no need to train our youth to be socialists or communists and there is no need to teach our children to hate our country.  The USA is a great country, and patriotism is important to maintaining our Democratic Republic.



Sunday, September 27, 2020

Conservativism and Patriotism - Awake, not Woke

MY #WALKAWAY

It's a personal tragedy for me to know how completely the Democrats had co-opted me in College, beginning in 1984, I was invited to organize for the Students Against Reaganism (STAR), and the nation-wide Anti-Apartied Network. There was every reason to protest Apartied and press for the freeing of Nelson Mandela. But there really wasn't anything especially wrong with Ronald Reagan's vision for this country. STAR was just the next thing, and therefore, a way for progressives to keep us involved. I know now that I was wholly deceived by the progressives for many years. I am awake, not WOKE. Liberals are all about controlling your personal liberty, because absolute compliance is pre-requisite under a Socialist regime.

SOCIALISM

Everyone is Not equal in a socialist nation. The leaders of the party are treated like royalty and the inner circle of the party leadership is next most affluent. Opposition is repressed, because a socialist country's biggest threat is an organized opposition party. The proletariat are relegated to poverty and stand isolated with no power. Moreover, a dark and dangerous underground grows within socialist countries to fill the void of opportunity that invariably prevails within socialist nations. The ruling class invariably installs a Chairman or President with a life-long term of office; hence, socialism begins to morph into a dictatorship rather quickly as history has demonstrated in China, the USSR, Cuba and Venezuela.

THE PLAYBOOK

I know that the Democrats have a well-honed partisan playbook. Heck, I was instructed to work from it and to improve it during my activist years.

TECHNOLOGY AND PROGRESSIVE ACTION

The Anti-Apartied Network was a nation-wide, social network of colleges and universities. Colleges were among the first places on earth to have reliable access to the DarpaNet which later became the internet. With e-mail and instant messaging applications such as they existed, we coordinated with Universities across the country in opposition to Apartied and to press for change - the ultimate goal was to free Nelson Mandela, which occurred very quickly in response to our efforts.

Democrats have practiced and refined their playbook for years since before Reagan and Nixon.

Many forget that the same playbook was in place with George W. Bush (Impeachment before taking office)! Democrats challenged the 2000 election results going so far as to contend that Jeb Bush being governor of Florida gave GWB the critical advantage he needed in order to win that state.

History

Democrats, with the assistance of Bob Woodward and his pall Carl Bernstein. were able to impeach Nixon - Don't be mistaken, I agree that Richard Millhouse Nixon deserved to be impeached for his role in the Watergate scandal.

IRONY

Isn't it funny? The First duly elected Republican Party Commander in chief after Nixon (who resigned under the eminent threat of being impeached for his part in the Watergate scandal - the alleged and provable rigging of an election) was besieged by the media and treated with utmost disrespect.

Conservatives are not so easily dissuaded.

Democrats believe that if they control the house of representatives they run the country. It is foundational socialist theory on which the Democrats have tended over the years. Socialists, in turn, understand that controlling the Democratic party is the only path to gaining control of our country.

As such, the Socialists have operated from the same playbook that the earliest Marxists operated from. Nevertheless - being weak-kneed Liberals with tears for the dead as their strongest Weapon. Do not be fooled. The COVID Death toll is a massive misrepresentation. And of course, this is precisely what the socialists need in order to launch their revolution: Millions locked down in their homes for months while their family members perish. This is utter nonsense and misappropriation of government and an injustice upon the citizens of our proud nation.

My liberal friends and family who have cancelled me due to my support for conservative issues are blinded by the rage that they have been indoctrinated to hold more dear than their own family members. After all, it is the nuclear family that is the singly largest threat to Socialism. I am irate that my former party creates soap-opera dramas whenever THEIR power is challenged. It's no surprise that Hollywood celebrities tend to support the Democratic Party. Actors have been reading and performing such soap operas for decades as they endeavor to make their path into far bigger productions.

Thursday, July 2, 2020

The Theory of Software Stability

Copyright © Thought Rising 2020 All rights reserved.

Abstract



Software Stability is a software engineering theory advanced by Dr. Mohamed Fayad in 2001; however, the term "stability" in the realm of software has only recently been used by a few technology companies such as Amazon.com, While not with the same methods as Dr. Fayad has documented.  Nonetheless, The notion of Stability has entered the language of corporate America through a philosophy that urges all corporations to be good corporate citizens.  When confronted with the economic benefits both in cost savings and public perception of a commitment to stability and sustainability with respect to concerns including environmental footprint/carbon footprint, the notion arises that the concept of stability might also find a foothold in software economics.  Thus we conclude that Software Stability Theory now must be examined carefully within the the academic literature pertaining to Software Engineering.  Similarly, Dr. Fayad's notion of Software Stability deserves a proper treatment and must be taught and shared with other Software Engineers for the betterment of all software engineers.

Software Stability in a Nutshell

  1. Simplicity and Elegance of Software Architecture, Design and Coding

Software Stability theory targets a renaissance in software engineering and a return to the guiding principles of simplicity and elegance in Architecture, design and coding.  Thus, we start with the mandate that simplicity and elegance of software is a desirable characteristic, which yields superior outcomes.

In a nutshell, Software stability is both a scientific theory for rapid software engineering and it is the only software engineering practice that fully embodies the desired objectives of Agile.  It achieves this objective by emphasizing simplicity and elegance of architecture, design and coding.

The core Principle of this theory of  Software Stability is that Patterns are at the core of any software that is built.  It can also be said that anti-patterns are at the core of any software that is built.    This does not mean that software is necessarily bad if it employs one or more anti-patterns.  What it does mean is that all software can be improved and should be improved as much as possible.  To wit, this is central to the agile concept of iterative development; however Software Stability takes the notion of software improvement to another level.  The objective of a software product must be that it is architected, designed and developed with the understanding that software must be maintained and improved iteratively.

As patterns are at the core of software improvement and software innovation, Software Stability targets solutions that employ stable and reusable patterns throughout the software engineering lifecycle.  By employing optimal patterns (Software Stability Patterns) within a software architecture, design and development efforts, you can greatly improve the economics of any software product.

This point is key: Every software engineer has had the experience of discovering a powerful and new approach to modeling a specific software solution and observed the following benefits:

1) Simplified and streamlined software maintenance
2) refinement of the support model for a software product.

Software stability mandates that we employ this approach holistically thereby creating simplicity and elegance of architecture, design and coding throughout all facets of software engineering.

2. Complexity is not a Friend

Software stability stands in firm opposition to the notion that a software solution must necessarily be complex and that complexity itself is inevitable.  In fact  it is central to software stability that complexity is an anti-pattern and that you must simplify relentlessly in order to build innovative software that yields high quality and remains cost effective over time.

3. Agile is not a Silver Bullet

Agile has received a great deal of hype among all technology companies.  Yet, the fact remains that Agile has failed in software engineering organizations with the same frequency that these teams have failed in non-Agile regimes.  An exhaustive analysis of project success within Agile and Non-Agile software engineering teams would reveal few insights about what exactly has gone wrong, but it  would likely fail to raise the most important point:  Namely, that Agile Methods, such as Scrum, Kanban, Lean, and XP are not software engineering methodologies.  Rather, these are Project Management Methods.  None of these approaches prescribes how software should be engineered.  This is where Software Stability is an important software engineering approach for achieving  true and reliable Agile results.  In fact, Software Stability is the only software engineering approach that embodies the same principles detailed in the Agile Manifesto.






Wednesday, July 1, 2020

Confused about Racism?

Copyright © Thought Rising 2020 All rights reserved.

I am confused by all of the rhetoric about Racism in the news and  in discussions with friends and family.  First off there is this term "White Privilege" that confuses me greatly.  Somehow because I'm  white,  I am a beneficiary of White Privilege.  Because I have White Privilege, it is concluded that I'm an institutional racist.  This simply doesn't calculate.  When White Privilege is explained to me, I do not  recognize any of the privileges that I am an alleged beneficiary of.

I raised an African-American child.  Does that mean that he has White Privilege, since White Privilege is something that is passed down from parents to their children?  What about Colin Kaepernick?  Is he White Privileged since at least one of Colin's parents if not both are white?
What about Nate McMillan, a multi-millionaire coach of the NBAs Indiana Pacers?  Is he privileged because he has spent his entire adult life within the shield of the National Basketball association either as a player or as a coach?  He decries racism in our country, but I'm confounded about how exactly it impacts him. Moreover, I've listened to and read dozens of heated comments about racism from privileged public figures who happen to be African Americans.  I understand that they feel compelled to condemn racism and I don't have a concern about their sincerity, but I'd like to know exactly how a Black man or woman who has made millions or even tens of millions or hundreds of millions over their lifetime has been harmed by racism?  When you call the shots in your life everyday and never have to wonder about where your next meal is going to come from; when you've not had to worry about having a roof over your head for decades, and when you've lived a thoroughly privileged life does the color of your skin give you some privilege to voice outrage over a White-Privileged society that has beaten you down?  I find it completely incongruent with reality., That's not to say that Black Americans of the top tier social class should not comment on racial injustice, I just would rather see the rhetoric dropped down a notch or two and the underlying issues addressed.  Systemic racism is not something that can simply be fixed; however the underpinnings of systemic racism and social justice concerns can be addressed individually.  Black lives do matter to me and, in fact, all lives matter to me; however, through my decades of political and social activism, I have learned that rhetoric tends to cloud the underlying issues that can be addressed concretely, and diverts attention from the good work that can be done to improve our society.

I protested against Apartied as a University Campus organizer in the mid-1980s.  Does this absolve me of any of this White Privilege that I am accused of?  Does it make me any less a racist that I have put my body and soul on the line for Racial Equity?

I am jewish by birth.  I was raised in a family that was not well-to-do.  We lived far beyond our means and mom and dad were perpetually bankrupt.  I had to work hard for everything that I've accomplished in my life.  Nothing was handed to me.  Does this reduce my White Privilege, or merely increase it?

For 20 years, I have been counselling Parents of divorce or paternity-related actions involving the family Courts.  I have been emphasizing the importance of Fathers having close bonds with their children.  I have counselled Fathers, and some Mothers of every race, creed color, religion and gender including a number of LGBTQO+ parents.  Does any of this this atone for my despicable white privilege?

I have a 30+ year record of political action supporting racial  and gender equality, yet I am institutionally racist.  This is what confuses me.


Wednesday, June 24, 2020

On Capitalism vs. Socialism

Copyright © Thought Rising 2020 All rights reserved.

It seems of late that there is a rather large mobilization of socialists throughout the country.  This outcry of socialism harkens back to the Occupy Wall Street events of a few years back and rides on the heels of Bernie Sander's push to turn America into a socialist country.

However, all of this belies the fact that people in the socialist regimes of our globe are far less free and far less well off than people are in the United States.  In fact, nearly every socialist country has a miserable record with respect to human rights violations. To wit, socialism has failed miserably in most every country in which it has been tried -- notable socialist countries include:

1) the USSR, which broke up some 30 years ago -- a nation rather infamous for it's Gulags and prisons.
2) China which is notoriously famous for repressing it's own people and killing it's own people should they protest in Tianamen Square or Downtown Hong Kong
3) Czecheslovakia, which is reknowned for oppressing it's own people until the country experienced a Civil War.
4) Romania, A country which repressed even it's national heroes.
5) Cuba, which has been a disaster for most Cubans.
6) Venezuela which went from being one of the most prosperous countries in Latin America to arguably the poorest and most repressive in just a matter of 15 or 20 years.

Why is it that socialism always results in poor outcomes?

I have a theory.  The problem is that the rules of socialism are complicated.  Who makes the rules? How do you compel people to be equal without repression of voice?  In fact is there real equality in any Socialist society?  Scarcely!  There are still ruling class and proletariat class in every Socialist country in the world.  So, what is it that attracts people in this country to Socialism.  I'm baffled.

There's no such thing as a free lunch!  No country and no government is going to pay you to stay at home and sit on your duff for any period of time.  Capitalism offers "We the People" in the United States of America the central concepts  that we have valued for nearly 250 years, and it's working.

Furthermore, the rules of capitalism are much more predictable:  If I have $10, I can purchase $10 of goods or services, but no more.  Of course credit cards add some nuances to the supply and demand concepts, but ultimately, the market prices itself based on consumer tolerances and supply and demand.  Most people understand how this works even if they have not studied economic theory.  Whereas even a year-long course of study in Marxism and Socialism won't help you to understand the rules of Socialism any better than you do at this very moment!

Clearly Capitalism is not perfect and we need a strong government to keep things moving along, but ultimately, Capitalism makes sense and people demonstrably experience great liberties in the USA in part because we have a Democratic Republic rather than a Socialist State, and in part because of the Declaration of Independence.

I am deeply concerned about the Socialist agenda in the Democratic party.  In Socialism, only the ruling class has any freedoms.  So, why wouldn't the Democratic politicians want Socialism.  They can rule indefinitely and control the country at their leisure so long as the Socialist Regime Reigns.
In a nutshell, this is the end goal of the Socialists within the Democratic party, and I cannot stomach any of it.


Saturday, June 20, 2020

Software Accidents Will Happen


Copyright © Thought Rising 2020 All rights reserved.
"Agile is the process used by disciplined professionals observed in the wild."
- Robert "Uncle Bob" Martin


In December of 1992, I traveled to Snowbird ski resort.  While there, I scribbled 4 statements on a chalkboard in the conference room at the resort.  Apparently no one erased that chalkboard between December 1992 and February 2001.

The Agile Alliance met at Snowbird Ski Resort  in February 2001 and published the Agile Manifesto.  According to Robert Martin, they never met again and don't have any desire to do so.  Is it because they anticipate that they will never find writing on that chalkboard  again?

in 2016, Robert Martin, in his talk on the future of programming, he asserts: "Civilization depends on us!" He notes that many dozens of people have been killed by software (due to software in automobiles malfunctioning and the vehicles consequently running into things).  He goes on to assert, "it's just a matter of time before a software cataclysm occurs when perhaps tens of thousands of people are killed by software written poorly."  He describes the scenario of  an airplane crashing into a football stadium.  But we need to consider whether Dr. Martin's "software cataclysm" will be with a bang or a whimper!  Perhaps Dr. Martin's prediction will not be something with so much man and machine carnage as a plane crash.

In the early years of my career, I was responsible for writing programs to manage and control a ballistic testing laboratory at TRW Safety Systems in Mesa, AZ.  The program managed various interlocks, in which the ballistic test (read: explosion) could not be completed until the testbay door was locked from the outside and every member of the test team that had entered the testbay had authorized the test to proceed -- thus indicating that there was no human being in the ballistic testbay.

Thus, I learned a profound lesson about the importance of Software testing and the reality that software could be harmful to humans.

Copyright © Thought Rising 2020 All rights reserved.

Monday, March 23, 2020

The Battle of the Sexes

The Battle of the Sexes


I was eleven years old in 1973 when the whole nation watched "The Battle of the Sexes" play out on television. Never mind that a movie was made of the subject in 2017.  The original competition between Bobby Riggs and Billie Jean King was touted as the battle to end all battles. But the hype was far more interesting than the tennis match.

And years later, we are left with all of the hype and very little substance.  The battle of the sexes has played out on many levels in US culture and society.Women's liberation continues to fight for equal rights and against the male-dominated establishment, when, in fact, the male-dominated establishment retired decades ago.  Unfortunately, the gender wars have raged on. We have women in the C Suite, Women in Congress and in the Senate. Still, the equal rights amendment hasn't been passed, and some women are sincerely P-O'ed and feel victimized by a society that seemingly fails to recognize Women as equals.

I disagree.  I think that women have had a far better outcome due to the unsettled nature of the battle of the sexes.  Moreover, I believe that feminists would rather not talk about the changing roles of men and women in society.  Women have enjoyed a thoroughly free ride in the past five decades.

While American Society has evolved to the point where it is nearly impossible for a family to survive on a single income, many women still hold on to the fantasy that they can aspire to be housewives, sitting at home eating cherry Bon-Bons a la Kate Bundy, while their husbands toil away frantically trying to make ends meet, pay the bills and save some money so that the family can enjoy just one annual vacation each year -- or perhaps every other year, and so that the children might go to college one day and become self-sufficient. No thought or dollar is invested in the thought that the bread-winner himself might actually retire from work at least a few years before he's 6 feet under!

What does this all mean?  I have uncovered a blockbuster finding:  Despite all of the pomp and circumstance surrounding the infamous "Battle of the Sexes".  Nothing at all was settled.  The fact of the matter is that our nation has never had a candid dialogue pertaining to gender roles in the age that followed the battle of the sexes.  Absent that we have fumbled along quite clumsily attempting to achieve some semblance of balance in an otherwise unbalanced world.

The end result is that we have a tenuous battle for a woman's right to choose versus a fetus' right to survive.

We also have an ongoing war of words between feminists who have utterly failed to engage in a long overdue dialogue as to what gender roles look like after the equal rights amendment and after the famed battle of the sexes is finally settled.  Surprisingly, the alleged male-dominated establishment does not especially embrace the concept of Women's liberation as defined by the National Organization for Women or embraced by more militant feminist factions.  But it all comes down to the failure of the Women's Rights movement to engage in a constructive dialogue about how society functions after the battle of the sexes -- as if it were the duty of men to sit them down and ask if they might condescend to even entertain such a dialogue.

I don't pretend to know what the solution is exactly, but it won't get solved until the dialogue is happening in earnest.

Saturday, March 14, 2020

Agile pitfalls to avoid ... At all Cost

Agile Pitfalls to Avoid 
...At all Cost

Copyright © Thought Rising 2020 All rights reserved.
Working in Agile Teams over the course of more than 15 years.  We have observed some distinct benefits; however, there are some formidable pitfalls and bad habits that can doom agile teams.  This paper, classifies these pitfalls and bad habits that must be avoided at all cost to ensure a successful Agile experience for the engineering team and for the product owners and end customers

In our experience, we have observed one or more specific pitfalls or fallacies corresponding to each of the 4 principles (or Values) delineated in the Agile Manifesto as detailed in the following table:

Principle/Value
Pitfall/Anti-Principle
  • Individuals and Interactions over Processes and Tools
  • Agile is a Gateway Drug
  • The Rat's Maze / The Swarm Instinct.
  • Working Software over Comprehensive Documentation
  1. NBUA - No Big Upfront Anything
  2. Non-Agile Software Architectures
  • Customer Collaboration over Contract Negotiation
  1. Agile Obesity
  • The Fallacy of "Yes" - Over-committing leading to Under-delivery
  • High Software Defects and Brittleness
  • Excessive Rework Cycles.
  • Responding to Change over Following a Plan
  • Inadequate Testing

1) Agile is a Gateway Drug

The first agile  principle values Individuals and Interactions over Processes and Tools; however, the need to automate routine processes often leads to massive tool propagation. In this respect, Agile itself is a Gateway Drug, such that ever more tools are needed to orchestrate the agile experience.  For example, we see the following tools employed within agile teams the world over:

1) JIRA for issue tracking
2) Confluence for Just-in-time documentation
3) Junit for Java Unit Testing.
4) DB Unit for database unit testing.
5) Mockito for injection of Mock objects into JUnit Tests.
4) Selenium for Application Test Automation and regression testing.
3) GITHUB for source code management
4) Artefactory for code library management
5) Jenkins for build management
6) UDeploy for deployment automation
7) Splunk for Application Logging and log analysis.

And on and on the list grows.  It is important to note that we have not listed all of the various tools that are needed within the production support team for the overall support and trouble-shooting of applications. It might be argued that many of the tools listed above were always needed, but this is a fallacy in itself.  One might ask, "how did we build software before these tools were available?" Simply, we found ways of solving the technical needs for building software by building one-off tools and thus we were building tools from scratch over and over again.  Perhaps these tools can save us time? Yet there is a cost to all of this tooling, and in the end analysis we were supposed to value individuals and interactions over processes and tools.  Where did Agile lose it's way? It seems that Agile was always destined to become a gateway drug for so many processes and tools.  We conclude that it's a fair question to ask the founders of the Agile Alliance, "Where did we go wrong?"

2) The Rats Maze / The Swarm Instinct

The value of Individuals and Interactions over processes and tools can be undermined when the Individuals and Interactions are not governed by some structure.  Since Agile is also predicated on self-organizing teams.  There is a tendency for disarray to reign within agile teams.  Everyone is on an individual mission to find a piece of cheese within a virtual rats maze.  Thus Agile Team members may find themselves wasting cycles searching the virtual rats maze for answers to technical questions whereas someone else has already found the virtual cheese.

Another analogy is the "Swarm Instinct".  In competitive soccer, we learn that inexperienced players tend to swarm wherever the ball may be on the field of play.  Whereas experienced players, teams and coaches will exploit the swarm  instinct by playing positional play which will allow a more experienced team to exploit the inexperience of the swarming opponent.  Grady Booch famously asserted that Software Engineering is a team sport; however, there is clearly a distinction between haphazard, self-organizing teams and a team that employs a fundamentally rich game-plan, where each team member has a defined role and position on the virtual field of play.  While there is no direct opposing team  per se  within  the Agile project environment, the takeaway is that a team working to a rich gameplan will achieve far greater success and far more reliable and repeatable results versus a team that is entirely self-organizing.

3) NBUA - No Big Up-front Anything

The NBUA pitfall was first detailed by Bertrand Meyer.  Meyer's assertion is that agile projects are destined to fail when agile teams reject all forms of up-frront documentation, in consideration of the assumption that all of the documentation relating to the software will ultimately become outdated.  This is not a legitimate rationale for decrying all up-front documentation.  An important consideration is to invest the appropriate level of effort upfront in any software engineering effort to design a solution that is built for test-ability and that embodies an Agile Software Architecture.  These points are treated in more detail in the following section. But it is sufficient that the fallacy of NBUA can be the root cause of many Agile failures.

4) Non-Agile Software Architecture

Agile software development works best when there is a high degree of repeat-ability.  Software architectures that are cumbersome do not lend themselves to agile software development.  There are two flavors of the Non-Agile Software Architecture Pitfall:

a)  The Square-Peg/Round-Hole Fallacy
b)  Design without Test-ability Fallacy

The Square-Peg/Round-Hole Fallacy occurs when an existing software that was created in a non-agile ecosystem is force-fitted into an agile world.  A similar fallacy occurs when the software architecture fails to take into consideration software life-cycle concerns, and fails to employ patterns that tend to produce a durable, resilient and flexible solution.  This fallacy can quickly doom any team to fail, and experience shows that the end result is an unruly mess.

A similar concern pertaining to software architecture relates to the all important mandate to design for test-ability.  When software is not designed for test-ability from the start, it is most challenging to achieve the level of test-ability needed to ensure product quality.  In addition, it is difficult to create the comprehensive unit test suite that is necessary to support the iterative development cycles that are typical of Agile development.  Without these comprehensive unit tests, the software quickly becomes brittle, defects begin to appear with regularity, and software releases become increasingly unreliable.  This fallacy can be realized in any software that is not designed from the ground up to support agile methods.

5) Agile obesity

Agile teams may loose sight of the principles laid out in the Agile Manifesto.  Agile obesity results from various lapses in judgment.

a) The Fallacy of "Yes" - Over-committing leading to Under-delivery
b) High Software Defects and Brittleness
c) Excessive Rework Cycles.

The  Fallacy of "Yes" is an over-committing problem that invariably leads to under-delivery and in the worst case scenario leads to unacceptable software quality. 

For example, the product owner in a scrum team may have incentives to include ever more features in a release beyond the capacity of the team to engineer, and test all of the promised features.  This is a clear case of an agile fat-cat who has lost touch with reality and has adopted the fallacy that you can get something for nothing with agile.  What's one more wafer-thin feature? 

In the real world, there is a balance of features that do not introduce unnecessary risk to a software product release. In the same vein, you may have a scrum master who doesn't know how to decline a request from the product owner.  It is vital for an agile team to grapple with the risk of adding additional features to a sprint or a release with at least equal weight to the reward of delivering said new features.  The Scrum Master must be able to have a dialogue with the Product Owner relative to any such requests and determine the tangible risks and trade-offs that apply.  This must be done objectively -- emphasizing pragmatism, resource capacity and bandwidth at all times.

6) Inadequate Regression Testing

Regression testing is a mandatory activity in agile development.  Every change -- regardless of how minute -- requires comprehensive regression testing.  Without the necessary and essential test cycles, software is sure to break and exhibit defects and unreliable behavior.  This fallacy is closely related to the Non-Agile Software Architecture Pitfall; however, this fallacy may occur even when the software is designed for testability.  This may occur in the following conditions:

1.     The QA or test team fails to invest adequately in understanding the software and it's failure modes.
2.     The engineering team fails to provide adequate hand-off of the software and its features and functionality to the test team.

Here, we are not simply talking about unit test suites.  Rather, we mean full cycle regression testing.  It is difficult to anticipate the myriad unintended consequences of a small change made to even a modestly complex piece of software.  A change to one component may result in cascading behaviors that bleed over into the function of other components.  Thorough unit testing that includes testing failure modes and edge conditions will ensure that a given module does not malfunction even when presented with edge-condition values that are otherwise unexpected and even unanticipated.  As the integration of highly modular components of software becomes the norm, the cascading effects of a failure in one module may have amplifying effects on other components of the software.  These amplifying effects seldom occur in normal operational scenarios, but software engineers in agile teams, including DevOps engineers need to plan for catastrophic cascading failures that can bring a software product to it's knees.

Conclusion

Assessing many companies that have undertaken a transition to Agile methods, it is clear that Agile is massively  to be a software engineering method, when in fact Agile is not a software engineering method at all.  Agile is a management methodology with application to software engineering and other disciplines.  Most important, because Agile is not well understood by management and also has been heavily promoted as a solution that introduces efficiencies within software engineering teams, non-technical managers see it as a master key that will magically transform a software engineering organization, with little or no cost.  This perception is a tremendous disservice to Agile methods and also to software engineering as well.  Software engineering is a highly disciplined endeavor involving the management of voluminous information and technical details.  

While some managers may perceive the exacting discipline  of software engineering as overkill, it is certainly not the case that the high level of discipiline of a software engineer is excessive by any means.  If the software that is being built is a trivial web page, then perhaps less discipline may be required, but if the software is for a complex satellite network used to defend one's country from attacks from a hostile nation, then clearly the software must work reliably at least 99.99% of the time and preferrably 100%.  If the software is for a self-driving automobile, then we must demand 100% reliability as the vehicle is transporting our most precious cargo - namely ourselves, our spouses, our children and our dear friends.

In fact the most powerful aspect of Agile methods is the concept of iterative development and iterative testing.  The software must pass unit tests under a variety of common operating scenarios as well as under uncommon conditions and edge or boundary conditions.  Software must also operate predictably, and recover gracefully, from failures when invalid and even corrupt inputs or data are passed to the software.

In short, Agile works best when employed with engineers employing repeatable processes.  It can require painstaking effort to create these repeatable processes, and most companies are not patient to allow these repeatable processes to be developed by highly compensated engineers.  Such perceptions doom Agile transformations to fail.  Since the Agile Alliance was formed to formulate solutions to the challenges experienced by software engineering teams and to emphasize the value of working software, it is a fallacy to think that the discipline that fundamentally underscores Agile methods may be tossed aside as useless.

But this does not imply that we simply replace one unsatisfactory management paradigm with another unsatisfactory software engineering management paradigm.  Rather we conclude that repeatable processes are the engine for increased velocity within software engineering teams.  By developing software with discipline and building out repeatable processes, software engineers can deliver high quality working software at velocity.  We've been doing it for years and we continue to do so.  The key to delivering high quality working software at velocity is to employ tremendous discipline and create the repeatable processes that are crucial to engineering high quality working software.  Furthermore, we've uncovered some important lessons for exactly how this should be done and we refer to this concept as the Simplicity Pattern.  The simplicity pattern builds on decades of research and refining the concept of Software Stability Method (SSM)  Software Stability Method is an approach that employs stable and reusable architectural and design patterns throughout the software engineering process.  The Simplicity Pattern is summarized as follows:

Complexity is an anti-pattern

Software engineers and managers within software organizations tend to become complacent with regard to software complexity.  This complacency is dangerous.  The more complex that a software product becomes, the more likely it is to fail.  Furthermore software failures are tremendously costly to fix after delivery. Thus we must simplify relentlessly within all aspects of software engineering encompassing: 

1) Software Architecture
2) Software Design
3) Software Development
4) Software Test
5) Software Deployment and Installation.

Thus the Simplicity Pattern dictates that software must adhere to the following simplicity principles by embodying the following concepts:

1) Architectural Simplicity Pattern 

Software Architecture must be as simple as possible while still satisfying the system requirements.

2) Design Simplicity Pattern

The Design Simplicity Pattern is best understood by two popular concepts touted within strong Agile Teams:

a) Single Responsibility Principle (SRP)  - a software module should have a single responsibility.  Software designs that adhere to SRP tend to remain simple and mitigate complexity
b) Test Driven Design (TDD)  - Software must be designed to be testable, and this is most readily achieved when employing TDD in which the tests that the software must satisfy are the key artifacts of the software design

3) Build Simplicity Pattern

In short Build Simplicity means that the process of building the software need not be a complex software engineering activity unto itself.  By simplifying the build process it makes it easier to continuously build the software and this in turn is the foundation of the continuous integration that is a cornerstone of Agile methods.  Moreover, software must be designed such that the software build is not prohibitively time consuming.  If builds take a long time, then engineers will be reluctant to build the software and defects inherent in the build process may not be identified until very late.

4) Test Simplicity Pattern

Software must be architected, designed, and developed to be fundamentally testable. When software is inherently testable, it is easy to test and testing itself is more easily realized as a repeatable and iterative process.

5) Deployment and installation Simplicity Pattern

Ultimately software is of no value unless it works reliably for its intended purpose and is installed for the end user or customer's use.  Whether the software is installed on a microprocessor within the engine compartment of a car, or within the CPU of an ATM machine. or on a satellite, the software must be easily and quickly deploy-able and install-able to the target operating system.  Software that is prohibitively complex, and difficult to deploy or install is prone to experience defects within the installation process.

In short, to succeed with Agile, or any other project management methodology, we recommend that teams adhere to the Simplicity Pattern.

Copyright © Thought Rising 2020 All rights reserved.