Friday, February 26, 2010

Successful Blue-Collar Jobs Employ Agile Practices

Inc's magazine February 2010 cover has Nick Sarillo, a blue-collar millionaire who owns Nick's Pizza & Pub. To create a successful business with high profits, low turnover, and very satisfied customers he instituted a framework akin to the lean principles of Agile. He compares his model to that of Navy Seals, where they're self-managed teams.

Created a backlog of daily tasks:

Nick was excellent in managing the daily tasks of activities to handle the huge volume of orders. But in order to scale he needed to successfully duplicate himself. As the interview in Inc states:
"So what did he do? 'I built a system to replace me,' Sarillo says. 'I put together a checklist of things that had to be done by 4 p.m., so we could handle the volume. It took about four weeks until it could work without me. Now we're nailing it."

Established their own form of a task board:

If you have a self-managing team the team becomes responsible for the work, not a specific supervisor who you are dependent on to make things happen by telling everyone what to do. Mr. Sarillo instituted his own form of a task board to get the process of opening and closing the kitchen down to a science, and something anyone on the kitchen staff can do:

"Take the process of opening and closing the kitchen. In a typical restaurant, a supervisor is responsible for both, has a long checklist of things to be done, and tells everyone what to do. At Nick's, by contrast, the whole kitchen crew is responsible. To help people keep track of what needs to happen, there is a laminated "ops card" for each task involved. Each ops card is red at the top and green at the bottom and has its own slot in a converted timecard holder. In the morning, when staff members come in, the ops cards are in the slots with the red end showing. Whenever a task is completed, someone turns over the corresponding ops card so the green end is showing. By closing time, all the cards are showing green. It's then the manager's job to make sure they are all red again before people arrive the next morning."

Trust & Track versus Command and Control:

Many business owners claim that no one cares about the company as much as an owner. In the successful Agile frameworks I've instituted in the past, the best way to get the team to care about the work and the business is by empowering them. Encourage self-organization and that the team is smart enough to know what's best. It's what'll keep them coming back every day to the office, because they know they have a direct impact on the decisions and direction of the projects they're undertaking. Nick Sarillo understood this fact and instituted his system, albeit unknown to him akin to an Agile framework, to create a trust and track culture:

"The system is an important mechanism for creating a trust-and-track culture and for breaking the habits of command and control. 'Managers trained in command and control think it's their responsibility to tell people what to do,' Sarillo says. 'They like having that power. It gives them their sense of self-worth. But when you manage that way, people see it, and they start waiting for you to tell them what to do. You wind up with too much on your plate, and things fall through the cracks. It's not efficient or effective. We want all the team members to feel responsible for the company's success."
Nick Sarillo's story is another example of how of lean principles and practices found in Agile, especially with Scrum in my experience, are frameworks that can work with almost any team in almost any industry or environment. What you find are highly motivated, self-managed, high-performing teams.

Sunday, February 7, 2010

But the Business Doesn't Care How Successful IT Works!

In my experience most business managers are more concerned with getting results out of their IT resources than how to get them. There was a time that I wanted to zealously evangelize the business about the benefits of Agile and other lean concepts that lead to high-performing engineering teams and quality IT development. I'd receive the invisible rolling of the eyes, the gentle long sigh, or the blank stare with a merciful yes-nodding of the head out of kindness. As an eager, sometimes naive, and ambitious young professional I tried not to let these reactions dissuade me from continuing. I thought to myself, "...eventually someone will listen to what I'm saying and help me make it happen."

These business leaders, of some the companies I've worked for, heard my words but didn't necessarily listen to them. They're all fine with following the latest proven productive trend if it lets them claim that they're a better organization for it. But the bottom line is that most don't really care how a successful IT project is implemented so long as it gets done with the results they expect. My answer to this problem is don't worry about explaining the "how" to them...just show them. Nowhere is this even better expressed, in my experience and that of my other professional colleagues, than within the financial industry. Everything here is about "P&L". Profit and Loss.

Now for those of you reading my past posts, you know I have a bias towards leveraging an Agile approach to successful software development. The problem that I and other Agile advocates face is that some business managers hear all the Agile jargon and perceive it as "touchy-feely", or even downright confusing. Here are some of the reactions I find to some of the Agile/Lean concepts I present to them. Heck, some are just plain good management practices:

Concept 1: Self-managing & self-organizing teams

  • "We're losing control by doing this. Some times you need a top-down approach to getting things done."
  • "It's no wonder there isn't focus on the work that needs to get done...we've got everyone acting like chiefs since they're self-managing."
  • "How will we know who's working on what?"
Concept 2: Estimating in Points, Using Velocity & Burndown Charts
  • "How the heck am I going to know when something is going to be done if there aren't days and hours attached to each and every task!!"
  • "Points are meaningless. This kind of talk is childish and full of garbage."
  • "Where's my Gantt Chart, the critical path tasks and the assignees for each?"

Concept 3: Priorities and Identifying Release/Sprint/Iteration Focus

  • "We already told you what's important, and what we're trying to sell/build. Just get started and get it done ASAP!"
  • "We've got a lot of contracts pending on all of these projects, so they're ALL IMPORTANT!"

Concept 4: Motivating & Empowering Your Teams

  • "If we get this product completed by year-end, we'll be able to close on a $3 million deal. Isn't that motivation enough?"
  • "These engineers get a guaranteed salary and generous bonus every year without having to worry about making any sales numbers. What more do they want?"

In the coming days and weeks, I'll be writing about my past experiences with the issues surrounding these concepts and the solutions I implemented to address them. The main point is I started to walk away from the jargon (Agile-speak). To make successful IT development work at these organizations I began focusing exclusively on just doing it and showing them the results they wanted.

Have you had some notable quotes and reactions to any Agile/Lean concepts you presented like the ones listed above? If so, what was said and how did you manage it?