Business Agility Manifesto

Sidebar for IT Project Professionals

 

by Roger T. Burlton, Ronald G. Ross & John A. Zachman¹

  

 

 ~~~

1. True Business Agility
   1. True business agility depends on sustainable business change – not just sustainable development of software.
   2. True business agility is measured not just by speed of response to requests, changes, or disruption, but also by the coherence of the response.
   3. True business agility results only when all silos or product pipelines are eliminated within value chains.
2. Self-Organizing Teams
   1. Self-organizing teams and other agile organization schemes alone do not lead to business agility.
   2. Self-organizing teams are a means, not an end. They do not reduce, but rather increase, the need for business strategy, value chain coherence, reuse of business knowledge, and effective portfolio governance. 
3. Customer Centricity
   1. Customer centricity is crucial – but never the only business goal. Certain business issues never go away including: trade-offs with other business goals, total cost of ownership, compliance, unacceptable risk, and unaffordable cost.
   2. The true business customer is the business product customer – not the software product owner.
   3. Around business people, ‘customer’ should always mean business customer and ‘product’ should always mean business product. 
   4. Users aren’t necessarily customers; user experience is not necessarily customer experience. Customer experience should predominate.
   5. Excellent customer experience encompasses all touch points with customers, not just digital ones.
4. Failing Fast
   1. Failing expensively or repeatedly, even if fast, is nonetheless waste to be eliminated. 
   2. The value of failing fast in order to learn fast must be balanced against other factors including: impact on business customers, cost of rework, and exposure to risk. 
5. Communication
   1. Relying solely on face-to-face conversations to convey and preserve business knowledge is highly risky.
   2. Effective communication of business knowledge over time – its retention – is invaluable. It is far more difficult than simply closing communication gaps on projects.
   3. A critical skill for analysts is the ability to engage in dialogs to assess business knowledge for gaps, conflicts, ambiguity, and completeness.
6. Change
   1. Instantaneous change is not the goal. The goal is well-considered change that achieves the desired business effect and avoids unintended side effects. 
   2. Frictionless change is not the goal. The goal is change that is dependably shaped according to business strategy, policies, and business obligations and commitments.
   3. Intimate, one-off change is not the goal. The goal is scalable, sustainable change.
7. Existing Lines of Business
   1. Skimping on the quality of business software – creating a tech debt – has no place in businesses striving for change in existing lines of business.
   2. In existing lines of business, self-organizing software development teams contribute to business agility only if they build on, and contribute to, explicit shared business knowledge.
   3. In existing lines of business, time-to-market is directly dependent on reconfiguration agility.
8. Concept Models
   1. The focus of a concept model is on what words you should use when communicating about the business, especially in writing and other business communication, and on what those words mean. 
   2. The things in a concept model do not represent things in the real world; they represent the business’s shared understanding of those things, as expressed in business definitions. 
   3. The connections in a concept model indicate how concepts logically (i.e., structurally) relate to one another. 
   4. A concept model is represented by a structured business vocabulary, including both nouns and verb phrases.
   5. A data model, class diagram or entity-relationship diagram is not a concept model. Neither is a process model, use case, or an activity diagram.
9. Business Rules
   1. Effective expression of business rules requires a concept model.
   2. Business is grounded in contractual obligations and commitments, which can be violated but with personal or business consequences. 
   3. Once business rules are encoded procedurally, semantics are lost that cannot be resurrected automatically. The loss renders business intent unclear and reuse impossible.
10. Software Design and Development
    1. Business agility cannot be achieved through agile software practices alone. 
    2. Rapid production of software tends to sub-optimize subsequent rapid cost-effective modification of business knowledge.
    3. User stories, use cases, and software prototypes can easily miss much of the business knowledge needed for a holistic, effective and changeable business solution.
    4. Certain things cannot be rank-ordered against software feature priorities including: fidelity to contractual obligations and commitments, fit in the value chain, and re-use of explicit business knowledge.
    5. A software strategy that fails to capture, retain and reuse business knowledge is poorly suited for the knowledge economy.

 

---

1 Thanks to Gladys S.W. Lam for input to the content and organization of the Manifesto and to Sasha Aganova for shepherding the work through to completion. Top

© Business Rule Solutions, LLC. 2017.
© Process Renewal Consulting Group (2015), Inc. 2017.
© John A. Zachman®, Zachman International®, Inc. 2017.

Permission is granted for unlimited reproduction and distribution of this document under the following conditions: (a) The copyrights and this permission notice are clearly included. (b) The work is clearly credited to its three authors. (c) No part of the document, including title, content, copyrights, and permission notice, is altered, abridged or extended in any manner.