There are no shortage of ways. They’re everywhere.

The problem is…

You can take the exact same practice, tool, or methodology … and either bludgeon each other with it, or achieve a mutually healthy (and positive) outcome. In some cases the bludgeoning “works”, albeit with some cognitive dissonance and harm generated as a byproduct. But eventually you’ll need to pay the piper.

Take a loaded word like discipline (and imagine some practices meant to instill discipline):

Team A:

We take pride in taking a disciplined approach! It means delivering higher quality code, and less firefighting. When we promise something, we don’t let people down.#### Team B

This process is killing us. Management says we need more discipline, but how are we supposed to be more disciplined when we’re digging out from mountains of debt, they’re interrupting us constantly, and they won’t let us hire more people! How about their discipline?Team B may have “consistent output” and their work may be “predictable”, but eventually you’ll encounter some issues there. Most organizations intuitively understand that they need more Team As, but have a tough time putting the pieces together to make that a reality and reflecting on what is blocking that progress.

I’m guessing you can find similar examples from your work-world for outcomes like accountability, safety, estimation, deadlines, commitment, velocity, agility, engagement, continuous improvement, goal-setting, and compliance. Things can, and do, go either way. Context is everything. Helicopter management vs. craft.

Consider this description of Sandro Mancuso’s book The Software Craftsman: Professionalism, Pragmatism, Pride:

If you want to develop software with pride and professionalism; love what you do and do it with excellence; and build a career with autonomy, mastery, and purpose, it starts with the recognition that you are a craftsman. Once you embrace this powerful mindset, you can achieve unprecedented levels of technical excellence and customer satisfactionSounds wonderful, right? If you’ve worked on the front-lines in software development, however, you would be excused for responding…

All that is well and good, but we are told to cut corners every day! We don’t have autonomy!The craft movement is interesting because, in my opinion, it is a response to a lack of coherence in our software development organizations. As Mancuso points out … “Agile isn’t enough!” Enough for what? Perhaps it is not enough to reconcile the mixed messages we send our teams, or to rationalize why we frequently cut corners. Perhaps Agile — as commonly practiced — isn’t enough to make people feel good about their work?

And this, to me, is the central issue. It is a question of coherence. In an incoherent organization, no “best practice” or “good tool” can be perceived as safe or worthwhile. The front-line will be justifiably skeptical. And when it comes to embracing potentially positive things like discipline, care, quality, speed, etc., it will be difficult for teams to perceive these things as something as worthwhile. Instead, the response will be to build a protective shield and figure out how to coexist in an incoherent system.