Agile Principles: Change vs Product Design

In addition to customer satisfaction, an important central idea of agility is to prepare for change. As a customer, as a client, this is perhaps the most attractive proposition of agility, but on the development side the idea that requirements can change late in the product development phase can be frightening. Where is the truth? Can the customer really change their mind at any time? How can product development prepare for this?

Let’s see what the Agile principles say about this.

The importance of change

The activity known as change management in traditional project management, tracking and managing change, is not a separate activity in agility, but part of day-to-day operations.

The second Agile principle is: Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage. (“Elfogadjuk, hogy a követelmények változhatnak akár a fejlesztés vége felé is. Az agilis eljárások a változásból versenyelőnyt kovácsolnak az ügyfél számára.”)

Unfortunately, the Hungarian translation is not entirely accurate in this case either, the verb “to accept” (“elfogadjuk”) being more of a verb of resignation, as opposed to the English verb “to welcome”. Of course, in practice, forced resignation is a more common reaction to change than genuine joy, but it is not necessarily the fault of change itself.

Let’s break down the changes that can potentially occur during product development, introducing the concept of positive and negative changes.

We consider a change to be negative if we have to make changes to an already finished product or part of a product, or even throw away the results of our previous work, because, for example: we misunderstood each other, we didn’t think through the assignment properly, there was not the right level of communication between the client side and the product development side, etc. A lot of the horror stories and dark legends of product development stem from such changes, with excellent examples being the real estate renovation fail photos we all know and are usually accompanied by such dialogues:

– How could you not think that through …?
– But you didn’t say that …!


These negative changes can also be called avoidable changes. As much as agility encourages a positive reception of change, changes that fall into this category should not be welcomed. Frustration is justified, and not only is it not our goal to welcome them, but it is of paramount importance to minimise them, as they are not only frustrating but also costly.

But there are also positive changes. A positive change is when the product increment provides us with information and knowledge that we can use to improve the product. The key to creating and stimulating positive change is to assess what we don’t know and find the smallest piece of the product building which is sufficient to determine the right direction to take. Such changes are most obvious in R&D type projects, where it is easiest to see how much we don’t know. It is important, therefore, to distinguish between what we know for sure and what we assume we know, and to test and verify the latter before we start any serious development based on them.

In our fast-changing world, a third category of change is emerging: external, independent change. The market, industrial, political, regulatory and control environment is constantly changing, there are likely to be competitors in the market, etc. While these changes are not always welcome, the ability to respond quickly to them is essential for success.

As we explained in our article What does Agile mean?, one of the most important factors that can help you decide whether agility is needed in an organisation is the chances of a large amount of change occurring during product development.

Can the customer really change their mind at any time?

Yes. As long as they accept the consequences and costs of making changes, in extreme cases even having to scrap the entire finished product and start from scratch. However, it is in their own best interest to manage change appropriately: minimise negative or avoidable changes, prepare for external changes where possible, and stimulate positive changes.

A very important tip to avoid negative changes is from the fourth Agile principle: “Business people and developers must work together daily throughout the project.” („Az üzleti szakértők és a szoftverfejlesztők dolgozzanak együtt minden nap, a projekt teljes időtartamában.”)

Another slight inaccuracy in the Hungarian translation: “developers” are translated to “szoftverfejlesztők”, meaning software developers specifically. In all our articles, we regularly point out that although agility was born in IT, it can be used in many other industries. Therefore, outside of IT, it makes sense to use the term product developer instead of software developer. The term software developer is not even appropriate in an IT context, as it is not only about collaboration between business experts and programmers, but also about collaboration between the whole business side and the whole product development side (QA, testing, support, tech writers, operators, etc.).

Experience in software development shows that a significant proportion of avoidable changes result from communication errors, often due to ambiguity in written communication. This is prevented by daily collaboration between all parties involved. Although in the short term this increased communication increases the cost of product development, in the long term, precisely because of the reduction in avoidable errors, this investment pays off.

Learn more about communicating between the business side and product development in our Advanced Product Owner training.

How can product development prepare for changes?

“Simplicity – the art of maximizing the amount of work not done – is essential.” says the tenth principle.

This principle encourages us never to create a more complex product than is sufficient to meet the customers’ needs known at the time. It is a natural engineering attitude to extend and generalise a problem, to produce an elegant solution that will answer problems that may arise in the next fifty years, yet experience has shown that such over-engineered solutions are usually unnecessary.

The simpler (technically) the product, the easier it is to make changes to it. Of course, you can prepare for future needs that are already well known, by leaving the relevant doors open. Since the implementation of this principle is very industry-dependent, we can only illustrate the concept of Agile design with a common example: at the beginning of Agile product development, instead of planning the whole solution in advance, as in a game of puzzle, we first find the cornerstones, the frames, and then the details are worked out during development, in continuous consultation with the business side.