Tuesday, September 25, 2012

Agile Enterprise Patterns

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
Product Definition
Agile Family/Product Line
Agile Development
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


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
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

Friday, September 7, 2012

Transformation to Agile IT Delivery

The number one IT issue for all enterprises today is delivery – responding to business demand for change in ever faster timescales, at lower cost. But in the typical large enterprise, IT is widely perceived to be incapable of responding in a reasonable timeframe and cost. There are many, many reasons for this. Existing application portfolios are frequently a complete mess typically resulting from continual compromises made in order to deliver rapid business change, which commonly result in duplication, inconsistency and increased dependencies. Enterprise architecture typically fails to deliver realizable guidance to delivery teams. Delivery projects are commonly driven by narrow focus, exclusively business centric goals. I could go on.
Because business as usual (BAU) doesn’t deliver, we can observe the “initiative count” increasing exponentially. Initiatives are top management driven demands for results that are frequently outside of the momentum plan. For example, narrow focused Agile projects; mobile IT and BYOD; SaaS projects; package acquisitions; M&A, BPO, outsourcing and offshoring projects etc.  Or technology focused adventures such as application level modernization. And what usually happens is the initiatives become the new silos, which in turn contribute to the ongoing maintenance and integration nightmare.
Over the past decade most large enterprises have established architecture as a key discipline precisely because of the situation described above. EA in particular was always intended to provide a “city planning” perspective, coordinating across domains to ensure consistent business processes and information and to govern standard infrastructure and shared services where appropriate. In many organizations EA has actually been disestablished because it was perceived as not adding business value. In other organizations EA has minimal influence on delivery programs because of the lack of interest in “doing things right” and the over-riding imperative to deliver as quickly as possible, regardless of downstream consequences.
Recognize the picture? The problem is that for most organizations there is no BAU. So the result is that stand alone initiatives become the only way to get rapid results, but the inevitable outcome is that the ability to change the core business is in steep decline. Short term “project agility” is confused with “ongoing business agility”.
The way forward is to view the IT Delivery as a Value Chain. You can’t focus on just one part of the chain such as Agile projects, you need to see the bigger picture and “manage” the way you respond such that business AND IT goals are achieved.
If you recognize this situation, you may be interested in my short Webinar – Transformation to Agile IT Delivery. (Note I recommend viewing in You Tube with high quality 720p)