Software Engineering in the Agile Manifesto

By Álvaro Ruiz de Mendarozqueta, Principal Project Manager.

“If you are not producing working, running, tested usable software in every single Sprint or iteration, you are not [yet] ‘doing’ Agile, you are not [yet] ‘doing’ Scrum.” — Ron Jeffries

Introduction

In his recent book, Clean Agile, Robert Martin states that the Agile Manifesto signees gathered with the aim of “creating a manifesto to introduce a more effective, lighter-weight approach for software development’ due to the ‘deplorable state of software development’.

Sometimes, because of the extensive deployment and usage of the Agile philosophy and of frameworks such as Scrum, the original focus on software is forgotten or it is not being considered as it used to be in that remote 2001 when the Manifesto was written. Not surprisingly, the Manifesto explicitly mentioned the software.

We would like to highlight the software engineering implications of delivering working software.

Agile Manifesto

We are uncovering better ways of developing software by doing it and by helping others do it. Through this work we have come to value:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Some of the principles behind the Agile Manifesto also emphasized the focus on software:

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
3. Working software is the primary measure of progress.

What is working software?

Working software is validated software that delivers value to the business, to the customers and the users. It is software that works well, does what it must do without errors, uses computer resources efficiently, and works in situations of security risks. It is software easily used and understood in all functionalities and situations; software that works in different situations without failure and that can be maintained.

In other words: working software makes your customers happy, has no bugs, it’s not slow, it doesn’t stop unexpectedly and it’s easy to use and understand. If you have a working software, the things you do with it are easily found, it keeps hackers away, your information is secured and the use of your computer efficient. Finally, software builders can modify, test, adapt, change and deploy it.

What is valuable software?

Gerald Weinberg, reviewing different definitions of ‘quality’ concluded that ‘quality is value for someone’.

As the stakeholders’ value is expressed in requirements, valuable software implements the customers’ needs into a software product that fulfills those needs and that is characterized by quality attributes.

What do we need to do to build working and valuable software?

We need to perform all the activities and best practices of the software development value chain.

The value chain is the transformation of our customer’s needs into a software product that fulfills those needs and it is characterized by the quality attributes.

The probability of building the right product increases with the application of the right construction. If you think that doing the right construction is expensive, try doing it with a bad construction.

We must establish an architecture of the solution and design it; develop the code, verify it with testing, apply peer review, and static analysis. Also, we must integrate software parts, build and test the software product components and validate them with the users, and deploy the software product in all the environments needed by the customers.

Software components must be managed, and product integrity should be maintained through configuration management.

The project team and their activities should be managed, measured, reviewed and improved continuously.

References:

1. Agile Manifesto.
2. Martin Robert. Clean Agile (Robert C. Martin Series) (p. 25). Pearson Education. Kindle Edition.
3. Article No Software: No Agile, No Scrum, by Ron Jeffries.
4. Weinberg, Gerald. Quality Software Management (Vol 1 Systems Thinking). Dorset House.
5. Article. Boehm, Barry. Improving Software Productivity. IEEE Software. 1987