As we celebrate the 21 years of agile manifesto (link) we are now way past the half-mark and arrive on the agile principle # 8, which is such a hallmark of good software development.
Agile Principle #8 says:
“Agile processes promote sustainable development.The sponsors, developers, and users should be able to maintain a constant pace indefinitely.”
Rather watch / listen? Youtube it is! Otherwise, keep reading.
Sustainability is something we understand for the health of the planet and its ecosystems. It’s actually a keyword for health in anything you do. Here’s what I mean:
I used to run road races and my favorite was the half-marathon. Anyone who is moderately serious about their running (or biking, or any sports) even at amateur level, knows the dangers of overdoing it or of going too fast in the beginning of a race.
In fact, running long-distance well depends on being able to manage your energy levels throughout the whole race. You need the discipline to not sprint in the beginning and have to drop out of the race or limp your way to the end. And if you think you can do the opposite and go very slowly for most of the race and then catch up in the end with an explosion you will sadly discover that you can overheat or suffer an injury, because there are limits to how much you can give at once, even if just in the final stretch of a few miles.
If you don’t care for sports, consider learning a musical instrument. The person who can dedicate 15 to 30 minutes everyday to their practice will make progress much faster than those who can dedicate hours and only in the weekend. Not only because of injuries of overdoing in the latter case, but also because constant pace allows your brain and muscles to process and integrate knowledge in a deeper way.
If excess seems to be known to be bad in health, in food, in anything basically, how come it needs spelling out when we talk about teams developing their products?
The history
You might be lucky and not have experienced the so-called death marches of software development. But the idea behind the agile principle # 8 is to really battle against that.
Picture projects that are managed in a way that when it’s time to deliver… it’s crunch time. Overtime and coffee and bad pizza and people that might sleep on the office to get things done. Acceptance tests with the user are done on a very specific timeframe and it’s usually a short window. We are talking a project that lasts many months and has acceptance test done in a week. That kind of disproportionate. Bugs are fixed immediately and everybody is just hoping for the project to end.
I’ve been there.
As you can grasp by now, that is not sustainable. 60 hours a week is not a way to produce quality software or to produce anything. It’s not a rhythm that can be kept for long and it usually leaves a scar in employee morale, it creates unnecessary friction between users and developers… which ultimately makes sponsors unhappy as well.
What to coach for
I’ve been around smaller companies and bigger companies making the shift for agile and what I observed is that sustainable pace has less to do with company size and more with two things: technical components and human components at play in the organization.
1 – Human components
That is coaching the human. That is understanding and making known the systems in place that keep people overworking.
In laymen terms?
There probably are processes, policies, and expectations in the organization, tacit or explicit, that make people work in those intense ways.
Look at processes and rewards.
Are people rewarded when they “hero” their way around delivering work? Is the person who is connected to the company slack channel on a Friday night the one who also gets more accolades and better bonuses? Human beings crave love, acceptance, and recognition, so if the culture and policies in the organization encourage this type of behavior, you will have a hard time trying to make a case for sustainable pace based on simple conversations.
Also, how teams and departments get structured can influence all that. Is the team or department organized? Do they communicate regularly and intentionally? Teams that do not talk or that work mostly separately might have limited views on what is the work to be done and discover the missing points only when it’s time to integrate their work.
Look at where do decisions get made
When decisions keep being made outside of the team, these decision makers can assume “it’s just a minor change” and in fact push work on teams that is actually more than what can be delivered. It is not by mistake this agile principle puts together users, sponsors, and developers. All stakeholders are implicated and conversing.
Look at personal lives.
Lastly sustainable pace in a human level also involves the fact that people have interests outside of work.
Who leaves work and go back to their families and friends and who goes back to a lonely life? And who has workaholic tendencies?
Mental and emotional health are important aspects of human life and sustainable pace includes considering how we can create space for people to thrive in their personal life as well. That includes policies and measures to make sure people take time off for sickness and for leisure, and that people face cordial relationships at work.You know, that people feel safe to be themselves at work. Stress can start way before we talk deployment of a product, and in a high-pressure environment, even when we are not on tight delivery schedules, people can still feel on the edge.
2 – Technical components
But there are also more technical components that you can look into, tweak, and coach for when you want to live the agile principle # 8. And these technicalities involve backlog and technological infrastructure.
The first question that you should dare to ask is how requests and backlog are managed. How incoming work is accepted. Because you will notice that is not uncommon that in any given year or quarter the organizational objectives are plentiful. Which means teams have to deliver against several competing priorities. Which means there are no priorities!
Priorities, when clear, are ordered. You do thing number 1 first and then thing number 2. If you need to bring your kids to school AND got o the pharmacy, you will have to decide where to stop first. It is similar with projects and deliverables.
That still holds true when change happens. Shift happens all the time. It’s normal and it’s many times THE reason for adopting agile thinking. Now changes are not exempt of prioritization by any means. You still need to prioritize how to respond to it. You don’t simply keep adding new work on top of existing work. If the context changes, so does the backlog.
You get to see that yet again the agile principles are all intertwined. If you were following agile principle #3, the one that calls for frequent and early software delivery, you would not be suffering with late integration of the code. Because since you know that it’s when you put my work together with your work that we will find the issues, you decided to do that early and often.
And if you know that agile principle #7 is about measuring progress only with working product, not with abstractions, you do not need to rush. Because when you report 70% done you are talking about deliverables already out, not tasks or documentation that give a sense of progress. In this case no one needs to rush to put more code out.
The final blind spot on the technical side is infrastructure itself. Pace can only be sustainable if the infrastructure is disciplined and organized. And it evolves to accommodate speed and quality of the teams. If the team is ready to deliver every week but their systems and environments are not always available or if they don’t have straightforward tools, delivering will always be a sore spot. And if it’s sore no one wants to do it often because no one likes pain frequent pain. So, you see the vicious circle of avoidance of suffering causing yet more suffering goes on and on.
Sustainable pace is good business
In the end, sustainable pace is good business.
Regular deliveries of decent quality make the customer and other stakeholders happy. That’s good reputation for your company.
Sustainable pace means people have more energy to work and therefore can pay more attention, ask better questions, and generate less errors. Good quality is a great side effect.
And ultimately, we are all humans. That means a pace that can be sustained indefinitely means more employee satisfaction, engagement, which leads to also better talent retention in the company. It is costly in time and money and in reputation to lay off and hire people.
This all translates into better revenue. Talk about good business!
I hope this post helped you see some possible avenues to facilitate and coach your teams and departments toward a sustainable pace. And if you are not confident on the technical side, remember people can figure out a lot of that by themselves. Your role as a coach is to hold the space and facilitate the conversations. And, hey!, there is such a thing as technical agile coaches. Especially in the software world.
Let me know what is the one thing you believe you can do now to advance the state of agile principle #8 in your teams and departments.
