With office space at a premium and a growing embrace of flexible working hours, the future of work is going to be distributed. As a result, for many programmers, the full time freelance lifestyle is ever more viable. However, with this evolving career path, new obstacles emerge for both employers and developers.

Traditional methodologies for managing work teams such as Kanban, Scrum, and even Agile, were all originally predicated on having at least one centralised team at the core of a workflow. Whilst these may be effective for large networks of remote workers, they can become less effective when the ‘team’ constitutes a solitary remote coder and project owner. However, Yegor Bugayenko believes he may have hit upon a new methodology for the age of outsource: eXtremely Distributed Software Development (XDSD) – a technique borne out of his own frustrations as a project manager.

In this interview, Bugayenko explains how he conceived the idea of XDSD, how it works for his company, and the fundamental pillars of the practice. 

Voxxed: What was your motivation for developing XDSD?

Bugayenko: I was a CEO and an owner of a traditional outsourcing company, with a 120-people office in Ukraine. It’s not a secret to everybody that the majority of outsourcing projects simply fail. This can happen for many reasons, but all of them have their roots in our inability to manage people who are working full-time on a monthly payroll. I even wrote an article about it recently.

Seven years ago, in 2009, I realised that it was time to change something. It was time to invent a new form of management which will put programmers and project owners truly into the same boat.

A management style should make all project participants interested in project success, not only in a monthly paycheck. That’s how XDSD was born. I created it mostly for my personal needs, but realised that the methodology must be public and open to everybody.

Can you break down the four fundamental principles of XDSD for us?

  1. Everyone gets paid for verified deliverables

This literally means that everybody gets payments only when they deliver something to the project. In other words, we don’t pay for time. We don’t pay for hours spent in front of computer. We pay only for delivered results. This may sound extreme, but that’s how we work for over three years now. Moreover, all deliverables must be verified by someone else – each contribution, each line of code must pass a code review. In our projects we do two code reviews for each change. (More here)

  1. Defects are planned and don’t block delivery

This means that we encourage everybody to make bugs and report bugs. This may also sound illogical, but in practice this gives a very positive effect. Our programmers are not afraid of bugs, they are free to make them and commit, provided their code passes the code reviews I mentioned above. In each project, we estimate how many bugs we’re planning to find and pay programmers for finding them. We also realise that all products have bugs and don’t stop delivery when bugs are still there. (More here)

  1. Quality-of-code metrics are CI gate conditions

We don’t allow anyone to break our quality-of-code rules, ever. This is a rather unusual approach, which very few teams can afford to practice. We basically keep our code base always in a perfect state. Even under time pressure we don’t allow anyone to cut quality corners. (More here)

  1. Master branch is read-only

This is the last and the most important rule, which epitomises the previous three. We simply don’t allow anyone to make any changes directly to the main repository. Everybody must come through pull requests, which will go through code reviews and quality-of-code control. Then, if everything is OK, the pull request is merged and its author gets the money. (More here)

How does it compare/overlap with other well-known methodologies like Agile, Kanban, etc.?

Existing methodologies simply don’t work and we all know that. Agile, which was popular in the past, is more like a joke now for modern software teams. Programmers understand that via Agile, product owners simply can’t control them. Instead, programmers control product owners.

Programmers dictate what will be done, when and how much will that cost. Moreover, programmers own the source code, making it impossible for project sponsors to rotate them or simply fire.

Agile, as far as I understand it, was invented by programmers, not business people. To the contrary, XDSD was invented by business and for business. At the same time, XDSD was created by programmers. This perfect overlap of interests makes XDSD really effective.

To summarise, I would say that Agile is dying and will be replaced by more advanced and effective methods. XDSD is one of them.

What are the biggest challenges in managing freelancers in your experience?

The biggest problem is that well-known “Definition Of Done” (DoD). Freelancers are the most difficult type of personnel to manage, but the most effective one, if you manage them correctly.

They only care about their personal income and personal growth. For many managers, this can be scary, and they prefer to work with on-site in-house programmers, who are much easier to manage.

In XDSD we found mechanisms and instruments for making the Definition of Done transparent and clear for everybody. That’s why our freelancers, even though they care only about themselves, are valuable and effective contributors to the projects they are working on.

How do you see XDSD as a tool to reduce developer stress?

Because we don’t require them to commit to anything, our programmers working under the XDSD model are completely stress free. We don’t set any deadlines or milestones, etc. We don’t have any meetings or status checks. We let them work when they feel like it.

On the other hand, we also don’t commit to anything except a promise to pay when the work is done. We don’t teach them, we don’t help them, we don’t patronise them.

We don’t care when they have problems or simply don’t know how to do something. They are not like kids to us. They are adults and we treat them like adults. Not surprisingly, only 15-20% of all programmers who come to us can survive in this mode. But those who survive are very happy. 

Do you think it could it help with the issue of burnout?

Definitely. We don’t have anything like that in our teams. Programmers are free to do the tasks they like to do. They can reject any task, they can stop any moment and come back later. We never ever talk to them in Skype or Slack. We don’t have any meetings or milestones. We just give them tasks and they are free to complete them when they want. If they don’t complete in 10 days, we simply give the task to someone else, without even asking what was the reason for non-completion.

In the past, methodologies like Agile have become somewhat diluted/mis-applied in the hands of marketers. Do you see this as a potential issue for XDSD?

We’re planning to start a massive marketing campaign of XDSD at the end of this year. We will be the only provider of the methodology and its instruments. Thus, we are not afraid of any mis-applications. We will help companies adopt XDSD and will train and consult them. Until then, we are still in R&D mode, making final improvements to XDSD, making sure it works perfectly in commercial projects.


XDSD: An eXtreme New Take on Managing Distributed Developers

About The Author
- Editor of Voxxed.com, focusing on all things Java, JVM, cloud-y, methodical, future-fantastic, and everything in between. Got a piece of news, article or tutorial you'd like to share with your fellow Voxxians? Drop us a line at info@voxxed.com

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>