Corporate IT has long been a paradox: as a source of competitiveness it is expected to be responsive and flexible; as a cost center it is kept on a tight budgetary leash.
To satisfy the prior, we use some form of portfolio management to reconcile competing - and sometimes confusing - priorities to direct IT effort toward the highest priority business needs. To satisfy the latter, we manage supply - people, infrastructure, solutions - to maximize productivity and throughput, and minimize idle time. Generally, we manage these independently of each other, but success lies in the balance of the two.
In software development, it is alluring to think that achieving this balance is a technical management problem that can be solved through process. We think of software development as a value-generative activity: the features we add have value, so if we can determine which features offer the best value at the smallest risk in the shortest time-to-market, we can maximize our business impact. If this is the case, the problem of balancing supply with demand should be primarily one of granularity of requirement: something fine enough to be deliverable in a short period of time, but coarse enough to be of business value. No surprise, then, that we've seen a rise in popularity of Agile, and particularly of Agile Stories, in corporate IT: being short and compact, they should make it possible to prioritize across diverse business demands, while minimizing work in progress because any given Story requires a short delivery horizons. In theory, we're making supply more efficient and simultaneously maximizing yield of the IT portfolio.
In theory. In application, we quickly run into two problems.
One is on the demand side. It's appealing to think of a portfolio of development projects, each of which will yield assets that provide some return to the business investing in them. In practice, a corporate IT portfolio isn't so tidy. It's got a little bit of everything, including major projects, minor modifications, packages of bugfix masquerading as enhancements, library version upgrades, and various & sundry other things. For many of the investments in the portfolio, the economics are neither crisp nor clear: "increasing customer satisfaction" and "reducing risk of failure" are worthy but cannot be rationally denominated in financial terms comparable to things like "increase revenue" or "decrease cost by eliminating jobs". Very often, things in the portfolio are things that just have to get done (e.g., upgrade or lose vendor support) or that people want to get done for appearance sake (e.g., halo projects). On top of it, it's not always clear who the business "sponsor" or "owner" or even the "user" of these things are. Demand is messy.
The other problem is on the supply side. The theory is that if everybody is working to satisfy a Story with business value, then we've achieved a state where throughput is optimized and people are always working on The Most Important Thing. But The Most Important Thing expressed as a Story will, by definition, always be some business goal or need - and that isn't how work gets done in IT. Corporate IT is overwhelmingly populated by monoskilled specialists: an ETL developer, a UI developer, and a middleware developer might all cut code, but they all do different things and they cannot do what each other does. Their "unit of work" is a very specific and very narrow task that, at best, contributes toward meeting a business need.
For the process wonk, this is inconvenient. It's a void, a "last mile" to bridge. The automatic response is to decompose Stories into a collection of technical tasks and assign those tasks to different specialists. We still have line of sight from tasks that satisfy a Story, and Stories that satisfy an Epic, and Epics that satisfy a business case, so we're still aligning supply with demand. That works, doesn't it?
It does not. When we cast portfolio needs in terms of technical tasks, we're subordinating demand to inadequacies of supply.
- Technical tasks are interesting to technical people, not business people. The Most Important Thing to somebody running a business will never be a technical task. The CEO is interested in fulfillment of a tech task only during times when IT is damaging the business.
- Tasking reinforces the biases and behaviours of tech that we want to change. The point of a Story is to have people think from a business perspective. When we task, we have to swarm specialist labor to solve a single business problem. They speak fundamentally different technology languages and will see the problem they're out to solve through different technological lenses.
- A "whole business solution" is more than the sum of technical tasks. Omnipotence for up front design twined with multiple hand-offs among myopic specialists has not historically been a formula for success in IT.
- Tasking creates local optimization at the cost of systemic efficiency. Because it is easy for specialists to complete tasks, tasking creates the appearance of efficiency. Somebody fluent in a specific area of code or with a specific business area can complete a task faster than somebody who is not. This efficiency comes at the cost of systemic responsiveness and resiliency: the greater the degree of specialization, the more bottlenecks we create and the less resilient we are to a loss of those specialists.
- Tasking is the triumph of effort over results. Keeping an army of specialists busy requires that we have a large backlog of work that they can tap into, otherwise we fail to maximize utilization of supply. This is done either by pulling demand forward - initiating multiple projects from the portfolio to fill the backlogs - or generating backlogs of purely technical things that we may or may not ever get round to doing. Either way, we are increasing work in process as a means of maximizing labor utilization (or, in simpler terms, keeping people busy).
Tasking might make supply a little less inefficient, but it does nothing to improve the performance of our IT portfolio.
However, it is acquiescence to the systemic inefficiencies inherent in an effort-centric operating model, largely because it is the path of least resistance. It's easier to administrate an effort-centric business than a results-oriented one. It's easier to define position specs and salary grades for specialists. It's easier to hire & rent specialists. It's easier to define task orders for specialists. It's easier to learn one technology well enough to get a job at it. It's easier box-tick work done by specialists. It's easier to do a defined task. It's just easier.
Effort is easy. Results are hard.
If the goal is to improve the performance of our IT portfolio, then we need to bring labor closer to the portfolio instead of bringing the portfolio closer to labor. We need each person to able to deliver a meaningful business result. We need polyskilled generalists who can bring skills and capability to bear on solving business problems through technology. We need people who are knowledge acquisitive and disciplined in how they work.
This goes against the grain. Companies are optimized to minimize how much they spend against gross revenue goals, not how well they maximize return against discreet, incremental uses of capital. Procurement and HR will have no means of compartmentalizing, grading and costing this. The CFO will chafe at the unit cost of generalist labor.
Results don't always speak for themselves. In IT, we need to become less concerned with measuring effort and more adept at framing results.
