Problems in Quality and Productivity of Agile Software Development in Theory and Practice: How to Overcome Them
Agile software development methodologies have gained much attention and popularity among software development companies. Agile is such a buzzword that even companies and teams outside software development try to incorporate it into their workflows.
There are many reasons for this popularity: Agile promises a shorter time to market, less waste of resources, better and quicker response to changes, earlier detection and fixing of defects, less bureaucracy, etc.
However, Agile development methodologies present specific challenges that may reduce the quality, productivity, and cost-effectiveness of the software development process. This case-study-based article uncovers these problems and seeks to find solutions.
This article is based on a theoretical discussion of the results of the literature research and the results of a case study in a software development company. The case study used observations, interviews, and questionnaires as data collection methods. The data were analyzed quantitatively and qualitatively.
Agile Software Development
The Agile approach to software development is most widely used today. It has many forms, including Scrum, Kanban, Extreme Programming, etc. Agile is an iterative software development methodology that values human communication and feedback, adapting to changes, and producing working results.
Iterativeness of Agile means that the work is done in a series of time-boxed pieces. The Scrum framework, arguably the most popular Agile framework, comes into the picture with its concept of Sprints – iterations of equal length. Agile is all about producing tangible, working results after each iteration. It is also about efficient communication over documentation or excessive endless meetings.
Agile is not a textbook, recipe, or certification but an approach and mindset. Formalizing it into a rigid template goes against everything that Agile is.
Software Quality Assurance
Every person has a subjective definition of quality. But more accepted definitions exist, one being “Quality is conformance to requirements” (Crosby 1979). The quality of a product can be described and evaluated from several different perspectives or dimensions (Garvin 1987): performance, reliability, durability, serviceability, aesthetics, features, perceived quality, and conformance to standards.
In practice, quality definitions, characteristics, and dimensions can be applied to software products as they can be used for any tangible or intangible product.
The software quality assurance process ensures that all software development processes and activities are actively monitored and compliant with the defined standards. Technically, it incorporates all software engineering processes, and its prime goal is to ensure that desired software quality level is met.
Measurable indicators are needed to improve software quality. While a total number of defects, bugs per story, bugs per line of code, and similar are helpful, we can use financial measurement – Cost of Quality (Crosby 1979), defined as:
Cost of Quality = Price of Nonconformance + Price of Conformance
where
Price of Nonconformance includes scrap, rework, claims, redesign, lost sales, etc., and
Price of Conformance includes testing, prevention, risk control, certifications, etc.
It is evident that achieving quality costs money, but not achieving it costs even more: it costs more when an organization must scrap or rework an item because of poor quality.
Problems of Agile Software Development in Theory
Being popular, Agile draws a fair amount of criticism. In 2012 a group of software engineering scientists published a Dark Agile Manifesto (Janes et al. 2012). The authors highlighted that many real-world companies often practice Agile as a rigid “the only true” framework, misunderstanding and twisting its philosophy.
Scrum, by far the most popular Agile methodology, also attracts criticism. By focusing on “user stories” (small units of functionality that bring value to customers), Scrum inadvertently hides the “macro vision” of the product. At the same time, Scrum is not providing necessary resources to the system level and infrastructural changes and improvements, as those “do not bring any direct value for customers.” User stories are also frequently seen as self-sufficient and independent. Many developers implement functionality considering only the user story in isolation while ignoring the large picture and system-level architecture.
Others (Gray 2015) criticize Scrum for becoming a formal, rigid methodology, which focuses on “wrong” things: the formality of the highly structured process, measurement of productivity, serving the needs of managers, high associated costs, etc. According to some researchers, Scrum is not well suited for software developments because of these issues.
Agile might not be the right approach for every software project, as it is built with certain assumptions. For example, developers need access to customers, an iterative process must be acceptable for the company and satisfy its business needs, the organizational structure must be simple enough, etc. If these requirements are not met, it is not easy to adhere to Agile principles.
Problems of Agile Software Development in Practice
Multiple interviews and observations were held at the case company. An extensive survey questionnaire was performed to identify possible problem areas and areas that would benefit most from changes in working practices and propose potential changes and corrections within the software engineering and software quality areas.
The main identified potentially troublesome areas were lower than desired software quality, not sophisticated enough testing environment, and too many annual major and minor software releases, leading to higher costs.
Suggestions to Solve These Problems in the Case Organization
As a result of the performed research and analysis, the following suggestions were proposed to the top management.
It is essential to institutionalize Software Quality Assurance. Top management and all company functions must take software quality topics seriously.
To satisfy business needs, we proposed reducing the number of major software releases from three to two annually while increasing their quality to eliminate the need for multiple minor software releases and to reduce the cost associated with software releases.
Another suggestion was to train software engineers in software quality and automated tests and train software testers in automated end-to-end testing. The number of automated tests must increase dramatically, and the company must allocate some development bandwidth for reducing technical debt. Also, a software release preparation cycle was proposed; implementing this cycle would increase software quality and reduce the amount of work and rework.
The final suggestion was to provide Agile training to all new employees and, possibly, move from Scrum to Kanban, as it will better match the de facto working process used by the software development teams.
Summary
Agile software development methods do not automatically produce high-quality software, but must be used wisely and applied in a way that is appropriate to each company’s specific situation. These issues should therefore be discussed openly within each organisation. Anonymous internal surveys and discussion forums can help in this respect. In this article we have shown how this can be done in practice.
References
Hnatiuk Roman (2022) Case Study: Improving Working Practices and Processes at a Software Company. Turku University of Applied Sciences, Master’s Thesis.
Garvin D. A. (1987) Competing in the Eight Dimensions of Quality. Harvard Business Review, September-October 1987.
Gray Aaron (2015) A Criticism of Scrum. https://www.aaron-gray.com/a-criticism-of-scrum/ (accessed on 2022-07-24).
Crosby Philip (1979) Quality is Free – The Art of Making Quality Certain. McGraw-Hill Book Company.
Janes Andrea, Succi Giancarlo (2012) The dark side of agile software development. Onward! 2012: Proceedings of the ACM international symposium on new ideas, new paradigms, and reflections on programming and software (October 2012).