“The Art Of Scrappy“ exclaimed an article. further asserting, the organizations should learn from the startups how to be scrappy.
“Be Scrappy“ urged a technical leader.
The notion of scrappiness is inherently fluid, rendering the communication of the value proposition more challenging. Everyone tends to preach a wide range of definitions for the phrase "Be Scrappy," often to excessively glorify a point.
Listen Grasshopper! What being “scrappy“ is plain and simple. It is an optimization problem. Here is my definition:
Spend the least amount of effort to swiftly find the most unconstrained way (however crappy that may be) to deliver high value to the end user as fast as possible.
The definition of "high value" can vary not only from one business to another but also between the two different agile delivery trains of a single project. Therefore what may be considered “high value” in one aspect may be crappy in another.
The definition of high value might encompass a functional feature, a level of security, or hyper scalability etc., or any combination thereof; it's subjective.
To swiftly deliver high value, the scrappy mentality is willing to sacrifice certain aspects of the system. Here, "the system" isn't strictly technical; it encompasses non-technical elements and elements that are not directly linked to the value being delivered.
Example:
Agile Delivery Train #1 : Let there be a login feature
High value: Just able to register and login
Forgone aspects: Scalability, extensibility, complete use case scenario
In broad terms, being scrappy entails achieving high levels of optimization in execution. This encompasses aspects such as decision making, design, code, delivery speed, cycle time, rapid pivoting, deployment speed, and ensuring customer success.
While all of the aforementioned aspects may indeed be swift in a startup environment, it is fundamentally erroneous to equate this pace with what can be achieved within an enterprise context.
It's akin to comparing the speed of a bullet in a vacuum versus through water. Avoid such comparisons. Instead, acknowledge the resistance present in the material; there are valid reasons for the bullet to slow down.
Being scrappy isn't inherently a desired goal, nor is it a universal solution for achieving agility across two entirely different business setups.
Indeed, startups shouldn't necessarily aim to be scrappy. However, being scrappy is often a necessity for startups in their early stages as they build revenue and brand capital. There are exceptions, particularly in regulated markets, where startups may need to adopt a more mature enterprise approach to penetrate the market.
Even for startups, being scrappy has significant cost implications that they may not always be aware of in the early stages of their business. A misguided push by the leadership team could potentially permanently alter the team's cultural DNA, making it more difficult to instill discipline later on.
The cost of being scrappy manifests in numerous ways, both in the short term and the long term.
Being scrappy in understanding user requirements often results in delivering features that do not deliver value, leading to increased churn.
If you're scrappy in design, the cost of change escalates within days of coding. Your team becomes disoriented faster than anticipated, especially if you're not the sole developer of the system. This accelerates the accumulation of technical debt in design, inevitably leading to higher costs of change in the future.
If you're scrappy with the code, you'll either end up with a bloated pile of code or retrospectively spend time refactoring it.
If you're scrappy with your decisions, the probability of getting something right is inevitably low or reliant on luck.
So on and so forth.
![](https://substackcdn.com/image/fetch/w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F8a76904d-56d1-4277-8b1e-566321cce842_1443x916.png)
In the early stages of the startup environment, being scrappier is both feasible and yields results because there often isn't an existing business architecture to fit into. As a result, startups naturally operate in a scrappy manner.
On the flip side, mature organizations (referred to as Enterprises) cannot afford to be scrappy because their cost of failure and the cost of change increase proportionally with the accrual of their brand capital. Consequently, they naturally evolve away from being scrappy, and that is entirely acceptable.
Don't compel startups to emulate mature organizations, and likewise, don't pressure mature organizations to adopt a startup mentality. Such endeavors are futile and outright detrimental.
Encourage teams, whether part of a startup or an enterprise, to:
Align on the high-value they aim to deliver.
Fully understand and appreciate the technical and non-technical debts resulting from their decisions and their implications.
Develop their system thinking skills to anticipate future changes stemming from present decisions, thereby minimizing the cost of change.