Monday, April 4, 2011

Agile and Lean – Interview with Mike Orzen

This week we are exploring questions two of our interview series with Mike Orzen.  You may read the first posting of our series here.  Look for post four of our Leveraging Agile Principles in IT Operations next week. 

I have had a great opportunity to read Mike’s book Lean IT and recommend this literature to you regardless of you experience with lean.  The book was recently awarded the prestigious Shingo Prize for Research.

Mike Orzen delivers a unique blend of lean, six sigma, IT and operations. He has been consulting and coaching for over 25 years to companies in IT, manufacturing, aerospace, high-tech, medical device, healthcare, casting, legal, logistics, apparel, and food processing. His experience includes systems design, application development, numerous ERP implementations, enterprise-wide process improvement, and large-scale roll out of lean enterprise initiatives for global companies.  Mike is on the faculty of the Lean Enterprise Institute and teaches the LEI Lean IT workshop.

Question 2.  What do you see as the difference between Agile and Lean within IT?  Can they coexist?

Agile software development methods have transformed application development from lengthy waterfall-driven projects to rapid, iterative delivery cycles of usable functionality. Most of us are familiar with the benefits of Agile, and it has been well documented (see Poppendieck’s Lean Software Development: An Agile Toolkit), but there is still a gap between Agile and the Lean community. Often IT leaders do not view Agile as a key component of a Lean transformation.

Lean is a philosophy, a set of principles, and a tool kit for creating a highly effective organization. The principles of Agile, acknowledged in 2001 through the Agile Manifesto and supporting principles, identify a perspective on how the work of software development should be viewed. This outlook is very consistent with the core principles of Lean. Both Agile and Lean strive for high customer satisfaction, collaboration between producers and end-users, frequent deliveries, the smooth flow of value at a pace which can be sustained, high quality, respect for the individual and effective teamwork. In fact, Agile is often referred to as “Lean software development.”

Lean and Agile also share many tools including daily huddles, visual management, mapping, co-located teams (cells), small lot sizing (one piece flow), delivery synchronized to customer demand, level scheduling, kanban, and critical reflection.

So if Lean and Agile share so much common ground, why is there a lack of understanding and acceptance of Agile practices in many companies that practice Lean? I believe three factors contribute:

1.      A lack of knowledge and familiarity

Many of the organizations I’ve worked with have invested heavily in Lean education, workshops, improvement events (Kaizen events) and certification. The majority of these organizations don’t see a critical need to bring Agile into their companies despite the painful consequences of traditional (waterfall) project management used in their IT development.  Frequently, they just don’t understand Agile or are not able to embrace it. IT associates are often very familiar with Agile methods and will bring up the topic to their bosses, who may view it as another “tool” or something that “won’t work here.” Because they are unfamiliar with Agile and do not see it as complementing Lean, some managers reject it as something foreign, believing it will confuse people and undermine their emphasis on Lean.

2.      A lack of effective support and coaching

I often discover that this is the result of not having a champion within the IT group that has either the position power or the thought leadership to influence the decision makers. There is usually no one on staff with the experience to train and coach the team in Scrum or other Agile method. They attempt to apply Agile and get poor or modest results, and quickly toss it out and revert back to the old way of doing things. For Agile to succeed in any organization, it must be experience-based (learned by doing) and many organizations lack an experienced and qualified guide.

3.      “Sharpen the saw” syndrome

In 1989, Stephen R. Covey published the landmark book, The Seven Habits of Highly Effective People, in which he explores behaviors that lead to truly great results. Habit #7 is “sharpen the saw.” Covey uses the story of a person cutting wood becoming less and less productive using a saw that gets duller over time. The implied solution is to sharpen the saw, i.e., improve the effectiveness of the tool.

In IT, we often conclude that we do not have the time to slow down development activity long enough to “sharpen the saw.” With a huge backlog of projects, pressure to deliver functionality at a quicker pace, and the risk that the business will go rogue and simply purchasing a solution which IT will inherit support responsibilities for, we conclude it best to maintain our present course, knowing its shortcomings. Just like the woodcutter, we are too busy to take measures to improve our work methods and tools!

IT leaders that have invested the time to introduce Agile (often in small pilots so as to mitigate risk) often declare after introducing Agile: “We should have done this many years ago!” People respond when they are a part of a team that produces high-quality work which truly meets the needs of end-users. Pride in their work returns and a willingness to take on and overcome challenges reappears as the team gets on a winning streak. The entire tone in the workplace changes as people become energized and reengaged!

For an exploration of Lean IT and how Agile fits in a Lean organization, see Lean IT: Enabling and Sustaining Your Lean Transformation, recipient of the Shingo Prize for Research.

Saturday, April 2, 2011

Leveraging Agile Principles in IT Operations:3 of 4

Customer collaboration over contract negotiation

Agile Overview

The last post in this series outlined how you can get your arms around creating meaningful documentation using the Agile concept of maintaining working systems over comprehensive documentation, starting with identifying how you will be using the documentation.

This week we’ll look at the third precept of the Agile Manifesto: Customer collaboration over contract negotiation.

Identifying the Customer

Identifying the customer can be more complex than it seems, particularly when your customers are internal, as they are for many IT operations teams. Numerous articles have approached the topic of the business as the IT customer. Basically, your customers include anyone who comes to you for help with any of the services you provide. They are looking for you to add value to their request. They have come to you with an understanding that you are the subject matter expert.

There may be dissention from the lean camp regarding who the customer is, but the customer in this case is the group that provides us with capital based on the value received. This article will focus on operations departments that only support internal customers.

Most companies have a set process by which internal customers may approach the operations team for services, often filtered through the helpdesk. Others have a more informal approach that relies on various types of shoulder tapping or other uses of informal methods. Another approach is to embed operations resources within project or product teams.

Whatever engagement model your organization uses, it’s important for your team to know how customers might contact IT operations and exactly what services you can provide them. Additionally, if your process requires more formalized methods it’s beneficial to ensure all participants of the process follow that process consistently.

The Contract Approach

IT service contracts are used extensively by consultants and 3rd-party service providers for various business-to-business needs. They’re valuable for defining factors such as time, cost and scope. They also set expectations relative to those factors. The common reason why this contract exists is because a contract is a legal binding between two independent and separate organizations. Without a contract there’s not a legally binding method of recourse should a disagreement occur. Furthermore, a contract will help two firms define the roadmap of their relationship and can provide details on the formalized components of the agreement.

Similar contracts are cropping up increasingly often between IT operations teams and their internal customers. A low-level type of internal contract is the Service Level Agreement (SLA). While I fully support the idea of establishing SLAs, I believe that following more elaborate contracts internally takes the concept too far for an agile and/or lean organization. Internal contracts are a bad idea for several reasons.

Contract Drawbacks

First, internal contracts cause division between IT and the business. When one group within a company can stonewall another by refusing help because a service isn’t listed in the contract, or because the service doesn’t fit the defined role of the IT operations person to whom it was assigned, it damages both the business (because of delays) and the relationship between operations and other parts of the business.

Second, internal contracts can’t be enforced. If a breach of the contract occurs, neither party has legal recourse for the violation. A process that includes portions that lack power is wasteful, particularly if those portions also limit the work that can be done to support the business. If an organization lacks discipline to the point that it requires an internal contract to get work done, then there are deeper issues that need to be addressed. A contract is almost never the right answer.

Third, a contract limits collaboration and the spirit of teams. A team structure and hierarchy are less important then most firms believe. What’s important is to realize that a team needs to have the right skills and relationships focused on value delivery, not the right contract. When the disparate divisions in a company realize that there is only one team and we’re all part of it, the productivity of the organization can increase dramatically.

Focus on Value Delivery

Agile thinkers and most Lean fundamentalists tend to have very effective relationships with their customers because of their focus on process for value delivery. Focusing a team on the most efficient way to deliver value should take precedence over writing binding contracts. Often this can only be done when there’s trust between all members of the teams. Trust is the outcome that emerges when efficient teams focus on value delivery rather than roles and responsibilities.


If the information a communication practitioner receives is flawed in any way – be it false, misrepresented, misinformed, or inapplicable to specific goals – then the remainder of the process is irrelevant: the disseminated message will be flawed.

When you concentrate on efficiency, your organization’s methods of communication should be prioritized as the number one focus for delivering value between two teams. Start by determining the most efficient process for your teams and then decide how your organizational culture can support a communication process which is empowering and value driven.

Looking Ahead

In part 4 of this series we will examine how the fourth precept of the Agile Manifesto, responding to change over following a plan, supports an IT operations environment.

Jen Browne and Patrick Phillips

Popular Posts