Projects, #noprojects, language and thought

It's a truism that when you learn a different programming language, you learn a new way of looking at code. The language we use changes our abilities to think about what we're describing. The same principle applies to Orwell's Newspeak, the linguistic battlegrounds of social equality, to the fact that arithmetic is simpler in Chinese than in English.

So it's likely that the language we use to describe our work affects how we think about it and how we perform it. Last year for example a client pointed out to me an emotive stumbling block for participants new to agile methods - he found the standard terminology of Scrum alarmingly negative - sprint, backlog, grooming.

I've had roles with an interesting range of employers, on different types of of work. Real-life examples:

• 'Lift-and-shift' of a website from one web stack to another, with no user-visible changes
• Ongoing feature development of a website and its custom CMS
• Development of a social network application, segueing into product support

All of these have been software development for long-lived products, and we've described all this work as projects.

But only one is a project. And the confusion is harming us, as practitioners and as a community.

Project projects and non-project projects

PMI describes a project:

It’s a temporary group activity designed to produce a unique product, service or result.

Temporary duration to meet scoped business goals. If that annoys you because it doesn't describe your work, bear with me for a minute.

By the PMI measure, my web lift-and-shift was clearly a project.

Ongoing feature development was not a project, and while initial delivery of my social network was a project, the current support effort is not. These efforts have existing descriptors - product development and product support respectively. Together they're sometimes classed as BAU (business as usual), distinguishing them from the one-shot (and disruptive) nature of projects.

Note that I'm not suggesting that one is 'better', 'more legitimate', 'more hardcore' or 'more professional'. Clearly these are all crucial software development activities and the language to tell them apart can help us.

Why does it matter?

Simply because the different types of effort have different delivery and (whisper it) governance needs. For the dev team, BAU and support need no spinning up - there's already a product, a UX framework, an architecture, domain knowledge etc etc. And save for occasional 'major' releases there's probably no need to think much about go-live. This makes them fertile ground for a wide range of fantastic lightweight agile techniques. Projects are harder, and often mean a new team, a new set of stakeholders and business domain, new architecture, a deployment plan, handover, training and so on.

For management - the lovely people paying us to develop software - there's a predictable operating expense to BAU (OPEX - the cost of doing business) to maintain and develop an existing product with known business value. Projects are a riskier proposition. They create change in the business - that's the whole point - which means rocking the boat. They take capital expenditure (CAPEX - investment over and above OPEX). The manager has a fixed pot of money and it might go anywhere - Project X or Projects A, B and C, another server, more marketing or straight into the bank to earn interest. She has to have some reason to believe that Project X is worth the investment, which means some idea of what she's going to get, when and for how much.

How our language harms us

We throw around the 'project' to describe all of these activities, and it harms us as individual practitioners and a community.

As an individuals, the language of 'projects' blinds us to difference between the models. After all, it's all programming (or design, or system development or...). We try to apply approaches suitable for BAU to projects, techniques for projects to support, etc. Or we simply get confused why two pieces of work are shaping up very differently. This is not conjecture - I've seen extremely intelligent and skilled engineers declare 'OK but it's all just projects.'

As a community, we're engaged in a divisive debate between estimates and #noprojects / #noestimates. Each side has its impassioned advocates, and they see each other as variously as hidebound or naive.

But the clue's right there in the name. If you're not doing projects, then the #noprojects paradigm might be an fantastic fit. #noestimates might clear a swath of unnecessary overhead - even enable you to make more accurate forecasts!

If you're doing projects, this doesn't apply. Your investors still need...a project and much that comes with it.

What doesn't this mean?

This doesn't mean that projects are waterfall and #noprojects is agile. It might mean that projects sacrifice a degree of agility for a degree of predictability. How far you end up along the agile spectrum may depend on the appetite of the investor and the deftness of the team.

In similar vein, it doesn't mean that there's a hard-and-fast divide between the models. The team doing a project within a product that they support. The ongoing dev effort managed as mini-projects. There are as many ways to blur the lines as there are individual circumstances.

Where from here?

As a software delivery professional, my role is to create clarity and shared understanding. Part of that is agreeing a shared language. So I propose the following.

Within the class of Software Delivery we have three (maybe more) subclasses:

• Projects
• Product Development
• Support

Because they are all Software Delivery, some aspects of all three are very similar.
And because they have different technical and management requirements, techniques that are suited to one are not appropriate for another.

And perhaps we can re-frame the #noprojects debate. Rather than pushing dogmatic points on two 'sides' that now appear illusory, we can ask when are #noprojects and #noestimates approaches beneficial? What new tools can #noprojects and #noestimates thinking add to the seasoned software pro's armoury? And framed like this, might they even find applicability in the projects domain?