Much has been written and observed surrounding the practitioner proposed software development approach called extreme programming. Indeed the wider agile movement should have failed long ago because it's just a bunch of people, not a corporation, not a University, not a government funded institute.
And agile methods are just a bunch of practices, they weren't designed as a single structure, an organisational standard that teams and organisations could adopt!
Instead of formal definitions the proponents of agile methods present their personal interpretations and expect adopters to adapt them to their own local contexts. Agile practices are mutually reinforcing attitudes, techniques, activities and skills, some of which are widely acknowledged as industry best practices: e.g. unit testing, coding standards, and short iterations. Other practices like as pair programming, collective ownership, regular releases, and on-site customer remain novel, difficult to adopt and subject to continued scepticism. It may seem that some of the key practices of Extreme Programming for example are at odds with accepted corporate governance structures and processes like top-down control. Attempts by groups to adopt agile practices within established organisations may fail as the practices contest existing power structures, redefine the relevance of certain resources, for example: from plans to planning activity or from external testing towards testing becoming the heart of design work. Bottom-up introduction of agile practices on development teams will introduce tensions at the interfaces with other teams, with professional overlaps, ownership of activities and resources, and upon the technological infrastructure (source code control systems, test tools, build environments, knowledge management tools etc.).
Notwithstanding the potential strains and tensions the focus on professional practice and practices in teams is a valuable additional perspective to bring to understanding how the work of software development is accomplished. Agile thinking turns attention towards the practical everyday activities that constitute development. And while the risks associated with attempts to adopt agile methods at the level of teams are amplified by the impacts on other parts of the organisation, they seem to be necessary changes if software development is to truly accommodate its unique conditions of production: digital media, multi-layered complexities of systems layered on systems, designs that remain in flux throughout the product life cycle, exceptional demands on communication and coordination behaviour by teams and beyond.
