- Purpose of this article
- A3 Thinking - The Lean Problem Solving Approach
- How to Use Cause-Effect Diagrams
- Example 1: Long Release Cycle
- Example 2: Defects Released to Production
- Example 3: Lack of Pair Programming
- Example 4: Lots of Problems
- Practical Issues: How to Create and Maintain the Diagrams
- Pitfalls
- Summary
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Example 3: Lack of Pair Programming
I was asked to help a client figure out why they weren’t doing XP practices like pair programming and test-driven development. “We know that we should be doing it, but we aren’t”.
){kind=small}
So is lack of TDD and pair programming really a problem? As usual, the things we call problems often turn out to be just symptoms.
Q: What is the consequence of not doing pair programming and TDD?
A: We think we would have much better code quality if we did these things.
Q: What is the consequence of bad code quality? Have you encountered any actual problems due to bad code quality?
A: Yeah, we’ve had some crashing demos. We are a research company and demos are how we get business, so this is really a problem.
)
OK, let’s take one of the issues and see if we can dig down to the root.
Q: Why aren’t you pair programming then?
A: Because many people are afraid that it won’t work, and that we will be wasting our time. We have no proof that it works.
Q: What kind of “proof” would you need?
A: Well, we’ve seen studies that indicate that it works. But nobody here has really tried it, so we aren’t sure that it works.
Well, there’s the first loop:
)
They don’t want to do it because they don’t know that it will work. And they don’t know that it will work because they haven’t tried it...
Q: Why haven’t you at least given pair programming a try?
A: We don’t have time to experiment.
Q: Why not?
A: Because we don’t have any slack. Each hour is accounted for. Our customers keep piling work on us.
Q: Why don’t they let you manage your own time, and let you pull in more work whenever you are ready?
A: They don’t trust us to use our time effectively.
The lack of trust also leads to a general fear of failure, which of courses reduces the likelihood that they will try something new like pair programming without “proof” that it works.
)
So there appears to be two big root causes: Lack of trust, and the management principle that every hour must be debitable. Let’s fold this back into the big picture.
)
Lack of trust turned out to be the root cause of not doing XP practices such as TDD and pair programming. That causes bad quality which causes crashing demos. And guess what? Crashing demos reduce trust even further. There’s a vicious circle for you!
The interesting thing is that we did this in a 2-day workshop with about 25 people. At the beginning we were talking mostly about technical stuff – how to get started with TDD and pair programming. That didn’t really get us anywhere, so we instead split into groups and had each group choose one problem and start drawing cause-effect diagrams and create problem solving A3s. The interesting thing is that several of the groups that were analyzing seemingly different problems came up with the same root cause – lack of trust! The diagram above was just one example of this.
So by the end of the day we were all talking about what we could do to increase the level of trust between the customer and the developers, which was a surprising turn of events.
For starters we agreed that we should invite “them” (the customers) to participate next time we do this type of workshop, which should lessen the use of terms like “us” and “them”...