Have you seen the Forbes article that has zero idea how efficient engineering teams work? They have a whole long list of “inefficiencies”. This is a quote from that article: Marking oneself as “in a meeting” on Slack Scheduling communications (Slack messages, emails, and code commits) for off-hours to appear active Blocking out private calendar […]
How Effective Are You? A colleague emailed me, asking me how she could tell if her staff was effective. She had developed a few metrics. But her gut was telling her she was looking at the wrong data. She was right. She was looking at the wrong data. Her managers wanted to know how effective
I’m tech-editing an article for the Agile Journal. I’m having a discussion with the author about the words “productivity” and “throughput.” I believe that what we measure in agile teams is throughput, the number of features through the team over time. I don’t think we measure productivity, the number of features per person or per
I’ve discussed this situation with several managers recently. The manager says, “I have a wonderful developer, who can code circles around everyone else. If he doesn’t like someone else’s code, he rewrites it over the weekend. If he sees a hole, he writes a ton of code over the weekend He starts work early and
I’m looking for a reference to something I thought I read but can no longer find. Technical people can work up to 6 hours a day on technical work. They may be at work longer, reading email, going to meetings, getting coffee, but they can only effectively do 6 hours of technical work a
My colleague, a senior manager, is inundated with too much to do. Hundreds of emails, seven of hours of meetings every day, hundreds of emails, hiring the next level managers so he doesn’t have to backfill, project portfolio management, and backfill of those management roles not yet filled. My colleague is trying to manage
A client was optimizing for what they thought was the bottleneck in their software development: the testers. In the assessment, I gathered some quantitative data about how long the testers took to test and how long it took for the other groups to perform their work. (They used a phased lifecycle.) The testers were
Last night at my SPIN talk someone came up to me at the end of the talk. I’d discussed earned value and inch-pebbles in my talk but hadn’t specifically discussed how to avoid the dreaded “percent complete” reporting problem to management. The percent complete problem occurs when you have to report progress to management as
On the face of it, higher productivity looks like a Good Thing. More products for less time. Who wouldn’t want this? But I wonder about this search for higher productivity. What do managers really want? If you want to understand about productivity for software organizations, read Putnam and Myers’ new book, Five Core Metrics:
It’s fall conference season, and I’ve been quiet because of the travel and final preparations for sessions. One of my sessions at the AYE conference is called Predicting Project Completion. I decided it was time to explore how to predict the end of a project when I encountered two clients this year. One made