But not everyone on a team will be able to spot particularly potent smells, or even know what to do with them once they are spotted. There is a capability issue here. What if a system was originally designed to let Java directly output HTML, but it is clear to a few programmers that this approach is far from ideal? And what if no programmer on the team knows how XSLT could replace the Java/HTML code to radically simplify the system? Well, given the burdensome nature of this Java/HTML code, the team might try to refactor it a few times. But if they don't come up with an entirely new approach, the code will continue to be a burden. OK, what if one person on the team does happen to know about XSLT? Then the team has a chance to greatly simplify their system. But how did this one person know XSLT? Perhaps this person is a continuous learner, someone who regularly reads industry magazines to stay up on new technology developments. It's a good thing for the team that at least one person happens to be a continuous learner. But this is certainly far from optimal. I want teams to continuously learn because doing so will help them produce simpler systems, faster than ever. Peter Senge, author of the profoundly important, best-selling book The Fifth Discipline: The Art and Practice of The Learning Organization, had this to say about team learning.
The two most powerful learning tools that I suggest for use by XP teams to support the practice of continuous learning are study groups and retrospectives. |