Peopleware is an excellent book built on this premise.

https://www.amazon.com/Peopleware-Productive-Projects-Tom-De...

Peopleware is a classic

https://www.amazon.com/Tom-Demarco/dp/0932633439/?nodl=1&dpl...

Peopleware is awesome https://www.amazon.com/Peopleware-Productive-Projects-Tom-De...

There's even a whole book about this: https://www.amazon.com/dp/B004SOVC2Y (by one of the authors of Peopleware[1], which is also excellent).

[1] https://www.amazon.com/Peopleware-Productive-Projects-Tom-De...

Please, please, please pick up the book Peopleware if you haven’t read it. It’s a classic for a reason https://www.amazon.com/Peopleware-Productive-Projects-Tom-De...

(New-ish manager here.)

_Peopleware_ by Tom DeMarco and Timothy Lister is the best management resource I've encountered.

https://www.amazon.com/Peopleware-Productive-Projects-Tom-De...

It also helped to keep careful track of things I really valued (and hated) about people I've worked for.

Just one example:

Depending on team size and culture it can concerning if your manager schedules a 1:1 meeting with you out of the blue and outside of your normal cadence. I had a manager that did this, on a Friday, with the meeting scheduled for Monday. Worrying about it would have bugged me over the weekend. Not a ton, but some. He followed the invite up with a Slack (team chat app) message explaining what the meeting was and what he wanted to talk about, turns out it was nothing to worry about. Him taking the time to clarify made a difference in my morale and it stuck with me.

Super small thing, but it matters.

Not specific to scrum but I am reminded of a part from Peopleware:

"The most surprising part of the 1985 Jeffery-Lawrence study appeared at the very end, when they investigated the productivity of 24 projects for which no estimates were prepared at all. These projects far outperformed all the others (see Table 5-3)."

  Table 5-3 Productivity by Estimation Approach (Full Result)   -----------------------------------------------------------------------   Effort Estimate Prepared by   Average Productivity   Number of Projects   -----------------------------------------------------------------------   Programmer alone                     8.0                    19   Supervisor alone                     6.6                    23   Promgrammer & supervisor             7.8                    16   System analyst                       9.5                    21   (no estimate)                       12.0                    24 

Source: https://www.amazon.com/Peopleware-Productive-Projects-Teams-...

There's no source because it's a completely false claim. The "remote doesn't work" trope is perpetuated by Silicon Valley Culture[1][2]. Remote work is like security. You can't bolt it on and expect it to work. You can't half-ass it and expect it to work. The companies that do it correctly make it a foundation of their culture. I will cede the fact that remote work isn't for every individual, but I think even that can be overcome with the right company culture and support network.

1. http://startupclass.samaltman.com/courses/lec07/ 2. https://www.amazon.com/Peopleware-Productive-Projects-Teams-...

I can't recall a time in the last 1-2 years when someone complained about it

Pick one (or more):

* they don't know the alternative

* they're afraid to speak up and sound un-cool

* they don't realize it's actually killing their ability to focus

* they do so privately and are ignored by the higher ups

Audio-visual distractions have proven to be detrimental to focused, "intellectual", work. Not by an article on Medium, but by actual research[1]. Time[2] and time again[3] and again[4], ad infinitum.

Open office is the anti-vaxx of today's tech world, where all known data is ignored in favor of superstition.

[1] https://www.amazon.com/Peopleware-Productive-Projects-Second...

[2] http://www.news.com.au/open-plan-offices-make-you-sick/story...

[3] http://online.rivier.edu/open-office-layout-and-employee-pro...

[4] http://www.sciencedirect.com/science/article/pii/S0272494413...

I second that observation. I wish the manager at my day job read ANYTHING, at the very least some informercial-laden industry publication.

In my case, I'd like him to read Fred Brooks' "The Mythical Man-Month", to make him understand how a programming system costs a lot more than a simple module.

Summary: http://javatroopers.com/Mythical_Man_Month.html

In second place, I'd place "Peopleware", so he'd understand the importance of communications, and how the current office arrangement is losing the company a lot of money:

Summary: http://javatroopers.com/Peopleware.html

Amazon link to both:

http://www.amazon.com/The-Mythical-Man-Month-Engineering-Ann...

http://www.amazon.com/Peopleware-Productive-Projects-Second-...

Learn that everyone has value. No one is as exceptional as they think.

The guy coding a little slower but who customer success always talks to about problems. Great, he’s enabling communication between teams.

The girl who cleans up behind the “flash” programmer whose prototypes are awesome but doesn’t quite finish.[1] Great, she’s creating production code to be maintained by a team.

The list goes on. People provide value in ways that are not always apparent. I think Peopleware talks a bit about this although I may be mistaken, about the one team member who didn’t seem to fill a role but made everyone happy.[2] If the team wins everyone wins (hopefully in a good org).

The most exceptional teams have people filling roles. Every role is important and provides value. It’s why teams with a ton of exceptional people often implode, because they are all exceptional at only one thing and no one is filling the other roles. So all the members may appear exceptional, but the team is weak. It's a value systems problem.

[1] http://firstround.com/review/how-to-spot-and-magnify-the-pow...

[2] http://www.amazon.com/Peopleware-Productive-Projects-Second-...

This was the source cited the last time this quote was posted here:

http://www.amazon.com/Peopleware-Productive-Projects-Teams-S...

Are you familiar with the book Peopleware? If not, check it out.

http://www.amazon.com/Peopleware-Productive-Projects-Second-...

"Peopleware" http://www.amazon.com/Peopleware-Productive-Projects-Second-... , a lot of insights and ideas how to build great teams. Great to read for developers, team leads and managers.

"The art of multiprocessor programming", excellent book on parallel programming theory with code explanations: http://www.amazon.com/gp/product/0123705916?ie=UTF8&tag=nirs...

Joel Spolsky has written a lot about open plan vs private offices (most of it inspired by Peopleware http://www.amazon.com/dp/0932633439)

> Not every programmer in the world wants to work in a private office. In fact quite a few would tell you unequivocally that they prefer the camaradarie and easy information sharing of an open space.

> Don't fall for it. They also want M&Ms for breakfast and a pony. Open space is fun but not productive.

http://www.joelonsoftware.com/items/2006/07/30.html

See also: http://www.joelonsoftware.com/articles/FieldGuidetoDeveloper...

Agreed, but limiting the human element (as opposed to 'drastically limiting') can lead to better productivity.

But most developers work better in offices with doors that shut (at least according to what I remember of Peopleware [http://www.amazon.com/Peopleware-Productive-Projects-Second-...], though that was published before IM was everywhere).

So I think acknowledging that you work better with quiet, and framing it as 'I want to be as effective as I can', is fine.

It can even open up a discussion on true effectiveness--if I am writing tons of great code because it is quiet, but you could have saved me 8 hours of code writing because of a library you know about or wrote, am I as effective as I could be (no). This is the quiet end of the spectrum.

The loud end is the bullpen with no headphones, where it can be very difficult to think.

There's a place for PMs. If you're willing to step into shoes other than your own, start by reading PeopleWare [1]. And then dig into the origins of self-managing Scrum and have a read through Takeuchi and Nonaka's paper[2].

When you're done, I'd love to hear your thoughts on PMs, and why we're still making the same mistakes we made, and wrote books about, 30 years ago.

[1] http://www.amazon.com/dp/0932633439/

[2] http://hbr.org/product/new-new-product-development-game/an/8...

peopleware http://www.amazon.com/Peopleware-Productive-Projects-Second-... goes into this a lot. i know it's an ancient classic that everyone has heard of, but it's actually still worth reading, imho (i found it much more relevant/useful/interesting than mythical man month - not sure why, it just clicked somehow).

I'll just leave this right here: http://www.amazon.com/Peopleware-Productive-Projects-Second-...