Category

Lean & Mean

• Lean & Mean

  Why Software Development should be like the Miami Herald

  07.18.07 | Permalink | 1 Comment

  I heard Mary and Tom Poppendieck talk about newspapers when referring to concepts of options theory. I didn’t put much thought into it until I met Victor from our Miami office.

  Victor said that newspapers always ship on time. He said it was a two pronged process.

  #1: Everyone must be willing to do anything to get the paper out.
  When there is a hurricane in Miami, everyone pitches in.

  “The writer must become the editor, who must become the assistant, who must also go out on the street in an emergency situation to get the paper out. The writer versatile, the publisher versatile, everyone is versatile at every level including the executive editor to get the paper out.”

  In a hurricane situation, if you’re a writer, you become a truck-driver to deliver the paper to the street corner. If the printing press is hit by the storm, you have pre-arranged mutual agreements with other printers outside of the area to do your publishing. Even in day-to-day operations, editors and writers are encouraged to visit the printing press and learn as much as they can about how it works. They encourage end-to-end knowledge about the entire system.

  “Everyone has a measured responsibility when it comes to seeing the product through.” Victor said.

  “They may not know exactly how the printing press works, but it’s encouraged. Every reporter, every writer, every editor will go into the press room and have the guy who is dirty with ink show them how the paper runs. When there is an emergency and the printer who is trying to get the paper out has a problem, because there is a basic understanding of the work, it augments the responsibility.”

  He used an example of when the print press broke down, and an editor jumped into a car to a neighboring press to get a piece of equipment. That was only possible because the editor could understand the printer’s explanation of what was wrong and what the printer needed to fix the press.

  #2: There is always more production than what gets out in the day
  Every day there is a brief 15-30 minute morning meeting at 10:00 AM to plan the production for the day. That way everyone is on the same page.

  There are several vetting points. Each writer has a budget (or capacity) of what the individual reporter can do. The first month that you join the paper your budget would be low. It goes up with your capacity.

  There is daily, weekly and monthly planning to make sure there is enough budget to fill a paper. If there are not enough people to write enough “column inches”, they know they can’t fill the paper. Therefore, they over commit column inches as well. If Victor was writing a column, he would get a few more quotes or details to expand the article if they needed to fill space.

  As applied to software:
  #1: System knowledge and a willingness to do anything
  We could learn a lesson. We don’t handle emergencies like a newspaper handles emergencies. If a server goes out, you can’t send in a product manager to go fix it. (Or most software engineers for that matter.) As a result we are less flexible and our capacity is reduced. Cross training is essential. Look for individuals with a wide range of talents. Train a front-end engineer on how to do usability testing. That product manager you’re hiring should have hacked up an underground mp3 exchange while in college.

  I’m not suggesting that anyone can pick up each other’s tools and get to work. But there should be an understanding of what it takes to get each other’s job done. That way when a developer explains that they need to spend a couple of weeks to improve the build process, the product manager understands why.

  Do whatever it takes. I hate hearing, “but I’m not a tester” or “I can’t do visual design.” Developers should become testers. Testers should become developers. Product managers should cut html.

  I’ve worked with a team that builds a UI-intensive flash application. The designers, testers, developers, product managers all sit together in the same space. Developers are constantly adding functionality to the product that affects user interaction. A developer is encouraged to think about and to improve the user experience as much the underlying software that makes it run.

  Even within functional groups, knowledge should be distributed. There was a team who had a developer, Li, who knew everything. Here is how a sprint planning meeting would work: Li would volunteer for every task because she was the best person for the job. As she became full, important features in the product backlog had to be skipped until something was found that another person on the team could work on. After three or so sprints of this happening, the team came to the conclusion that Li had to stop signing up for tasks. That way, she could help other team members get up to speed.
  
  #2: Cut features to fit
  Deliver value every day. Set deadlines for the team.

  I was working with a team who did what outsiders thought was an absolutely unbelievable achievement within the organization.

  Get this, they delivered on time.

  I asked one of the developers, Daniel, how they did it. His response was nonchalant:
  “They gave us 3 months, so we built a product to fit that time interval.”
  Me: “If the team had 4 months?”
  Daniel: “Then we would have had more features.”
  Me: “And two months?”
  Daniel: “There would have been less features.”

  Arrange your work so that you can trim down features to deliver in regular intervals. When working with a full-bore XP team, every time someone checked in code the system had to function. Every check-in was “potentially shippable.” Not that we would, but we could.

  Our constraints are time and people. A newspaper’s constraint is time, people and column inches. By trimming features down, we can build software products with the time and people we have.
  
  Names have changed in this article to protect the innocent
  

  

Joe Arnold’s Blog