The Social Compact of Agile

If you don't set priorities your office could be like this.
From the Iron Mitten web site.  

One of the biggest challenges in technology is there are not enough people to do all the necessary work.  Only about 18.5 million people in the world of 7.4 Billion people can maintain software and modern computer networks.  That means that less than .05% of the world have the skills to keep the global economy spinning. It would not happen without dedicated project professionals and smart technologists holding everything together.  Without prioritization, the gears of the industry would grind to a halt, and that is what I want to talk about this week.

When Thomas Hobbes wrote “The Leviathan,” in the aftermath of the English Civil War; he spoke about something called the social contract.  The social contract to Hobbes was an unwritten set of rules where individuals traded their liberty with the state in exchange for safety and protection.  Ignore the social contract, and society would collapse, and philosophers and social scientists still use the idea of a social contract to explain how communities work.

In the world of business, we also have social contracts.  People who have more authority have offices instead of cubicles, so they meet with people in private.  When it is time to distribute profits, shareholders receive preference over employees.  Finally, no one gives human resources any trouble because they have the authority to hire and fire anyone.  None of these rules are written down, but we all know they exist.

In agile, there is one social compact.  The product owner sets the priorities, and the development team says how long it is going to take to do the work.  The developers may disagree with the preferences, but they have to accept them.  The product owners may not like how long it will take to do the work, but they have to agree with them.  It is the trade-off which makes agile work.  If neither the developers nor the product owner respects this setup, then the implementation will fail.

It is well and good if you have only one project and one team.  What happens when you have multiple projects and not enough teams to do the work?  It is when prioritization becomes more critical.  Business leaders need to be part of the process, and they need to know what is being worked on and when.

There are plenty of processes to set priorities.  The most significant challenge for me is the mindset of the business of professionals.  Sales and marketing professionals are trained to think each “no” is one less objection to “yes.”  It is admirable for a sales professional; it is madness for a large organization as self-interested and selfish people scratch and claw to “yes.”  Projects hopscotch up and down in priority as developers struggle to stay ahead of the shifting needs of the organization.  Unclean code is released to production because someone needed a feature released “today.” I continue to struggle with this challenge.

So as a scrum master or agile coach, you need to enforce the social contract of agile.  That social contract is product owners set priorities and developers say how long it is going to take to do those priorities.  If you can do this, you just might succeed.

Until next time.