The pies aren’t the same size

Something that’ s been hard to explain is why I think the “sprinklings” can’t, must not, be managed, even when we’re in a time crunch (are we ever not in a time crunch?). The thinking goes, “These sprinklings are great, but you probably need to postpone them till after we fix this critical defect. You need to concentrate on fixing this defect for now.”

See? We don’t have spare time sitting around to throw at these “sprinklings”. Why should we allow or encourage time to be spent on them? We’re so far behind already – we can’t encourage these “other” activities, can we? At least till we’re out of the hole?

Yes. We can. We must. Here’s why.

Doing Only the “Necessary”

Here we have a picture of where a developer spent one week of his time. In a 40-hour work week, he spent 94% of his time doing Official Stuff and 6% of his time doing Sprinklings (He felt a little guilty for doing the Sprinklings since no one had given him permission to do those things). He produced 114 DBPs* of work.

Not many sprinklesLegend

He fell behind on his estimates this week, though. Hmm. It looks like we could boost his productivity 6% by having him eliminate the “sprinklings” for now. Right? Wrong. Here’s the twist: the sprinklings didn’t take time away from his project – they’re what keeps him going.

The Momentum of Flexibility

Here’s my experience. Let that same developer have the flexibility to add in those extra sprinklings using his own judgment, and here’s what will happen (at least if he’s me):

In the following diagram, given freedom, the developer has now spent 56% of his time on Sprinklings and only 44% on Official Stuff. WHAT?! We can’t afford that kind of waste, can we?

Lots of sprinklesLegend

But wait, look, in this same week he produced 745 DBPs of work. He was six-and-a-half times more productive, even though he only spent 44% of his time “on-task” as opposed to 94% time-on-task in the other scenario. (And he didn’t feel guilty – he knew what he was responsible for and was accountable for that).

Is This Realistic?

I admit it – I made up all these numbers out of my head. But I know that personally, when I’m discouraged and feeling that my hands are tied, it is so hard to be productive, and when I’m feeling free to do the Sprinklings along the way, I also get more done on my Official Stuff. It really does make a difference if a developer feels empowered or bound!

What do you think, developers? Does this match your experience (or is this “pie in the sky” ?)

Is this phenomenon limited to developers?

*Development Battle-Points


5 thoughts on “The pies aren’t the same size

  1. Are the DBP the same size? If not, then maybe they produced the same amount those weeks (even though the DBP is different).

    Could that developer reduce his sprinklings to only a few eye-popping, intriguing sprinklings, cut out the other less important splrinkling and still produce just as much? What is it about the sprinklings that drives that developer to produce more? The hope of newer, better technology? The grass is greener over there so I will picture myself in that grassland (or beach) while I work on this less glorious project? What is the root motivation that causes that developer to produce more when looking at the sprinklings?

    I don’t think the sprinklings work for everybody, I think it is just one of many motivation techniques. Maybe it is how the sprinklings are defined for each individual that this could then be applied to a generic population.

  2. For me, the sprinklings that you are talking about may be tools that take the tedious, boring busy work out of my job and let me focus on the main thing. It is unfortunate that there aren’t more 3rd party tools out there to help us work faster, but we probably wouldn’t get approval to download anyway, even if they were free.

    Reading books or joining discussion groups about my craft helps me look at my tasks differently, and approach them with more maintainable, readable, testable, robust designs.

    I agree that not all developers are like this – they don’t all have initiative, curiosity, or creativity. But it is unfortunate that those of us who do aren’t being allowed to use it more to improve the company.

  3. I believe Daniel has pinpointed one of issues behind the low morale with this topic. As a company, we used to allow people to spend a few hours a week to work on training and/or tool and process improvements, etc. Somewhere along the line we stopped having time for these things. It is rather sad since 2 hours a week is only 5 % of a 40-hour workweek. And, this time isn’t “lost” to the company. Not only would productivity and morale increase but the company would also have time saving tools and more knowledgeable developers as just a few of the byproducts.

  4. I wonder how important it is to have time *set aside* for this type of thing though? It seems to me that this continual improvement stuff is woven into the fabric of our day-to-day work, not a separate activity (I guess I lean toward time-logging style 1).

  5. When I mentioned setting time aside, I didn’t mean it was one single block of time. I meant we could log up X hours total in a week. We could log that time in any size increments throughout the week, as long as we didn’t log more than X hours in any given week.

    In one case, we were allowed up to 4 hours a week for creating documentation about various aspects of telephony to aid developers (current and future) and documentation to aid Telephony Support.

    There were weeks when I had a lot I wanted to document so I used all 4 hours and then continued to work on the documentation (unpaid) outside of the 8-5 timeframe. There were other weeks where I logged little or no time. The weeks when I used all 4 hours were the exception not the rule.

    By the way, in reference to the case I mentioned above: the 4 hours were granted when a group of developers within Telephony brought up the need for documentation to John Tucker. There were several areas of the product that often resulted in Support needing Development’s help because of high turn over in Support and lack of documentation (this was before the Knowledge Base existed). John listened and agreed that this documentation would save us a lot of time in the future and he granted the time.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s