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.
No comments:
Post a Comment