When I was first exposed to agile software development seven years ago, executives told us the “what” of the change but very little about the “why.” For example, we logically assumed that the reason we were no longer allowed to sit in meetings (“Standup!”) was that our new vice president had some kind of irrational hatred of chairs.

Initially, we were excited by the platitudes: “No more releasing poor-quality products. We release every two weeks, and it’ll be like a bus on a schedule. If a feature is not of high enough quality to justify release, it doesn’t get on the bus. Only the scope that’s ready goes out on that bus.”

Even better, scope creep was to become a thing of the past. From now on the engineers would decide what they could do in a given time frame. This new system of team commitment would mean the death of crunch mode. Of course, our new VP informed us all that crunch mode was a “management failure” that he would not tolerate.

Imagine my surprise when I saw features still creeping into our new, smaller release cycles. Engineers were just as stressed. They weren’t working fewer hours—if anything, they were working more. Quality was now even more of a rubber-stamp exercise than it had ever been.

A zealous and passionate senior developer whose heart was full of undying love for the company and who had started there as an intern informed me that he had to work through the following weekend because he was way behind on his commitments. I asked him if he realized that he would be contributing to an intolerable management failure by doing so, and he gave me a puzzled look.

“But nobody’s making me work the weekend,” he said insistently.

I countered, “Then why are you doing it? Why don’t you just take up where you left off on Monday?”

“Because this is the last weekend before we ship sprint nine, and if I don’t work the weekend, I’ll never finish in time. Nobody’s making me do this. I made the commitment myself,” he said.

This only gave me more questions, so I asked, “Why did you commit to something that would require you to work over the weekend to deliver?”

He said, “At the time I didn’t know it was going to take this long.”

So I asked him, “If you made a commitment without the information you needed to accurately understand the scope of what you were committing to, is it reasonable for you to have to keep that commitment in light of the new information?”

He seemed to be getting annoyed and further elaborated on his feelings on the subject.

“But it’s my fault for not knowing what I was committing to, so I should be responsible for delivering that through any means I can. There’s no other way about it.”

I asked him, “What about the bus? Isn’t this kind of thing supposed to be mitigated by just removing your unfinished thing from the bus because it won’t be ready?”

He said, “But I committed to releasing this feature, and if I don’t get it on the bus, it’s my fault, nobody else’s.”

I asked, “Did you have the option not to commit?” I had lost him. We were back from coffee and he was far too busy punishing himself for a predictable failure of the system to continue the discussion.

Humans react in predictably irrational ways to the systems to which we subject them. I’d say from conversations I’ve had with some consultants that some of these self-blaming and self-shaming behaviors are perceived as a desirable consequence from this kind of iterative, commitment-based approach.

In my experience, collaboration and quality suffer when we pressure people to work themselves to death by forcing them to promise things they cannot yet understand.

What other options are there? There are useful, more humane ways to achieve predictability and reduce risk in project delivery.

Once we understand the nature of the system and can coherently express the intents of the delivery organization, we are in the best possible position to begin experimenting with more humanistic approaches to delivery.

If the organization is using an iterative approach with timeboxed sprints, it can reduce the probability of the problem described above by starting and ending iterations midweek. This can help, but it doesn’t guarantee that panic won’t still set in and lead to weekend work or long nights.

Reducing the batch size of increments of work to the smallest measurement that can deliver value to the customer and business creates more frequent logical breakpoints in the development process, which reduces urgency to complete features. If everything is small, we can deliver any time.

One technical way to achieve this end is to invest in continuous delivery systems. By eliminating timeboxes, we can ease the cognitive load and stress caused by deadlines. Of course, this can be accomplished without continuous delivery, but that’s a topic for another article.

Experimenting with humanistic approaches to optimizing the flow of value is a valuable and worthwhile endeavor. Emotional well-being is essential to the optimal performance of knowledge workers. Investing in systems-thinking approaches to improve the lives of our workers will pay dividends in improved quality, engagement, and creativity.