Ken Schwaber

Position Statement

With all deference to Dr. Boehm, I don’t find the assertions posed for the workshop to be either correct or very interesting. Since the assertions are being used tos set the stage for the workshop, I question whether the workshop is of interest to me or the agile community.

The questions stated are:

· Size - Agile development works better for smaller teams and is more difficult for larger teams, e.g. refactoring can be done only for small systems and great developers.

· Architecture – Agile’s emphasis is on designing for current needs, not for future ones. Therefore agile methods work best when the future is unknown, and are less than optimal for projects in which future requirements are known, e.g. Barry asserts that when requirements vary by less than 1% per month, a plan-driven methodology might be a better choice over an agile methodology.

· Application area - Agile methods fit applications that can be built quickly and don’t require extensive quality assurance. Agile methods work may not be a prudent choice for critical, reliable, and safe systems.

I find all of these assertions to demonstrate an ignorance of agile processes and how they have been applied over the last eight to ten years.

Questions much more interesting to me are:

Why do people persist in using defined methods to try to build complicated systems and products? Despite every effort to increase the level of definition to a point where successes increase, increased definition has resulted in stifling creativity instead. Agile processes spring from a completely different theoretical model in process control theory than such traditional processes as waterfall, spiral, and even RAD. They employ empirical processes based on frequent inspections, increments of product, emergence, and self-organization. Agile is a paradigm shift.

Why does emergence work? Over and over again, for large and small, user oriented and life-critical FDA systems, emergence of requirements, architecture and design has worked, even when employed by normal people. Why is this, and what role does complex adaptive system theory have to do with it?

How do we get the business people and customers to take over the system and product development process. We’ve made it so complicated over the last twenty years that they don’t want to touch it. Agile processes allow them to closely control and manage systems development. Yet agile is a radical change to the way business is conducted now and will require massive organizational change. How do we go about educating people and fostering this change?