Comparing Agile and Waterfall Values

12 April 2013

The cleverness and dexterity of Egyptian workmanship, as evidenced in the pyramids, is magnificent. In them we can see the unlimited human capacity for imagination and architecture. Even today, researchers still study the organizational chart and construction aspects of these impressive monuments, because they required precise architectural planning, millions of slaves, and a huge amount of construction time.

After thousands of years, we continue to evolve as regards project management, but we can still observe the traditional division of tasks and hierarchical command structure: the customer (Pharaoh), architects and engineers (his vassals), analysts and developers (servants). This systemic thinking was the key to the success of large projects in the past, and today it continues to guide grand endeavors in many fields.

Waterfall, which was widely used for decades on civil, mechanical, and electrical engineering projects, spread to software development projects. However, the consensus today is that Waterfall does not masterfully meet the specific demands of an effective software project.

As a result, we note the gradual evolution toward Agile. This method was developed to make software maintenance dynamic, aiming for the highest levels of applicability with aggregated value for the owner. Keeping this in mind, we notice lower quality using the traditional Waterfall method, because it doesn't prioritize dynamic revision of the project, instead immobilizing it and delivering lower value to the user.

Agile method

It's commonly observed in software development that the customer is usually dissatisfied with the solution delivered at the end of the project. It's usual and expected that, in the middle of the project, new elements nobody imagined will pop up and the priorities of the project may be altered. It's aggravating when we see the end user not using many functionalities of the solution, which translates into a big waste of time and money. The project scope can and may change drastically over time, which indicates that we work with a nebulous and inexact logic.

Agile assumes that everything is in transformation and that the solution demanded yesterday may not solve the problem that created it. We need only observe the advances in information systems technology over the past two decades, starting with the creation of the internet by Tim Berners-Lee in 1992. Today we have the fervor and creativity of social networks, which explain to us in explicit detail the challenges of the modern world and the competitiveness resulting from the current economic system.

This model of the information society reflects on our training as software engineers, which includes responsibility for designing and developing mutable applications that bring competitive value to companies, based on two foundations:

  • Effectiveness: To carry out precisely the task that was detailed in the last project evaluation meeting
  • Efficiency: To implement the desired functionality without wasting time, money, and/or energy, bringing more value to the customer

Scrum framework

To avoid being labeled as a loose process based on creativity without a focus on value, a procedural approach to task execution called the Scrum framework was developed. This proposes that before developing software, it's necessary to define a vision, which synthesizes the project's initial documents and explains the goal to be achieved. That is, something vague, but what the customer will express as the macro solution to an identified problem. For example: a stock control system for my shoe store.

Product owner (P.O.)

In the case of a customer who desires management software, as in the example above, the software company should assign a professional who will be the dynamic link who recognizes what value means to the customer in this project and can forward this information to the development team. When this professional is located in this strategic position — as the product owner (P.O.) — the project can begin with a clear path to navigate, established priorities, and a dynamic channel between the customer and the development team. This link allows the original project to be updated in accordance with new perceptions from the customer.

It is up to the P.O. to detail system functionalities, called the product backlog. This list of requirements brings together the customer's desired functionalities in greater detail, specifying items of value as well as the customer's perceived priority level. However, due to the dynamic nature of the customer's scenario, it's expected that the list can be modified by the P.O. at any time during the project.

Other benefits: Development team structure

The use of the Scrum framework to make everyday adjustments to the way the development team works is also one of the indirect benefits of Agile. In this way, the organizational structure of the development teams becomes more agile and efficient, so they can organize themselves and take better advantage of the team skill set.

It's well known that a member of a development team can perform many functions on a project: design the structure, program functionalities, test the application, document, etc. As such, the "polymorphism" of a good developer is valued, encouraging cooperation between team members in tasks and making members focus on the effective delivery of the project.

Final reflections

As in all branches of science, innovation follows the evolution of society, and it will always emerge to address a new topic that wasn't seen as relevant when the theory was laid out. In the face of dynamic social evolution, it is urgent that we concentrate on our paradigms, rearranging them so we don't lose our competitiveness.

For us software developers, things won't be any different. Those who easily adapt to this change without losing current levels of productivity will better be able to capitalize on these benefits in their careers. We can reflect on the great thought expressed in 500 B.C. by the Chinese philosopher Confucius: "Only what changes remains."


Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 4.5 (4 ratings)

Comments

Sameer Chudaman Patil, CSP,CSM,CSPO, 4/16/2013 11:25:22 PM
Very nice Article which proves why we need Agile in today's competitive world.
Just one comment here:
Product backlog is high level Epics/requirements and not documented in greater detail. Its team and PO who groom these requirements together.
Michael Brashier, CSM,CSPO, 4/19/2013 11:36:35 AM
Sameer,
Entries in the product backlog often start as high level Epics/requirements. The team (including PO) groom the backlog. However, you need to remember that the PO is responsible for the requirements and the priority. The team sizes the stories or informs the PO of changes required so that the story can be sized.
There is no requirement that the backlog only contain high level Epics/requirements. In fact as items come to the top of the backlog I would expect Epics to be decomposed into stories and larger stories decomposed into smaller stories. It is also the case (if the business has very specific requirements) that a Story can enter the backlog with very specific requirements.

You must Login or Signup to comment.