A variety of Software Development Methodologies, frameworks, and practices have evolved over the years, each with their own recognized strengths and weaknesses.
Although common methodologies like waterfall, extreme programming, and various types of agile methodologies may have made more sense when they were being developed (mostly in the '80s & '90s), much has changed in the following years.
Startups and businesses with workforces that used to be small and localized are now more globalized with employees collaborating with each other from multiple countries and time zones. In addition to a newly evolved workforce, the technologies and languages we have available to us in the workplace are going through their own evolutions, enabling businesses to operate in newer and more energetic ways. As the world continues to evolve around us, it makes sense that our software development methods should evolve, too.
The Open Development Method is a summary of lessons learned in leading large teams around Agile, Scrum, Waterfall and other common methodologies.
After witnessing those methodologies fall short when unexpected variables get introduced into the mix, especially with teams that are distributed, multi-lingual, and cross-functional (a scenario that many startups teams are experiencing today), I realized that as our global economy continues to grow, traditional notions of centralized workspaces are no longer desired.
The Open Source world provides an example of a familiar, and clearly successful model, where a natural flow of conversation, discussion and contributions to online projects occur asynchronously, across disturbed physical location, with members sharing a common goal, and the ability to look beyond language, timezones, and other barriers to communicate and coordinate more efficiently.
Open source in 2015 is ubiquitous. Potentially every person benefiting from modern technology is also benefiting from open source solutions in some fashion. When you consider the international pool of developers contributing to the world's most popular open source projects, you have to wonder how they've been able to succeed without the benefit of managers, meetings, and code sprints. Upon researching how open source projects have succeeded, a set of principles that could be considered the tenets of the open development method start to emerge.
As part of an open development method, code quality is king. You should be asking key questions every time you write code:
Every question asked benefits not only you, but your team. When you write code in a such a way that another developer half a world away can sit down and start working on it immediately, without needing to ask any questions, you're helping improve your team's efficiency. Likewise, when you ensure your code is testable, you drastically cut down on the number of roadblocks your team may encounter. With modularity, you present code to your team that is both easily maintained and potentially recyclable for another project. And finally, economical code can save everyone from your team and future contributors, to clients and end-users—both time and money.
Developers do not necessarily enjoy documenting their code—that is no secret. Moreover, when they are subjected to the emergency room processes of a system such as Scrum, even if they wanted to document their code, chances are they will not have the time because priorities determined by the business often take precedence. The most significant piece of documentation you will write is your high-quality code, but that is not enough. Consider those who do not know the code, and those who have neither the time nor the desire to read it all. When your team focuses on documenting your projects appropriately, you are doing for your code the same thing that the popular TV show How It's Made does for its viewers by explaining away the complexities of your project and bringing it to a wider audience in an easier-to-digest fashion.
On a geographically diverse team in which you may not be able to receive help in real time, taking a test-first approach with code allows you to work with greater independence and fewer roadblocks. With testable code there are many benefits to consider. Let's take a look at Tim King's list of 12 benefits of writing unit tests first:
Everyone should have a say when it comes to discussing your project and direction. Never discount the marketing coordinator, the account manager, and non-coding designers. Everything is open to discussion, and when everyone is on has access to one another without needing to go through a chain of command, some of the most ingenious ideas and solutions can be discovered.
Although a veteran developer may dominate discussions due to their expertise, never disregard the new developer who has different, fresh ideas. The TODO Group Open Source Code of Conduct outlines general expectations of the community of a project that we can also consider when participating in team discussions:
Engendering user trust, promoting engagement with the community, and improving the security and stability of your project are traditionally considered separate goals on a roadmap for a project's success. But when your team embraces the open development method of transparency, all three goals can be achieved simultaneously.
From releasing a project's source code to making public the issue tracker and providing insights into internal processes and communications, the passion behind a project is apparent to anyone who comes in contact with it. When users and developers have access to these resources, your team will not only find many willing contributors, but greater respect and acceptance from the community. Transparency is a powerful marketing and working tool.
With startups, businesses, and open source projects distributing the workload to developers around the world, maintaining a certain level of synchronicity that a software development process like Scrum expects becomes difficult. For some groups, maintaining a daily Scrum meeting is unrealistic, and when you have five developers in five different countries, you can discount the possibility of paired programming. The software world today thrives on asynchronicity, and teams following the open development method can, too.
If someone has a question, he or she may send an email or post on a developer board with the expectation that their message will not get responded to for a while. Does that questioning developer stop their work? Not necessarily. With the need to be self-reliant and adaptable, developers can modify their expectations, focus on code quality, enhance their documentation, and improve their skills.
In addition to open discussions and sharing ideas within a project community, community members should be involved with the decision-making process. When decisions get made by closed-door board meetings, executives, or managers, it is usually with a narrow and limited point of view. When everyone is involved in the decision process, including the end-user or client, potential issues that would otherwise fail to get identified have a greater chance of being resolved before they become problems.
Rather than allow one person or a small number of people to develop this methodology, The process should be as open and inclusive as any other open source project.
There may be several missed priorities or points that need to be smoothed out, so please join the discussion on GitHub, and lets work together on creating a beautiful set of guidelines that will enable all development teams of all sizes to succeed.