Thursday, April 30, 2015

Remote Work Denial Is a Bad Look

When out-of-state recruiters email me about their awesome tech company, my first response is always something along the lines of, “You support remote work, right? I live in Grand Rapids, Michigan.” When the response comes back as a flat denial of the possibility, suddenly that hot tech company seems very old-fashioned. And old-fashioned is not a good look in the tech industry. I always think to myself, “Really, you’re one of those? Well, that’s embarrassing.”

If “Agile” could be said to have traditional values, one of them might be colocation. I’ve come to view this emphasis as a bit naïve or idealistic in the present day.

As Keith Richards says in an article for InfoQ about distributed Agile:

Most of the agile body of knowledge that has been written is based on the utopian situation of one team, one ‘product owner’ and one location. Although this is still often the case, is it the exception or is it the rule? Having worked for well over a decade now on implementations of agile I find that multi-team, multi-location, multiple business area and even multi-time zone agile is more the norm.

If agile is to thrive over the next 10 years then it not only has to work in a distributed environment (i.e. an environment where we do not all work in the same place), but it has to work well in order to deliver the most value to an organization.

Mike Cohn, in his book Succeeding with Agile, expresses a similar thought:

A few years ago, collocated teams were the norm, and it was unusual for a team to be geographically distributed. By now, the reverse must be true. Personally, I’m now surprised when someone tells me that everyone on the team works in the same building.

Not a good look

You can think face-to-face, in-person communication is most efficient, and I won't argue with you, but it ultimately doesn't matter as the remote work trend will not be stopped.

When I see tech companies taking a hard-line stance against remote work, I can't help but think, “Imagine how dumb you're going to look in a few years.” I truly do not mean to offend anyone’s sensibilities with what I’m about to say and hope my point gets across regardless of your particular political beliefs, but remote work denial feels very much to me like people vehemently opposing the legalization of marijuana or same-sex marriage at this point--do you really think you're going to stem this tide? With all due respect to your beliefs, this is happening anyway.

Get on the boat now before your company has been too badly embarrassed in front of the people it wants to hire. Remote work is still a differentiator in this moment of time. What are you waiting for...your competitors to do it first? You want to clean up in the talent wars? Figure out how you're going to make remote work effective for your company and then shout it from the rooftops.

From the closing sentiments of Remote:

Life on the other side of the traditional office paradigm is simply too good for too many people. Progress on fundamental freedoms, like where to work, is largely cumulative. There might be setbacks here and there from poorly designed programs or misguided attempts at nostalgia, but they’ll be mere blips in the long run.

Between now and the remote work–dominated future, the debate is likely to get more intense and the battle lines more sharply drawn. Remote work has already progressed through the first two stages of Gandhi’s model for change: “First they ignore you, then they laugh at you, then they fight you, then you win.” We are squarely in the fighting stage—the toughest one—but it’s also the last one before you win.

Remote work is here, and it’s here to stay. The only question is whether you’ll be part of the early adopters, the early majority, the late majority, or the laggards. The ship carrying the innovators has already sailed, but there are still plenty of vessels for the early adopters.

Thursday, April 9, 2015

Continuous Delivery and Management Pathologies

I believe continuous delivery is a foundational practice. In fact, it’s mentioned right at the top in the “Principles” section of the Agile Manifesto:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

There’s a lack of trust that develops amongst stakeholders when the gap between “developer done” and “I can see that it’s done” is too great. In a perfect world, everyone trusts everyone, but that’s just not the case on real projects a great deal of the time.

You want to know how to cultivate trust? Deliver consistently. Perhaps, continuously.

I believe one of the greatest causes of managers behaving badly is a fear that the things that need to get done are not getting done. This is one of the great causes of micromanagement, which technical folks tend to hate (I know I do).

By reducing this fear, you can head off several management pathologies. You can prevent a hundred status meetings by sending a URL to someone and saying “see for yourself.”

I’ve come to believe that on most software projects, the speed of progress is not particularly important as much as steady progress. Optimize for steady, externally-visible progress.

CD is the ultimate progress indicator of your project. As Jenifer Tidwell says in Designing Interfaces:

Experiments show that if users see an indication that something is going on, they’re much more patient, even if they have to wait longer than they would without a Progress Indicator. Maybe it’s because they know that “the system is thinking,” and it isn’t just hung or waiting for them to do something.

Note that this is the same lack of trust that makes otherwise intelligent software organizations hesitant to embrace remote work. What if my daily work produced artifacts of working software that you can look at every day whenever you wanted? Would that assuage your concern that I’m sitting in my pajamas and watching cartoons all day?

I see CD as a sort of great equalizer. Working software in front of the people who paid for it levels all arguments.