Agile practitioners and
advocates are prone to a fallacy that the "Whole" is equal to the sum
of it's parts. While this principle should be true in most cases, it
is not always true.
For example, lets consider two
major categories of transactions in a system Category A and Category B:
|
Category A: Domestic Purchase/Shipment |
Category B: International Purchase/Shipment |
||
|
Taxable? |
Yes |
Taxable? |
Yes |
|
Requirements |
State Sales Taxes apply bsased on the location where the product is shipped. Some states have no sales tax (e.g.: 0%) |
Requirements |
Value Added Tax Import Tax and Tariffs as per current regulations. |
A subsystem that orchestrates the shipment, and also the application of Taxes and Tariffs may not work correctly in particularly in cases, when Tariffs may be assigned by a foreign government on short notice. This is a rather simple example, but it demonstrates a form of complexity that may surface in a Scrum Team.
If the work of the overall
orchestration of the Taxation and Tariff assessment is split out among
different Scrum teams, the results could be unpredictable. Taxation rates
vary from state to state and country to country. The proper division and ownership of duties
is important here. Perhaps there is an expert on the team who understands
US State sales taxes, and another expert who primarily works with international
sales taxes and tariffs, but no one who understand both. In addition, there is
a great need for coordination with the DevOps team who will be responsible for
the build and deployment of the solution.
Consider that certain product
is no longer available for shipment from the United States to customers in the
United States due to a structural change in off-shoring of the product's
manufacturing. As a result the products will ship from China to the USA;
however, China has recently had new Tariffs and sanctions imposed on its imports into the
USA, due to its failure to adhere to a trade agreement. In this scenario,
we have import shipments from a foreign nation to the US. This breaks the
division of labor into a less-than-ideal outcome. As the shipments will
be taxed based on the destination state, plus the shipment will also have a
tarrif, which is not normally the case for imports into the USA. The Scrum Team
may decide to break this piece out into a module of its own; because, over
time, things may change and the product again may be sourced domestically.
Where the difficulty arises for the overall Agile team is when the teams are not clear about the division of responsibilities and overlap exists or the work is divided up in a hurry due to pressing enterprise obligations. As a result team-members anxious to help with the effort may needlessly duplicate efforts or fail to provide the coverage for a feature that is required. The end result is defect that are unanticipated. Who is responsible for pruning the citrus tree of code artifacts and ensuring that this doesn't happen within agile teams? Perhaps the scrum master owns this responsibility, or does she? If agile teams are self-organizing, then they may not receive this coverage from the scrum master. Moreover a question is prompted. When was the last time that you observed a living breathing scrum-master in the wild? They are an interesting, but rare species, and apparently nocturnal creatures, because they are rarely observed in the daytime.
There are vast examples of agile teams dropping the ball as in the scenario that I featured above. The question is two-fold:
1) Are we so arrogant as to believe that agile is the end-all be-all of software engineering practice?
2) What is missing from Agile that seems to produce these unfortunate outcomes?
I have found specific software engineering discipline to be nearly absent in agile teams. Many teams simply struggle to adopt the ceremonies required for agile with the level of discipline that is needed. DevOps teams pushed to the hilt with a barrage of deployment tickets simply jury-rig the deployments just-in time to meet the insane schedules that they deal with on a daily basis. This results in further concerns such as deployment of artifacts that were never intended to be deployed, simply because they have worked before, or adding unnecessary and volatile steps to a release as a stop-gap, but introducing production failures as a side effect, If you think that these are funny examples, I've got a million of them.
Perhaps instead of riffing on the unfortunate souls who have been hit and run by agile practice we need to shed the arrogance of agile and get back to some modicum of software engineering.
First principles of software engineering are a good place to start.
1.1) There is a root cause for every effect or outcome.
1.2) Garbage in yields garbage out.
By analogy, we can assert the following Theorems as well:
2.1) There's no such thing as a free lunch.
2.2) Agile methods require software that is crafted to satisfy agile expectations
2.2.1) Testable
2.2.1.1) Has a very high percentage of automated integration tests.
2.2.1.2) Code coverage through unit tests is also equally high.
2.2.1.3) Every test is correlated to functionality specified in user stories.
2.2.2) Well understood
2.2.2.1) There are no significant gaps in the user stories, unit tests or integration test suites.
2.2.2.2) The application or solution is well understood.
2.2.2.3) Knowledge of the solution is substantial and not limited to the minds of a small cadre of experts.
2.2.2.4) Experts are expected to share their knowledge with the team, and this knowledge is shared freely
Regrettably, these principles are not widely adopted in software engineering organizations, nor is knowledge shared broadly. In fact, critical knowledge is often owned by a small fraction of the team and there are large portions of a system that are so complex that no one could ever explain how it works as it does or why it works in such a way.
In practice leading software engineers understand that there is an elegant solution for every software application and there are fully elegant techniques for reducing software complexity. Agile teams rarely reach the maturity required to realize how to mitigate software complexity, because everyone is so focused on sprints and deadlines.
This prompts many questions. The first is this notion of deadlines. Weren't deadlines supposed to be a thing of the past in the agile world? We were supposed to be killing the notion of artificial deadlines with the transition to agile, but it ultimately turns out that there are more deadlines than ever. Daily deadlines, weekly deadlines, sprint deadlines, story deadlines and epic deadlines. But in the agile ceremonies, no one is really managing to these deadlines, certainly not the scrum masters that eschew deadlines, and think in terms of nothing more than the current sprint and the next sprint.
