Hey 👋 this is Luca! Welcome to a ✨ monthly free edition✨ of Refactoring.

Every week I write advice on how to become a better engineering leader, backed by my own experience, research and case studies.

You can learn more about Refactoring here.

To receive all the full articles and support Refactoring, consider subscribing 👇

Become a better tech leader ✨

When I studied CS at university, I remember being told the mythical story of how the Agile Manifesto was born.

These 17 people, closed in a chalet on the mountains in 2001, who spent a few days and came up with the 12 principles that defined software engineering culture for the next two decades.

Aside from these founding fathers vibes, though, there are actually many things people get wrong when remembering this moment.

📜 Pre-Manifesto Era

For instance, many believe the manifesto led to the creation of the various Agile methodologies we are all familiar with. Actually, the opposite is true: Scrum, Extreme Programming, and others mostly predate the manifesto.

In fact, the manifesto was born out of the necessity of putting order into all these similar-but-different disciplines.

Why am I telling all of this? Because it seems to me today we are in a similar pre-manifesto era. Many people struggle at defining what Agile really means, while successful subcultures like DevOps, Continuous Delivery, and Lean, each cover only some parts of the original Agile scope, with overlapping principles.

So a few days ago I went back to the original manifesto — kind of how you go back to the Scripture — to draw some inspiration from it.

🔢 The Four Values

Reading the 12 principles today, they still feel very relevant. This is already an incredible feat in such a fast moving industry.

But we also learned a lot in these 20 years, and we can probably reframe these principles today in the light of such learnings.

So I started annotating the principles and extracted a few major themes from them. I chose the ones that were both the most recurrent in the manifesto, and I believe are the most important today.

Here they are:

1. 👥 Work closely with stakeholders

2. 🚚 Work in small batches & deliver incremental value

3. 🏅 Give teams agency

4. 🎨 Promote simplicity and good design

Let's explore each one and why I believe they are the key takeaways from the Agile manifesto in 2021.

👥 Work closely with stakeholders

Good communication with stakeholders is a primary factor in any project's success, and Agile has long preached about keeping customers in the loop and welcoming requirements' changes.

This feels as relevant today as ever.

Startups move at super high speed and need to work closely with users to find product-market-fit. Larger businesses need to stay lean and react fast to market changes.

How do you know if you are doing it right? You can ask yourself these questions:

• 🔍 Are customers able to regularly review new features? Have you set up an effective feedback loop for your work?

• 📣 Are customers able to suggest new features? Are you in touch with what customers really want?

• 🏆 Do you know what success looks like? Have you set KPIs and targets for product success?

🚚 Work in small batches & deliver incremental value

Splitting work in small deliverables is key to the health of your development process.

Small batches lead to frequent releases, which in turn make the feedback loop faster and reduce risk.

This virtuous cycle means that, counterintuitively, there is no trade-off between speed and stability in software. Higher speed brings higher stability, because it also brings faster recovery from failures.

Luca Rossi @lucaronin

Stripe deploys 10 times a day, while maintaining 99.996% availability. This surprises many people, but it's just natural. Continuous delivery brings stability. – Frequent releases = small batches = less risk – Fast releases = fast recovery from failure

Patrick Collison @patrickc

Fun fact: we deployed 3,350 new versions of the Stripe API last year. https://t.co/19Pv2Iu2gk

March 8th 2021

8 Retweets14 Likes

How do you know if you are doing it right? Ask yourself these questions:

• ⚡ How fast can you release? High performing teams deploy to production in 10 minutes, and do it 10+ times a day.

• 🏃 Do you iterate on features? After a first version is delivered, do you leave room for iteration? Not doing it leads to half-assed features and turns the process from agile into a series of mini-waterfalls.

🏅 Give teams agency

A simple way to sort high-performing from low-performing teams is based on their agency:

• Bad teams are given solutions to implement.

• Good teams are given problems to solve.

• Great teams are given the agency to find problems and provide solutions.

The best results I have witnessed in software have always been delivered by diverse, cross-functional teams who had the skills and trust to independently iterate over a product.

The manifesto got this exactly right, also highlighting the key elements to make it happen:

• 🤝 Trust (point 5) — teams should have the agency to find both problems and solutions on their own.

• 🔄 Self-organization (point 11) — teams should be able to work independently and include all the skills needed to evolve the product.

• 🧘‍♂️ Reflection (point 12) — improvement is obtained through regular retrospective within the team.

🎨 Promote simplicity and good design

Out of 12 principles, it may seem weird that only two (9 and 10) talk explicitly about software design, but I actually think they tell everything you need to know.

Good design means minimizing the work to be done, both right now and in the future, and this mostly comes from good communication.

In fact, technical excellence comes from good understanding, as much as technical debt comes from the lack of it.

A few directions to get this right:

• ✍️ Invest in good design — this means, of course, engineering analysis, but also a lot of talking with stakeholders. Make sure you discuss both the here and now and the future evolution of the project, to be able to produce a design that stands the test of time.

• 🙅🏻‍♀️ Avoid premature abstractions — when you have limited understanding and/or limited context into the future, stick with simple solutions that are easy to refactor once requirements consolidate. Wrong abstractions are hard to remove and are the #1 source of tech debt. Even duplicating code is often better than a bad abstraction.

• 🧩 Buy instead of make — as stacks and platforms consolidate, there are less and less use cases where it makes sense to write custom, expensive code. Building something with code should be your last resort, instead of your default solution. Take advantage of frameworks, no-code and low-code tools to reduce the tech footprint of your product.

📚 Resources

I wouldn’t have been able to create this article without the several ones I wrote in the past about the same topics!

Writing them allowed me to reflect on what I believe in, and provided most of the ideas that ended up into this one.

Here are a few, organized by the four themes:

👥 Work closely with stakeholders

• 📑 The Pyramid of Stakeholders — this article explores the relationship we have with the different types of stakeholders and provides advice on how we can communicate well with them.

• 📑 How to Design a Communication Architecture — in 2012, Ben Horowitz wrote that a CEO’s most important duty is "to design a communication architecture for their company". This article provides a step-by-step approach based on responsibilities.

🚚 Work in small batches

• 📑 The Four Measures of Software Delivery Performance — this article explores how delivery metrics reliably predict wider business performance and benefit your company goals.

• 📑 How Shipping Fast Changes Your Life — shipping fast is truly one of the major areas that separate elite engineering teams from average and poor ones. Here is what happens to your team when you ship fast (or slow).

🏅 Give teams agency

• 📑 Feature Teams vs Durable Teams — a reflection on various teams configurations through the lens of ownership, resource allocation and decision making.

• 📑 The Pyramid of Engagement — in over 80 years, Gallup defined a model for workers' engagement which is based on twelve needs across four categories. Here I discuss them and provide a small framework to support them as leaders.

🎨 Promote simplicity and good design

• 📑 The True Meaning of Technical Debt — this article dives into the origins of this widely used metaphor, why it is often misunderstood, and provides some battle-tested advice about how to deal with it in real-world situations.

• 📑 The Best No-Code Tools You Should Use — No-code tools have grown from being a cute option for non-technical folks to an indispensable weapon for any engineering team. This article includes a list of my favorite ones, organized by purpose and category.

⭐ Weekly Featured Jobs

Here are the jobs featured this week!

1. Tidelift: Senior Software Engineer (Remote)

2. Candor: Software Engineer, Infra/Backend/Full-stack (Remote)

3. Catawiki: Senior Back-end Developer (Remote)

4. Pallet: Full-Stack Software Engineer (Remote)

5. Secureframe: Full-Stack Software Engineer (Remote)

6. Solv:Full-stack Technical Lead (React) (Remote)

7. Hatch:VP, Mobile Engineering (Remote)

8. Gearflow:Full-stack Software Engineer, Marketplace (Remote)

9. Foster:Founding Lead Engineer (Remote)

Browse many more open roles (or add your own) on the full board 👇

Check out all Refactoring Jobs

Hey, I am Luca 👋 thank you for reading this far!

Every week I read tens of articles and draw from my own experience to create a 10-minutes advice about some engineering leadership topic.

Subscribe below to receive a new essay every Thursday and put your own growth on autopilot!