XP is a “software development through the eyes of an engineer” kind of methodology. It focuses heavily on engineering practices.

On contrary, neither Scrum nor Kanban seems to care much about best software development practices. But wait, if you read about Kanban a bit you’ll quickly find an advice to focus on your engineering practices too as Kanban (or Scrum) alone is not enough.

Actually I can’t recall any project management approach which says “when it comes to code, do whatever – this whole programming thing doesn’t really matter.”

So we’re back here again – a set of best software development practices is important. Yet, there is plenty of them, how to choose the right ones?

You may choose a set of tools you believe are most valuable. However if you don’t have comfort of choosing toolbox first and then looking for people who are familiar with tools (or at least willing to learn how to wield them) you’re likely to fail.

Every change is difficult and developers tend to be pretty stubborn. Yes, they will do this whole code review if they really have to, what a big deal anyway, but don’t expect to get decent results unless developers believe it is a valuable technique. They will hate it probably as much as filling data in time tracking app, which isn’t even close to what you wanted to achieve, right?

And this brings me to another approach: let engineers choose which engineering practices they want to employ. Let them argue. Let them look for consensus. Help them in facilitating discussion if it’s necessary but don’t enforce any specific technique. Throw in a few ideas but if they don’t catch up don’t try to use your magic power: “I can force you to do so.” If you’re a team leader or (even worse) a manager it’s not you who will be doing this darn thing every single day for next couple of years so just shut up, OK?

The best set of engineering practices is the one which will be adopted by engineers. And yes, this means it will be changing over time. The more mature the team is the more practices people are able to adopt.

The same rule works in other areas too. Product management? Well, don’t you have a product owner or something? Let her decide. Testing procedures? Shouldn’t you agree to whatever your QA guys want?

When it comes to discussion on standards a manager should take a step back and let a decision to be made by people who will be affected.

There’s one trick here however. If you happen to work with inexperienced or just average people the consensus may be “let’s just hack some code instead of wasting time on this stuff, we’re Cowboy Coding Wizards and nothing can beat our code.” But then you have a bigger problem than deciding which of best practices your team would use. You better start to evangelize your team a bit or look for another job, whichever looks easier.

There’s another trick too. What to do if you have hundreds or thousands of developers? Well, different toolboxes should emerge in different teams and it would be pretty stupid to try to standardize all of them. “What if nothing emerges despite a multiple teams working on software development?” you may ask. Well, running away while screaming would be a pretty good option there I guess.

You didn’t really expect to see here The Big List of the Best Engineering Practices Every Team Should Adopt, do you?