Software development is usually an iterative process. It starts with a hypothesis, which goes through design, production, testing, validation, and, finally, release. The goal of agile teams is to bring the product to market in the shortest possible time frame, receive feedback, and correct course before large amounts of time and money are invested.
We’d like to contend that in its current form, the development process is overly distant from end-users and may lead to flawed decision-making.
Although methods like Design Thinking, Customer Development, and Lean startup all use data as the fundamental element of development, we’d like to argue that the very process of data collection, analysis, and application is subjective and prone to mistakes.
Agile teams usually consist of 5 to 9 individuals. Scrum, a popular development methodology, argues that teams with a number of developers higher than 9 can’t stay true to the rapid development process, necessary for agile frameworks to be successful due to communication between team members becoming overly complicated.
The notion is — the fewer people are involved in decision-making, the faster they can reach consensus and avoid bottlenecks at the conceptualization and approval stages.
While this approach enables speed, it also forces the teams to base decisions on a limited number of opinions. We argue that limiting the number of thinkers involved in hypothesis creation does not provide enough diversity in experiences. As a result, the decision-making process becomes biased and overly-reliant on the opinions of a small group of people.
While the validation and testing stages are designed to counteract this issue, the limited sample size sometimes proves insufficient and true validation can be achieved only post-release.
Cases that support this theory are abundant. For example, Apple is notoriously known for creating products that value less important cosmetic details over fundamental features.
The perfect instance of this behavior is seen in the release of the 2013 Mac Pro, which the community dubbed the «Trash Can». That piece of hardware prioritized compact footprint and slick visuals over heat distribution and expandability. Further, post-2015 MacBooks Pro pioneered slightly thinner chassis at the expense of overheating and thermal-throttling, causing many fans to stick to their pre-2015 models and skip several generations.
Another notable example in software development is Battlefield 5 — the latest installment in the well-known shooter video game franchise. In this case, a series of controversial creative and design decisions alienated the fanbase and ultimately led to a termination of support for the product before the planned date.
Apple and DICE are both mammoth companies with access to top-notch talent and near-limitless resources. The list could go on, but you probably get the point.
The contradicting approach was temporarily practiced by DICE from mid-2014 until November 2018 in the form of a Community Test Environment. Before rolling out the updates to production software, they were first tried in an open, experimental environment accessible to anybody. The final implementation of features depended a lot on the community sentiment.
Similarly, Apple’s 2019 MacBook pro is praised by the community for embraсing a lot of the suggestions. «It almost seems like Apple created a listen-to-the- people committee. Great job. Now do it again» MKBHD, a popular tech YouTuber, said in his review.
In both cases, the products improved noticeably after the respecting companies embraced community feedback. Both products became wild commercial and critically recognized successes.
These examples lead to the conclusion that when more diverse opinions are utilized, the resulting products have higher chances to become successful.
Thus, we propose a new development framework that blends best practices of Scrum, Agile Development, and Rapid Prototyping but enables a more diverse pool of opinions.
The framework should retain sprints — loosely time-bound development periods characterized by a measurable end result.
The process of hypothesis creation should be made open to all community participants via transparent voting and proposal creation.
The governance portal should establish an accessible and inclusive process of sharing and evaluating proposals through well-thought-out UX/UI. Making the platform’s learning curve lower will aid in increasing the diversity of participants and points of view expressed by suggestions.
The team’s backlog should be heavily or completely influenced by the results of the votes, and community members should be welcome to directly affect the prioritization.
To stay true to the promise of open development, the team should report on progress regularly and in an accessible manner. This will enable community members to share feedback during the development and not wait for the final release.
Proposals should be aggregated into smaller batches of work and most of the proposed additions and improvements should be achievable within a month-long time-frame to retain the iterative development methodology.
The team should be able to assist in filtering out technically impossible proposals, while an independent overseeing committee should be formed to filter out cases of trolling and ill-intended suggestions.
The discussion around development does not have to be limited to professionals as long as participants avoid the technical side and not try to answer the question «how do we achieve the desired result?».
While it is true that quality implementation of a proposal requires specialized knowledge in the corresponding domain, it does not mean that users lacking the technical skill are unable to create a valid proposal.
For example, if we return to the case of Apple and lackluster thermal engineering, anybody who uses their products for professional needs can propose to fix the overheating by making the chassis bigger. Only common sense and basic knowledge of physics are required to arrive at this conclusion.
On the other hand, that same person, if not an engineer themselves, will not be able to describe the exact steps or technical specifications necessary to achieve the desired result.
Thus, the centralized core team and a smaller group of community developers should lead the development effort, but let the broader community guide the general direction and backlog prioritization.
What we essentially arrive at is an experimental development methodology that can be called «Decentralized Agile Development.» By taking the best agile practices and combining them with decentralized decision-making already utilized in blockchain communities, we can create a more inclusive development process that will ultimately lead to better products and better user-experiences.
