8 simple rules for achieving 'Lean IT'

8 simple rules for achieving 'Lean IT'

Summary: An agile response: 'I’m here to prevent more software from being written. We want to write less code, not write more code faster.'

SHARE:
TOPICS: IT Priorities
5

There's a tension between development and production that occurs across all businesses. For IT, it often means development versus operations. Managers that master "lean approaches" can learn to synchronize these two sides of the business.

That's the view of "Lean IT" guru Steve Bell, who recently released a video of his keynote speech at the European Lean IT Summit in Paris last year.

The lean philosophy is intended to being the creative (development) and operations sides of the house together, he explains. "These two are fundamentally different. When I'm speaking to a lean audience that comes from a traditional lean mfg background, I think many of us miss this. The success of Toyota is as much responsible for the success of the Toyota development system as it is for the production system. One side achieved operational excellence, the other is focused on development and innovation. The two synchronize so well, and that is what allows Toyota to bring out a Prius from conception to launch in about two years."

The two sides are fundamentally different, and this has implications for devops initiatives, Bell continues. "It's about certainty. On the operational excellence side, we're trying to find things that can be standardized and repeatable. On the development side, it's about leveraging uncertainty.

"If you talk to an agile person, and say: 'Quality at the source, do it right the first time,' they'll look at you and say: 'No, you've got to fail fast early and often. You have to learn from your mistakes, and settle on what works.'"

On the development side, things need to be creative, unstructured and somewhat uncertain. On the production side, standardization is key, and variation is to be avoided at all costs. So how do we bring these two sides together? By adopting lean principles, Bell said. "By working together, by learning together. There is learning in the production process, and there is certainly process in the creative process."

Bell provided the following advice for moving to Lean IT:

  1. Do not focus on costs: "Isn't that what everybody was focused on over the past four years?" Bell said. "I can guarantee you can lose a pound of weight. If you want to lose a pound, you give a pound of blood. Losing weight by cutting costs in IT is very simple. Fire people, cut projects, reduce the service levels. Are we healthy? Are we bouncing back? Are we overburdened? Do we have the time for continuous improvement? Of course not."

  2. Build in "slack time": "One of the principle ways that a company like Toyota continually improves over time, and drives stability up is that every time employees are presented a problem, they are not only given the time, but they are required to stop the line. And not only fix whatever's wrong, but prevent it from happening again. Only by doing that can you improve over time, so that you have fewer interruptions, fewer line stops." Otherwise, Bell explained, people are too afraid to stop production for quality issues because they're afraid they'll get into trouble for not meeting production quotas. "If you plan slack for the day, that doesn't mean you wasted that time," he said. "I guarantee that time will be used constructively in some way. If you don't stop thinking that everybody being busy is a measure of success, then ... you're on the wrong road. But it's a very hard mental model to break."

  3. Develop people through continuous coaching and learning: "Develop people before you develop software," said Bell, cautioning that this "takes a deliberate and sustained investment in time. And it will not happen its own. It will [be] squeezed out by more urgent things, but not more important things."

  4. Know your value streams and who owns them: Bell likened the owners to orchestra conductors.

  5. Keep it simple: Often, businesses will call in developers to write or deploy more software to solve a problem. However, Bell said, "One of the principles that gets lost in the Agile Manifesto is when you talk to someone who truly gets the spirit of agile, the agile person will say: 'No, I'm here to prevent more software from being written. I'm here to help you simplify your process. The agile mentality is to write less code, rather than to write more code faster."

  6. Make it visual: Bell said the Kanban board, which provides a visual diagram of scheduling in a lean manufacturing environment, is a great tool for dev-ops as well. "In software teams, in IT operations, the moment they can put sticky notes, and visualize demand and work in process and problems and velocity, you have given them the ability to see where their problems. Until then it's just a jumble in their heads. It's up to us to help them see through that jumble."

  7. "Think backward from customer value, not forward from IT capabilities": As Bell explained, "until you really know what's it like to be a customer of yourself, all you have in your head is a hypotheses. If you think you know what it means to be a customer, you need to experience that."

  8. Embrace uncertainty: "Somehow we come together, with a purpose as a team," Bell said.

Topic: IT Priorities

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

5 comments
Log in or register to join the discussion
  • This is a very good list

    n/t
    Ram U
  • Stopping the line...

    We could sure use to stop the line sometimes where I work. Not every team abides by that philosophy, unfortunately.
    dferguson75@...
  • Excellent articulation of Lean IT Development

    It’s very difficult to convince customers and end-users that often the best way forward is to eliminate unnecessary development – period. This means eliminating the recurring cycle of getting requirements, design, development, writing code, code testing, user acceptance tests. And Oops! Afterward comes a new idea from the team, a new perspective from another group, or a missed requirement from a business unit not originally included. In any event, another-and-another development cycle ensues.

    As a SharePoint architect, I’ve seen three or more Sprints used to re-invent and to develop an out-of-the-box tool or an easy customization to one. That’s weeks of work, instead of three short one-day trial-and-error customizations of an OOTB component.

    Paraphrasing what resonates the most, here, for me:
    - Bring together Lean and Agile.
    - Prevent more software from being written... Write less code, not write more code faster.
    - You need to experience what the customer needs.
    - Continuous coaching and learning.
    - Accepting an unstructured and uncertain processes that support creativity.
    cascella.mark@...
  • Forgot one

    #9 Hire developers to write software and hire Systems Administrators for operations and keep their duties seperate nothing ruins uptime like a developer with access to a production system.

    Can't stress #3 enough some companies just chew through people eventually they are left with the bottom of the barrel becasue no one with skill will want to work for them.
    ammohunt
  • Hasn't changed since the '70's!

    The same debate was going on in the 1970's, with dueling buzzwords like "egoless programming" (going over every line of code in committee, supposedly finding errors to FIX rather than to PUNISH) vs "super programmer" (give one genius free rein to develop an entire application system, then expect him/her to document it well enough for others to maintain). Managers (other than company-building entrepeneurs) have always wanted the work done under their control to conform to predictable rules, even if that work is creative development, and want costs to be completely predictable. Practical workers see through "processes" that are just an excuse to make more management work, versus those that actually help produce quality results.

    Companies that have no slack in either schedules, staffs or capital resources only SEEM to be efficient. As we all know, a hard drive that is almost full or a CPU that is always 99% busy may SEEM to be efficient, but is actually wasting resources thrashing between jobs, and has no room to add new ones. An IT department, or any department, presents the same paradox, which requires balancing the desire not to pay for more than you need against the desire to be able to grow and allow for unexpected needs.

    A humorous example can be found in the 1960 Presidential campaign. Opponents were accusing Senator Kennedy of using his father's money to "buy" votes (some things never change), so at one campaign stop, he opened his speech by reading a mock telegram from the old man: "Son, don't buy any more votes than you need. I don't want to pay for a landslide." And so in business management (including IT): don't pay for a "landslide" of waste, but don't starve people and end up just a few "votes" short either.
    jallan32