A recent article on BBC reminded me of the well-known Hawthorne Effect. Or maybe it isn’t as well-known as I thought. A factory in the Chicago area, the Hawthorne Works, commissioned a study in 1924-32 “to see if their workers would become more productive in higher or lower levels of light” (quoting Wikipedia). There was a temporary increase in productivity during times when they changed the light levels in the factory, and then productivity leveled off where it had been before. This sort of temporary effect has been observed many times in many situations since that time. Many people have tried to understand…

When I tell colleagues and clients I’m not a resource, they often appear puzzled. “Aren’t you resourceful?” they ask. “I’d like to think so, on a good day,” I reply. “Then you’re a resource!” According to the glorious Internet, resourceful means Able to act effectively or imaginatively, especially in difficult situations. or Able to meet situations: capable of devising ways and means Yeah, that sounds good. I’d like to be that. But a resource is just a thing. A resourceful person might be resource-full, but isn’t merely a resource. Humans are far more than that. In my book on software metrics, I make the observation that to…

Most organizations are struggling to determine how much revenue any given project is going to create; therefore, they need some other criterion to prioritize their backlogs. That’s the reason I see companies turning to Cost of Delay (CoD) more and more. Often, I overhear people talking about CoD like it’s some mathematical formula where they can crunch tangible revenue numbers, get an output, and that everyone is just going to get it. In my experience that hasn’t been the case. The reality is that in most cases the CoD is more than just dollars. The cost is usually something more…

A hallmark of lightweight software development methods is the notion of emergent design. The idea is that the design of the solution will emerge little by little as we build up the code in small increments, typically using test-driven development with very short red-green-refactor cycles. When it goes well, we avoid a number of problems. We won’t create a comprehensive design and write a lot of code that only leads us down a rabbit hole that’s hard to climb back out of. We won’t get carried away with our natural creativity and over-engineer the thing way beyond what our customers want…

Backlogs, Teams, and Working Tested Software are the fundamental preconditions that must exist for an organization to be able to do agile well. In agile these three things have very specific meanings. Compromising on the quality of the backlog, the completeness of the team or the definition of working tested software always decreases agility. Backlogs Most organizations underestimate the amount of time and energy it takes to create backlogs with the needed level of granularity. User stories written in a consistent format 1-3 days in size Agreement on method of collaboration Teams Teams that don’t stay together and aren’t able…