Agile Zone is brought to you in partnership with:

Gil Zilberfeld has been in software since childhood, writing BASIC programs on his trusty Sinclair ZX81. With more than twenty years of developing commercial software, he has vast experience in software methodology and practices. Gil is an agile consultant, applying agile principles over the last decade. From automated testing to exploratory testing, design practices to team collaboration, scrum to kanban, and lean startup methods – he’s done it all. He is still learning from his successes and failures. Gil speaks frequently in international conferences about unit testing, TDD, agile practices and communication. He is the author of "Everyday Unit Testing", blogs at http://www.gilzilberfeld.com and in his spare time he shoots zombies, for fun. Gil is a DZone MVB and is not an employee of DZone and has posted 69 posts at DZone. You can read more from them at their website. View Full User Profile

Trust vs. Control

10.24.2013
| 7153 views |
  • submit to reddit

As I was tinkering with my new CI toy, I became aware of a difference between light CI tools and feature-heavy ALM tools: Permissions.

I always knew it was there, the ability to restrict all kinds of stuff.

From adding work items, to deleting files from source control and to view comments. You can prescribe roles, apply permissions and take them away.

And the big question is: WHY? What are these features for?

I’ll give you the answer in a moment. But let’s talk about the 2nd WHY: You control permissions in order to limit accessibility to information. You control permissions when you’re afraid that your minions will break stuff.

We control because we don’t trust

That’s true not only for ALM tools, by the way. Take the government, for example: you regulate what you don’t trust. Sometimes it is done for good reason, because organizations and people we trusted have turned on us. And sometimes the government regulates because it doesn’t trust the lowly citizen to make the right decisions.

Meanwhile, in Agile world…

In agile teams, we value visibility and self-organization. These are two forces that cause self-regulation.

Visibility into process and progress takes away the power from information mongers. When information is available for all, it is not possible to trade in it, to give it to the fortunate few, or hide it from investigative eyes.

Self-organization takes away power from individuals and puts it in the hands of the team. The team makes decisions openly, creating trust between team members and stake holders. Because the team progress, estimations, assumptions and plans are discussed in the open, the team takes breaks when it needs to, and accelerates when it can.

When we have trust, we don’t need regulation through administration. And we get other tools (open source or commercial) lacking these features. Less configuration and administration, less tinkering, easier implementation.

So why do these features exist?

I mean, it’s quite ironic that you have scrum templates in these ALM tools, that come with all these permission options.

Because there’s a demand for them from management, who pays for these tools. Managers either have misplaced their trust before, or they live in a no-trust culture.

And in an open, self-regulated market, the tools gravitate toward their corresponding, welcoming environments. Low-trust tools go to low-trust, highly regulated environments, and high-trust tools are used in agile, high-trust cultures.

The funny thing is that people go that way too.

Individuals AND tools.

Go figure.

Published at DZone with permission of Gil Zilberfeld, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)