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?”
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””
This is a copy of the post originally published on the eSKY IT blog.
How does our way of scaling Scrum at eSKY compare to Nexus, the new Scrum.org’s framework? This is the question we asked ourselves recently – and that I’ll try to answer in this post.
Continue reading “We have invented Nexus!”
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.
Continue reading “Test isolation: Dependency Injection vs stubbing constructors”
One of the defining attributes of Unit Tests is isolation. Even the name “Unit” implies it. Well isolated tests make it easier to pinpoint errors, are less brittle, and run faster.
But are your tests really well isolated? And are they easy to isolate or are they painful to setup?
Continue reading “The 4 steps towards well isolated tests”
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”
Some time ago, I discussed why an MVP should be built iteratively. In this post, I’ll illustrate the benefits of such an approach on a concrete, step by step example.
Continue reading “Building the MVP iteratively – a practical example”
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”
How long should a Product Backlog be? How should it be organized? Is there a universal rule of thumb or is it product-specific?
Continue reading “The size and shape of an ideal Product Backlog”
Are the concepts of the MVP (Minimal Viable Product) and iterative development related? Do they try to solve the same problem in a different way or are they complementary and can be used together?
Continue reading “Does it make sense to develop an MVP iteratively?”