The Compassionate Agile Manifesto

Agile has always encouraged putting people first, yet this message seems to get lost in the dash to ship features and meet deadlines. We’d like to share our Compassionate Agile Manifesto with you, that reframes and emphasizes people as critically important in developing software.

Let’s start with a reminder of what the 2001 Agile Manifesto says:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

Whole Team Wellness

Jumping straight in, we propose that “Individuals and interactions” are important, but the mental health of the whole team is more important than what the individuals do.

It’s funny how the first word is “Individuals” yet many teams skim past that and focus on what people must do. We set up our standups and ceremonies, burn down charts and task boards, and call it Agile. Doing Agile is a set of interactions, but being Agile is an attitude. In Compassionate Agile we believe that our attitudes must include looking after the wellness of the whole team.

Too heart-led for you? If you really believe that creative, intellectual work like writing software should mimic factory production lines, please let me know how that’s working out for you. I’ll give you a hint that you can look at employee turnover. Does your company accept that software developers change jobs every 18 months to 2 years, and yet think that it’s got nothing to do with their own working conditions? Employee churn is only an accepted truth in a poor work environment.

The People who do the Work

“Working software” is good, but the people who do the work are more important.

Let’s unpack what Working Software means. Mostly, it means that the bare minimum has been achieved. It works. But does it work efficiently and deliver on performance requirements? Is it maintainable in the future? Was it delivered within budget? If the software has a user interface, is it pleasing and efficient to use? Does the team or individuals involved in creating the software feel a sense of accomplishment and pride in a job well done? Or do they just feel like they’ve wasted weeks, months or even years of their lives?

I’m not being overly dramatic here – we’ve seen demoralized teams in our consulting work at so many organizations.

What we really want is a team who is energized, empowered, productive and committed to the work they are doing. To achieve this, management needs to listen to the team, and act on feedback. Investing in training shows that the company cares about career progression for staff. Salaries need to be competitive, and employees mustn’t have to beg for increases. This last point is one that really bugs me. Companies can raise market-related salary budgets for new hires, but will claim budget restrictions to underpay existing staff. It shows a total lack of respect for their people.

Trust and Safety

“Customer collaboration” isn’t as important as the trust and safety that makes collaboration possible.

If only some voices are being heard, you’re potentially losing out on a lot of good ideas. You may also be losing out on diversity perspectives. It’s not a good look to bring a product to market, and find out that you’ve excluded a chunk of potential clients.

Psychological safety is the belief that you won’t be punished or humiliated for speaking up with ideas, questions, concerns, or mistakes. It doesn’t mean that everyone is nice all the time, but that conflict will be handled with respect for the individuals, and without future retribution for speaking up.

In the Compassionate Agile Manifesto, we’d also like Collaboration to include colleagues as well as customers. Developing software is a whole team activity.

Shared Vision

“Responding to change” may lie at the heart of Agile, but it also papers over poor planning and erratic priorities from business. We value a Shared Vision that guides what we do and the priorities that are set, more than we value being reactive.

A common dysfunction in Agile, particularly with Scrum teams, is the Feature frenzy. The team is worn down by constant pressure to deliver new features. Quality suffers, and over time the pace of delivery slows down as there is never enough time to go back and refactor aspects of the system that need a re-design. This goes hand-in-hand with a short-term focus on the next feature at the cost of an overall road map and vision.

A shared vision gives the team a framework within which to consider upcoming stories. Having a broader view of the product or system direction enables better planning and design, and a more robust solution. Humans need a goal that they can buy into, and doing quality work builds pride and satisfaction in work.