| The necessary time isn't spent thinking on the tasks but instead the pairing rushing things through with very little thought to design and long term maintainability. Indeed, and this is a problem that can affect other “Agile” practices too. Mandatory/permanent pairing is one example. TDD is another. Both can reflect a more general trend to try to break development down into tiny steps. It’s not that there is no value in developers working together in real time, or in unit tests, or in incremental development and short feedback loops. All of these can be very useful. In my experience, they are often adopted spontaneously by developers even if there is no formal process in place that requires them. But it’s also important to look at the big picture. You need a coherent vision for the product. You need a consistent domain model that is well understood and shared by both developers and non-developers. You need a reasonable software architecture that provides useful patterns and abstractions but also isn’t afraid to change them as requirements evolve. Without these things, it’s easy to take a lot of small steps and create an illusion of progress, yet not move efficiently towards your true goal. Increasingly serious problems tend to get shoved under the carpet (sorry, “added to the backlog” or “labelled as tech debt”) until inevitably quality and productivity start to suffer. You can’t fix those kinds of problems working in the small with only one or two participants. |