Businessagility.works is a customer-centric operating framework that enables an organisation to sense, respond and adapt to rapidly-evolving customer needs. It is comprised of 1 shared goal, 3 enablers, and 7 principles and value streams that aligns and enables the Customer, the Teams and Leadership. The synergy of all three domains enables Business Agility.
Business Agility = Customer Agility + Team Agility + Leadership Agility
Customer Agility – The ability of the Customer to move, think and react quickly. This ability will be constrained by one, or more factors including time, cost, access, capability and many others. The need or want to remove or lessen these constraints defines the value the customer expects to receive from our products, or services.
Team Agility – The ability of an Agile Team to anticipate, adapt and act upon the evolving needs and wants of the Customer (internal or external). This is enabled through direct and long-term Customer relationships and enhanced through physical, or digital products and services.
Leadership Agility – The ability of Business Leaders to enable Agile Team’s to realise the Customers’ value expectations through co-creation, empowerment and a commitment to reduce organisational complexity. Business Leaders strive to provide a seamless integration of standards where centralised control must be retained for economies of scale, governance, risk and compliance.
This framework builds upon decades of lean and agile practices that were originally developed in manufacturing, and later adapted into the corporate environment by the IT software development community.
Our approach extends these practices beyond IT software development, to create a high-level, end-to-end framework for the creation, management and enhancement of agile products and services.
Why use a high-level framework?
Organisation’s that struggle with low agility, typically suffer from high organisational complexity. This manifests through many different forms including:
- Extensive centralised governance
- Complex process frameworks
- Segregation of specialism into functional siloes, and
- Low-cost technologies that do not integrate, or scale well
This complexity symbolises the traditional cost-focussed business tactics that are required to survive in mature, or over-saturated markets. Organisations that dominate these markets, must have an ability to scale significantly at a lower cost than competitors.
Unfortunately, when these organisations attempt to create new products, or rapidly innovate upon existing ones, they quickly and consistently find that these tactics slow everything down – to the point that they are not able to compete. Especially against start-ups, or smaller organisations with less complexity.
To address this problem, our Business Agility Framework has purposely been designed as a high-level (low complexity) framework that combines enabling roles, principles and value streams to balance an organisation’s need to deliver new products and faster innovation with the implicit expectations of efficiency and reliability.
The Triple Infinity Diagram
The agile value streams are visualised as two overlapping infinity diagrams. This represents the two amplifying relationships in an organisation. Agile Teams enable their Customers, and Business Leaders enable Agile Teams.
When each pair of stakeholders in an agile relationship work together; agility increases, and their shared vision and goals will be enabled. If one, or both do not work together agility decreases, and the shared vision and goals will not be enabled.
More information on each value stream can be found by clicking the appropriately coloured Principle button on the main framework page.
How is Business Agility different from Agile Software Development?
The modern IT Agile movement started in the 1990’s with practices adopted from incremental (1957) and adaptive (1974) software development practices, combined with lean thinking and lean practices from the manufacturing industry (1980’s).
These practices were tailored for the operation of small software development teams (not support), which branched into new frameworks and methodologies such as unified process, DSDM, Scrum, Crystal Clear, Feature-Driven Development, Pragmatic Programming and Extreme Programming (XP)
In 2001, The Agile Manifesto (https://agilemanifesto.org/) was signed and published online by 17 software professionals who had helped create these frameworks and methodologies. Whilst each signatory practiced agile differently, the manifesto served as a common ground on which they all could align upon a common purpose, ‘pleasing customers through working software’.
The Agile Manifesto is comprised of 4 values and 12 principles, which all agile development frameworks and methodologies aim to align with. Due the origin and purpose of the manifesto the overarching theme is to provide working software quickly and reliably.
The benefits of Agile Software Development
Utilising agile practices enabled software development teams to reduce the time to deliver working code (cycle time) and increased the amount of work completed (throughput).
The limitation with Agile Software Development
Whilst the adoption of agile practices within the software development teams had measurable benefits, the reduction in time to deployment, time to market or time to restore service (operations) was not always realised due to a reliance upon other non-agile IT teams.
For example, enterprise architecture, testing/quality assurance, change management, release & deployment, IT Infrastructure, IT support and many other teams within the IT organisation who were not practicing agile.
The Theory of Constraints (aka bottlenecks)
In 1984, Management Expert, Eliyahu M. Goldratt published ‘The Goal’. A novel that introduced the theory of constraints within a manufacturing business. The logic behind the theory is that every system/lifecycle will develop a bottleneck at some point in time which impedes flow. The objective of management is to identify the bottleneck, resolve it as quickly as possible, and drive improvement thus increasing flow.
The adoption of Agile Development had resulted in a visible bottleneck within IT.
Whereas once, the entire IT software delivery lifecycle was consistently slow. The adoption of Agile, within one part of the lifecycle (development) had simply shifted the backlog of work to further down the delivery lifecycle.
The DevOps (development working with operations) movement which began in 2009 was driven by the misalignment between agile software teams and non-agile operational teams. DevOps introduced 1 common goal ‘to put working software into production faster’, 5 new values and 3 new principles, known as ‘The Three Ways’.
The benefits of DevOps
Organisations that adopted DevOps were able to realise benefits across the entire IT software delivery lifecycle including a reduced time to deployment, reduced time to market and reduce the time to restore software services (operations).
The limitation of DevOps
The goal of DevOps is ‘to put working software into production faster’. Therefore, DevOps does not align the whole of IT. For example, IT Support, IT Requests, Infrastructure Projects, Migrations, New Office Setup and many other IT functions that are not involved with ‘putting software into production’.
IT Service Management (ITSM)
The most widely adopted ITSM framework, ITIL® has now in its 4th version (2019), has expanded to include good-practices from Agile, Lean and DevOps. The objective is to align the entirety of IT functions under a common framework, with a set of 7 principles and 34 practices.
The limitation of ITSM/ITIL
ITIL® is designed for IT. Whilst not a limitation per se, its management practices are specific to designing, delivering and operating IT services.
Just as the Agile Manifesto was created to align software development, DevOps was created to align software delivery and ITIL®4 was created to align the whole of IT. Business Agility has been designed to align the entire organisation.
High-velocity IT, using Agile Software Development, DevOps and ITSM shifts the bottleneck of work from IT back to the Business. For this reason, the Business Agility Framework was designed to specifically focus upon the wider organisational challenges that limit end-to-end flow, from the customer – to the customer, whether going through IT, or not.
Whilst Business Agility does not refer to the Agile Manifesto, DevOps nor any specific IT practices, it is perfectly compatible with an IT organisation this ‘is agile’. Our basic organisational unit, the Agile Team could contain IT functions, non-IT business functions, or a cross-functional combination.
In addition, we do not specify the adoption of any one agile practice. If an Agile Team wishes to utilise Scrum as the way to manage their IT, or non-IT development work, they are free to do so. It is the alignment of the organisation through end-to-end value streams that is the focus of our framework, not individual practices.
Ultimately all agile frameworks and methodologies share a common purpose. To shift the focus from shareholders, or internal goals towards customer-centric goals. Increasing agility is simply a means to achieve a common objective, and that objective is to maximise customer value quickly, consistently and sustainably.
- Agile Manifesto (2001) – 1 goal, 4 values, 12 practices (emphasis on delivering working software)
- DevOps (2009) – 1 goal, 5 values, 3 principles (emphasis on delivering working software)
- ITIL®4 (2019) – 7 principles, 34 practices (emphasis upon aligning the whole of IT)
- Business Agility (2017) – 1 goal, 3 enablers, 7 principles and value streams (emphasis on aligning the entire organisation)