"Culture can affect whether programmers are able to get long stretches at all. If they aren't, then they're obviously more available to short-term tasks such as

"Culture can affect whether programmers are able to get long stretches at all. If they aren't, then they're obviously more available to short-term tasks such as code reviews." Good point. I do like to distinguish between tasks of an architectural level, or at an implementation level. An architecture task can take a few days, an implementation task can take an hour. I find myself to be able to think only on one level at a given time. Doing code review while in my lead and architectural position is very hard, as that is on an implementation level. I also feel the need to lock myself away from the team to "think technical thoughts" when I have an architectural task to complete. I usually plan a meeting before I start on such a task, where I can present the design and discuss it. It's the architectural equivalent of a code review. I do find it important to differentiate between the two types. Stories that are all about implementation can usually be split up into smaller tasks. A rule of thumb is that you should be able to finish a task a day. This keeps people from repeating the same things at a standup (the same story as yesterday) and organises tasks in small enough tasks, that you can do code review. A culture reflects how the company is structured and vice versa. Is this kind of stuff explicitly planned at your company, or do you guys use a more laissez-faire kind of approach and everybody seems to find their own way contribute to the whole?