In the blog post, “Don’t Organize Around Projects! Choose a Better Unit of Focus to Eliminate Waste & Increase Agility,” I provided an overview of the desired set of characteristics for choosing an agile unit of focus—one that a company or organization could rally around for budgeting, planning, and team organization. In this posting I will elaborate on the first of these characteristics: choosing a right-sized unit of focus.
Two Extreme Examples for Unit of Focus
How we define the unit of focus will determine how many instances of the unit of focus will exist (i.e., the batch size of the unit of focus). Let’s define two extreme examples:
| Example | Size | Batch Size |
|---|---|---|
| Entire company | Very large | 1 |
| Individual class method | Very small | Huge |
I will show how both of these is likely a very poor choice for a unit of focus, and while doing so, provide guidelines on how to choose a good unit of focus.
Entire Company Unit of Focus
Let’s say that the unit of focus was the entire company. Then there would be only one instance (batch size = 1) of this unit of focus. As such, the entire company (as a single entity) would be the focus for all budgeting, planning, and team organization. Unless the company is very small, it is unlikely that “entire company” is the right-sized unit of focus. With such a large unit of focus people probably won’t have sufficient transparency into what is happening at a level of granularity that would be lead to effective inspection and adaptation. Also, with such a large unit of focus it is hard to imagine how activities such as planning and budgeting would be effective at an actionable level.
Individual Class Method Unit of Focus
Choosing another extreme example, let’s use “individual class method” as the unit of focus. In other words, the creation of each individual piece of functionality in a software system would be its own unit of focus for budgeting, planning, and team organization. This would be absurd. It could result in many thousands of methods (batch size = huge) and the overhead of using individual class methods as a unit of focus would be crushing, not to mention the logistics on how to form teams could get very complicated. So again, this would not be a right-sized unit of focus for our purposes.
How to Determine the Correct Size
As the two previous extreme examples illustrated, choosing a very large or very small unit of focus almost certainly won’t be sensible. A right-sized unit of focus needs to be defined in a way that will yield an appropriate number of instances (not too many and not too few) at an appropriate level of granularity. You’ll know the unit of focus is the right size when two things are true:
- It minimizes the total cost of performing important activities such as planning, budgeting, approval, and team organization.
- It allows for sensible business inspection and adaptation, which requires an appropriate level of visibility and transparency.
Let’s explore these characteristics further.
Minimize Total Activity Costs
We want to choose a unit of focus that allows us to minimize the total cost of performing important activities such as planning, budgeting, approving, (team) organizing, etc. Total cost here means the cost of initially performing the activities plus the cost of having to rework or throw out work when something changes.
Let’s use the project as the example unit of focus in this discussion. Large companies or organizations can have a lot of projects (large batch size). Each individual project could (and probably would) require its own planning, budgeting, approval, team organization, and other important activities. As a result, the total cost of all of those activities across all of the candidate projects is likely very high.
Worse yet, in many companies, the work to complete these activities is done in a large batch to correspond with a company’s annual planning and budgeting cycle. So, for example, it is common for annual planning and budgeting for the next fiscal year to occur in the third quarter (Q3) of the current fiscal year. As a result, some of the projects that get considered in the current Q3 might not get worked on for up to 15 months into the future.
Think of it this way, if your company uses projects as the unit of focus, consider how much time your company spends during annual budgeting and planning cycles to identify, quantify (budget), evaluate, and prioritize (consider for inclusion in the portfolio) all of the candidate projects for the next fiscal year.
Now consider that all of that up-front planning, budgeting, and other activities is only one part of the actual total cost. These initial activities typically happen very early on (during annual planning and budgeting) when the people performing the activities have limited or poor knowledge about the projects. As a result, when conditions on the ground change (over the next 15 months), or people just learn more about what they are doing (as they certainly will), a lot of artifacts produced from those activities (e.g., project plans, budgets, etc.) will need to be reworked or thrown out. So, an accurate total cost would necessarily have to include the additional costs to rework all of those artifacts after initial planning and budgeting.
To help minimize total cost, we must then necessarily consider the issue of waste. Throwing out work that we don’t need is waste. Having to rework plans or budgets or to change team structures because we now have better information is wasteful if we could have avoided the rework by not committing ourselves too early by making decisions in the presence of poor information. To be clear I am not saying that reworking plans and budgets because the situation has evolved is wasteful. Arguably doing so is a key element of being agile (i.e., inspecting and adapting in the presence of new information). What I am saying is that violating the principle of “the last responsible moment” will likely lead to unnecessary waste by making decisions sooner than we should.
So, we would like to choose a unit of focus that would allow us to perform appropriate higher-level activities such as planning and budgeting, but also allow us to defer detailed decision making until a point in time when we have better information to make such decisions, and therefore reduce the probability of waste. Doing so will help minimize the total activities cost.
Applying this logic, project would not be a right-sized unit of focus. But, something like a product or a value stream or a journey might be. Instances of each of these units of focus could lend themselves to an appropriate amount of larger-scaling (e.g., annual) planning, budgeting, and team organization. These units of focus also allow appropriate deferral of detailed decision making until the last responsible moment. In other words, we could fund a specific product or value stream on an annual basis without defining upfront exactly how every dollar will be spent against each specific piece of work over the funding period. Such detailed decisions can be made by the owner of a specific product or value stream at the appropriate time.
Support Sensible Business Inspection and Adaptation
A right-sized unit of focus should also support sensible business inspection and adaptation. Earlier I argued that using the entire company as the unit of focus might be too large and not support the appropriate granularity of decision making. In a larger organization with many different areas, it might make more sense to apply planning, budgeting, team organization, and other activities to each specific area. Doing so might provide a better level of visibility into each of those areas. And, when things start to change, or people acquire better information, there will be better transparency into individual areas that would allow for inspection and adaptation in each area.
Or, said another way, our choice for a unit of focus should provide the appropriate level of transparency for making sensible business tradeoffs both within each instance of the unit of focus and across instances. Returning again to our earlier example, using “individual class method” as the unit of focus would yield many tiny instances. As such, there aren’t obvious examples of tradeoffs that could be made inside each of these very small units of focus. And, moving money from one class method to fund another seems ridiculous. The overhead of making tradeoffs at that level would be crushing.
However, moving money from one value stream or product to another, or reallocating how money is spent within a particular value stream or product would seems quite sensible and appropriately granular (assuming value streams and products of reasonable size).
Conclusion
When choosing an appropriate unit of focus, being right sized is an important characteristic to consider. A right-sized unit of focus will yield an appropriate number of instances (not too many and not too few) at an appropriate level of granularity to minimize the total cost of performing important activities such as planning, budgeting, approval, and team organization, while at the same time allowing for appropriate transparency for inspecting and adapting so that an organization can properly manage its business in a sensible way.