I am new to Project Management. I was reading the Agile Manifesto Principles and would like to understand what "sustainable development" means in the following principle:
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Maybe some practical examples?
One of the fundamental tenets of the Agile software development methodology is sustainable development. Sustainable development in the context of Agile refers to a development process that can go on indefinitely without endangering the development team or the organisation as a whole.
This means that both the long-term health and wellbeing of the development team and the organisation as a whole should be given top priority while designing the Agile development process. This comprises:
Keeping a balanced work-life schedule: Agile teams should make an effort to have a work tempo that is sustainable, enables team members to put in appropriate hours, and prevents burnout.
Technical excellence should be prioritised: Agile teams should concentrate on developing high-quality software that is simple to maintain and flexible enough to be adjusted to changing requirements over time.
Handling technical debt: To prevent technical debt from becoming a significant burden over time, agile teams should take proactive measures to manage it (i.e., the expense of maintaining and reworking current code).
Constant improvement is essential for agile teams if they want to make sure that their development process is long-lasting and productive.
Agile processes promote sustainable development.
The explanation is right in the next sentence:
The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
It means that if your team roughly did an amount of work in one sprint (or whatever word you use in that methodology to measure an amount of time), the goal is that this amount of work can be done any sprint. So that you can plan with that. If you only managed the amount of work with a huge amount of overtime for example, it is not sustainable, because there is no way all the people will do that amount of overtime every single sprint. If you only managed to pull that amount of work off with three additional short term contractors, you cannot achieve the same when the contractors are done. Not sustainable.
"sustainable" means "able to be maintained at a certain rate or level." and that is exactly the meaning here. Not a short term increase (or decrease), but a level that is constant and can be used to plan out further steps.
The meaning is stated within the principle itself: the sponsors, developers, and users should be able to maintain a constant pace indefinitely.
The answer from nvoigt is on point and provides examples of sustainable and non sustainable approaches. There is just one thing I want to add to the existing answer, and that is to consider some context surrounding the Agile principles.
Agile showed up as an alternative to the documentation driven, heavyweight software development processes of the time (still there to this day), i.e. predictive approaches such as Waterfall, with fixed processes and steps, and most importantly, deadlines on when each phase was supposed to be finished.
Waterfall or predictive approaches have their place, but for most software development initiatives they don't work, simply because the methodology does not fit the nature of the product being developed with it.
So what tended to happen was that the early stages went at a reasonable pace, but the more you developed, the more you learned about what you were doing, and with new insight and understanding, it became obvious that what was estimated and planned at the beginning was not realistic. In other words, you would be missing the deadline.
So how was this solved? Acknowledge the error, stop, re-evaluate, re-estimate and decide on a new deadline extrapolated from the additional acquired knowledge?
Nope!
Overtime. Crunch time. Death marches. Basically, putting more pressure on people to work more hours to still hit the fixed agreement committed at the beginning on the project when you knew the least about what you were building.
Choosing that approach causes people to burn out, make mistakes, take shortcuts, miss things, etc., which in turn decreases the quality of the product, which then has more bugs, which need to be fixed, which require more overtime, more stress, and more pressure, until the project either ends somehow, or people have enough and leave.
That's not sustainable! So, as a response to that, Agile methods promote sustainable development.
Agile processes are often designed around terms of "pace" or "velocity", i.e. some measure based on often purely virtually-scaled story points, and some experience about how many story points "fit" into a given time interval - a sprint for sprint-based methods, or something else for continuous methods like Kanban. I'll stick with Scrum terms here for simplicity.
"Sustainable" then means that the development team (but also other critical roles like process owners) should do only so much work that they run within their capability; in other words, avoid running into overtime, burnout, stress-induced negligence or other negative outcomes.
Depending on the particular agile method employed, there also may be other facets which go into this direction. In Scrum, the Sprint Backlog is arguably the most important artifact of the method; and ideally it is sized such that said "sustainable" workload is not surpassed, but also, very importantly, outside changes to the sprint content during the running sprint are highly discouraged. On the other side of the coin, the team promises to finish the stories as best as it can. This means that developers know pretty well what to do in the next 2-3 weeks, and can plan around their upcoming work nicely.
Sometimes the matter of the fact is that a team has to stomach unplanned work, i.e. if it is working as a highly integrated DevOps team, handling unplanned incidents next to the planned stories. In that case it can be worthwhile to reserve some percentage of capacity (say 20%) just for random incidents, and still be overall sustainable. In this case it would be fatal to always plan for 100% as any incident would lead to stress. If there is time left at the end of the sprint, stories can still always picked form the backlog.
"Indefinitely" literally means that. Opposed to projects in the distant past, where it was normal to have a long period of quiet work and then a few ultra hectic months nearing the delivery deadline, agile processes (together with software architecture aspects like CI/CD, focus on smaller packages like microservices instead of monoliths, and so on) should be structured so that there simply are no important deadlines (aside from the end of the current sprint - which is a very foreseeable and manageable event). If this is achieved properly, you can just work all day, every day, and the load will always be the same - sustainable, forever.
A good process of course takes changes into account; i.e. when people go onto vacations, new people join the team, people leave the team, or when other constraints change, but within a horizon of 2-3 sprints, Agile can make all of this very achievable.
This one isn't really a principle at all, more like an observation about what the effect of taking an agile approach might be. As per Bogdan's great answer, the manifesto's view of sustainability may be best understood as a reaction to some undesirable situations inflicted on development teams in the past.
DevOps techniques have in any case far overtaken what the manifesto authors' considered a sustainable cadence (two weeks). It's also debatable whether teams really should aim to deliver at the same pace indefinitely. Productivity tends to be cyclical for very sensible reasons and variations in pace over a longer timescale seem to be implicitly acknowledged by modern versions of agile frameworks, for example product goals in Scrum and product increments in SAFe.
Some practical examples of sustainable development:
I would like to bring up another viewpoint: The business customer which requests a change with IT involvment.
Think about the outside perspective: IT is often perceived as something "different" and not an integral part and enabler for business opportunities. So if you tell me you will do X in 20 weeks i trust that you understood my request, knows what has to be done on your side and I can forget about until delivery. If you then come back with detailed questions because something was not specified exactly enough and you tell me you will need an additional 4 weeks I will be annoyed because we talked about everything beforehand as you requested.
Now comes the agile approach: You deliver the part which is well-defined first. And then you come back and ask me: Is this what you wanted? I can reflect and use the time to further my idea. Maybe I see something i didn't before because now the idea got more "real" and i see constraints/dependencies. But I already have part of what I want.
With each iteration,this gets better because I am able to understand the level required for IT better and IT understands more of the use case over time, and can decide things for themselves, if it serves the ultimate purpose.
This builds trust, and know I will always receive something valuable while iterating and not only at the end. It's also sustainable for the business customer, because I can cut the work idea into tranches and work on different parts over time, while learning about the implications, and getting a feel for the real product. This lessens the load on me either while specifying or on the acceptance test side.
Agile methodologies encourage sustainable development, by promoting a constant and realistic pace for sponsors, developers, and users. Rather than setting unrealistic expectations, which can lead to burnout and high turnover rates, the focus is on maintaining team morale and work-life balance.
In practice, before each sprint: development teams carefully estimate the amount of work that can be committed. This ensures expectations to be realistic and that teams do not overpromise on deliverables. Once the sprint begins, no additional tasks are added ( unless it's absolutely a necessary) with product managers acting as gatekeepers to reduce stakeholder's noise.
Product managers should cultivate a sense of psychological safety within the cross-functional team to further support sustainable development, encouraging open communication and feedback.
By following these principles, agile processes can lead to more sustainable development practices and, ultimately, to better outcomes for all actors involved.
