At first, the answer may seem obvious. You may be tempted to assume that the teams are anti-Agile and they’re never going to buy into Agile. This could be the case, but you may want to consider other explanations. Some teams are convinced that pair programming and test driven development will slow them down. For instance, pair programming can be viewed as inefficient (especially when you take it one step further towards mob programming). The truth is, pair/mob programming is inefficient. But efficiency is not the goal. EFFECTIVENESS should be the goal. Most teams want to show how busy they are because they believe that equates to throughput. Agile teams should strive to complete as many stories as they can instead of having 10 stories that are all 90% done. 90% done is the same as 0% done. In reality, pair programming INCREASES the speed of development because teams will be able to close out stories faster. Many teams view TDD as extra work. So naturally they assume that any amount of extra work will delay the delivery of the story. This scenario becomes even more troublesome as teams feel pressured to deliver stories and meet their sprint goals. What teams often fail to realize is that TDD saves time. TDD enforces upfront testing which translates to faster feedback. This faster feedback means that teams don’t have to waste time later on fixing defects when they’re much more costly. TDD not only helps to complete the task at hand but it also serves as regression testing when the corresponding code is changed at a later time. Finally, the test-first mentality forces the code to written in a way that it is testable. This forces elegant design which results in SOLID principles and other benefits. Another reason that teams may be hesitant towards these 2 XP practices is that there may be a misunderstanding that has been accepted as the truth when in reality it isn’t. For example, some people may be uncomfortable with the thought of sitting side-by-side with someone for an entire day when they are used to working by themselves in a cubicle with 8 foot walls. What many people fail to realize is that there are many ways to do pair programming. Some pairs do program side-by-side for the entire day. Other pairs switch every 90 minutes (i.e. promiscuous pairing). While others continuously rotate between working individually and then pairing. A misunderstanding of TDD is that it’s redundant. Many teams feel that they already have testing in place (whether it be manual or automated) that negates the need for TDD. Some teams use high-level testing frameworks like Robot or Selenium (which are both good tools), but they assume the coverage replaces TDD. TDD provides a different level of testing. It is concerned with a specific unit of work and that’s it. Trying to cram low-level testing into Robot or Selenium will just make those tests fragile and difficult to debug. The bigger question is, when there’s resistance to pair programming & TDD, what can you do about it? Like most things, try to get to the root cause. Maybe the hesitation comes from something that was mentioned in this blog. Regardless, find ways to address the root cause. That may require additional training which may need to be budgeted for. But it doesn’t have to be formal training. Scrum Masters can gather their teams for an hour to watch a webinar on Pair Programming (for example). Or maybe starting a Community of Practice (CoP) on TDD. There are times when some people refuse to try. If this does occur, some individuals may need to be removed from the team or the entire organization.
コメント