Concept: Context for Change
This concept presents an approach for identifying a set of practice measures by focusing on the context in which they are needed.
Main Description

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.

Variance and scale from low to high

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.

Measures and Practices for a given context

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.