Is remote work only for the chosen few?

I was talking about remote work with my two colleagues recently. Our opinions on this topic lie on the opposite ends of the spectrum: I’m a big proponent of remote work while my colleagues strongly believe in co-located teams.

We have made a lot of typical arguments for and against remote work. As most of them are addressed in 37 Signals’ “Remote”, I’ve used this fantastic book to support many of my points. But then my colleagues argued that 37 Signals’ experience isn’t a good example because their situation is special. They’re famous for creating Rails, so they can attract a very different breed of developers – more motivated and self-driven than the ones working for a typical company, only to get a salary. The proof of this is that most big companies don’t allow remote work.

There are 3 underlying assumptions in this opinion:

  • only especially driven developers can reliably work remotely
  • only a few companies like 37 Signals can employ such developers
  • big corporations should be your role models for new methodologies adoption

Are these assumptions true?

Continue reading “Is remote work only for the chosen few?”

8 Agile lessons from “Convict Conditioning”

Recently, Paul Wade’s “Convict Conditioning” went viral in our team. It’s a book about calisthenics (strength training using only body weight for resistance). Yep, we developers ain’t couch potatoes! But that’s not the point. What has struck me is how many similarities Paul’s philosophy shares with Agile. Let’s hear what “The Coach” has to say, because he can teach us Agilists a thing or two:

Continue reading “8 Agile lessons from “Convict Conditioning””

Test isolation: Dependency Injection vs stubbing constructors

To fully isolate the tested unit, we must be able to stub its dependencies. In many programming languages, stubbing hard-coded constructors is impossible. The Dependency Injection pattern is the go-to solution for this problem – it allows us to extract dependencies into parameters provided from the outside of the tested unit, which in turn allows us to substitute them with stubs.

In some languages, though, due to their dynamic nature, stubbing hard-coded constructors IS possible (e.g. in JavaScript and Ruby). Is there still a reason to use Dependency Injection in such languages? Or is it just an unnecessary complication?

Continue reading “Test isolation: Dependency Injection vs stubbing constructors”

Empiricism in Agile – embracing change AND planning

Embracing change is at the heart of Scrum. The whole Agile philosophy is built around empirical, inspect and adapt approach. The Agile Manifesto contains statements like: “Responding to change over following a plan” or “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.” It goes so deep, that we not only embrace change – we expect, or even desire it. We become suspicious of our process if the change doesn’t happen.

Yet, we want to have a well refined and ordered backlog. We want detailed user story acceptance criteria. We do a sprint planning and make a strong commitment of what goals we’ll achieve during the sprint. We even fight against changing these goals; the Scrum Guide states: “During the Sprint […] no changes are made that would endanger the Sprint Goal”.

Continue reading “Empiricism in Agile – embracing change AND planning”

How to implement Agile

On the one hand, Agile is based around inspection and adaptation. It acknowledges that every company, product and team is unique, and that to achieve high efficiency we have to fine-tune our methodology to our particular context.

On the other hand, some Agile frameworks may seem very prescriptive at first. Scrum, for example, defines what meetings should be run, how often, what’s their maximum duration and so on.

Is it contradictory? How should we adopt Agile: by the book, or through experimentation?

Continue reading “How to implement Agile”