Antipattern of the Month: Disguised Project

As product delivery stabilizes and matures, any further enhancement can sometimes take on the characteristics of a service. Once little work is believed to remain that is of high risk or complexity, the justification for continuing to fund a dedicated product team generally diminishes, and the need to maximize flow starts to outweigh the value of Sprint Goals. Multiple products may instead be supported by a single team which undertakes to provide a certain quality of service for each of them. Different priorities and expectations concerning turnaround times might be observed.

Kanban ways-of-working are often favored at this point, and the scaffolding of Scrum might be challenged or even removed. Each product may then be sustained in an ongoing "Business As Usual" (BAU) context, rather than the original project one. The funding of any work may also be organized differently, such as by drawing resource from an operational rather than a capitalized budget.

None of this necessarily constitutes "best practice." There's a lot to be said for organizing work in terms of value streams regardless of its complexity, scope, or the process a team might follow. A hand-over from one team to another can also include technical debt, a toxic legacy that is often complex, extensive, and very high risk. Nevertheless, the above product-to-service model represents a sort of canonical approach which has become widespread across the industry.

In principle, BAU work ought to consist of low-risk enhancements, support, and maintenance. These are, by definition, small and repeatable changes and might be absorbed by the wider organization as an operational expense. It's not an unreasonable policy when capitalizing itty-bitty pieces of work seems like overkill and hardly worth the chase.

Stakeholders who want more substantial work to be done would therefore be expected to secure an appropriate, capitalized budget. Yet rather than do so, they can be tempted to try and game the system. They may disguise the work they want done as a series of small changes, any one of which would arguably fall under a BAU operationally-funded mandate. They might then seek to run the whole kit and kaboodle through a BAU work-stream "on the sly." In effect, the work constitutes a disguised project.

BAU teams need to be on guard for any such abuse of their remit. They need to be aware of the risk and complexity of each work request they take on, and to swiftly recognize patterns that suggest project-level scope. After all, each time inappropriate work is actioned, the service level expectation due to more honest stakeholders is likely to be compromised.

Disguised Project is Antipattern of the Month at agilepatterns.org

Disguised Project

Intent: Try to get substantial work done without having to set up and fund a project

Proverbs: "If the Devil is going to disguise himself, it will be as a monk or a lawyer."

Also Known As: Scope Creep (in a Business As Usual context)

Motivation: Some changes to IT systems can be trivial in nature, such as minor amendments to site content or defect fixes. This type of work is considered to be “Business As Usual” (BAU) and as such it is often absorbed by the organization-at-large as an operational expense. Departmental stakeholders who want more substantial changes must usually resource a suitable project from their capital budgets. They, therefore, have an incentive to disguise such work, either by misrepresenting it as a normal operational small change, or by breaking it up into a series of small changes that they hope will slip through a BAU work-stream unnoticed.

Structure: A Kanban Team will action items that are drawn from an ordered backlog, each of which may require a certain quality of service. Work In Progress limits will be observed, and metrics will be used to inspect and adapt the team’s working practices on an iterative and time-boxed basis. The backlog is expected to consist of “Business As Usual” changes that are small and repeatable in nature. However, large or mutually dependent work items will have been placed on it that do not represent BAU work, and which are associated with significant scope risk.

Applicability: Disguised projects are commonly found where there is a separation between operational and capital budgets. It is also found where there is inadequate control over the parameters of BAU work, or over the threshold that must be reached to trigger project inception.

Consequences: A disguised project will compromise the ability of BAU teams to handle genuine “Business As Usual” work. Throughput will be reduced due to the size and scale of the work items, and the associated scope risk is likely to be hidden.

Implementation: Business As Usual work is typically handled by Kanban teams, and as such, they are most likely to encounter disguised projects on their backlog. Scrum teams tend to be organized in terms of project delivery and so this work is unlikely to be disguised. Scrumban teams might be aligned to a project while simultaneously providing BAU support, hence they are also at risk of encountering disguised projects on the BAU stack.

See Also: Scrumban