Myths about Developers

In our process of implementing Agile and Lean, I have realized that there are things said or thought of about developers that Agile/Lean are showing as myths. If you still believe these statements are correct (or have developers believing them as well), you need to change your thinking if you want to adopt Agile/Lean. I used to believe some of these myself until I was surprised to find something much different.

Myth 1: Developers make poor testers. We established an entire QA department based on this myth. Developers don't like to test. Developers don't know how to do it. Developers are too close to their code. Developers should not test their own work. We said these things thinking that testing was a unique skill that could only be taught to non-developer types. What we realized is that these skills can be taught to anyone but few developers really know how to think about tests. The value of QA (or other testers) is to make sure that multiple people validate the test results. Two heads are better than one.

Myth 2: Developers do not work well in teams. It is thought that most developers by nature are introverted, and would rather go off and work in the corner than interact with others. Therefore, they we thought they would have a hard time with the teamwork that is required of Agile and Lean. What we realized is that developers just want to make sure there is value working in teams and they will come out of the comfort zones if it makes sense to accomplish more as a team. I will agree that for some this is an easier process than others, but eventually I have seen all developers warm up to working with others on a team.

Myth 3: Developers are not good in front of customers. Developers are too technical for customers. They talk above their heads. They don't have great communication skills. They are too brash and abrupt. They don't really care about what the customer wants. These are things that I have heard (and perhaps even said). However, just like testing Developers just haven't received the proper training and experience to work with customers. For most, it isn't natural to them. But, if you have them working often with customers they learn quickly. The customers also learn how to adapt to working with technical people. In the process, they learn the value of some of the "technical talk". Agile/Lean forces everyone to think in terms of the customer and working more directly with customers (or customer representatives).

Myth 4: Developers only care about coding. I just want to get back to my real job. When we used to use Waterfall, I would hear these words ALL the time from developers. After spending days and days in requirements and design meetings, I couldn't really blame them. However, I knew the value that they brought to those meetings in addition to the knowledge they gained to do a better job of coding. Agile helps developers get to coding more often, which is what they love. While at the same time, they appreciate the time to understand what needs to be accomplished. It's now the time it takes to do that is in matter of minutes or hours instead of days and weeks (and sometimes months!).

Myth 5: Developers want everything figured out at once. As we first implemented Agile, I got some push back from Developers that doing things in pieces would lead to poor architectures, design, missing requirements, etc. With Waterfall, they believed that they were able to get all of those right at the beginning of each project. However, I reminded them that pretty much every project we found changing requirements which lead to changing design which lead to changing architecture. So really how valuable was it to figure everything out in the front?? With that question posed, they gave it a try. And found that they could more easily adjust architecture, design, code by working on things in increments.

Myth 6: Developers cannot self-organize or self-improve. As a manager, this is where I really learned that this was a myth. I honestly thought that project managers and myself as a functional manager needed to be there to identify where improvements needed to be made and make the team implement those improvements (whether or not they truly understand the improvements). As a result, the team became dependent on management to make things better. Those dependencies became bottlenecks, because we would try to implement big changes instead of a lot of little changes. I also thought it was management's job to help assign tasks to people and make sure those people stayed on task. Again, this caused more bottlenecks. Here, the role of management was to REMOVE bottlenecks, yet we were BECOMING the bottleneck. All because of this notion that developers needed management to do these things for them. What developers really needed was practices that provided them the focus, direction, feedback and autonomy to do their work well. They are in the best place to know how to do their jobs well, so shouldn't they be the ones who figure out how best to accomplish that? When management backs off and the teams realize that it is their responsibility to improve things, they will do so. Plus, in the process they will feel better about themselves, their role in the company and their feelings about management.