This post is part of my collaborative research with Shinsei Bank on highly-evolvable enterprise software. It is licensed under the Creative Commons Attribution-ShareAlike 3.0 license. I am indebted to Jay Dvivedi and his team at Shinsei Bank for supporting this research. All errors are my own.
Jay recently introduced me to Pivotal Tracker, a “lightweight, free, agile project management tool”. It looks like a promising step toward computer-orchestrated knowledge work. To explain what I mean, let’s start by thinking through the relationship between structured work, unstructured work, and computers.
Using computers to orchestrate highly structured work is relatively straightforward, because structure translates relatively directly into software algorithms1. Much knowledge work, and especially sophisticated knowledge work at the core of modern economies such as research, design, product development, software development, strategic analysis, financial modeling, and general management, is relatively unstructured. Can computers support such general knowledge work?
One way to leverage computers in unstructured work is to decompose the work and factor out structured subproblems that can be delegated to computer systems. Done effectively, this enables the structured subproblems to be solved more rapidly, reliably, and inexpensively. In cases where performance on structured and unstructured subproblems complement each other, computerization of unstructured subproblems may lead to qualitative improvements in overall problem-solving performance. In other words, computerization may result not only in efficiency gains but also in qualitatively better output.
For example, computer-aided design software and spreadsheets make possible more sophisticated building designs and financial models by efficiently solving critical structured subproblems. Factoring the (relatively) unstructured task of designing a building or modeling the growth of a new business into unstructured, creative subproblems (sculpting the contours of the building, selecting the parameters in the model) and structured, algorithmic subproblems (mathematical calculations, visualizing data, storing and retrieving work in progress) enables architects and business analysts to focus their attention on creative tasks while computers handle routine processing.
If the complementarity between structured subproblems and unstructured subproblems be sufficiently strong, factoring out and computerizing structured subproblems will increase human employment. If architects can deliver better designs at lower cost, demand for architects will rise. If business analysts can deliver deeper insight faster, demand for business analysts will rise. The degree of complementarity depends to some extent on inherent characteristics of the problem domain, but problem factoring and computer system design influence the degree of complementarity as well2. Thus, advances in computer-orchestrated work may have significant implications for firm performance and economic growth.
Seen from this perspective, the Pivotal Tracker is an intriguing technology. Its design is premised on the agile programming technique of structuring software development as a series of short (one to four week) iterations. Development work is further decomposed into a large number of small, modular “stories” which (as far I understand the methodology) describe bits of functionality that deliver incremental value to the customer. During each iteration, the development team implements a number of stories.
Although originally intended for managing software development, Pivotal Labs, the company behind Pivotal Tracker, proposes using the tool for managing just about any kind of project. From the FAQ:
A project can be anything that you or your team works on that delivers some value, and that is large enough to benefit from being broken down into small, concrete pieces. For example, a project may be to develop software for an e-commerce web site, build a bridge, create an advertising campaign, etc.
Pivotal Tracker screen shot. The active stories for the current iteration are shown on the left, and the backlog is on the right.
The reason Pivotal Tracker (PT) represents a step forward in the computerization of knowledge work is that the tool goes beyond simply tracking progress on a collection of tasks. To begin with, PT enables quantitative planning and analysis by asking users to rate the complexity of each story on a point scale. Several scales are available, including a three point scale. Constrained scales enforce discipline in problem decomposition: for example, using a three point scale, stories cannot be rated accurately if their complexity exceeds three times the complexity of the simplest (one point) stories.
PT uses these complexity ratings to measure the rate of progress in terms of points completed per iteration (termed velocity) and estimate the time remaining until project completion. According to Pivotal, estimates of future progress based on historical velocity prove relatively accurate. PT orchestrates the work by maintaining a queue of active stories to be completed in the current iteration and a prioritized backlog of stories for completion in future iterations. After an iteration ends, PT moves stories from the backlog to the active queue. PT manages the active queue to keep the project moving forward at a constant velocity (complexity points per iteration), helping the team stay on schedule and avoiding last-minute dashes. All of this occurs transparently, without burdening the team members.
PT also handles simple work flow for each story. Team members take ownership of stories by clicking a start button on the story, and then deliver them to the requester for approval when finished. This clearly delineates accountability and enforces separation of worker and approver.
Technologies for computer orchestration of knowledge work are still relatively primitive, but Pivotal Tracker seems to represent a significant step forward.
1 Work is structured to the extent that it can be executed predictably using specialized routines. More here. For a rigorous study of the tasks amenable to computerization, see Autor, Levy & Murnane 2003.
2 Regarding the importance of how problems are factored, see von Hippel, 1990. On the implications of computer system design, see Autor, Levy & Murnane, 2002 and Zuboff, 1989