It's a year since I wrote the "People vs Processes and Tools" article. Apart
from being busy with other things, the main reason I don't write very much
here is that my criteria for a post are:
cover something that I want (or need) to assert in public
include something new/innovative/challenging, that isn't widely understood
stand the test of time, i.e. hopefully still be valid in a decade
Suprisingly the main thing I feel compelled to write now is actually
another assault on the "People, Processes, Tools" dogma, which has been been
lobbed at me a lot, recently, as a magic spell to thwart my reasoning or
recommendation about a specific tool or set of tools.
In other words, the underlying message is...
"You're wrong to even be thinking about the tool(s) at this point. We
need to figure out the team and organisation first, then establish the
processes that matter... and then will be the time to choose the tools."
My internal monolog takes this further...
"...And by then, Paul, you'll no longer be one of the People involved.
And in any case we'll have established Processes that you would either refuse
or fail to follow. And just to completely box this off, we'll be choosing a
different tool, that you don't like, to demonstrate how wrong you were.
And we'll make sure you aren't even allowed to access it."
AFAIK the People>Processes>Tools ordering was originally cited as part of the
Six Sigma approach. It may well be fantastic in that context - I have no
idea. But for large scale software work, particularly in established
organisations, it seems largely irrelevant to me.
For a start, there aren't many effective levers we can pull with People:
incentive and environment factors
Without adequate leadership, management, incentives and environment the
remaining factors don't actually get us very far.
If we have the wrong people leading, no amount of education/training will help.
Inadequate managers will struggle to even recognise, let alone hire
the right people. And firing established staff is usually surprisingly
stressful and difficult.
Most of the Processes I've ever seen documented were at least in part
unworkable in practice, and/or
not relevant to the actual objectives
People who define processes without understanding both the details of the
actual work, and the stakeholder objectives and values, will usually produce
bad processes. Ironically, these documents are usually described as
So what's the answer?
Based on some decades of experience, and with a number of successful
(as well as unsuccessful) projects delivered in various scenarios, I'd like
to describe my alternative:
Philosophy => Key People => Tools and Environment => More People => Processes
Philosophy: let's make sure that we're as clear as we can be about what is
the best/right work to do, before we start. This is where our leadership needs
to get its principles, intentions and objectives straight. We may need to
adapt/improvise later but doing the thinking early can avoid a huge amount of
waste and grief later.
Key People: now onboard the (core, small) set of Key People, selected for
their knowledge and ability, to lead/drive/implement the initial phase, which
Tools and Environment: choose the best Tools for the work, and set them up
in an Environment which
is dogfooded (used and tested by the Key People)
is reliable, reproducible, backed up etc
causes minimal friction for the work
is locked down so normal users working in good faith can't actually break
has appropriate gates for review/quality/validation/signoff (but note that
gates can cause bottlenecks and friction)
is simple and obvious for users who are competent and experienced in the work
is self-service (minimal handover/wait-steps) so users can get on with their
provides enough basic documentation for new users to get going quickly
provides immediate and correct feedback from user actions so that
problems and documentation can be improved quickly and effectively
collects and maintains evidence about the work done
More People: Onboard the rest of the team, preferably in phases, and:
fix the problems they encounter
document the things they find confusing or unclear
measure the bottlenecks and do everything practical to reduce them and
increase overall throughput
Once this is working, the remaining step is...
Process: Now that everything is running, we can relatively easily document
what the actual processes are. However, this may not actually be worth doing:
we already have the best tools for the job, in a low-friction environment
we already have with evidence of appropriate reviews/approvals and outputs
we are already measuring our throughput and reducing bottlenects
If you're still here, your internal alarm may be wailing
"Hah! He's hidden 'People, Processes, Tools' in his "Key People
=> Tools and Environment' steps. The people chose tools to implement their
Actually, that's true;
I work with the best People I can find, and I've learned a huge amount
from them. As a result I'm relatively experienced in both software engineering
(doing the work) and the business implications of software engineering
(stakeholder). As a result I'm relatively confident in what software
enginering Processes at scale need to involve; in my view they boil down
"continous integration, automated test, and continous delivery... with evidence
of provenance, reviews and approvals.""
And so, in the end, I recommend specific Tools that help to achieve that.
TL; DR We need to figure out how to guarantee that software can be trusted
In the over-simple graphic above, I've tried to map some of the key technical
roles being performed in the delivery and maintenance of complex systems and
services. I'm struggling to work out who precisely sits …
GENIVI Members need to make attractive, useful software to run reliably in cars for a long time. The amount of software needed is increasing faster than our capacity to bring in extra engineers, and our ability to increase the productivity of the engineers already engaged. Given the economics, automotive organizations …
In my experience many organisations experience systemic difficulties in getting work 'done' to an acceptable standard. The Scrum solution for this is 'agreed definition of done', which typically leads to a checklist eg
Actually it is surprisingly difficult... Do I mean true as in fact or true as in 'I believe this'? Maybe we're in the matrix, and everything is a simulation... maybe the people you trust are lying.. or maybe they're just wrong …
After a typically ignored secretive softlaunch, I'm finally taking the wraps off devcurmudgeon. The idea is to be funny, incisive... and maybe change the world one hacker software developer at a time. But I'm not optimistic. This project may fail, like so many others :-)
Developing complex software well is actually very difficult to do.
Seems to me it requires intelligence way above average, combined with enough pig-headedness to refuse to be defeated by dumb chips and other people's code spitting random error codes at you - often for hours or days at a time.
After years of advising folks NOT to blog, tweet or display their backsides innermost secrets on facebook, here I am poised to break my own rules. No doubt I'll come to regret it later, but really, I need to vent.