Scrum is dead: breaking down the new open development method

http://opensource.com/business/15/11/open-development-method

"Snake oil salesman" is a phrase that conjures up images of stuffy old men with bowler hats, bushy mustaches, and tailored pinstripe suits peddling bottles filled with "cure-all" liquids. Although prevalent a few centuries ago, the snake oil profession is now lost to the annals of history. These days the snake oil description has expanded beyond human health care. In the tech world, for example, a snake oil solution can be used to describe anti-virus software or a favorite software development process.
Among the most "oversold as a cure" methodologies introduced to business development teams today is Scrum, which is one of several agile approaches to software development and introduced as a way to streamline the process. Scrum has become something of an intractable method, complete with its own holy text, the Manifesto for Agile Software Development, and daily devotions (a.k.a., Scrum meetings).
Although Scrum may have made more sense when it was being developed in the early '90s, much has changed over the years. Startups and businesses have work forces spread over many countries and time zones, making sharing offices more difficult for employees. As our workforce world evolves, our software development methods should evolve, too.

Open technologies today

Startups and businesses are being founded on the ideals of open technologies, and even more established corporate entities, including Microsoft, are embracing all things open. Matt Asay does a good job of describing the current state of affairs:

Ten years ago, a new open source company or project was news. Not anymore. Open source dominates mobile, with Android displacing the seemingly unbeatable iOS in both smartphones and tablets. Open source also dominates cloud, with every significant cloud platform except Azure built using open source. And even Azure treats open source technologies as first-class citizens on its platform. And open source dominates Big Data, with Hadoop and NoSQL technologies the major forces used for managing the world's data explosion.

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. When I began researching how open source projects have succeeded, I realized they share a set of principles that could be considered the tenets of the open development method.

The tenets of the open development method

Code quality

As part of an open development method, code quality is king. You should be asking key questions every time you write code:

1. Is this code legible?
2. Is this code testable?
3. Is this code modular?
4. Is this code economical?

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.

Documentation

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.

Testing

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 tips from the Perl Shop:

1. Unit tests prove that your code actually works.
2. You get a low-level regression-test suite.
3. You can improve the design without breaking it.
4. It's more fun to code with them than without.
5. They demonstrate concrete progress.
6. Unit tests are a form of sample code.
7. It forces you to plan before you code.
8. It reduces the cost of bugs.
9. It's even better than code inspections.
10. It virtually eliminates coder's block.
11. Unit tests make better designs.
12. It's faster than writing code without tests.

Discussions

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:

1. Be friendly and patient.
2. Be welcoming.
3. Be considerate.
4. Be respectful.
5. Be careful in the words that we choose.
6. Try to understand why we disagree.

Transparency

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.

Asynchronicity

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.

Democracy

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 (what I would call single points of failure), 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.

Building the open development method together

Rather than allow only myself or a small number of people to develop this methodology, I believe the process should be as open and inclusive as any other open source project.
There may be several priorities that I have missed or points that need to be smoothed out, so please join me on GitHub, where I am continuing the discussion and working on creating a beautiful set of guidelines that will enable all development teams of all sizes to succeed.