Dragan Stepanović

The ways that we usually set up “cross-functional” teams doesn’t really help us with this, but it’s crucial for each member and role in a product development team to ask these questions on a regular basis:

• “How are our features doing in the production?”
• “Are they meeting users’ needs?”
• “How do we know that that’s the case?”
• “Are they solving the problem that they were supposed to solve?”
• “Is the work and effort we’re putting in delivering value or we’re just spinning our expensive wheels?”

Have you thought about how architecture and functional decomposition of a system influence documentation and a need for it? 🙂

It’s very true that in environments without psychological safety pairing/mobbing or any kind of close collaboration won’t work.

Mob/Pair-Commit-Revert

Actually, most often they hurt predictability because of a narrow focus on achieving the short term goal of meeting an estimate and piling up cruft, which then hurts predictability.

In order to shorten lead times and increase throughput of the system focus on managing (reducing) the queues, not the work.

I have a feeling that decision making in organizations in which everyone is so busy that they have no time to build relationships with other people in the company and talk about the topics that are not related to the task at hand will necessarily grind to a halt.

Because the cost of code review when pairing/mobbing is literally zero (reviewer immediately available next to a developer typing the code), it is more likely to both:

• get the feedback in a timely manner (as you type the code) and
• get very rich feedback (which tends to be the case because it’s verbal and immediate, in context)

simply by encouraging people to collaborate more.

you’ll do Continuous Integration with centralized (e.g. Subversion) than with a distributed versioning control system (e.g. Git).