xviii ◾ Foreword
controls on the rogue groups. Ultimately the company’s bottom line will suf-
fer because the business units are not leveraging the economies of scale and
strategic advantage that a corporate IT group can offer.
So, instead of IT- centered goals such as “increase on- time delivery of
IT projects by 20%” (unless your company’s business is IT project manage-
ment), define the business need first and then define what IT needs to do to
support the goal. For instance, “To improve on- time delivery of manufactur-
ing orders, increase the rate of new feature delivery in the factory schedul-
ing software project by 20% within six months.” This is the type of logic and
practicality that prevails in this book but is often missing in other books.
At the same time, the authors provide an excellent overview of both
Agile and Kanban practice and help us understand that a one- size- fits- all IT
improvement effort is likely doomed to fail.
Agile, with Scrum as its most common and well- known process, is best
suited to software development efforts where features can be designed,
built, and delivered by one non- specialized, cross- functional team work-
ing together. Typically these features can be completely designed, built, and
delivered within the time frame of a two- to four- week sprint (though I and
many others do use Scrum to deliver software features on longer multi- sprint
time frames, particularly for data warehousing).
Lean, and its most frequent incarnation, Kanban, however, allows you to
keep your existing process and specialists while still providing a framework
for improvement. To this effect, the authors do a great job of detailing the
origins of the Lean movement in manufacturing, and at Toyota in particu-
lar, highlighting the “seven wastes” that Lean tries to address. Although
meant originally for a manufacturing context, these wastes apply to soft-
ware “manufacturing” just as readily: defects, wait time, too many items in
process, and unnecessary extra features, just to name a few. If this is your
case, Kanban is a method you can apply to your existing process that limits
work in progress (WIP) to optimize workflow and reduce lead time rather
than the traditional sprints. To this point, it is not hard to see that Kanban
might work better for a software development organization with specialized
teams and a more sequential process flow, especially in the case of software
support teams.
An industrial engineer by education who progressively became special-
ized in IT team management, I also appreciate the authors’ initiative to
create a new process framework (called the soccer process framework), as
described in one of the case studies. Based on both Kanban (Lean) and
Agile practices, it provides a process for larger project teams. It is guided by
我的内容管理
展开
