Agile principles: sustainability

Sustainability is the final topic in our series interpreting the principles of the Agile Manifesto, which is twenty-two years old this year. (Previous articles in the series can be found here: customer satisfaction, change vs product design, team, communication.

The importance of sustainability, and the challenge it posed to the software industry in the early 2000s, is clearly demonstrated by the fact that a quarter of the twelve principles of the Manifesto, three principles, are devoted to this issue. Sustainability is associated with terms such as stability, reliability, predictability and longevity. No wonder, then, that the creators of the Manifesto were so concerned about this issue.

Can a product development methodology be developed that ensures sustainability in itself? As much as we would like to, life always brings surprises and plans can easily be derailed. How can we reduce the negative effects of unexpected events and get back to a healthy “business as usual” mode as soon as possible? Is there any way to prepare for them?

Objective

The eighth principle clearly states the objective: “Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.”

This principle does not yet help in implementation, it merely draws attention to the objective. But if we combine it with the Agile concept of self-organisation we have already learned about, we can easily translate it into practical advice. One aspect of self-organisation is that the product development team, i.e. the people who actually carry out the development work, determine how much they can do in a given unit of time. How does this relate to sustainability?

If the product development team is over-planning iterations, taking on more than it can reliably deliver:

– 1. not all the work will be completed,
– 2. or not of the right quality,
– 3. or only completed with more effort (overtime) than planned.

The first case is the simplest, if iterations fail sequentially, then the constant pace required is unknown, making it impossible to plan.

Of course, if the finished work is not of the right quality, you could say that it is not really completed. It is a qualified case, however, because this shortcoming is often not easy to spot. Thus, in the longer term, it undermines sustainability, with subsequent iterations building on an unstable foundation.

And the last point is a personal one that violates sustainability, as overwork is only sustainable for a very short period of time. And even then it is dangerous, because a tired person makes more mistakes, so a vicious cycle can easily develop: you have to work harder to correct mistakes made when you were tired, but this leads to even more fatigue… Unfortunately, this point supports the criticism of the Scrum methodology that, although it fits well into the language borrowed from Rugby, it was an unfortunate choice to call the iterations Sprints. After all, during a Sprint, the runner gives it their all, exhausts themself at the end and needs to rest. But in Scrum, a Sprint is not followed by a rest period, but another Sprint.

So, setting the speed too fast is not sustainable, as previously covered in our article: Do you want to achieve more in the sprint? Work less!

But what about moving too slowly? Fortunately, the principle under review is not just about product developers, the list points out that sustainability is also of a goal for sponsors. Deliberately slow development is far more expensive than necessary, overburdening sponsors while giving competitors a market advantage. Too low a speed is therefore commercially unsustainable.

An experienced Scrum Master can help you find the right speed. You can also learn more about this topic in our Advanced Scrum Master training.

Solution One: quality and technical design

The ninth principle helps to achieve the goal set out in the eighth principle: “Continuous attention to technical excellence and good design enhances agility.”

We must draw attention to the ambiguity of the Hungarian translation: ‘a good plan’ in this case means a technical design and not a plan for implementation, project plan, etc. We wrote about the latter in the change vs planning section. We discussed the latter in the change vs product design section.

Technical excellence, i.e. quality

We don’t build castles on quicksand. Meeting clear quality standards is essential for sustainability. What we mean by quality may vary from industry to industry. However, as a general point, it is important to pay sufficient attention not only to the “visible” quality of the product, as perceived by the user, but also to the “internal”, technical quality. No matter how beautiful the cover of your product is, if the parts inside are rusty, sooner or later the machine will break down.

The question asked in the introduction, how to reduce the negative effects of unexpected events and get back to healthy functioning as soon as possible, is answered here. By ensuring technical quality. Sometimes, it is necessary to hurry. We found a bug that causes millions of dollars of damage every minute. In such cases, we don’t need a future-proof solution, but a quick fix. Initially. But we cannot stop here. After the fire is out, you must take the time to find a future-proof solution and implement it. Read more on this topic in our article Eliminate technical debt, we can help!

Good design

What is a good Agile design? Because of the differences in the industry, it is difficult to give specific suggestions, so we will give you some ideas.

Agile design is like putting together a puzzle: first you find the corners and pin them down. Then the frame. And then we fill in the content as the product develops.

Where multiple options come up in the design, it makes sense to choose the easiest to add/expand or the cheapest to replace.

If the product development team has an insight into expected future needs, it can deliver solutions with more confidence that do not require too much redesign when future needs arise.

Solution two: improving the process

One of the keys to sustainable development is continuous improvement. In the introduction, we also asked whether it is possible to prepare for unexpected situations. By definition, of course not, hence contingencies. But it is possible to design a process that is sufficiently resilient. This is what the last, twelfth principle is about: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”

Regular reflection, the technique of regularly fine-tuning the process, has become known in Scrum methodology as retrospective. Its importance has been discussed in several articles:

– Retrospective meeting – Why is it important to look back?
– “No need for a retrospective, we are so good at dealing with problems on the fly”

A common understanding of Agile principles is key. If you feel you need help with this, we recommend our online Scrum / Agile Elevation training designed for Agile teams.