Enterprises are grappling with Agile methods- but there's much to learn. The basic Agile methods don't cut it in the enterprise. There are many big questions including:

• What type of projects can use Agile?
• How do we coordinate dependencies between Agile and non Agile projects?
• How do we operate in predictive approach for some projects and empirical for others?
• How do we choose? Who makes that decision and when?
• How do we integrate Agile projects into all the enterprise frameworks such as enterprise architecture, life cycle infrastructure, inter project coordination, systems development life cycle standards, deliverable standards, asset management, outsourcing and offshore arrangements, contracts and agreements, budgets, and so the list goes on.
• How do the frameworks need to change?
• To what extent should we stick to the core Agile methods? Should we allow diversity of method across the teams? Will methodology creep happen anyway, and should we worry?
• Is progressive Agile adoption a normal capability maturity problem, that needs to be managed?
• Which resources should be assigned to Agile projects? How do we ensure they are properly skilled? Do we need to assign our best people to Agile, in which case, what risks are we running in non-Agile projects? Where do we find real Product Owners?

By observation, most Agile use in the enterprise is in development. A subset of Scrum with TDD and XP. Or Water-Scrum-Fall as defined by Forrester. In the Agile world, it seems this is a derogatory tag but in the enterprise it's a pragmatic response, that allows planning and requirements to be executed in a low risk manner, and some key benefits of Agile, to be realized in development.

The Agile community is starting to understand this roadblock. Scott Ambler's recent book on Disciplined Agile Delivery[i]provides some general advice on scaling Agile, as does Dean Leffingwell's open framework Scaling Software Agility[ii]. However both of these useful resources address the issue from the Agile perspective, that is extending the management framework a bit, rather than figuring out what the holistic organization needs to do to facilitate effective Agile delivery.

I argue that architecture patterns are "at least as important as Agile methods" in delivering "business agility". But equally there are many opportunities to adjust current practice right across the life cycle to complement Agile projects.

The Gartner Group have identified what they call Pattern-Based Strategy, and this seems a useful technique - to provide some structure (as opposed to direction) for a proactive approach to Agile adoption which integrates with the momentum enterprise, right across the life cycle, including as I say agile architecture. By using patterns (and more detailed playbooks), we can guide and coordinate practitioners in all disciplines to engage with agile thinking to find sensible answers. I have set out below my starter list of patterns with a bare minimum of classification.

I note that Schwaber and Sutherland in their excellent book Software in 30 Days[iii], recognize that empirical methods are applicable to any form of project, not just development. They give the example of using Scrum for managing the implementation roadmap of Agile. Perhaps more interesting is the applicability of Kanban, which just may be more enterprise friendly than Scrum, to demand management, architecture, release management etc. Of course it's important that enterprises and their teams understand and adhere to the fundamental principles of the empirical approach.

Strategy-Based Patterns

• Agile EA
• Agile Demand Management
• Product Definition
• Agile Family/Product Line
• Continuous Modernization
• Water-Scrum
• Agile Development
• Water-Scrum-Fall
• Agile Solution Delivery
• Agile KD/MDA/MDD Infrastructure
• Service Provisioning
• Service Delivery
• Service Offering Delivery
• Agile Software Factory
• Agile Integration
• Agile Maintenance
• Hybrid Project Delivery
• Agile Governance

Management Patterns

• Scrum
• Loose Scrum or Ruck
• Kanban
• Scrumban
• Kaizen

Contract Patterns

• Agile Statement of Requirements
• Scrum Change Request Protocol
• Incremental Delivery Schedule
• Definition of Done
• Acceptance Protocol
• Agile Project Termination
• Late Binding Agreement
• Target-cost contract
• Progressive Contract
• Fixed price per Iteration
• Fixed price per Story Point
• T&M
• Shared Risk
• Pay per use
• Service Level Agreement
• Service Specification
• Automation Unit Specification
• Security Specification

[i] Disciplined Agile Delivery: A Practitioner's Guide to Agile Software Delivery in the Enterprise,
Scott Ambler
http://www.amazon.co.uk/Disciplined-Agile-Delivery-Practitioners-Enterprise/dp/0132810131

[ii] Scaling Software Agility
http://scalingsoftwareagilityblog.com/

[iii] Software in 30 Days,
Schwaber and Sutherland
http://www.amazon.com/Software-30-Days-Customers-Competitors/dp/1118206665