One day, the organs decided to hold a meeting to determine who should be boss.
The brain said, “I have the capacity for abstract thought, and I also control the autonomic processes of the body. Clearly, I should be boss.”
The heart said, “I pump the blood, taking oxygen to all the parts of the body. Brain, without oxygen you die before anyone else. Clearly, I should be boss.”
The stomach said, “Without me, none of you could function. I process food and convert it into the energy you all require. Heart, without energy you stop pumping. Brain, you consume energy even when the body sleeps. Clearly, I should be boss.”
The sphincter said nothing, and remained closed. After a couple of days, the brain had a headache, the blood was toxic, and the stomach was bloated. The brain, heart, and stomach unanimously declared the sphincter boss.
Although a useful, valuable, and high-quality software product requires the collective efforts of people who have a variety of skills, ultimately a software product is code. Without the user documentation, you could still have something usable. Without testing, you could still have something functional. Without analysis, you might be able to come up with something valuable. But without the code, there is no product at all, good, bad, or indifferent.
Maybe the primary stakeholder is the heart. Maybe the business analyst is the brain. Maybe the testers are the stomach. But ultimately the programmers are the sphincter. If the sphincter chooses to remain closed, the rest of the body will become progressively less comfortable.
Tempting as it may be from a Taylorist point of view, it isn’t really practical to pry the sphincter open by force. That would do more harm than good. If you don’t believe me, then just close your eyes and imagine someone prying your sphincter open by force. Did you enjoy it? Right, I didn’t think so. The only rational remedy is to feed the body whatever it needs to establish and maintain healthy flow.
What the sphincter needs…er, I mean, what programmers need…is an unambiguous definition of “done.” Based on that, they can determine what code to write and how to prove it is correct. Without it, they are doomed from the start.
The funny thing is that most programmers in most organizations would never dream of telling their colleagues that they will not proceed with coding until they get a clear definition of “done.” What they do instead is try their best to write whatever code seems to be wanted, and then deal with the inevitable game of bring me a rock until they can’t stand their jobs anymore. It’s a tragic and heartbreaking pattern, and it’s entirely unnecessary.
If you’re a programmer and you aren’t getting what you need from the other parts of the body, I suggest you just remain closed. According to French and Raven’s model of power bases, you lack the Legitimate Power to tell anyone what to do, by virtue of your position in the pecking order. You certainly don’t have any Reward Power or Coercive Power. You may have a degree of Expert Power based on your knowledge and experience, and maybe even Referent Power, depending on your interpersonal skills.
But your real power comes from the fact you are a sphincter. So, start acting like one. Don’t start on a work item until you understand exactly what “done” looks like. You might be surprised at the effect it will have on other participants in the development process.
[quote]You might be surprised at the effect it will have on other participants in the development process.[/quote]
Or you might be surprised that, after a week or two of stubbornly refusing to write any code because ‘there’s no definition of done’, even though the other developers don’t seem to have a problem with it, you are escorted out of the building.
(Have you actually seen this work in practice? In my organization, I am pretty sure it’d end with me having to tell my wife I was fired for cause. My boss doesn’t -know- the definition of done, and is expecting the team to come up with one).
A week or two? Stubbornly refusing? Wow. That sounds pretty dysfunctional.
Here’s how it works: In a collaborative working atmosphere, when anyone doesn’t understand how to advance a work item, they immediately discuss it with their colleagues. Within a few minutes, you understand what to do and you resume adding value.
Yes, I’ve seen that work in practice.
Your boss doesn’t know the definition of done, but your stakeholders do.
Obviously you aren’t working in short iterations or short cadences.
Obviously you aren’t holding daily stand-ups.
Obviously you aren’t working in a collaborative style.
Obviously it isn’t safe to speak up and ask questions.
What you describe is nightmarish. I’m glad I don’t work there!
. . .
On edit: I’ve reconsidered by knee-jerk reaction to your comment. I shouldn’t say I’m glad I don’t work there. To the contrary, it sounds as if I, or someone like me, needs to work there for a while.
I use this magic phrase: “I’m sorry; I don’t know how to do that.” I learned that from Dale Emery. It works incredibly well.
If your boss has intentionally delegated the definition of “done” to you, then your boss has also intentionally delegated the definitions of “revenue” and “cost” to you. Ask your boss whether s/he is really comfortable doing that. Probably s/he will not be.
If you want to propose a definition of “done” to your boss, I don’t have a problem with that, as long as it doesn’t devolve into “bring me a rock”. If it marks the beginning of a collaboration to decide on the definition of “done”, then it can absolutely work well. Sadly, that’s not what I see frequently, and I can guess that Dave has similar experience.
I’ve sometimes tried that in the past (“I really don’t understand what this vaguely-worded feature is supposed to do.”) and was always told that it was -my- job to figure that out (“Do you need me to come write the code for you?!”) ; management was not going to give me detailed examples of what the software was supposed to do, presumably because they did not have any; why else would they not? Before I learned about agile, I’d assumed this was just the natural order of things, and did my best to come up with plausible definitions-of-done that satisfied the absentee stakeholders.
(Remember the Bugs Bunny cartoon where the King wanted ‘hasenpfeffer’ but had no idea what was actually in the dish? …)