5 years, 4 months ago

Agile Business Modeling – The Core Heuristic?

How many times have I heard that the real problem with Agile is getting to the start line? There has to be some definition up front, but Agile methods don’t really help. Perhaps it’s a little secret for many organizations that they feel they must do more specification work up front because it makes it easier to control the Sprints. Oh dear!

To get to this starting gate we need to model the agile business in an Agile manner (YES!). Further we do not want to undertake complete or detailed business architecture (NO!!). We don’t have time, and anyway the core of the innovation and architecture should be done in the Agile Delivery project. But before we can fire up Agile projects we need to determine the scope and charter. If we use conventional scoping methods we may well deliver great functionality very quickly, but we probably won’t, unless we are very lucky, have delivered agile business capabilities that map to the business dynamics and can evolve along with the business.

Here’s a technique that may help.

In the first image below I show a functional decomposition for complaints management which I have clustered into “candidate capabilities” labelled 1, 2 and 3, process management, customer relationships and analysis respectively. This usefully shows that capabilities can be varying levels of abstraction; there’s absolutely no necessity to have elegant models!  The table below the decomposition shows various criteria I used to help me decide on the possible clusters. As you will see there’s variation in strategic classification; the partitioning – which may be key for deployment, some could be centralized others local; and the need for implementation independence and so on.

This analysis certainly helps me present some choices. But aside from the independence and scalability criteria and possibly standardization criteria, I feel I have not fully exhausted the analysis of the need for business agility. In the table below I develop this a little further. First I make an assessment of the potential requirement for future change in each function. I call this Agility Potential (AP) on a 1=Low and 5=High scale [1]. Not surprisingly Analysis and Skills are the capabilities that will probably be subject to considerable volatility. Second I look at the dependencies between the functions; note you have to read this as each row dependency upon a column. And low and behold, Skills and Analysis, and Analysis and Follow-up have high dependencies. This causes me to reconsider my initial cut of capability boundaries. I feel that Skills needs to be very close to Analysis as the investigatory function. And Follow-up should be similarly very close to Analysis. And what’s more these three functions score most highly on the AP scale. I feel Follow-up could easily be collapsed into Analysis, and a name change to Investigation would be perfect. I think a little more deeply about Skills. The degree to which the outcomes of Investigation need to be fed into Skills on a dynamic basis will vary depending on the type of business. If this was a safety critical business, I might recommend consolidating Skills and Investigation and renaming it Knowledge Management. But this really would depend on the business sector specific needs. 
To recap, what I have done here is developed a sharper understanding of the capabilities, and I have attributed them with governance criteria (in the first table) – I know what I must have delivered, and I am communicating some really important information to the delivery team, without constraining them at all on the implementation and delivery method. Also I now know the dependencies between the capabilities, and we can very quickly resolve the services that will be required and the inter project dependencies. And it didn’t take me very long at all.

More on Agile Business Modeling 

[1] I first outlined the idea of Agility Potential in the CBDI Journal April, 2010. Let me know if you would like a copy.
5 years, 4 months ago

Agile Business Modeling – The Core Heuristic?

How many times have I heard that the real problem with Agile is getting to the start line? There has to be some definition up front, but Agile methods don’t really help. Perhaps it’s a little secret for many organizations that they feel they must do more specification work up front because it makes it easier to control the Sprints. Oh dear!

To get to this starting gate we need to model the agile business in an Agile manner (YES!). Further we do not want to undertake complete or detailed business architecture (NO!!). We don’t have time, and anyway the core of the innovation and architecture should be done in the Agile Delivery project. But before we can fire up Agile projects we need to determine the scope and charter. If we use conventional scoping methods we may well deliver great functionality very quickly, but we probably won’t, unless we are very lucky, have delivered agile business capabilities that map to the business dynamics and can evolve along with the business.

Here’s a technique that may help.

In the first image below I show a functional decomposition for complaints management which I have clustered into “candidate capabilities” labelled 1, 2 and 3, process management, customer relationships and analysis respectively. This usefully shows that capabilities can be varying levels of abstraction; there’s absolutely no necessity to have elegant models!  The table below the decomposition shows various criteria I used to help me decide on the possible clusters. As you will see there’s variation in strategic classification; the partitioning – which may be key for deployment, some could be centralized others local; and the need for implementation independence and so on.

This analysis certainly helps me present some choices. But aside from the independence and scalability criteria and possibly standardization criteria, I feel I have not fully exhausted the analysis of the need for business agility. In the table below I develop this a little further. First I make an assessment of the potential requirement for future change in each function. I call this Agility Potential (AP) on a 1=Low and 5=High scale [1]. Not surprisingly Analysis and Skills are the capabilities that will probably be subject to considerable volatility. Second I look at the dependencies between the functions; note you have to read this as each row dependency upon a column. And low and behold, Skills and Analysis, and Analysis and Follow-up have high dependencies. This causes me to reconsider my initial cut of capability boundaries. I feel that Skills needs to be very close to Analysis as the investigatory function. And Follow-up should be similarly very close to Analysis. And what’s more these three functions score most highly on the AP scale. I feel Follow-up could easily be collapsed into Analysis, and a name change to Investigation would be perfect. I think a little more deeply about Skills. The degree to which the outcomes of Investigation need to be fed into Skills on a dynamic basis will vary depending on the type of business. If this was a safety critical business, I might recommend consolidating Skills and Investigation and renaming it Knowledge Management. But this really would depend on the business sector specific needs. 
To recap, what I have done here is developed a sharper understanding of the capabilities, and I have attributed them with governance criteria (in the first table) – I know what I must have delivered, and I am communicating some really important information to the delivery team, without constraining them at all on the implementation and delivery method. Also I now know the dependencies between the capabilities, and we can very quickly resolve the services that will be required and the inter project dependencies. And it didn’t take me very long at all.

More on Agile Business Modeling 

[1] I first outlined the idea of Agility Potential in the CBDI Journal April, 2010. Let me know if you would like a copy.
6 years, 1 month ago

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

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

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