A new perspective on ways of working

Introduction

It may come as a surprise that in a conference full to the brim with exciting tech announcements and showcases of new tooling, the most memorable talks for me had for the most part no trace of actual coding.

The truth of the matter is that if you follow the Vue ecosystem very closely, and treat every tease of a new announcement as the hot new gossip in town, most of the topics presented will hardly be of any surprise, as exciting as they may be.

On the other side of the spectrum you’ll find these less technical talks which are more concerned about the mentality you should have when tackling your daily challenges, and less about the low level implementation details that you might employ while coding.

These talks advocate for taking a step back and thinking about the what and why of what you’re doing, before focusing all your attention on the how. These are the kind of talks that, if you’re like me, you’re likely to skip when browsing through the recordings of a conference.

The presentations that stuck the most with me share a lot of the same sentiment, which in my opinion could be summarised as stop over-engineering and focus on what really matters.

The talks

How thinking small is changing software development big time

First talk of the 3-day conference and Sander Hoogendoorn came out with guns blazing ready to wake up anyone that needed it. His very energetic talk focused on how the world is not moving fast enough to align with the advancements on technology. He mentions how even though the development world is an entirely different thing from what it was in 2001, the industry still sticks to the principles of the Agile Manifesto as if they were law. He drives special attention to how the Agile process does not allow us to deliver value at the same speed as modern tooling enables.

Most companies are following Scrum or Kanban processes to a fault because they assume they are correct, not because they fit best their particular circumstances. As a result, their processes such as standups, retrospectives, etc. have become ceremonies that don’t necessarily uphold any value.

Technology advances in an exponential rate but our processes don’t necessarily do so with the same speed. With how much technology has evolved in recent years and how much more accessible it has become, any market is vulnerable to being disrupted by anyone, at any point; just like the hotel market was disrupted by airbnb, taxis were by Uber, banking by N26 and the like. They might be doing the same thing we’re doing but faster, more efficiently and cheaper. As a result we need to move even quicker, not to be left behind. We need to be more agile than “Agile”.

According to Sander, to accomplish this, we must:

Deliver small features

As Developers, if we’re doing any meaningful work at all, our work is “chaotic”. Meaning we cannot attempt to linearly predict the solution and how to get there. Things change and we need to rethink and react to our environment. There’s not a predetermined set of solutions from which we can choose. The only thing we can do is take a small step, see what happens, and then decide on what the next step should be.

To quote Dave Snowden:

“In a chaotic context, searching for right answers would be pointless: the relationships between cause and effect are impossible to determine because they shift constantly and no manageable patterns exist, only turbulence. This is the realm of unknowables.The chaotic domain is almost always the best place for leaders to impel innovation.”

Because of the uncertainty, we’re better off thinking about delivering small increments continuously, over big projects seldomly.

“After doing them wrong for 50 years, we should finally stop doing projects”.

Have even shorter cycles

Instead of doing two or three weeks sprints, we should aim to provide a continuous flow. We can do this by removing ceremonies from our processes, making use of smaller teams with smaller goals, and automating wherever we can. The more you automate, the faster you can push to production.

According to Sanders, Agile nowadays means taking the ceremonies from SCRUM, instead of taking its ideal of adding value continuously and improving on each iteration. If we followed this principle, we should theoretically be equipped with how to deal with this ever-changing world. The goal was never for an iteration to be every few weeks, but to be as fast as possible.

We should aim to find the optimal processes for us, which might not necessarily consist of having retros, kick-off’s, or other “ceremonies”. The process could be as simple as finding the most important tasks and just moving them from left to right on a Kanban board. The fastest you’re able to do this movement, the more agile you are.

Have small teams

We should strive to have teams that are smaller, self-organising and autonomous. Communication is hard and we end up creating too many meetings and rituals to combat this. With things like full day refinements you end up employing a big group that doesn’t necessarily need to be there. With smaller teams though, you get less communication channels.

• Instead of aiming for more communication, you should strive for better collaboration.
• And instead of discussing every item with the whole team, we should discuss one item with a small team.
• Smaller teams usually end up causing each member to think for themselves and to develop a sense of ownership and autonomy.
• By removing bureaucratic team compositions and processes we can focus our attention on the customer instead.

Make even smaller components with Microservices & Serverless

Sander doesn’t go into detail about this one but the title is very clear.

Instead, he summarizes the rest of the talk with this:

• Think for yourself instead of just copying a different model, as their effectiveness is case by case.
• Keep things small and simple.
• Stop doing projects.
• Never stop learning, don’t settle on the “correct way to do things”.

But, you’re not Facebook

A lot of developers that speak at conferences try a little bit too hard to include comedy into their presentations in an attempt to keep the attention of the audience. Kitze manages to pull off the feat of being as entertaining as he was insightful while accusing us of a sin most of us are guilty of: over-engineering.

In this talk, Kitze explores the tendency of developers to reinvent the wheel each time they face a common problem in web-development.

“How many of you have written your own Button components?” -he asks, while I (and most of the audience) sheepishly raise our hands.

No matter how many times we repeat “premature optimisation is the root of all evil”, most of us still partake on it on our day to day.

Instead of focusing on delivering value to our customers, we spend our time and energy creating workarounds for problems that may not even exist.

While we are focusing on covering absolutely every base before our first release (as if we couldn’t simply iterate over it later, if need be!) others might take the leap and be first to market by focusing on what the customers actually cared about.

While we were working overtime rewriting Vuex to fit our company’s imaginary needs, others had already developed a userbase and were actively iterating and improving based on user feedback.

“But Kitze! Facebook had to develop their own state management system as they had to make sure the bundle sizes were small enough for people with a Nokia 3310 on a 2G connection!”

And to that we all respond: “BUT YOU’RE NOT FACEBOOK!”

Team First

 

This talk by Tim Benniks goes over his “Team First” framework for finding success on large scale projects by focusing on the people behind them.

“Team First” relies on the principle that producing good tech in a high pressure environment is directly dependent on a well organised team.

Tim states that problems like pressure from clients, cultural differences and a lack of rewards and autonomy end up causing stress for the team members and thus, cause low quality output. The team, as a whole, must deal with these issues before writing a single line of code.

These are the ways you can tackle them, based on your role:

Leader

Make the team feel responsible for their work by providing trust, overview and personal growth.

• Trust 
  • The trust behind the team must be the root of its culture.
  • Give people the freedom to be responsible.
  • Give direction but don’t micromanage.
  • Let people manage their own time.
• Overview 
  • Teach every person in the team about all disciplines.
  • Ask people what they want and guide them to what the collective needs.
  • Explain “grind and glory” and give glory when deserved.
• Growth 
  • Let people champion subjects.
  • Put people directly in front of the client.
  • Go “bottom-up”.

Developer

• Know yourself (your limitations and aspirations).
• Look at the big picture.
• Obtain autonomy, purpose and mastery of your subjects.
• Champion subjects you like.
• Know that failure is iteration.
• Act on intuition.

As a team

• Be one team, even across offices.
• Be explicit, don’t make assumptions.
• Make commitments and say no when needed.
• Understand cultural differences.
• Foster social interaction.

Conclusion

The technology industry, especially for Web Development, is filled with noise caused by the constant barrage of libraries, patterns and opinions we submit to on a day to day basis from every medium. Because of this, we might feel an immense pressure to concentrate all our efforts on following what the crowd is doing (using the same exact frameworks, libraries, design patterns, development processes, etc.) and we might lose track of the things that really matter (delivering value to our customers, fostering better team collaboration, comparing our progress to a bigger picture, etc.).

As exciting as the tech announcements for some developer conferences may be, I encourage others to also take a look at those less technical talks that focus on the soft skills we might sometimes neglect, and to take a step back every once in a while to make sure what you’re doing still makes sense.