Strona głównaBlogWhy You Shouldn’t Use GitHub Issues and XDSD in Managing Your Projects

Październik 27, 2017 Management & HR

Why You Shouldn’t Use GitHub Issues and XDSD in Managing Your Projects

Efficient project management is the key to successful project delivery. At Polcode, we test many different PM methodologies for effectiveness and performance. Today, we’ll share with you two solutions for coordinating project work that didn’t meet our expectations, thus landing on our PM blacklist.

Reading Time: 2 minutes

#1 GitHub Issues

Source: guides.github.com

GitHub Issues is a GitHub module that helps users keep track of tasks and action items related to the code. Overall, GitHub is a useful code repository manager with a lot of features, but it lacks certain solutions necessary for the commercial use of a software house such as Polcode.

First of all, GitHub Issues doesn’t have a full set of features for tracking and managing SCRUM sprints. It also lacks automatic or manual task time logger—feature necessary to calculate project time properly.

Of course, GitHub Issues has a decent issue categorization and labeling feature, but because the issues can have multiple labels with various meanings with no reflection on actual issue status, chaos in the project is imminent.

These drawbacks can have a negative impact on the project calculation for both the client and the software development house. After all, the software house wants to be fairly remunerated and the client doesn’t want to pay for the work that isn’t documented.

The above is not to say that using GitHub Issues in software development is wrong. The tool just doesn’t work for commercial project management. Unless you invest in premium add-ons, GitHub Issues can lead to miscommunication, undermining your professionalism.

What to Do?

Instead of using GitHub Issues you should seek other, more effective issue trackers that have all features required for a given PM methodology. And if you fear losing GitHub Issues features such as commits or pull requests, there are many issue trackers out there that have integrations for those.

#2 XDSD (eXtremely Distributed Software Development)

XDSD is a software development methodology characterized by a completely different approach to project managing compared to other PM methodologies, such as SCRUM, Kanban, or Waterfall. Unfortunately, the innovative principles of XDSD failed to respond to our needs.

The biggest issue with XDSD is task completion and unclear DoD. Only the tasks subjectively finalized by the author or product owner are paid for, with a maximum of one-hour remuneration for each task or bug solved. Since various tasks and bugs require different time allotments to be solved, this can cause various problems. Also, the organizational overhead this methodology imposes could possibly be compensated only by tripling an hourly rate.

Key Takeaways

  • If GitHub Issues doesn’t work with your PM methodology, replace it with an issue tracker that does. You’ll avoid a potential project risk.
  • Be wary of XDSD methodology if you want to avoid organizational overhead.

To successfully carry out your software development projects, you need to be able to cut out all elements that underperform. If methodologies and tools you’ve been using don’t generate desired results, be sure to look for other solutions. Holding on to ineffective toolsets can negatively impact your performance and the quality of your work.

Dominik Raś,
Senior Project Manager

  • Timofey Solonin

    I wonder if you could express your reasons even more concisely…

  • Hey @timofeysolonin:disqus, I’ll assume you’re asking about XDSD because now I’m realizing that we really didn’t go into that much detail in this blog post. In general, XDSD seems to make sense for individuals. It’s concrete and innovative. If you check out Yegor Bugayenko online you’ll see that he lives and breathes XDSD and shows a tone of passion for it.

    Based on my experience, I noticed a lot of overhead in XDSD related to just getting started with each individual task, even the smallest ones. It often happens that after initial communication with the author of a task, after clarifying requirements via an issue on GitHub and after a noticeable amount of time devoted to estimation, the author decides not to proceed. That might happen after half an hour of research and estimation of a task that requires 1 hours of dev time. Hence, ROI appears to be low, unless you jack up your rates really high. So, in some cases, it turned out that ‚clients’ who decide or agree to work in XDSD face a risk of super high cost or too much time burnt on estimates, instead of delivering value to their customers faster.