Peopleware: Productive Projects and Teams (Second Edition)

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...

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...

Project Management with Respect to Time and Budget

There are a couple of books you should check out:

Exploring Requirements: Quality Before Design.

Software Project Survival Guide

Software Estimation : Demystifying the Black Art

Joel Spolsky posted a quick estimation technique.

I found this software project management blog.

I attended a Project Management class (as part of a Masters in Technical Management) and they used the Project Management: A Systems Approach to Planning, Scheduling, and Controlling book. It is a very dry book but has a ton of very useful information; luckily our professors were pretty good at their job (one topic that helped me a lot was dealing with conflict -- but that has little to do with estimation and budget which your question seems to focus on).

Product Pricing

I think that the book, Micro-ISV: From Vision to Reality, discusses that. Basically, you should already have established a relationship with some people that represent your customer base and who have cobbled together a crappy solution. If your software represents an elegant solution that fixes their needs, you ask them 1) would you use this if it was free? If they say yes, then you ask them 2) Would you pay a million dollars for it? At which point they'll say, no way, the most I would pay would be $500 (or whatever) -- that's one way to price your product. :)

Management

If you are going to be managing people, read these books:

Behind Closed Doors: Secrets of Great Management

Peopleware: Productive Projects and Teams

Peopleware: Productive Projects and Teams

by Tom DeMarco and Timothy Lister

alt text http://ecx.images-amazon.com/images/I/51MlUgcSICL._SL500_BO2,-64_OU01_AA240_SH20_.jpg

This classic book encourages us to think about the people instead of the process. It's full of practical advice on team building, productivity and office environments. It's a must read, not just for managers, but anyone related to software development.

Get two copies, one for you and one for your manager.

Interestingly I just finished reading PeopleWare, and the authors strongly discourage individual metrics being made visible to superiors (even direct managers), but that aggregate metrics should be very visible.

As far as code specific metrics I think it's good for a team to know the state of the code at the current time, and to know the trends affecting the code as it matures and grows.

The question is obviously not focussed on .NET, but I think the .NET product NDepend has done a lot of work to define and document common metrics that are useful.

The documentation section on metrics is educational reading, even if you're not doing .NET.

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 are some great books which may help provide you with some structure on how to manage the team:

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

Delivering Happiness: A Path to Profits, Passion, and Purpose http://www.amazon.com/Delivering-Happiness-Profits-Passion-P...

Rapid Development: Taming Wild Software Schedules http://www.amazon.com/dp/1556159005/?tag=stackoverfl08-20

The Five Dysfunctions of a Team: A Leadership Fable http://www.amazon.com/Five-Dysfunctions-Team-Leadership-Fabl...

Fundamentally, cultivating a healthy team culture is the most important role you can play. Foster open, transparent communication, and avoid falling into the trap of micromanagement. Keep things happy, keep it real. All the best!

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://www.amazon.com/The-Mythical-Man-Month-Engineering-Ann...

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...