February 2001, in the bleak market midwinter following the dotcom bubble burst, 17 representatives from across the tech industry met together on a mountaintop in Utah to solve a problem.
These were not managerial professionals, CPAs, and MBAs looking to climb back to their previous inflated valuations. That group was busy picking up the pieces of a popped balloon, and likely looking for jobs in a more reliable sector– aerospace or energy seems like a good bet right about now…
These were not economists, financiers, and political power wielders planning how to manipulate the economic machine for the future. That group had just attended their own mountaintop retreat in Davos, Switzerland to determine how they might meddle and mismanage for another year.
This was a meeting of the builders- software developers in standard issue drab polos and pleated khakis favored at the turn of the millennium. These were the backs upon which the still-nascent “e-business” and “web” industries were built, and that building had taken its toll as markets rode the boom/bust cycle. These engineers were working in the most efficient hierarchies and most competent bureaucracies the Industrial Age could conjure, and they were managed in the most tried-and-true methods Henry Ford could imagine a century earlier. These were not the Bosses; these were the Dilberts, and they were together in the Wasatch Mountains to find a lightweight alternative to the heavy yoke of antiquated processes, firm contracts, and overbearing documentation which had ground down their peers for a decade. They wanted to be more mobile, dynamic, and responsive to change. In a word, they wanted to be more Agile.
What is Agile Development?
The Agile movement is not an anti-methodology, in fact, many of us want to restore credibility to the word ‘methodology.’
The engineers, dubbed “The Agile Alliance,” came together to socialize, theorize, and formalize best practices for developers, and they did so with an eye on reducing extraneous work and removing unnecessary oversight. They left that weekend with a new concept for managing teams which would redefine software development. Today it is broadly recognized by the term “Agile Development.” Stripping away strict procedural bloat and institutional waste, they favored a system in which smaller and more nimble teams could adapt to the ever-changing digital landscape, transparent communication between developer and stakeholder groups was prized, and critical product inspections were welcomed early and often instead of avoided for fear of changing requirements. This system of operations was codified as a set of principles and practices recorded and free for the world to access in The Manifesto for Agile Software Development, and from those humble origins it has grown to dominate the world of software engineering and product development.
Agile is not a prescriptive method of management, but instead a series of principles and guidelines for teams to follow which has spawned more specific operating practices such as Scrum, Kanban, XP, and others. However, Agile teams and organizations share common operating concepts. People are organized into smaller, focused development teams which can operate independently from monolithic org structures– Agile teams are decentralized. These teams are cross-functional and staffed to include all positions needed to build and deploy software on their own, and partnerships are put in place to hurdle the typical roadblocks of product release– Agile teams are autonomous. With all of these teams operating semi-independently, open communication and coordination horizontally between teams is required to be effective– Agile teams function best when tied in with a larger Agile organization.
Agile practitioners therefore fit into our DAO framework. As such, the systems and mental models first proposed 20 years ago can be adopted to improve communities in Web3 (whatever that is) in the same way early Agile improved the world of “e-business” (whatever that was). We will explore the Agile Manifesto’s elements to understand how to coordinate and motivate distributed teams towards accomplishing a common goal. We will focus this exploration around five of the Twelve Principles of Agile, and we will look at how each can be an asset for DAOs today.
Agile Principle: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Success for Web3 projects will be defined by the only key metric that matters- value for our customers and end users. For a Web3 organization or DAO to be successful, they must be able to answer two questions: Who is our customer? What value are we delivering? We need to find that product-market fit – the elusive “use case of crypto” – and focus energies on delivering value in the form of a great product or active community engagement, and delivery on a regular and dependable cadence can go far in hammering that value home for customers.
Agile Principle: Business people and developers must work together daily throughout the project.
Break the “us vs. them” mentality so common in the corporate world. In the crypto space we see some early adopters- developers, engineers, and coders- resistant to their communities being invaded by new talent, especially as this new talent takes the form of marketers, investors, community managers, and countless other specializations which enable a product to fit a market. While we want to avoid the evils of corporate bloat (I will not be attending any DAO community sensitivity training, by the way), without the enabling capabilities of business development talent, Web3 will be full of clever science projects which fall short of mass adoption.
Agile Principle: Build projects around motivated individuals. Give them the support they need, and trust them to get the job done.
This is where Web3 shines, and this is why DAOs (in whatever form they may take in the future) are critical. Today, sitting in a bear market and having just wrapped the worst month in crypto history, there can be no doubt that the energy is still high among the true believers. Individual contributors are motivated, so let us define the mission of DAOs as anything and everything necessary to support them in doing great work, building, and delivering value. Tools, rules, team norms, processes, procedures, communication channels, incentive structures… the list can go on. With the bull market died the lofty and unrealistic visions of DAOs as “the future of corporations” or even “the future of governments.” We can now realistically look at them as an organizational structure meant to connect and empower individuals to do good work.
Agile Principle: The best architectures, requirements, and designs emerge from self-organizing teams.
Both an operating principle and an endorsement of the free market, we must provide the core infrastructure so that individuals can form teams themselves to tackle the challenges as they see fit. In this way, managers in the Agile framework serve the role of first responders and not political tyrants. DAO administrators must be focused on removing roadblocks, providing access to tools, and ensuring healthy engagement. Besides that, let the teams form naturally, let them work as they see fit, and should conflict arise allow it to be handled at the lowest level possible. Enable a free market of minds and you will be amazed at the results.
Agile Principle: At regular intervals, the team reflects how to be more effective, then tunes and adjusts its behavior accordingly.
Here is where a formalized process and competent facilitator/manager can be used effectively. Set a time on the calendar to review what you have accomplished as a team: How well did you do in achieving your goals? How have you been communicating as a team? How would you do better next time? How are you feeling? Leave this meeting with concrete actions on what you will do better in the future and how you will measure that improvement.
The Counterexample and Conclusion: Waterfall
The method for planning and management which Agile replaced is all too familiar for many of us- the Waterfall Methodology. This system requires highly organized structures with centralized decision making which favors a top-down control pattern. People are assigned to teams, delegated individual tasks, and disincentivized from taking initiative outside of their sphere of influence. Following a plan is prized over the quality of the end product- implicitly or explicitly. This not only restricts creators and developers, but also the customers who must agree to product specifications up front and are given little-to-no opportunity to provide input and feedback during development. Change is designed to be expensive, and therefore it is feared. This central administration, authoritarian control of internal stakeholders, and territorial protection from external stakeholders aligns the Waterfall Methodology within our framework for “the State” as the antithesis of a DAO.
Instead of exploring “what not to do” with this alternative framework, let’s review the Agile vs. Waterfall evolution as a case study in spontaneous adoption of a new system of governance, tools, and team structures. In 2001, the “powers that be” were entrenched in their old way of doing things. Organizations large and small, and notably the massive-blank-check-machines of government and US defense industry, took for granted that Waterfall methods were the only option for developing products which adhere to strict requirements for security, budget, and schedule. How could we trust the developers, the “regular people,” to plan their own work, manage their own tasks, run their own teams, and still deliver on time? Countering this there was no formal organization to promote Agile practices; there were no lobbyists or evangelists preaching this good work. There was only the good work. Dedicated developers, usually working in smaller companies, adopted these principles, implemented their own structures, and began to deliver working products. These products were more closely aligned with user needs, and that attracted attention. These products were delivered within budget and schedule, and that required more attention. Finally, the top talent at companies began to press for Agile implementation or left to work at companies that followed these principles, and that demanded attention.
What was the result? Can decentralized, autonomous organizational practices gain a foothold in a world dominated by codified, centralized, “statist” methods? According to the digital.ai 2021 State of Agile Report, all signs point to “Yes!” 94% of survey respondents across multiple industries indicated their company used Agile practices in some way, with 65% claiming significant adoption and experience. We have no way of knowing how well these self-identified teams are implementing the practices, but those numbers indicate a cross-industry recognition of Agile’s superiority and a desire to adopt practices at scale. Reasons given for adoption range from increased discipline, to greater alignment, to better management of distributed teams– how many of us have seen a Discord channel that could benefit from those improvements?
Agile is not a silver bullet or panacea. We cannot just “throw some Agile on the fire” and expect things to fall into place. But, history shows us that these operating principles applied with discipline attract talent, empower teams, and have the power to transform industries when implemented correctly. How might we capture the best parts of Agile methods for our own DAO?
(cover image courtesy of agilemanifesto.org)