CodeX
Published in

CodeX

Values of a software development team

I decided to write down the values that I cherish in the form of a manifesto. Hopefully, they can impact the success and happiness of your dev team.

Photo by Lorenzo Herrera on Unsplash

User-centered

We don’t want to build technology for the sake of itself. Our main drive is to bring value to the user, so we avoid technical “stories”. No internal stakeholders are telling us what the users want nor are we simply executing prescribed solutions. Instead, we, as a team, investigate each problem ourselves (e.g. with user research) and try a solution.

We don’t blame users when they can’t accomplish something; instead, we recognize we can make things better. We strive to deliver value and we cultivate empathy with the people who use our software.

Experimentation culture

We never consider anything final and we welcome change; a product is a neverending discovery and user stories are experiments which is why they should be small and vertical slices of value.

We keep the sunk-cost fallacy in mind so we don't get too attached to code or product features, among others.

We try to be open-minded and we fight assumptions. Anyone can challenge the ways of working, product functionality, and technology, and propose new ways. We set hypotheses, devise experiments, learn from them, and iterate.

Trust

As grown-up individuals, the company should trust us to do our jobs and refrain from managing us; they should expect us to make our users happy. They provide us with the autonomy and resources to do such. Dev metrics, backlog, and refactoring, among many other details, are owned by the team.

Within the team and across teams, there’s no “us and them” mentality; we collaborate. Mutual trust is underpinned by a psychologically safe environment, which we hold dear. It’s also built upon a feedback culture, a proper hiring process, get-together activities, etc.

Psychological safety

We embrace differences, care about each other, try to be always kind, and assume positive intent. We value ideas and opinions from anyone; we avoid judgments, blaming, and gatekeeping.

We help each other rather than compete. We often say “I don’t know” and value egoless discussions. We are not afraid to make mistakes because we rely on a culture of quality and safety nets to prevent them (e.g. TDD, automated tests, CI/CD pipeline, pairing) and strive to reduce their impact. We learn and take action when an accident happens.

The teams are in the best spot to run the hiring process as they know the culture and values and can eventually work with the candidates. They focus more on the attitude than the tech skills.

Balanced teams

We keep away from single points of failure so we prefer a flat hierarchy.
As balanced teams, we have a cross-functional set of roles with a high degree of autonomy and collaborate to deliver value to the users (whole team).

We cherish empathy with the users but we recognize it’s not enough, so we value what a diversity of backgrounds can bring to the team and the company.

Autonomy

Following a DevOps culture, we build and operate the product. We are autonomous and empowered to do what it takes to get an idea realized into our users’ hands. This implies no hand-offs nor being blocked by other teams or by individuals (we avoid a culture of champions and heroes).

The team is free to choose methodology, technology, and tools (with few constraints).

We avoid complaining given that we have the power to change things or at least to influence them.

Lean mindset

We seek minimalism — we avoid over-engineering, big design up front, and product featuritis. We prefer to implement what’s needed with the least effort to fulfill each goal. This includes scope definition, product complexity, technology decisions, and processes.

We continuously try to eliminate waste. We detail user stories and solutionize as late as possible and avoid early buy-in.

Focus

We acknowledge that overtime reduces focus so we keep that in check. Quality is generally preferred over quantity.

Context switching takes a high toll. Therefore, we are assigned solely to one team and we limit work in progress. We work on small stories and prioritize work often. To get early feedback and adapt often, continuous delivery is essential.

We help each other and acknowledge that a story is only done when it’s in users’ hands. We are focused on the present; we embrace uncertainty because the future is too volatile; we keep the backlog as small as possible.

Continuous improvement

We learn and grow together, throughout pairing, mobbing, code reviews, workshops, and presentations. We often provide direct feedback to each other and act upon it. Coupled with retrospectives, it promotes constant improvement, individually and as a team.

We continuously refactor the codebase rather than doing it as a separate endeavor. The same applies to our ways of working.

All team members contribute to continuously improving the product, the implementation, and our day-to-day, regardless of their roles, seniority, and expertise.

--

--

--

Everything connected with Tech & Code. Follow to join our 900K+ monthly readers

Recommended from Medium

Software Business Models, Examples, Revenue Streams, and Characteristics for Products, Services…

Progate Co-Founder Kenta’s “Egotistic” Beliefs in The Best Learning Experience for Coding Newbies

What Are the Kotlin Scope Functions?

I Attended a $20 Bootcamp and Became a Full Stack Developer

Introduction to Message Brokers. Part 1: Apache Kafka vs. RabbitMQ

What Is the Navigator in Flutter?

Comparing Executable Specification tools

Getting started with Behavior Driven Development (BDD)

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Luís Soares

Luís Soares

I write about Lean, TDD, CI/CD, trunk-based dev., user-centric dev, DDD, coding good practices, testing

More from Medium

Visualizing Communication Between Bounded Contexts

Fail Fast: Becoming a learning organisation

From ‘you shall not pass’ to ‘the pass is here’ .

The first rule of estimations: Know thyself