Why aren’t Blockchain projects agile?
The Agile Movement and “Lean Startup”
In February 2001, seventeen software professionals met at a distant ski resort in Snowbird, and wrote the Manifesto for Agile Software Development. The rest is history. Now, nearly two decades later, from small startups to big corporates, most of the software industry follows the principles of agile development.
Seven years later, Eric Reis coined the term “lean startup”. The “lean startup” reflects a methodology, closely related to agile development, which aims to “get a desired product to customers’ hands faster”. This methodology, adopted by startups all over the world, helps them achieve product market fit as fast as possible. The process suggested by Reis is to launch a product as quickly as possible (a.k.a., a Minimal Viable Product, or MVP) and then iterate over and over, adjust and improve through measurement and customer feedback.
Why aren’t Blockchain projects agile?
Since the inception of Bitcoin in 2008, dozens of projects aiming to build a new blockchain infrastructure and new applications on top of them have emerged. For people, such as myself, who have been working in the startup scene for long enough, it’s hard to grasp how much the majority of these projects deviate from the basic principles of the agile movement.
One of the main triggers for the establishment of the agile movement was the burst of the Dot Com Bubble. During the bubble, a lot of money was thrown at projects that either never launched a product or never fit any real market needs. There are many resemblances between the current blockchain scene and that bubble, where an extensive amount of money is invested in projects who are delivered late to the market and are, in many cases, detached from real market needs.
One of the core values represented in the agile manifesto is “working software over comprehensive documentation”, however one of the main characteristics of blockchain projects, and specifically projects that involve a token sale, is the release of a very detailed documentation of the business plan and the technical roadmap and architecture before a single line of code was even developed, and in many cases without prior feedback from potential customers.
To be fair, there are a few reasons, some which I find very legitimate but some less, for why blockchain projects are not as lean as other startup minded projects:
- Platform shift — Blockchain is not just “yet another technology”, but rather the enabler of one of the major platform shifts of our lifetime. This revolutionary shift, in order to succeed and sustain, requires massive resources, efforts and risk-taking, in a magnitude that incremental agile processes might not be able achieve.
- Decentralized network — TCP/IP protocol was published in 1974, and now, 44 years later, is still one of the building blocks of the Internet. Same goes for HTTP, which was invented in the early 90s. These protocols are very decentralized in the sense that, even though there are very respected compliance organizations, such as W3C, they can only propose changes but cannot enforce them, and any upgrade or replacement can be fully applied only upon consensus of an enormous number of decoupled entities throughout the world, from infrastructure providers, through software companies, to network hardware manufacturers. Any major change in these protocols could take decades to apply, which is one of the main reasons TCP/IP and HTTP are still widely used and have changed very slowly and gradually although they are far from being perfect. Blockchain protocols face a similar challenge since neither their adoption nor upgrades can be enforced by a single entity but only by the consensus of the network participants. Introducing a good and sustainable protocol requires a lot of planning, research work, and has to be documented well so others could review and follow.
- Decentralized implementation — One of the ways to achieve better decentralization of a blockchain infrastructure is to encourage as many implementations as possible of the protocol, to avoid a “single point of centralization” in the code level. Therefore, in many projects, the initial release is not code but rather a protocol. Protocols are released as documents and diagrams, and rarely as pieces of code of a working software like we’re used to in agile projects.
- Academic incubation — Many of the well known projects ideas started as an academic or semi-academic work, and developed initially by people from academia, and well, the academy doesn’t work by the same rules the business world works by. Business needs are what often push companies to become agile and lean.
- ICOs — In the last couple of years, public token sales (a.k.a. public ICOs) have become a very popular vehicle for funding the development of blockchain-related projects. Conventional VC funding process requires personal dialogues with a limited set of potential professional investors and a very systematic due diligence process. ICO kind of fundraising, on the other hand, is done by turning to a very wide and diverse audience in an unregulated environment. They don’t trust, they can’t have an in-depth discussion with you, and each of them has very different due-diligence metrics. The most efficient way to gain the trust and faith of this audience is by publishing very comprehensive papers that cover every detail of your project’s business plans and its underlying technology, known as White Papers.
How does Orbs aim to be agile?
As big believers of agile development and the lean startup philosophy, I would like to share with you a few major ways Orbs keeps its project agile:
- Customer collaboration — Orbs is in quite a unique position in the blockchain space, since it matured from a consultancy project into an infrastructure project, through customer needs, first Kin, and now a longer pipeline of customers whom we work closely with to understand their needs and timeline and to shape up the product roadmap and architecture accordingly.
- MVP launch — Reid Hoffman, a well known investor and entrepreneur, said once that “If you’re not embarrassed by the first version of your product, you’ve launched too late.” So here at Orbs, we are actually very proud of our initial product release, but prefer to follow the YAGNI (You aren’t gonna need it) principle where we insist not to add any functionality until deemed necessary.
- Short release cycles — Short release cycles and tight feedback loops are achieved through a combination of: Kanban boards, test-driven development and continuous delivery.
- Decentralized continuous deployment — Fully-Automated upgrade of all nodes in a blockchain network makes them less decentralized. However, in order to allow delivery that is as continuous as possible, we are planning to add to our protocol the ability to upgrade the entire system upon consensus (vote by a majority of the nodes to upgrade will incentivize other nodes to follow this upgrade).
- Gradual and incremental document release — We recently published our Position Paper. Further technical papers that cover in more detail topics such as our consensus algorithm, network protocol and architecture to follow soon. Instead of publishing early on a gigantic monolothic White Paper that pretends to specify every detail of how our business and product will look like in the future, our document release strategy goes hand with hand with our agile development process, and is executed iteratively and incrementally and improved through community feedback.
Join the Orbs community:
- GitHub: https://github.com/orbs-network
- Telegram: https://t.me/orbs_network
- Twitter: https://twitter.com/orbs_network
- Reddit: https://www.reddit.com/r/ORBS_Network/
- Read the Orbs white papers: https://www.orbs.com/white-papers
