Isn't a higher velocity a sign of a more productive team?
The Scrum guide is very clear that velocity is purely about establishing the likely capacity of a team for future sprints. The actual value is irrelevant, it is the predictability that is important.
One of the founders of agile, Mike speaks with authority on a number of agile subjects. His focus is slightly more towards the product/project side with less focus on engineering practices.
1. Use the same deployment mechanism for all environments
When you do something often, you get good at it. So deploy to all environments using the same mechanism. That way, when you deploy to production things less likely to go wrong.
Agile emphasises the importance of communication. This is not just about the formal communication at stand-ups and meetings, it is also about everyday communication within the team.
Consider the following example.
A team member tries something new with some automated tests. They hope the change could be an improvement and that it could provide significant benefits.
It has long been a tradition in waterfall style projects to associate long hours with increased productivity. A recurring pattern is up-front planning, followed by realisation that a deadline is not going to be achieved and then finally a push to increase working hours.
Performance testing is often difficult and expensive to do. When you need to get real-World performance figures you need to test on real-World hardware and this is not always possible. Even when it can be achieved it is difficult to do frequently without a dedciated (and hence expensive) performance environment.
