Values over vendors
This post was originally published here.
Many times when I start explaining Scrum or Agile for the first time, one of the first questions I get asked is “what tool do I use for
One of the most important aspects of true Agile teams is a self-organizing team, which determines how best to deliver and develop what the business needs. If the business can’t trust the team to choose how, how in the world can the business trust them to deliver anything at all?
A self-organizing team cultivates a set values, principles, and practices to deliver software. The values come first, and everything else is built on top of that. If you start with tools and try to fit values around the tools, you’ll find the team is only going to care about fulfilling the corporate policy and much less about the value behind the tool. It’s far easier to build policies on values than to derive values from policies, as policies built without values will seem arbitrary and pointless to the team. If there is a need for a corporate policy, involve as many of the stakeholders as possible into those decisions. I’ve seen several teams become disinterested and disheartened when a tool is forced upon them without their input or approval.
So instead of forcing the organization to use a certain build, bug tracking, or requirements gathering technology because of political or vendor-lock-in reasons, cultivate a set of values like “Simplicity”, “Feedback”, “Quality”, etc. Values define principles and practices, practices reinforce values, and practices can be followed through tools. By focusing on the values instead of tools, we can broaden our scope of practices to reinforce our values. Tools can enforce practices, but tools can never define values. If we focus on tools, our value system becomes warped and twisted towards the tool vendor’s values (selling their tool) or those pushing the tool internally (political, ego, or personal gain).