Is Colocation Still Relevant to Agile?

As 2020 has undoubtedly been the watershed year for remote work, I've been thinking a lot lately about colocation and its relevance to Agile.

When the principles of the Agile Manifesto were written in 2001, the authors believed in the importance of colocation:

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

I was curious to know what Agile thought-leaders were making of the remote work phenomenon these days, and if the idea of colocation was still imperative to them.

Martin Fowler, one of the original signatories of the Agile Manifesto, makes the point that although face-to-face communication is more effective, a more important concern is to hire the best people you can and figure out how to make their collaboration more efficient later:

The first value of the agile manifesto is “Individuals and Interactions over Process and Tools”, which we should read as encouraging us to prioritize getting the best people we can on the team and helping them work well together. While we recognize face-to-face communication is more effective, that recognition cannot act to override the importance of individuals and interactions.

The fact that you can get a better team by supporting a remote working pattern has become increasingly important during my time in the software business and I expect its importance to keep growing.

It's interesting to think about this topic in the "necessity is the mother of invention" vein. When we all presupposed that a daily commute to the same physical building with your coworkers was the normal thing to do, we had best practices that presupposed that requirement.

In the current climate, we're all presupposing that work will carry on as normal with no one commuting anywhere and all communication being digital. What best practices will emerge in this world? Will the primacy of hiring good people quickly obliterate the former primacy of physical proximity in these conditions, with the world quickly moving on?

¯\_(ツ)_/¯

The Golden Rule of Interviewing

We've all heard the Golden Rule, which goes something like:

Treat others the way you want to be treated.

Well, my Golden Rule of Interviewing goes something like this:

Treat candidates the way you would want to be treated if you were the candidate.

Here are some corollaries to the Golden Rule of Interviewing:

• Don't ask a question you couldn't answer yourself if you didn't already know it was coming.
• Don't ask a question you wouldn't want to answer yourself.
• If you like to ask trivia questions about your favorite subject, think how you'd fare if the candidate asked you trivia questions about their favorite subject.
• Don't give a candidate homework you wouldn't do yourself.
• Don't ghost a candidate unless you like being ghosted.
• Don't require more preparation from the candidate than you're doing yourself.

You're a busy, high-status, well-paid professional. And so is the candidate you seek to hire. Do unto candidates as you would have them do unto you.

Start with a Walking Skeleton

Agile pioneer Alistair Cockburn introduced the concept of the Walking Skeleton:

...a tiny implementation of the system that performs a small end-to-end function. It need not use the final architecture, but it should link together the main architectural components. The architecture and the functionality can then evolve in parallel.

In the book Growing Object-Oriented Software, Guided By Tests the authors elaborate on this concept:

A “walking skeleton” is an implementation of the thinnest possible slice of real functionality that we can automatically build, deploy, and test end-to-end [Cockburn04]. It should include just enough of the automation, the major components, and communication mechanisms to allow us to start working on the first feature.

The Walking Skeleton is usually described as the best way to start a new project, by confirming first that you can get a small amount of functionality from end-to-end—in other words, that your delivery pipeline is working. Since we know that the value of software is realized in production, we establish from the very beginning of the project that we have the means to release something.

I believe that not only is a Walking Skeleton the best way to start a project, but it's also a great way to start a user story. When adding a vertical slice of functionality to the software, I begin by establishing that I can simply communicate anything through all the layers. Once I have a Walking Skeleton built for my user story, I'll then start adding meat to the bones, knowing that I have a mini-pipeline in place.

It's a delivery-focused mindset that can be applied at the micro and macro levels of a software project.

2020: The Watershed Year for Remote Work

As someone who's been advocating for remote work for almost a decade and working fully remote himself for half that time, I never could have guessed that the tide would turn so dramatically within the span of a few months. Due to a once-in-a-century pandemic, we're suddenly inside the greatest experiment in the history of...well...work.

When I was writing my to-this-day most popular blog post ever--But Where Do People Work in This Office?--back in 2015, Facebook was in the midst of building the world's largest open-plan office. Mark Zuckerberg had a dream of "the perfect engineering space: one giant room that fits thousands of people, all close enough to collaborate together."

And in May of this year, Facebook in an about-face announced that it will let many employees work from home permanently. Zuckerberg is quoted as saying, "We’re going to be the most forward-leaning company on remote work at our scale."

Twitter, another open-plan bandwagon company I highlighted in my aforementioned post, also announced in May their employees are now encouraged to work remotely permanently if they please.

The CEO of Shopify said about his company's COVID-initiated transition to permanent remote work, "We choose to jump in the driver’s seat, instead of being passengers to the changes ahead. We cannot go back to the way things were. This isn’t a choice; this is the future."

With all the horror of 2020, I'm hoping we can at least look back on this year as a landmark of the Information Age when the world finally woke up to the liberating force of remote work.

Autonomy: Not Just the Good Parts

It's a common lament from management that development teams don't take ownership of the product they're developing.

This may mean:

• Caring about the quality of the product
• Proactively implementing improvements to the product
• Not waiting to be told what to do

The Agile Manifesto talks about self-organizing teams:

The best architectures, requirements, and designs emerge from self-organizing teams.

It's a beautiful concept: teams that rally around a product, nurturing it like it was their own child. Why is it so hard to find people like that?

Actually, those people are everywhere. They've probably just had their hand slapped or their heart broken too many times.

Let's think: What is it that makes a development team want to take ownership of a product? It's probably because they like creating something in their own image, in their own way.

Who wants to own an ugly product that has been foisted on them by the decisions of people whose command always takes precedence over their own?

This isn't the team's baby anymore, it's yours. No one is going to raise your child.

Perhaps this goes without saying, but micromanagement and autonomy are incompatible. If you want the team to own the product, then they own the details, too.

If you want the team to take ownership, then the product has to look like them, warts and all. You don't just get the good parts.

Does this feel sustainable?

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

- The Principles of the Agile Manifesto

I'm kind of obsessed with the idea of sustainability. In fact, you could say it's a major theme of my writing on this very blog.

Below are some unsustainable practices I've covered in the last few years, with links to my writing on them.

---

We've been collecting paychecks for several months without delivering a valuable feature to a real user.

• Maximize the Amount of Work Not Done
• Breaking Work Into Chunks That Users Care About
• Continuous Delivery and Management Pathologies

We complain often about the need for improvement in our processes, but we don't make time for the work or hold anyone accountable.

• Retro Grade

We're paying highly-trained technical experts to do tedious, manual tasks that a computer could do.

• Discipline Is a Limited Resource
• My Job Went to the Cloud
• Be the Automator

We're pulling our hair out trying to forecast release dates, and working overtime to fit in all the work.

• How Do I Convert Story Points to Hours?
• The Psychology of Story Points

The QA people never have enough time to test all the code the developers are writing by the end of the sprint.

• Quality Assistance

We're rushing to meet deadlines, and we insist on getting every detail right the first time.

• Don't Trap Your Clients in the Bikeshed
• Opportunistic Programming

We're slowing down the delivery of features to do code reviews of every commit, but the code quality is still low and we have tons of bugs.

• Small Diffs and Code Reviews
• Keep Code Reviews Focused on the Code

Maximize the Amount of Work Not Done

My favorite principle of the Agile Manifesto addresses simplicity, or as they describe it...

the art of maximizing the amount of work not done

This principle is so core to the way I approach my work as a software developer, that I often take it for granted.

"Maximizing the amount of work not done" almost sounds like a definition for laziness, right? No, it's not about laziness--we just don't want to work on things that no one will care about.

Software is such a pain in the ass to describe, develop, test, budget for, maintain, operate in production, etc. I can stomach all these things because I think about the people who will use the software and how it will save them time and make their lives easier.

It's hard to get motivated to work on things I don't feel confident any real user will value.

In fact, I'd say a thread that is woven throughout the Agile Manifesto is this idea of never drifting too far away from what we know will be valuable to real people.

Let's examine a few more of the principles of the Agile Manifesto...

Principles:

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

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Translation: At every stage, let's make sure that the customer sees exactly what we're building for them, so that we don't waste time building things they don't like.

Principle:

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

Translation: We don't want to keep building something the customer doesn't like just because the requirements say so.

Principle:

Business people and developers must work together daily throughout the project.

Translation: Let's make sure the people who will actually use the software we're building actually like what we're building for them and find it useful.

Principle:

Working software is the primary measure of progress.

Translation: The people we're building the software for only know that we've built something valuable for them when they have real software at their fingertips. Until then, they must take it on faith that we're building something valuable.

Maximize the amount of work not done. The customer gets the most bang for their buck, and the team stays motivated. Everyone wins.