Response to “Agile Software Development in China”


This article is a response to Agile Software Development in China by s1314857.

In the article, the author presents an overview of what Agile Software Development means and some of its principles together with the challenges firms in China are facing to adopt this methodology.

The main point of this article is to challenge one of the author’s main statement about why Chinese software businesses did not adopt Agile Methodologies (“non-large scale companies do not implement standard methods“). I  will argue that small companies can easily adopt Agile and I will provide examples and methods to overcome the possible challenges. In the first sections I will also touch a little bit on the structure of the article and suggest some improvements.

First let’s start with the Introduction

Where is the Introduction? There is no introduction.

While the author starts with a good overview of what Agile Development means, I found it hard to find a structure of the article, struggling to find an introduction paragraph. Therefore, I did not know of whether it will talk about software companies that use Agile or maybe Agile methodology successfully implemented in China. Only after reading the 3rd section everything became clearer.

In conclusion, I really think that this article would have benefited from a better organization, by providing an introductory paragraph which would mirror the conclusion.

Where do the ideas come from?

While some of his arguments are well structured, there is little evidence that can support his statements, like: “Firstly, there are lots of software companies in China, but few of them are large-scale.” or “Some Chinese development teams prefer the cowboy coding, which is a term refers to go-as-you-please and unplanned coding style.”.

Arguments like these bring little value to the content of the article and make it seem that the article brings many ideas into play. Also I do not understand if the arguments come from personal experience or they comes from a specialized source, therefore it fails to convince the reader about how Chinese businesses actually work.

In conclusion I find it quite hard to argue his statements since I do not really know the source. It should have been specified whether the ideas in the article come from personal experience or from a reliable source like a book or survey over the Chinese software companies and what the challenges they encounter are.

Agile in Small Companies

I will continue this section by studying some of the challenges a small team might encounter when using Agile techniques, but how easy it would be to overcome them. By looking at the size of the team, the number of projects a team can have in a sprint and how they handle refactoring I will try to demonstrate how Agile can be incorporated in the culture of a small team.

Size of the Team

Ever since the launch of this methodology, Agile development has been seen to fit small teams of experts. A team of four or six developers can therefore work perfectly.

The main roles in an Agile team are: Team lead (also called “Scrum Master”, who is responsible for facilitating the team, obtaining resources and protecting it from problems), Team member (developer, which can include modelling, programming, testing, release activities, etc. ), Product owner (person responsible for the prioritized work item list).  Also having an even number of programmers facilitates pair programming, and having a meeting with the whole team might just involve turning around the chairs.

There is no success scheme into implementing Agile Methodologies and each of them cam be adapted to the size of the team while maintaining a number of self-motivated team members.

Too many projects competing for limited number of developers

Smaller teams of developers sometimes spend too much time swapping between projects (people are not like supercomputers to switch context whenever its needed with no effects), so the efficiency of the team could reduce.

A solution to this problem would be to shorten the sprint length (the time period between two deliveries), so that the sprint can concentrate only on one project at the time. Even though unexpected problems might arise, solving them could be easily added to the next sprint rather than interrupting the current focus, giving us an increase in the productivity and quality of the code. A simple Kanban board (a simple model consists of three columns: “to-do”, “in progress”, “done”)  can also be used so that the team  to impose the constraints on the work that the developers are doing (limiting the work-in progress), so they do not do unplanned work.

In conclusion, there need to be some sort of compromises in regards to the amount of work a team undertakes during a certain sprint in order to keep the efficiency and productivity of the team to the maximum.

Refactoring older code

Time for deep refactoring is sometimes lacking in small teams that have many projects, although this is crucial in a Test-Driven Development approach and maintaining a clean code database.

This is where pair programming comes into help, having two sets of eyes on every ticket reduces the time for refactoring, this way developers help each other by talking about what kind of tests to write and go on for a better start. One problem that refactoring is addressing is about functionality that is never used and makes the code unreadable. By pairing the problem can easily be addressed and it is more likely to build in scope.

Many mistakes are caught as they are typed, pair programming encouraging code review.  This way refactoring can be done on the way as well, needing less time to spend afterwards.

Even though the time for refactoring older code is sometimes lacking, by using a pair programming approach helps us write better code,  more likely to build in scope and therefore spending less time for refactoring.


I have looked at some of the challenges that a small team might encounter when using Agile techniques and provided examples of how to overcome this problems. At its beginnings, Agile was designed for small teams and its purpose was to enhance communication and interaction. What make Agile methods different is the way they deal with development and how the teams need to adapt to this working culture based on communication and cooperation.