Sustainable Pace | Glossary


One of the principles behind the Agile Manifesto speaks about “Sustainable Pace”

“Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.”

Sustainable Pace is an essential part of Extreme Programming (XP), where Kent Beck suggests working no more than 40 hours a week, and never working overtime a s second week in a row. Working overtime sucks the spirit and motivation out of team. When team becomes tired and demoralised they will get less work done, no more, no matter how many hours are worked.  Instead of pushing people to do more than humanly possible change the project scope or timing.

To set development pace, team should take seriously that they must deliver completed, tested, integrated, production ready software at the end of iteration. Even if it is last day of iteration it is better for the entire team to re-focus on stories which can be completed than keeping many stories incomplete. Building a sustainable pace, as you plan your releases and iterations keeps team away from getting into death march. The team should aim for a work pace that they should be able to sustain indefinitely.

Sustainable Pace is not about taking it easy and going slow, instead it’s just the opposite. It is investing energy wisely by setting your focus on priority items, delivering at regular intervals i.e every iteration and regain strength without overburdening as a continuous process.

Further Reading:

Rule of Simplicity | Glossary


Kent Beck while developing Extreme Programming (XP) came up with rules of simple design. He recommended that developers should do the simplest thing that could possibly work. Simple code means you’re travelling light – low up-front investment, and not much to slow down when things needs to change. Simplicity is being recognised as one of values in XP, where programmers are encouraged to start with simplest solution which helps them to focus on designing and coding for the needs of today instead of tomorrow.

Rule of Simplicity

  1. Pass All Tests
  2. Clear, Expressive & Consistent
  3. Duplicates No Behaviour or Configuration
  4. Minimal Methods, Classes & Modules

With these rules, we can judge whether the code developed is simple enough. What we can derive is to think about what is most important, the code should work, pass all tests. The next most important thing is that the code should be easy to understand, therefore we need to ensure that it expresses every idea  with clarity. Even though the code works, we need to consider maintainability, see to that there is no duplicate code. This minimises cost and maximise benefits over the lifetime of the software.

Further Reading:

Book: Extreme Programming Explained: Embrace Change by Kent Beck
Book: Understanding the 4 Rules of Simple Design by Corey Haines
Book: Understanding Software by Max Kanat-Alexander