Values, Principles and Practices in Engineering Team

Let's explore transformative effect of defining values, principles, and practices in your team.

Let me start with a little abstract for this article, to set expectations about what you can learn by reading this post. I will explain a method of setting values, principles, and practices (VPPs for short onwards) in your team. I will then share with you why, based on my experience, setting VPPs can be transformative for your team and your company - it's vital for hiring, engineering culture, team alignment on making engineering decisions, professional fulfillment, and high team morale and psychological safety. High team psychological safety leads to high team performance. Last but not least, strong VPPs in a team serve as an antidote against the "effect of broken windows" and lack of direction.

In the end, I will bring actual examples of some of our Platform team's VPPs in Pactum, so it would all click for you and hopefully inspire you to define your own unique VPPs in your team - and it's my objective in this article to help you with that, without wasting your time hopefully!

Still interested? Let's dive in.

Standing on shoulders of giants: Kent Beck introduced VPPs in XP book

I first heard about the concept of engineering values, principles and practices from Kent Beck's book Extreme Programming Explained, aka "XP book". For those who don't know, Kent Beck quite literally revolutionized software engineering (not alone of course, but he had a big impact). He introduced Test-Driven Development (TDD) to the industry, explained the importance of team dynamics and doing engineering socially through his work of extreme programming. Pair programming was an unthinkable practice until Mr. Beck made it a norm. None of these things are silver bullets, but they were a force to reckon with, no one can deny, that shaped our industry. These things changed our mindset, collectively and steadily as an industry, about software engineering.

The 1st edition of the book is from 1999, yet the idea that Kent Beck introduced there about teams defining their values, principles, and practices holds to this day, in my opinion. As they say, "there is nothing new under the sun".

To explain quickly what do I mean by VPPs, and how they are interconnected with each other, let me bring one example based on Kent Beck's XP book.

One of XP Values - Feedback. “Though planning ahead can avoid some mistakes, it’s only through actual work that you can understand your real obstacles“. (Extreme Programming Pocket Guide: Team-Based Software Development (p. 8). O’Reilly Media).

Some XP Principles based on the Feedback value above:

1. Rapid Feedback: Implement mechanisms for getting quick feedback on the work being done to allow for timely adjustments.

2. Incremental Change: Make small, incremental changes rather than large, sweeping changes to ensure better control and understanding of the impacts.

3. Embracing Change: Be open to changing requirements and improvements as the project progresses.

Some XP Practices, based on the above Principles:

1. Test-Driven Development (TDD) as the tool for getting rapid feedback, especially on your software design.

2. Refactoring: Continuously improve the code by making small changes to keep the design clean and efficient without altering functionality.

3. Continuous Integration: Integrate code into master/main branch frequently, ideally multiple times a day, to catch issues early.

4. Small Releases: Same idea as continuous delivery. Deliver small, incremental updates frequently to get quick feedback and make continuous improvements.

I have omitted many other practices that Kent Beck describes in more detail in the book, but that's not the point of this blog post. I am not indoctrinating you to follow extreme programming here, he-he. Actually, the main idea is for your team, and for yourself, to discover your own VPPs.

Values inform principles, principles inform practices

Values are the most generic, but serve as the core that a team adheres to, believes in, and lives by. Values rarely change. Values are domain agnostic. As Carl Rannaberg, my fellow colleague and staff engineer in Pactum wrote in his blog post, "know your core values". Once you know your values, decisions and choices become easier in everything!

Principles are then built upon values. Principles are more specific and closer to the actual nature of work we do and the domain we are involved in. Principles in fintech engineering might differ from principles in medtech, due to different nature in domains. Principles change more frequently than values, but less frequently than practices. Reflect on your team's principles from time to time, for example quarterly. If your principles don't serve you well - change them!

Practices, in turn, are concrete and practical protocols/actions that a team and individuals can implement in their work. Practices can (and maybe should) change often. One of very good places to reflect frequently on a team's practices are team retros. If current practices don't work for you - experiment and change them! There is no shame in changing practices often - on the contrary, learn and evolve practices continuously in your team.

If, let’s say, in our team we value feedback and have a principle of rapid feedback loops, but we don't support it with any practice of, let's say, automated tests that give us confidence to continuously release, then we should take a good look at the mirror and calibrate if what we believe in is supported by our actions.

In a diagram below, you can see how values, principles, and practices are related. Notice the dependency graph. Values don't depend on anything, they are the core. Principles rely on values. Practices rely on principles. X axis is  frequency of change - how frequent a change occurs for a certain thing. Y axis defines level of specificity - how specific and detailed a certain thing is (value being not specific, while practice being very specific).

practices rely on principles, principles rely on values

From theory to practice

So far all of this might sound like a theoretical mumbo-jumbo probably. I hope you still follow me, since this is the most interesting part now. It's not about following someone’s VPPs, but the point is to set your own, of course. No silver bullets served here, unfortunately.

Now you get to define your own values, principles, and practices. This is the most scary (because responsibility now is on you) and exciting part. Here. Take your team for a 1 hour meeting to define the first draft of VPPs. During the first 20 mins, each team member thinks and writes down what they believe should be VPPs in the team. The rest of the 40 mins is discussion and comparing VPPs. Optionally, in the first session, focus only on values and principles. Add discussion on practices in next sessions.

You will be blown away probably by how much you will learn about your teammates. Find commonalities. Discuss differences. Try to align and create the first draft of VPPs for your team. Sleep on it. Iterate once again on the next session some other day. Now your team has a first version of its values, principles, and practices! Treat it as a living document, let it reflect reality.

"Wait...what are the benefits anyway? Are you trying to sell something to me?" I hear you say. Fortunately, defining VPPs is free of charge. No certificates to make you "certified VPP coach". OK, I will stop making fun of agile certificates now :)

Let me share the real benefits of VPPs that I experienced.

Benefits of defining values, principles, and practices in your team

Hiring

Hire first and foremost based on a person's values and principles, supported also by the person's actual skills and experiences. Look at stack-specific experience as the last thing.

Let me give an example. When I interviewed Allan (who used to work in Skype, Microsoft, and Twilio) to join our Platform team in Pactum, I deliberately ignored the fact that the stack Allan used in previous jobs is very different from what we use in Pactum (Allan was not versatile in Kotlin or TypeScript/Node.js). It didn't matter. Allan held very strong engineering values and principles. We aligned on them 100%. I knew he would be an amazing addition to the team! Then I verified skills, but asked close-to-zero stack-specific interview questions. Now my teammates and I are very happy about Allan being in the team!

Once you have VPPs defined in your team, if a hiring candidate doesn't match your team's values and principles (it's a matter of another blog post how to verify a person's values and principles), I suggest don't even go further in the interview process. 

Also, consider sharing some of your team’s VPPs in your hiring application page. This will attract candidates that you intend to attract, and filter out those who do not align with your team’s VPPs.

Enabling team growth, empowerment, high performance

There is some likelihood that your team has some "legacy" to deal with, tech debt, some codebases that you know were written in a hasty way. The effect of broken windows is very real and can creep in as well. It leads to mediocrity and de-motivation, which cannot be underestimated. "If something is not written well in the first place, why even care right now"...Right? 

Once your team defines its own values, principles, and practices that it believes in, and team members hold each other accountable for adhering to them, suddenly the power is in your team's hands. The team doesn't feel helpless anymore. There is a sense of direction for growth and improvements, guided by your VPPs.

The positive effects are cascading even further. For example, there are no more senseless pull request discussions about "should this critical module be tested or not". If, for example, your team has a principle that all business-critical logic should have effective automated tests, the answer to the above question in the PR becomes obvious - "yes". The best part - you all agreed to this principle. No one forced it on you. This binds well with team members feeling empowered and responsible for their choices and actions. Your team has won, and mediocrity and helplessness are shocked in disbelief that they lost.

Over time, VPPs, in my experience, help teams to have high morale and strong psychological safety. High team psychological safety is a major factor to high team performance - this phenomenon was researched and is quite known in the industry by this point.

In addition, when there are heated debates, the team relies on its values and principles to guide the debate. It avoids dogmatic senseless debates, for example, “TDD sucks. We should not use it”. Start conversation with the team's values and principles. TDD could be part of a team's practices, and is just one tool in a toolbox. Align on values and principles first :) The debate on values and principles would be much more productive than arguing over practices in the first place.

What we value in Platform team in Pactum

I am Platform's engineering lead in Pactum, and, yes, we do have VPPs that we follow. Many of our VPPs we have reiterated to ourselves many times verbally and we know we agree on them, because we are a tight-knit team. We did have a session, as I described above, of sharing with each other our VPPs that we want to adhere to. Luckily for us, the intersection was almost 90%+. We are hiring more engineers into Pactum right now, so I think having VPPs written down in a concise document is worth it (we will do it as the next step), as it helps to align with new team members quickly and to onboard new members effectively.

Not to bore you with our VPPs, allow me to share just one value that we strongly believe in inside our Platform team, and I will list some principles and practices that are derived from this value.

Value - we do hard things together. Principles that are derived from the value above:

1. We avoid knowledge silos like fire. Everyone can take vacation any time without any stress. We rotate knowledge all the time, effectively sharing knowledge in the team continuously.

2. Feeling safe and empowered in the team. Having psychological safety - expressing our own opinions with respect. Avoid groupthink.

3. We limit work-in-progress work, to avoid parallelizing too much.

4. If someone is stuck, we help each other and unblock each other. It’s about team’s throughput, not individual’s throughput. 

A set of practices that we derived from the above principles. 

1. We work on epics together - at least 2 people from the team on one epic. Epic usually lasts 1 to 2 weeks, preferably 1 week. If the epic seems too large - we split it, until it’s scoped to ~1-2 weeks.

2. Epic owner is assigned for an epic. We rotate epic owners continuously for new epics. It helps all of us in a team to exercise leadership, which comes with making decisions and responsibility. 

3. Epic owner decides how to organize work with teammates in the epic. They manage tickets themselves, decide how they work, when they sync, do they use pair programming or not etc.

4. Usually, we do 2 epics in parallel in our team during any week.

5. Also, to break the reinforcing loop of having same teammates being dragged into the topic they dealt with again (which creates knowledge silos), we rotate deliberately who is working on what, to make sure we have a continuous knowledge sharing of different topics in our team's surface area. 

Note that we have these practices at this point in time as I write this blog post. We reflect on and evolve our practices constantly on our team retros.

Engineering culture in a company: scaling values, principles, and practices

I suggest you start with VPPs in your team. First put your house in order, then change the world :) Once you experiment with VPPs and it works out for you, go share the learnings with other teams in your company, through engineering knowledge sharing sessions that you have. Don’t indoctrinate, but share your successes, and others might readily follow. This is called leadership and how you can actually affect engineering culture in your company - when others see that you practice what you preach and are inspired by it.

And that's it for this article. I hope you enjoyed it! I hope you will reflect on values, principles, and practices in your team. Also, if you have read this far, and you would like to consider joining Pactum, check out our careers page, we are hiring!