Software Engineering in the Agile Manifesto

Software Engineering in the Agile Manifesto

(by Carlos Fau and Alvaro Ruiz de Mendarozqueta)

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 Manifest 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 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

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.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
7. 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 has to do without errors, that 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. Last but not least, 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.
We have to establish an architecture of the solution and design it; develop the code, verify it with testing, apply peer review, and static analysis. Also, we have to integrate software parts, build and test the software product components and validate them with the users, and to deploy the software product in all the environments needed by the customers.
Software components must be managed and product integrity should be kept through configuration management.
The project team and their activities should be managed, measured, reviewed and improved continuously. 

These are the right construction activities that lead to the right product: working software.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.

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