一旦分级管理拥抱复杂性和非线性,我们就得到了我所称的 敏捷管理 方法。这是 敏捷软件开发 的逻辑伙伴,敏捷软件开发是上世纪九十年代由一些组织和个人独立开发的软件开发方法(参见第2章)。它源自对确定性软件开发方法失败的不满,这些方法采用的严格控制、前期设计以及自上而下的计划导致许多项目高度集中管理但惨遭失败。
敏捷软件开发(部分)植根于复杂性理论,它承认因果决定论无法胜任成功的项目交付。许多众所周知的敏捷概念,诸如自组织和涌现,都直接来自于复杂性科学文献[Schwaber, Beedle 2002],同时,当下的敏捷实践者已经认识到构成法(constructionist approach)无法防止软件失败的脚步。只有不断地接受失败并从系统中清除问题的根源,才能使软件项目稳步增长并成功执行。这同养儿育女几乎如同一辙。
尽管敏捷软件项目在投资回报上取得了巨大的成功[Rico 2009],但世界各地的管理者对组织内采用敏捷项目管理和敏捷软件开发方法的设置的障碍有着不可推卸的责任。有关敏捷采用的调查表明,变更管理、组织文化、管理支持、团队教育和外部压力是进一步采用敏捷的障碍,并且也是造成软件项目失败的元凶[VersionOne 2009],而且其中绝大部分属于管理责任。假如报告是正确的(我实在没有理由怀疑它的正确性),看上去,世界各地的管理者都正在制造问题,而不是参与解决问题。尤为可悲的是,这不只是敏捷软件开发的问题,几乎所有实质性的组织变更都遇到了这个问题。
在本书中,我的立场是,在任何类型的变更管理中,传统管理方法通常都是问题,而不是解决方案。戴明(W. Edwards Deming)在多年前也表述过这一观点。因此,我们需要一套敏捷管理理论,一个为敏捷软件开发量身而定的理论。