I'm working with a team of five developers working on a software product. The tasks range from very basic to rather complex.
There is no rule making it mandatory to use pair programming. The current practice is to ask to pair-program when one is facing a situation where pair programming would be beneficial: either an ambiguous or complex situation, or a case where there is a lot of logic or business rules which are not easy to understand or to transcribe into code, or a problem which may not be clear to understand later.
Some tickets clearly invite pair programming and are started this way. Some other tickets are simple, and are successfully performed by a developer working alone.
A few tickets, however, look simple, but as the developer is working on them, he discovers that the situation is much more complex. Usually, the discovery is not sudden, but grows organically. The original fifteen minutes of easy work become an hour of not so easy work, then two hours, then a day of a rather complex stuff.
I observe that in those cases, the developers usually remain alone, trying to persevere. It's only in retrospective that they notice that asking someone to come pair with them could have been very beneficial.
Why is this happening?
What should be done to ensure developers ask for help soon enough when they notice that the problem is more complex that it appeared originally?
It would be useful to note that when somebody from the team is facing a problem he cannot resolve, he would probably ask for help rapidly enough—likely within minutes after being blocked. The cause is therefore not the fear of looking incompetent or disturbing colleagues, but rather the inability to perceive the fact that the task became difficult enough, probably related to the boiling frog behavior.