1. Tools are not a substitute for thinking
In my years of consulting and working with many organizations and managers, I have discovered a common formula for fixing problems, and that is managers trusting that tools can "solve" a given problem. This works well when the problem domain is well understood, and when there are unlikely to be many exceptions, and when everyone behaves the same way. Unfortunately, many real-world problems are not.
Too many times I've seen managers use organization-wide tools to lock themselves into specific ways of working. Naturally, the tool failed to solve the problem and blocked the real completion of the work. Tools should be there to help, to help prevent known mistakes, and to help us remember repetitive tasks, not replace thinking.
2. Unless the management team can truly understand the value of an agile “transformation,” it won’t work.
Many managers make the mistake of thinking that the rest of the organization is making changes while only those who are involved are doing the work. Talent needs to "accept agile." Doing this kind of orchestration in an enterprise takes a lot of time and skill as you focus on synchronizing changes at different levels of the organization.
Organizations that want a part of their organization to embrace agile face a real threat. As the saying goes, "Either change the organization, or change the way it is organized."
3. Learning requires a safe environment
The necessary process for learning is to make mistakes. In the Dreyfus model, this means that, especially at the advanced primary stage, one needs to learn by making mistakes. But people don’t risk making mistakes when they feel that making mistakes will have a bad impact on their jobs, losing the respect of their colleagues, or hurting others in the process.
Because I'm passionate about teaching and learning, I've figured out ways to create a safe space for failure, where failure can be learned by making basic mistakes.
4. Everyone Can Be a Leader
I've written about this topic before because it's a very important observation. A common mindset trap I see is that people feel that in order to be like a leader, you need to be in a leadership position. But people can actually demonstrate their leadership regardless of title, and can do so in many different ways, simply by taking action on things that are not clearly expected or required.
5. Architects who write code tend to make the best decisions
In the Tech Lead courses I run, I advocate that tech leaders spend at least 30% of their time coding. Spending time coding helps build trust, respect and understanding of the current system. When making architectural decisions, not taking into account the constraints of the current system often leads to bad decisions.
6. Change takes courage
I remember someone talking about XP values and one of them was courage. Courage is necessary when leading because you take the risk of failure and the risk/reward of trying something new. Without risk, there is often no great reward.
7. The key to building trust is
to do what you say. There is an old adage, "Do what you say, don't watch what you do." In reality, no matter what you say, people will first remember that you are how to act. You have to always remember to walk the talk. Inconsistent words and deeds can damage mutual trust. Saying "no" or "not now" is much better than promising to do something and not doing it.
8. Successful pair programming is associated with good collaboration
While not all pair programming environments are healthy, I believe that when pair programming works effectively, teams tend to have a better collaborative culture. Many developers prefer the anti-pattern of (long-term) branch-based development because it delays feedback and a potential source of conflict.
I see (navigable) conflict as a healthy sign of a collaborative team. Postponing feedback, such as in the case of long-term branch code reviews, tends to lead to more dissatisfaction because it's delivered so late.
9. Multimodal Thinking Promotes Stronger Results
One of my favorite subjects in college was Introduction to Philosophy, where we studied a different philosopher each week during that semester. Over the course of my career, I have come to appreciate the value of diversity and have begun to see things through multiple perspectives. Systems thinking also recognizes that facts can be interpreted in different ways, leading to new ideas or solutions.
10. Recognize that everyone has different strengths.
Everyone is unique, and everyone has their own strengths and weaknesses. While we tend to look for like-minded people, teams with broad strengths do better. Strengths in this area can become weaknesses in a context, so when team members have broader strengths, the team becomes stronger. While differences in strengths can lead to conflict, healthy teams embrace each other's differences rather than abhor them.
11. Lifelong Learning
The world is constantly changing and we always have the opportunity to learn new skills, techniques and tools. We can even learn how to be good at learning, and there are books like Apprenticeship Patterns and The First 20 Hours that teach you how to do that well.
12. Positive Influences Spark Happiness
Drive, a popular book, talks about how people develop happiness by moving toward a goal. In my experience, helping others find solutions and having a positive impact on them is the source of happiness.
Conclusion
These twelve points above are not all of the lessons I have learned during my 12 years at ThoughtWorks, but they are certainly some of the more important lessons that have helped me serve clients.
Author of translation: Code Agricultural Network – Xiaofeng