Inc.com | by Darren Dahl | May 2009
The first thing you notice when you walk into the Chicago offices of Total Attorneys, which provides software and services to small law firms, is the number of people on their feet. Every morning, the company’s 180 employees gather around the office in groups of five to 10. Close your eyes, take in the often raucous banter and laughter, and it’s easy to mistake Total Attorneys’s headquarters for a college cafeteria. But these meetings, which last for about 15 minutes, are more than mere employee chitchat. They are intended to create what CEO Ed Scanlan calls controlled chaos.
The inspiration for the gatherings comes from a process for designing software called agile development, which aims to promote flexibility, speed, and teamwork. But rather than limit participation to software engineers, Scanlan has deployed agile development concepts companywide, in a drive to make the seven-year-old business act more like the start-up it once was.
Scanlan became interested in agile development about a year ago. He had grown increasingly frustrated with his company’s software-development process. When he founded Total Attorneys in 2002 to make customer-relationship-management software for law firms, he and a handful of employees would write code on the fly. Projects were completed quickly, and employees often worked late nights and weekends to launch new features and fix bugs. But as revenue grew to $24 million, the company abandoned the fly-by-the-seat-of-your-pants approach in favor of a more formal system. Sometimes referred to as the waterfall model, this system divides a software project into sequential stages, in which the work is handed off from designers to coders to quality-assurance testers.
But Scanlan found that the waterfall model made Total Attorneys move a lot more slowly — so slowly, in fact, that in some cases clients’ needs had changed by the time a piece of software was complete. “We had more than a hundred employees, but we were getting a lot less done than when it was just me and three other people,” Scanlan says. “Morale was suffering as well.” Employees felt disconnected not only from the projects, Scanlan says, but also from their colleagues. Designers rarely interacted with developers, let alone anyone from the accounting department or the management team.
Scanlan’s search for a solution led him to Getting Real, a book about agile development published by the software company 37signals. “I learned about cutting the ‘big picture’ into small pieces,” Scanlan says. “You have to be able to change course as often as your customers’ needs or market conditions dictate.”
One way to accomplish this is by breaking down large departmental silos and creating small, cross-functional teams instead. A typical team might be made up of one project leader, one designer, one coder, and one quality-assurance tester. Large projects get carved into lots of mini projects, often with deadlines as short as a couple of weeks. Each team focuses on one mini project at a time and is given the freedom to make decisions. The teams hold daily meetings — or “scrums” — to discuss each member’s progress and daily objectives.
Scanlan adopted the strategy and found that the software team’s productivity improved. What’s more, employees seemed happier. That got Scanlan thinking: Could he use agile development to change how the rest of his company operated as well? He decided to find out.
. . . more
