WFH Scrum

Working From Home (WFH) is an amazing thing. I have done it for years, off and on, and I really like it. Studies have repeatedly shown that people are more motivated, more focused, and more productive when working from home than when working at the office. Another major benefit is for people who face long daily commutes. Not only do they not have to spend two or more hours of utterly unproductive time driving to and from the office, people working from home also reduce traffic volume and air pollution, both major concerns where I live on the Front Range of the Rocky Mountains of Colorado.

But how does one accommodate WFH within a Scrum team? I have coached a few teams that wrestled with this issue. It is tempting to say "everyone needs to be here, every day." And indeed, that is the only way to ensure the highest-possible bandwidth communication within a team. Given my own affinity for WFH, however, I decided the dogmatic approach would be neither effective nor realistic.

The approach I have adopted consistently -- and successfully -- is to work with the team to make sure everyone understands the importance of the principle of face-to-face communication and then recommend a few WFH ground rules for the team's consideration:

• During the first Sprint or two, everyone needs to be physically present while we learn how to apply the rules of Scrum in practice
• When the team decides it is ready to run a WFH experiment, I suggest the following ground rules:
• Everyone is present for Sprint Planning, Story Time, Sprint Review, and Retrospective, which generally works out to be three days in each two-week Sprint
  
• Use Skype or other video conferencing technology to facilitate the Daily Scrum -- voice-only dial-in may suffice temporarily, but is not adequate over the long-term
• The team needs to adopt a standard, high-bandwidth communication medium/technology, such as Skype with video, that all team members commit to use for daily collaboration
  
• The Daily Scrum rules: if team members decide pairing or other face-to-face contact is needed, the necessary team members must be physically present even if it means driving to the office after the Daily Scrum, although we try to avoid the latter whenever possible
  
• Try to give people as much predictability as possible, but the team's needs trump all else

This is just a basic set of ground rules that I recommend and that teams I've coached have successfully adopted to accommodate WFH. Teams always refine, change, and adapt the initial WFH ground rules, of course, but this list serves as a good starting point.

Let me know if you find these suggestions reasonable, useful -- or not.

All for now....

...-.-

Rehumanize Your Work

I was -- and remain -- a big fan of the popular music that characterized the 1980s. One of my favorite bands was The Police and one of my favorite songs was "Rehumanize Yourself" from their album Ghost in the Machine. That song was never a radio-play hit, but it always hit home with me. Listening to that album the other day on my iPod reminded me why it is exactly that I now spend my working life at what is essentially Agile evangelism.

Many of the key reasons companies decide to adopt Agile are based on hard-nosed financial, business, value, and competitiveness calculations. And that is as it should be. After all, without a competitive business there would be no employment. So yes, the competitive boost companies derive from Agile is a key benefit. But for me, the greatest benefit is the rehumanization of work and of the workplace.

Among the most insidious results of Frederick Winslow Taylor's Scientific Management was the utter and complete de-humanization of work and the workplace. In the software development world, the various pre-packaged methodologies that have come along have all contained the spirit of Taylorism with its cynical, command-and-control approach to the people doing the work.

The real genius of the Toyota Production System, to me, was its inventors' realization that the assembly line was not mechanistic; it was, in fact, a social system that could only work properly if it took into account the human element. The result was the andon cord, which gave all workers on the floor both the responsibility and the authority to control their work.

Henry Ford once said: "Why is it that when I want to hire a pair of hands, a brain comes attached to them?" This is the essence of Taylorism -- and the antipathy of the entire concept of the andon cord. No worker in any of Henry Ford's factories was ever given authority to stop the line.

Software development -- or any other type of product development -- obviously requires hands that are attached to a brain, but traditional methodologies assume that the brain thus involved must be allowed to work only within rigid constraints because the people doing the work obviously have neither the capacity nor the inclination to take responsibility for their work. This, too, is the essence of Taylorism.

The genius of XP and Scrum, which are my main focus within Agile, is the recognition of the human element, of the fact that product development is primarily a social activity. By offering the people doing the work the authority to accomplish that work as they see fit, by giving them the responsibility to ensure that the work is done in the best possible way, and by establishing the social environment in which that authority and responsibility can be expressed to its fullest, Scrum and XP provide the best known framework for rehumanizing the work and workplace.

Along with the values, principles, and practices of XP and Scrum, conscientious, dedicated leadership completes the puzzle. So how about it? What will you do, today, to rehumanize your work?

All for now...

...-.-