Slack

Tom DeMarco

Mentioned 3

Argues that the "lean and mean" corporate model of workaholism and downsizing is proving counterproductive, explaining how companies can implement downtime, promote flexibility, and foster creativity as part of realizing increased revenues. Reprint.

More on Amazon.com

Mentioned in questions and answers.

The CodePlex team has a Slack time policy, and it's worked out very well for them.

  • Jim Newkirk and myself used it to work on the xUnit.net project.
  • Jonathan Wanagel used it to work on SvnBridge.
  • Scott Densmore and myself used it to work on an ObjectBuilder 2.0 prototype.

For others, it was a great time to explore things that were technically not on the schedule, but could eventually end up being of great use to the rest of the team. I'm so convinced of the value of this that if I'm ever running a team again, I'm going to make it part of the team culture.

Have you had a formalized Slack policy on your team? How did it work out?

Edited: I just realized I didn't define Slack. For those who haven't read the book, Slack is what Google's "20% time" is: you're given some slice of your day/week/month/year on which to work on things that are not necessarily directly related to your day-to-day job, but might have an indirect benefit (obviously if you work on stuff that's totally not useful for your job or your company, your manager probably won't think very well of the way you spent the time :-p).

I just want to mention Google's policy on the subject.
20% of the day should be used for private projects and research.

I think it is time for managers to face the fact that most good developers are a bit lazy. If they weren't, we wouldn't have concepts like code reuse.
If this laziness can be focused into a creative force, and the developers can read up on technical issues and experiment with architecture and language features, I am certain that the end result will be better code and a more satisfied developer.

So, if you are a manager: Let your developers slack of now and then. Encourage them to hold small seminars with the team to discuss new ways of doing stuff.

If you are a developer: Read, learn and love your craft. You have one of the best jobs in the world, as long as you are willing to put some time into learning the best ways to do your job.

I have now worked on two different teams that use the Agile/Scrum approach in the last two years and both teams were eager to improve the way they approach software development. In the first team, we could easily convince our product owner to get time for internal things like improving the build system, setting up better integration tests, having a better release strategy etc. Right now the PO is also willing to give us time, but he is more pushing back, which is reasonable as he also must get his things done.

Anyway my question is now, how do other teams handle this? Do you create an improvement story and put it on the table during planning or do you keep a "bucket" of time around for such things? How difficult is it in your experience to convince the product owner to do get time for improving? After all these kind of improvements will benefit the team, but not directly or immediately the prodcut owner/business.

Crystal Methods has the concept of the Reflection Workshop as a means to tune your development process. Teams meet periodically (less frequently than your development cycle, perhaps) to discuss improvements and status of the process. Come up with 0-3 things we tried this time that worked and we'll keep, 1-3 things that aren't working, and 1-3 things to try next time. The idea is to have incremental improvement in process as well as in product.

No, one shall not create technical user stories: theoretically, and since they generally bring no direct value to the customer, they have very few chances to be selected in an iteration. Convincing the Product Owner is an option to alleviate this, but there is another tool that can be used here : slack.

Slack is a small portion of your iteration time set aside to those improvements tasks. If everything went well during the iteration, then you will be able to use that time for those improvements. On the other hand, you will get another chance to meet your commitments in case the team over-committed for the iteration (or a task were underestimated, harder as expected...)

Another benefit of using slack is that this will lower the variation of the velocity as you will likely meet your commitments more often, without resorting to overtime.

Refer to Tom DeMarco Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency (Amazon link) - ISBN 0767907698.

In a workplace where many people (including management) feel long hours is the way to demonstrate commitment, what are effective arguments that such practices are harmful, not just to the team members themselves, but to the project itself?

I am familiar with - and I believe - the common arguments: the risk of burnout, compromised quality, insufficient attention to keeping our skills up and our code malleable. But what arguments are most persuasive? What is the most persuasive way to deliver them?

Update Thanks, everyone, for all the great links to data - it's helpful, but what I'm really after is what arguments will be persuasive to people who are deeply invested in the crunch-mode ethic. I think I need more than data to shake loose their preconceived notions.

Have a look at The Mythical Man Month, Peopleware, and Slack. Then cite the hard work and real numbers of those more credible than yourself.