Already from the article title I started to have this reaction. As a software engineer, nothing kills focus and productivity faster than interruptions. From the perspective of a manager, I can understand - and really appreciated the respect and consideration that went into the article and the recommended approach.

However, every point in the description of an XP workplace sounds like torture. Paired programming, in a shared room, always a "low buzz of conversation", requirements not written but verbal only.. To be fully engaged and productive, I need the exact opposite.

Regardless of that issue, XP isn't for everyone, and there's nothing wrong with that. I like it though, that's why I'm back. :)

EDIT: Also, I don't know him, but our writer here seems to think a lot about how he interacts with his dev team, which I appreciate, but think maybe he got into his own head about it a little bit too much here. But I also don't really mind interruptions.

> [Stories often] get written up with gherkin-like Given/When/Then sets of acceptance criteria with additional details/considerations noted down

Very interesting to hear, especially in contrast with the "verbal only" approach mentioned along with XP.

For my personality type, I work best when there are requirements/acceptance criteria clearly specified in writing. Even better if the logic is written in a DSL that all stake-holders can create together.

> I also don't really mind interruptions

Yeah, I see that software engineers come in all colors, and some are able to multi-task while fielding questions and interactions all the while. And others, like me, need more isolation / insulation to maintain silence and solitude to be able to focus and be productive.

I suppose that's a challenge for methodologies like XP. In order to be effective, it needs to take into account the different working styles and personality types that exist in a team of any size.

I think the interruption thing is interesting - at jobs where I was solo, I probably minded it significantly more. With constant pairing, different interruptions can be handled in different ways. Two-second questions can be answered by the non-driver while the driver continues to focus. Five minute answers should probably stop both members, but having two brains allows you to bounce back into context through re-merging your mental model of where you left off.

Thinking about this though, I realized that in pairing you have internal interruptions as well - if one person needs to use the bathroom or take a phone call, the other can choose to keep working and maintain context. When the breaker returns they can reload their mental models much more easily. Or you can both take breaks and you've already got a built-in ping-pong opponent ready to play :)

Wow, I never thought of pair programming like that. It sounds nice actually, to let another brain keep the ball rolling while one is busy with something else.

It makes me realize that a big part of my reluctance (preconceived notions about pair programming) is due to having worked alone for most of my career. I never experienced the kind of "mind meld" you describe. I'll remember to keep an open mind about collaborative working methods!

- Some sort of sound barrier so that I couldn't parse the background conversations.

- To be able to decide "what is our current plan?" and to write that down. Of course you'd change to a new plan in light of new information.

Individuals doing solo work are often distracted by background noise, and even I do! But in pairs, it doesn't seem to have quite the same effect in my experience.

On the planning part, I know a lot of pairs that set up small daily roadmaps to stay on track. Totally normal, and also totally ephemeral as well. Usually an updated plan is drawn every day since the pair might change.

Yes. Its an unpleasantness I endure if I’m not trying to work through anything which is an intense use of my Working Memory.

The theory is that introverts don't dislike social interaction but unsafe social interaction. It's why you're generally more social with friends and family.

Left the company for a usual startup setup with your own Macbook, pull requests, and things.

I miss the almost zero friction collaboration.

As a pair. Either of us will point out each other mistakes and suggest an improvements to what we're doing in real time without the ping-pong of pull request.

If both of us can't figure things out. We can just scooch over to other pair workstation, sit in the other chair, use the mouse and keyboard to show part of code we have issue with, point to the monitor, and ask questions.

I can't even begin to imagine the sheer amount of meetings and "chats" that would need to take place on a regular basis just to keep things moving along.

I admit to knowing very little about XP but this sounds like my own personal hell.

Pivotal R&D has struggled with maintaining context. For multi-megaSLOC codebases with many moving parts, organic memory begins to fall a bit short.

Different teams deal with this differently. Some write design notes, some keep architecture design records. But IMO it's one of our weaknesses.

Also a problem that's solved by the combination of pairing and frequent communication. You don't need full context on anything yourself, as long as the combination of you, your pair, and anyone you can grab within arms reach can fill in the blanks.

This practice is just saving time writing down behaviour that won't be implemented.

What do you do when people forget things?

There's still something written down, just not massive amounts.

Personally i try break stories down smaller to avoid the need for large tasks which helps. I also try minimise the time between story creation and story development.

Otherwise I just communicate a lot.

Things get differently from what I invisioned, sometimes they're worse sometimes they're better.

It's on the engineering blog of a company trying to hire a ton of developers at the moment and it reads like the most toxic work environment imaginable to anyone who doesn't have that context, so perhaps the author and the team who approve blog posts should have made that MUCH clearer.

No, it isn't. A PM should be having these conversations - briefly! - in front of the rest of the team in the standup, and in more depth in a weekly planning meeting.

If a PM feels a need for updates more often than that, then that is a problem of theirs that they should work in in their one-on-ones with their manager, not something they should dump on their team and then blog about.

It's sad that a PM at Pivotal has gone adrift like this, but it's tragic that this shitty advice has made it to the company's blog.

He goes through a lot of psychology and science of how people work better when they're not distracted. It seems that all of the "Extreme Programming" guidelines go quite the opposite of what the science, per Cal Newport, suggests.

He also points out that collaboration is perfectly acceptable during deep and focused work, but this doesn't sound like how it should be at all.

While I’ve never worked in an XP team, the description here sounds like it’s primarily focused on making sure the individual members of the team aren’t accidentally working against each other. For projects that aren’t reliant on the sort of insight that Deep Work is teaching us to generate, the team cohesion may be able to make up for the hit to individual productivity.

I stopped right there. My personality is such that being social exhausts me. Don't get me wrong, I like people, I just can only do social for short bursts and then I have to recharge. There are people who get energy from other people, so this might work for them, but not for me.

You might want to take a look at the original short book "Extreme Programming Explained" by Kent Beck and form your own opinions.

The main thing is that every single change needs to be vertical in nature. You are never making stories where you say, "I'm going to add this functionality to a library. Later we'll add the UI and finally, we'll add the data to the DB schema and then ship". But it means that you need to design your software quite differently in my experience.

Even just from the DB level, you need to have things set up so that you can make very quick changes safely. You need to be able to change the schema, do migrations and make sure that rollouts can be done safely -- and it needs to be done on the order of an hour or so. That probably seems impossible to some people, but it's one of the reasons you can't really take a legacy project/team and say, "From today we are doing XP!"

Similarly, you need to be able to make changes to your infrastructure quickly. So if you have some big set of microservices and each small change requires a signoff from some group somewhere: well, it's not really going to end well. You need to be able to make that change and get everything working end to end in hours, not days/weeks.

One of the things that a lot of people have difficulty with XP is that it's generally incompatible with nailing communication specs to a wall. One day, I may need to add something to the API. The next day I need to be able to change that API. If someone comes to me and says, "You need to know everything you want this API to do for the next 3 months so that we can have a sane versioning system", I'm totally screwed. I don't know what I'm going to need next week let along 3 months (or whatever) from now.

For a lot of people, this stuff is just way too different to deal with. XP comes with the subtitle, "Embrace change". It literally doesn't work unless you decide to go whole hog on it. I've been successful introducing it to some teams, but on others I don't even try.

To try to answer your question a bit more closely... it's probably not what you imagine. It's not like you have people telling you how everything is going to work all the time. However, you are constantly thinking about it. Sometimes you'll have developers say, "I want to work on X" and you'll respond, "Why? How are we going to give value with that work?" And then they think about it and say, "Well, what if we altered the work flow here. That would allow us to remove this stuff. And then if we added this, it would mean that we don't need that library any more", etc, etc, etc. And instead of telling management that today "We removed some technical stuff" or "We got rid of some old libraries", we say, "We improved the workflow for the customer which enabled us to simplify the code at the same time".

This is why I was asking - I still don't fully understand if this is a "XP thing" or not.

Doesn't this reflect some much deeper problem with the product planning or management? If you literally can't plan even a week in advance that suggests there simply is no plan, and even the most scatterbrained business environment doesn't change that fast.

I'd say customers being able to stick to a coherent story about what they want for more than a week would be a key need in any successful IT project.

Methods like XP embrace that by allowing requirements to change over time, to account for the customer accumulating more knowledge about all three areas.

When do they write documentation?

They solved the problem of breaking flow by banning flow in the first place?

What is your book name? I would like to buy it.

As far as I know, there's only one type of printing, and that's a lay-flat softcover.