Scrum is no longer fit with remote work

With remote work taking over, meeting intensive Scrum needs to move aside


The pandemic crisis has shown that remote office for everyone just works. Many people were skeptical before but had to jump and now see that most companies work like before and remote work didn’t crash them. Talking to many developers and managers in the last months, one thing seems clear. They will not come back. Remote work made their live a lot more pleasant; they have more spare time, after some adjustment there is less stress, they spend more time with their kids, they can schedule time as they want, start earlier and work longer with free periods over the day and the hated commuting is gone. People won’t come back five days a week, but only select days for socializing. If you force them, they will resist you. Requiring all week office time will be a downside for employer brands that need to be compensated by higher salaries. Only the best employer brands like Apple will be able to pull off office time. People will not come back. Only few employees miss the office and will return, because they like being with others and home office might be hard for various reasons e.g., they have no place to work from or separating work and family might be too stressful. Some want to come partially back and decide when to work in the office and when to work at home to get the best of both worlds. And some – the majority? - have seen that remote works for them, will not come back and even resist coming back. We have a mix of people, but it’s clear most won’t come back to the office, remote work will be the new normal. Jack Dorsey, the CEO of Twitter, announced employees they do not need to come back and can work remotely unlimited in the future.

We now see the first changes to software development. But for many software developers remote is nothing new. Many have done that in the last decades. What has changed is that remote work is the new normal and whole teams work remotely. Not one person on the team is remote, or one of your teams works remote, everyone works remotely. If everyone is working remotely, there will be profound changes, and we might ask what will change for software development? A new environment for everyone will cause a different software development model.

As a study from Microsoft has found how work patterns have shifted. There is no typical lunchtime dip in commits and people start working earlier and work longer into the evening. Talking to managers, what we already can see: Meetings are shorter than before and more documentation is written to reduce the number of meetings. Video calls are more exhausting than meeting face to face. Four hour workshops come down to one hour meetings. Companies write documentation before a meeting. Ryan Singer writes in ‘Shape Up – Stop Running in Circles and Ship Work that Matters’: “Write the pitch. Once we think we’ve shaped it enough to potentially bet on, we package it with a formal write-up called a pitch. The pitch summarizes the problem, constraints, solution, rabbit holes, and limitations. The pitch goes to the betting table for consideration. If the project gets chosen, the pitch can be re-used at kick-off to explain the project to the team.” People come around to what Amazon already does since its beginning: “Instead, we write narratively structured six-page memos. We silently read one at the beginning of each meeting in a kind of ‘study hall.’” (Jeff Bezos, 2017 Letter to Shareholders)

The style of software development was always a reaction to its environment. Let’s look at agile. Agile software development was driven by the internet and the new internet company. Instead of slow changes, few direct customers and manageable competition, the internet brought rapid changes to the market, millions of direct customers for companies and lots of competition that was well funded and sprung of weekly, because the barrier of entry was getting so low. Agile was driven by the advent of the internet as it solved all these problems. The new environment of the internet caused a new paradigm of software development. The old paradigm of waterfall processes, long requirement engineering phases and yearly releases did no longer fit the new environment. Just like life adapts to new environments, software development and people adapt to new environments. The same will happen with remote work. Agile, self-organized teams with Scrum meetings will no longer be the best fit for the new environment. What will be driven by remote work? These are long term changes, nothing that happens tomorrow. Remember, it took ten years for the internet to drive the mainstream to agile.

We currently can’t see how this new way to develop software, including processes, will look like exactly but see what it might roughly look like.

1.

The new process will come up with much fewer meetings than Scrum or meetings in companies in general. Meetings are more exhausting over video. Exhausted people are not creative or make good decisions, so they need to be shorter and less often.

2.

No longer will we have teams. We have teams to promote collaboration. We have teams to promote communication. Scrum is based on the idea of collaborating development teams, with retrospectives and daily standups to give opportunity to communicate. The benefit of a collocated team is how much they get information from others, e.g. by listening in on other people’s conversations. In the past I have seen many good ideas coming out of overheard conversations. And even outside work, e.g. at lunchtime teams collaborate by discussing ideas. All this goes away with remote work and the benefit of having a team in the first place diminishes. There will be much smaller units than the current teams we have.

These units will be autonomous, with autonomous decisions to reduce communication. Even the one-person developer heroes of the 80s might make a comeback and organizations will learn from the on-person mobile app companies. Technology has made huge leaps forward in the last two decades and there are many examples already of one-person internet startups. Like in the old days, developers will code straight without interruption for a whole day (at eBay I needed to remove all phones from developers to get some interruptions free time).

How do self-organized, cross-functional teams evolve? How do developers access UX and design? If we have no longer teams as an administrative work unit, how will product managers give work to people? Without falling in the trap of backlogs. How should developers know what to code? How do we manage work units? There are more questions than answers. Product managers giving work to teams will no longer work when we have no more teams. Managing individual developers is too time intensive, teams were an optimization for less communication in the first place.

Most teams I have worked with break down into smaller units on their own. Mostly into two developer units building each feature. People work with whom they think they learn most and have the most fun with. Two person ‘teams’ will appear to share knowledge and grow junior developers. We already see how Youtube Stars and Streamers achieve a reach of millions with very few people, compared to large teams at traditional broadcasters.

3.

When people have less personal contact, it is harder to learn from each other. People development will be harder with remote 1:1. Those sessions do work as I have seen from coaching people with video conferencing but much more exhausting than mentoring in person. One side effect is, that seniors will be in even greater demand, because they can work on their own in a remote office. Companies will put more effort into mentoring for onboarding but have fewer people management for developing their employees. The future process will be centered around knowledge transfer and learning, not around communication and collaboration.

4.

Remote tools are taking over. We have seen the move from desktop to laptops for developers in the past but working remotely will push that even further. Remote development environment like Github Code Spaces are on the rise and work with a low power device everywhere. People can move wherever they like and work there, cementing remote work. Processes will evolve around remote coding tools, and we will see new forms of collaboration, e.g. more co-editing.

5.

We see the first sign of a trend toward more openness. In the future companies will develop code in the open.

6.

With remote work we see more of people’s life’s at home and share intimate moments. This will shape the way we work together in the future and opens deeper and more meaningful connections when mentoring people.

7.

Remote work is hardest for top management. Top management currently has the most meetings – the whole day usually is one meeting. Top managers seldom write or do ‘real work’. They shape the company by being there. CEOs and CTOs will have much more change coming for them in a remote-first company. Both functions will focus even more on the outside of a company than the inside. Next in line is middle management. Middle management organizes people and communicates up and down. This doesn’t make as much sense in a remote setup. So middle management will dry up, and we get much flatter hierarchies.

The pandemic was a milestone in the way we work together. Nothing will be the same in the future with the irreversible move to remote work. As the internet has shaped agile development, remote-only development will shape the next software development process. With better work-life balance, living outside congested cities and more meaningful connections, this is a future to aspire to.

Join the AMAZING CTO newsletter!
By signing up I agree to receive your newsletters and accept the terms and conditions and data protection

More Stuff from Stephan

Other interesting articles for CTOs

Best books for CTOThe CTO BookExperienced CTO CoachEngineering Manager CoachingCTO MentorCTO MentoringCTO NewsletterHow many developers do you need?Postgres for Everything Technology and RoadmapsHow to become a CTO in a company - a career path

Other Articles

How to Outsource Development Successfully

The ZigZag Model of Vision and Strategy

Best Books for a CTO

The 5 Reasons Not to Use Scrum

Goals are a Spectrum not a Number