Do You Hide Behind Guidelines?

I cannot tell you how often I hear the term “guideline” these days. It seems to creep into every other meeting or so, especially when “new and improved” concepts are being discussed at the management table. In my eyes, even if you substitute the word “guideline” for rules, you still view them as rules. Why do I think this? Well, just like in Texas Hold ‘Em, there’s a tell.

When someone begins their explanation about a new process (that has taken weeks to draw in Visio or to create in Power Point slides) by saying, right out of the gate:

“OK. This is a guideline, not a RULE…but a simple GUIDELINE”

…then you know it’s a RULE. Period.

This substitution is transparent & disingenuous. Please don’t hide behind this obvious bait and switch. If you want to create rules, say as much. At the very least it gives the poor souls subjected to the rules a chance at an open discussion with you. I have been guilty of this misdeed in the past, and my main motivation was to avoid difficult discussions. To create a culture of openness and trust, I feel we need to relish the opportunity to open a dialogue. It might be more painful (especially if you feel a specific RULE is critical), but the team will be stronger if you hit this challenge head on.

Stewardship: An Engineering Virtue

I have been thinking a lot lately about how I might go about working with teams to ensure they understand the main message behind agile engineering practices. In many ways, the knee jerk reaction of many managers, including me, is to edict the use of common practices and skills. In my past, I have heard many many reasons for why people don’t want to unit test, setup build automation, peer review code, and refactor. What I haven’t heard is a GOOD reason. This has made it even tougher to refrain from handing down a set of criteria to the teams on “how to code”. After all, for me these practices “just makes sense”.

“What” vs “How”
A lot has been said about internal versus external system quality and I think this concept has helped me teach the difference between “what” systems teams deliver, and “how” those systems are built. When starting a conversation with teams about learning the well tested agile engineering practices, I typically hear a common refrain.

“We are senior developers. We don’t need to improve quality. We’re doing great…just ask the business!”

In one way, they are RIGHT. The business loves what they are seeing. But quality to a user of a system is only skin deep. They see half the equation (arguably the most critical) but half none the less. They see the working system. They see the new feature they requested and by gosh it works exactly as expected! The system is performing as expected. There may be a few lingering issues, but 95% of the system is awesome. It supports the business just fine. Mostly, we just need more features, faster!

Lurking Under the Surface
So what don’t customers see?

  • They don’t see the manual jobs we kick off behind the scenes every morning to ensure the data “looks right”.
  • They don’t see the delays to building products because only one person knows each individual part of the system, and if they are busy (or even worse on vacation), then nothing in that specific module can be delivered.
  • They don’t see the painstaking manual testing efforts that go on before we push to UAT.
  • They don’t see the manual roll out, roll back, roll out dance we do simply “moving” code to UAT and PROD.
  • They don’t see massive nested If-Statements that look like Japanese word art.
  • They don’t see the 12 year old version of J++ that their core processing engine is built with, and that if Christy loses the J++ disk she has in her desk drawer, we’re screwed.
  • They don’t see how difficult it is to add simple logic to the system each time they ask for something new.
  • They don’t see how often even simple changes strike fear into the hearts of anyone relatively new to the team.
  • They don’t see the 18 month ramp up time it takes skilled developers to “learn the system”.
  • They don’t realize that “regression testing” really means “test whatever we can for the 2 weeks we have left”. (hint: ~10% of features)
  • Etc, etc, on and on, ad infinitum -1.

For the above reasons, we need to be better. As technologists, we need to be stewards of our systems. And in many ways, that means protecting both “external” and “internal” quality.

Stewards? What does that mean?
It means if there are time bombs in our code, we have to make those time bombs REAL to the business and advise them how to prioritize up what is critical and to prioritize away what is not. In technical debt terms, pay down your high interest technical debt quickly by prioritizing it as high up in the backlog as possible. Business people will never do this on their own. We have to help them toward this decision.

It also relates to “how” we build systems. As professionals, we need test automation, build automation, refactoring, pairing, peer reviews, patterns, etc. This is where my brain and my emotions clash. On one hand I want to pass down upon high an EDICT, “Thou shalt unit test!” I would say this is my emotional, impatient side. Intellectually I understand that I need to lead these teams toward these principles. More “supposing” and less “proposing”, as they say. The minute I create the rule, the simple and powerful act of automated unit tests lose their power. People begin to test in haste. They write tests that assert nothing so test coverage reports show arbitrarily high numbers. They write tasks for testing and never get them written. They come up with every reason in the book why testing isn’t that valuable for them, in their system. And when rules are imposed, any shortcomings, difficulties, roadblocks, or otherwise ill will surrounding the approach are attributed to external sources…namely, me. After all, this is Jason’s RULE. He owns it, not us.

Grass Roots
So, I am back to the grass roots. I want to rebrand engineering principles (and the stewardship it implies) as a virtue, not a rule. I am back to the task of building a ground swell in our culture. I am back to focusing my efforts around a few key (and critical) early adopters who have seen the value of software craftsmanship. With these progressive folks, I hope to create a magnetic pull. A “why aren’t we doing that” effect that emanates.

With the rest, I have but one request:

“If you don’t think that these principles and techniques are valuable, so be it. In the absence of using these techniques, please show me how you can assure consistent, sustainable, internal and external quality of the systems in which you have been granted stewardship.”

I am being sincere when I say I am open to being wrong about this. If those principles I have come to lean on are of low value for these teams (and in their context), I am anxious for a better answer. More to come!

Revisiting “The 5 Dysfunctions of a Team”

I recently re-read The 5 Dysfunctions of a Team. I am through it for the 2nd time and find that I have gleaned so much more this time around.

The Role of a Leader: (A look back at 5 Team Dysfunctions)

  1. Absence of Trust – Avoid Invulnerability
  2. Fear of Conflict – Avoid Artificial Harmony
  3. Lack of Commitment – Force Clarity & Closure
  4. Avoidance of Accountability – Confront Low Standards
  5. Inattention to Results – Focus on Collective Outcomes

In my first foray into this book, I found many insights useful, but not particularly familiar. I read the book quite a few years ago and really didn’t have the 5 dysfunctions of a teambackground to understand the content that the book addressed. I just hadn’t faced those types of team building dilemmas (or maybe I just hadn’t thought about it that way). Even in an Agile coaching capacity, I find many small teams quickly gel and find a rhythm, building trust, managing conflict with help, and holding one another accountable. I think software teams are, in the end, really good at this given some subtle guidance.

Fast forward to 2010
I’m currently part of a management team that displays many of the detrimental failure modes that the book describes. Sadly, I’ve come to realize over the years that this is more the rule than the exception. The team members are all, individually, extremely talented. They are also great people. I mean that sincerely. This fact makes me both hopeful and fearful at the same time.

It’s great news because it’s obvious that my current challenge is unambiguous and squarely in front of me: work on building a dynamic and healthy TEAM. It’s also scary because I now know what I need to do: work on building a dynamic and healthy TEAM!

This supremely simple concept, the one that eludes 95% of leadership teams in all types of organizations, is one of the most difficult experiences teams can go through. Knowingly embarking on that journey is a sure-fire way to bring emotional exhaustion and short-term discomfort to your collective lives. But alas, like many things in life, I know it’s critical and completely necessary. There is no exception.

Mentally I know that this hard work and emotional discomfort will be the only way to long-term fulfillment and happiness in a collaborative endeavor like building great software for customers.

I’m growing more encouraged day by day.