I’ve always been a huge Pink Floyd fan. And Dark Side of the Moon is one of my top 100 favorite albums of all time. And Time is one of my favorite songs on it.
Here’s a snippet from the lyrics that I think serve as a fine entry for this post.
So you run and you run to catch up with the sun but it's sinking
Racing around to come up behind you again.
The sun is the same in a relative way but you're older,
Shorter of breath and one day closer to death.
But I digress…
I’m mature, experienced, or old enough to remember a time when software development was treated as a time-based activity.
You were measured by—
How fast you typed
How many lines of code you wrote (per hour, per day, per project)
How many hours you worked (typing as fast as you could)
How much time you spend (not typing) in meetings, writing documents, etc.
How quickly you could hack-together a design
How many bugs you produced
How many times you had to rework your code
How many breaks (bathroom, lunch, etc.) you took and for how long
I believe the thought at the time was—the more time you spent working, the more value you delivered to the company, and the more you earned your pay. The optimization goal in this case was on time and production.
Sounds like a really good model, doesn’t it? And I’m not joking with the above. This was real!
One of the cultural elements of this was (and is) the notion of filling out timesheets. I remember not too long ago that I had to fill out a weekly timesheet that captured the hours I spent on a specific project(s) and activity(s) that week.
One of the drivers for this was software capitalization. But it was sort of funny. I would scramble each Friday to remember what I’d specifically worked on all week. Often, I was wrong. But that didn’t matter. What mattered was that I filled in the sheet so that there could be an “accounting”. I often thought that ~50% of my guesses were wrong just due to the craziness and reactive nature of each week. But again, accuracy didn’t really seem to be the point.
I also felt, and I probably shouldn’t say it this way, but like a cog in the machine. Simply a human-robot that was cranking out code.
But again, I digress…
Getting to the point
If I had a dime for every time I was challenged about the amount of meeting time that Scrum events took, I would be on my own island right now fully retired. With dimes left over for drinks for everyone.
It’s a nearly continuous complaint that I hear from leaders, managers, and team members. Everyone is always whining about how much of a “waste of time” all of the events are. And they want to calculate the amount of “waste” as a percentage of the sprint.
I’ve seen estimates from 15% to 25% and beyond.
But I think this level of thinking and concern is wrong-headed. As was the case in my long introduction, the delivered value is not a function of the days, hours, and minutes. It’s a function of the quality of the collaboration, engagement, thinking, and customer focus of the team.
I think focusing on hours sends the wrong message. Hours spent in meetings (events) be damned. I’d much rather focus on the customer outcomes and impact that is being made.
Wrapping Up
Why can’t we stop the relentless focus on hours?
You know that the teams are gaming things when you measure in this fashion anyway, don’t you? Not maliciously, but what you think is happening is never what is really happening (remember my earlier timesheets example;-)
Point being—
For example, introduce Scrum;
Be disciplined in its execution (including the events);
Focus on customer outcomes and impact;
The hours become irrelevant;
And the results will speak for themselves!
Stay agile my friends,
Bob.
And the Cherry on Top of this article is another one that describes the Siemens WFH policy announcement which focuses on outcomes over hours spent in the office. You can read it here.
Due Credit
I must give the inspirational credit of this article to Tom Cagley and a series of posts on this topic.