Blog

Is there a better way to do software?

This is Part 4 of the series of articles "Why go Agile?"

Yes, there certainly is a better way to do software development. And at PSL we believe it is Agile, specifically under SCRUM. More than a development methodology, Agile answers to a philosophy and a perspective on what software development really is. Software development is not similar to civil engineering. In civil engineering, once a column or a girder is in place, it stays there. That is the building you built, period. In software, theoretically at least, things are "soft" –they can be changed, molded, expanded. This is one of the principles that makes software developments ever more challenging: they always can be changed, and because human being always seeks to improve or make things better, software applications always do change.

Engineers that evolved Agile, or particularly, that evolved SCRUM as one of Agile's main methodologies, were reacting to a system and a way of doing software that they believed did not work. The fathers of Agile realized that despite their efforts and their discipline in applying "traditional" software engineering methodologies such as RUP or SCRUM, they delivered projects off-schedule, out of budget and with functionality that did not fully meet the client's needs. Furthermore, they noticed that the relationship between the software developers and the client tended to be tense, defensive and sometimes outright quarrelsome –it was a constant fight between sticking to the initial requirements (what the developers fought for) and changing them to fit new needs (what the client fought for, but without increasing the price!). Agile methodologies in software were adapted from other industries that are intensive in creativity and inventiveness.

For example, Jeff Sutherland, one of the fathers of SCRUM, was inspired by an article in the Harvard Business Review written by Hirotaka Takeuchi and Ikujiro Nonaka about "The new new product development game". In the article, Takeuchi and Nonaka describe a new approach to electronic product development in which all phases of the project overlap, with the team working together across the different phases with an emphasis on quickly adapting to new challenges, and incorporating new ideas / modifications to the product, as they come into existence.

The fathers of agile realized that any software development project is very much like the invention of a new electronic gadget, for several reasons:

1) it is a "product" that has not existed before, therefore, its coming-into-being involves creativity and trial and error;

2) it is not possibly –or at the least it is very, very difficult—to estimate the time and effort it will take to iterate the product until it is first released to the public;

3) many people interact to make the product a reality, with different teams finally integrating their work into the "system as a whole" so that all components work seamlessly, in tandem;

4) the initial idea or first sketch of the product is very distant to its final representation (i.e. what Steve Jobs first thought an iphone would look like was fundamentally different from what it ended up looking like, and it would have been impossible, for Jobs or for anybody, to predict how long it would take and how much it would finally cost to iterate the "iphone" idea to completion).

Promoters of agile, and specifically of the SCRUM methodologies, sought a new way to manage software engineering that, instead of revealing against the nature of creating a new product, business model or process (all of which are made tangible through software), worked with the human qualities that are inherent to such a creative process. That is to say, they sought a methodology that would recognize that:

1) creativity follows no clock and sparks of genius come unexpectedly;

2) a person's capacity to imagine an intangible concept is limited, therefore, when the concept is made tangible –i.e. when a person first sees a software screen and "plays" with it—new ideas immediately come gushing in, and because many of them are good, they should be incorporated;

3) software is complex and often interacts with other systems in ways that are difficult to predict and foresee –therefore, any exercises to plan ahead will almost always end up incomplete;

4) iterative and incremental processes are best at creating malleable ideas and maturing them until they are ready for the market.

In essence, then, the agile software development movement sought to create a process –a methodology—that was adaptive rather than predictive. By adaptive we mean a software process that is able to incorporate new ideas, even potential changes of direction, without creating havoc in the projects flow and organization, and without imposing unnecessary costs on the development itself.

About PSL: PSL specializes in outsourcing and nearshoring Agile software development, software maintenance, quality assurance and staff augmentation. With offices in Colombia, Mexico and the US, PSL has customers all over Latin and North America, ranging from tech startups to Fortune 500 companies. 

So, how Agile Software Development stacks in pract...
What was the end result of traditional software de...
 

Comments

No comments made yet. Be the first to submit a comment
Already Registered? Login Here
Guest
Thursday, 21 June 2018

Captcha Image