Main Description
Change initiatives and their associated measures are unique to the environments of an organization. Therefore, the
decisions for what the right measures for an organization at any particular time must be made within a defined context.
Scale & Complexity
Complexity is usually associated with things such as lines of code, function points, or number of use cases.
Scale relates to team size. The larger the team, the more complex the human dynamics become. Therefore, adding
people to projects inherently makes the projects more complex.
Addressing scale and complexity enables you to leverage these two dimensions in a way that most organizations never do
when implementing a change initiative. That helps you introduce the right set of changes to the right set of projects.
Rather than treating all projects as the same, you need to recognize key differences and apply the right changes to the
right projects.
Variance
Variances are those things that affect the outcome of a project. Variances may be characterized according to several
criteria:
-
Risk.
-
Team member skills.
-
An organization's ability or inability to deliver.
-
Outsourcing.
Context Mapping
Not addressing variance with scale when introducing a change initiative limits an organization's ability to introduce
the right set of changes to the right set of projects. Rather than treating all projects as the same, recognize key
differences and apply the right changes to the right projects. Context determines the focus for improvement.
In the chart below, variance and scale are both represented as progressing from low or small to high. A project
considered to be small in scale and have low variance if fairly predictable and, typically, needs to work only on the
efficiency of each team member to complete the project on time and within budget. Conversely, a project that is very
large with high variance has more to focus on than the efficiency of each team member.
All team sizes, whether the variance is low or high, focus on efficiency improvement as a business driver. As the team
size grows, the team needs to maintain agility at scale or they will not become more efficient. The context of agility
changes with the context of the project. Large, highly variable teams must also focus on achieving a level of
predictability that increases confidence within the organization that they will finish the project within an acceptable
range for the schedule and within budget.
Context determines the focus on the preferred practices. Different practices apply to different contexts, and team
effectiveness varies based on which practices the team focuses on, as the next figure shows.
Predictability
|
Variance: Cost, Schedule, ...
|
|
-
Requirements Elicitation
-
Evolutionary Architecture
|
|
-
Risk-value Lifecycle
-
Requirements Management
-
Modeling Practices
|
Agility
|
High
Medium
Low
|
|
-
Iterative Development
-
Release Planning
-
Shared Vision
|
|
-
Architecture Management
-
Requirements Elicitation
-
Iterative Development
-
Release Planning
|
Efficiency
|
|
|
-
Test Management
-
Change and Release Management
-
Continuous Integration
|
|
-
Test Management
-
Change and Release Management
-
Continuous Integration
|
|
|
|
Scale: Application Size, Team Size, ...
|
|
Small -- Medium -- High
|
Serialized development (also known as waterfall development) works well in a low-risk environment but
does not effectively enable the management of risk, so there is a penalty for using serialized development in the upper
half.
Agile development works for all contexts, but the biggest return for agile development is in the upper half.
Also, the type of agile development that is the most effective varies by context. Disciplined agile development, such
the scrum process and XP, works primarily for small projects, because they lack good mechanisms for handling large
team, distribution, and outsourcing arrangements.
But when you add strong governance and other scaling mechanisms to these methods -- what we call agility at
scale -- you can effectively operate on the right half. Some development approaches move you left within the
context of a project. The strong focus on risk mitigation allows you to operate as if you were in the lower half after
you have completed 20-40% of the project. The agile development notion of strong automation of change, build, and test
practices further enables a team to operate as if they were a smaller team, thereby bringing them to the left of this
chart.
Capturing baselines of executable code early allows for many small component teams that can now operate and gain the
efficiencies as if they were in the lower-right quadrant of the chart, leading to improved software economics.
The measures to implement are associated with the practices chosen for a given context. Cost-related measures will be
relevant in all areas. Agile development measures are crucial, especially in the upper two thirds. Predictability
measures are crucial for the upper third: projects that are of medium to high variance and medium to high scale.
|