Strategic agility at scale refers to the application of agile and lean strategies across your entire organization. From an IT point of view this includes the majority, if not all, of your IT delivery teams as well as a the IT-level teams support activities such as enterprise architecture, operations, support (IT help desk), portfolio management, IT governance, and other topics. From an enterprise point of view this includes all divisions and teams within your organization, not just your IT department.
The following indicates that there are four organizational levels to consider when scaling agile delivery. These organizational levels are:
- Individual (tactical/strategic). As an agile professional, you need to understand the fundamental agile/lean principles and to follow those principles in your every day work. In other words you need to “be agile”. However, being agile isn’t enough, you also need to “do agile” by following agile strategies and practices. To be effective you need to understand how these strategies and practices fit together, and when (not) to apply them. Finally, you need to be flexible enough to modify your approach for the situations that you find yourself in.
- Team (tactical/strategic). Your team needs to be “whole”, in that it should include team members with the skills to address the problem that it faces. The team should be organized and work in manner that reflects the scaling factors that it faces. This is particularly true for IT delivery teams.
- IT department (strategic). Your IT department will have delivery teams facing different situations, which means that they will be following different tailorings of the DA framework (or may even be following non-DA strategies, sadly enough). The implication is that your IT strategy must be sufficiently flexible to support such diversity.
- Organization/Enterprise (strategic). Your entire organization should work in an agile/lean manner that dynamically optimizes your whole, overall strategy.
Figure 1. Tactically and strategically scaling your agile delivery process.
Scaling Agile and Lean to your IT Department
An Agile/Lean IT department must be responsive to the needs of the rest of the enterprise while “keeping the lights on”. As you can see in Figure 2, an Agile/Lean IT department does this via three categories of ongoing efforts. Each category is organized into several process blades, each of which describes in detail an activity or capability within your organization. The three categories are:
- Disciplined Agile Delivery. This category supports the four delivery lifecycles – Continuous Delivery, Exploratory/Lean Startup, Lean/Kanban, and Agile/Scrum – as process blades as well as Program Management (the coordination of a large delivery team).
- Disciplined DevOps. This category expands on Disciplined Agile Delivery to add five process blades: Non-Agile/Lean Lifecycles, Release Management, Operations, Support, and Data Management.
- Disciplined Agile IT. This category expands on Disciplined DevOps to add the following process blades: People Management, Product Management, Portfolio Management, , Enterprise Architecture, Reuse Engineering, IT Governance , and Continuous Improvement.
Figure 2. The Disciplined Agile 2.x framework.
The table below describes each process blade and provides links to more detailed discussions about each blade. Note: We are currently in the process of releasing descriptions for all of the process blades.
Table 1. Process blades that support Disciplined Agile IT.
|Process Blade||Description||Further Reading|
|Agile/Scrum||Describes the end-to-end solution delivery lifecycle for teams working in an agile, or Scrum-based, manner. Project teams who are new to agile, or who find themselves in situations where a regular work cadence is effective for them, will often choose to adopt this lifecycle.||The Agile/Scrum-Based Delivery Lifecycle|
|Continuous Delivery||Describes the end-to-end solution delivery lifecycle for teams working in a continuous delivery manner. Product teams who are often working in a DevOps environment often adopt this strategy.||The Continuous Delivery Lifecycle|
|Continuous Improvement||Addresses strategies for sharing potential improvements across teams; supporting teams; and governing the continuous improvement efforts.||Continuous Improvement Process Blade|
|Data Management||Addresses strategies for improving data quality; evolving data management assets; and governing the data management efforts.||Data Management process blade|
|Enterprise Architecture||Addresses strategies for supporting stakeholders; supporting delivery teams; evolving the enterprise architecture; capturing the enterprise architecture; and governing the enterprise architecture efforts.||Enterprise Architecture Process Blade|
|Exploratory/Lean Startup||Describes the end-to-end solution delivery lifecycle for teams working in an exploratory, or “lean start up”, manner. Teams who find themselves in situations where rapid innovation is called for often follow this lifecycle.||The Exploratory/Lean Startup Lifecycle|
|IT Governance||Addresses strategies for consolidating various governance views; defining metrics; taking measurements; monitoring and reporting on measurements; develop and capture guidance; defining roles and responsibilities; sharing knowledge within your organization; managing IT risk; and governing the various governance efforts.||The IT Governance Process Blade|
|Lean/Kanban||Describes the end-to-end solution delivery lifecycle for teams working in a lean, or Kanban-based, manner. Teams who have many small, relatively independent requirements (be they change requests or potential defects) and who are working on an existing solution will often adopt this lifecycle.||The Lean/Kanban-Based Lifecycle|
|Operations||Addresses strategies for running systems in production; managing the infrastructure; evolving the infrastructure, mitigating disasters; and governing the operations efforts.||Coming soon|
|Other (Lifecycles)||Encapsulates other approaches to build software-based solutions such as Unified Process, traditional/waterfall, or even ad-hoc. These are all out of scope for the Disciplined Agile Delivery (DAD) framework.||Coming soon|
|People Management||Addresses strategies for forming teams; helping people to manage their careers; training, coaching, and educating people; human resource planning within your IT department; managing movement of people within your organization; reward structures; and governing people management efforts.||People Management Process Blade|
|Portfolio Management||Addresses strategies for identifying products/projects; prioritizing products/projects; initiating product/project teams; managing vendors; and governing the portfolio management efforts.||Portfolio Management Process Blade|
|Product Management||Addresses strategies for managing a product, including allocating features to a product, evolving the business vision for a product, managing functional dependencies, and marketing the product line.||Product Management Process Blade|
|Program Management||Addresses strategies for managing large product/project teams; allocating requirements between sub teams; managing dependencies between sub teams; coordinating the sub teams; and governing a program.||Program Management Process Blade|
|Release Management||Addresses strategies for planning the IT release schedule; coordinating releases of solutions; managing the release infrastructure; supporting delivery teams; and governing the release management efforts.||Release Management Process Blade|
|Reuse Engineering||Addresses strategies for obtaining assets; publishing assets; supporting delivery teams; evolving assets; and governing the reuse engineering efforts.||Reuse Engineering Process Blade|
|Support||Addresses strategies for determining your overall support strategy; escalating incidents; addressing incidents; and governing the support efforts.||Coming soon|