When you’re finished changing, you’re finished.
As mentioned in the Introduction, for decades, organizations largely followed Waterfall or phase-gate methods on IT projects. Gantt charts representing one- or two-year timeframes ruled the day. (See Table I.1 in the Introduction.) Failure was common, expensive, and often devastating.
Fortunately, this has started to change. Agile methods are no longer weird. Startups have embraced them for years, but mature organizations are finally starting to see the light. They are opting for smaller batches and Agile methods to further their software-development efforts. In a parallel way, these same organizations’ analytics efforts can benefit from adopting a similar mind-set. In a nutshell, this is the premise of this book.
This chapter briefly defines Agile methods, roles, techniques, and terminology with a particular emphasis on Scrum. It is not supposed to be comprehensive. Dozens or even hundreds of books exist on every mainstream Agile method.
The origins of Agile methods date to 1984 when Hirotaka Takeuchi and Ikujiro Nonaka authored a paper in the Harvard Business Review entitled “The New New Product Development Game.” Takeuchi and Nonaka surveyed ...