Singh's Inevitable Avoidance Principle

Asshok Singh, in a post on Linked In, spoke deep wisdom in these words

...when people are not able to solve organizational problems, they come down to tweaking the framework to accommodate the dysfunctions. 

I dub it Singh's Inevitable Avoidance Principle. Let it be noted.

A Little Context

The forum question where Assok Singh uttered the IAP was answering the question "Why do we have sprints instead of just working one story to completion at a time?"

A great question. Why, indeed?

Working on one item at a time requires teamwork, as indeed all Agile methods are intended to do.

But working on groups of features is more palatable because people can divide up the work individually and defer learning how to deliver as a team. Giving up the "solo ninja programmer" is hard for some people, as frankly most of us are introverts and a few are genuinely anti-social.

If your team is full of people who hate working together, they'll want at least one task available per person at all times. Singh's Inevitable Avoidance suggests that we can avoid solving this problem with a tweak -- so load up the sprint with a lot of stories, maybe a few per team member.

It's even more palatable to managers because with many tasks in flight, they can have different tasks assigned or self-assigned to different people and hold them individually accountable. That kind of thing is hard for managers to let go of. Sinhh's Inevitable Avoidance again comes to the fore, and we allow that within Scrum sprints.

Of course, avoiding or preventing teamwork is entirely anti-agile, but this is what Singh's Inevitable Avoidance warns us about.

One Story Makes Sense

Working on one story to completion at a time is a much better idea, provided you do the most valuable part of the story first and work as a team, and let the PO choose when you have 'enough for now.' That's the point behind story mapping and thin slicing.

Even within a time box it makes sense to work one story to completion at a time, most-important first, so that if any work is left over at the end, it's the least important thing.

Mob programming is the other technique entirely compatible/orthogonal with Scrum or Kanban or XP, by which teams work an entire story to completion. It's pretty amazing stuff.

Pairing, Mobbing, 3 Amigos, story mapping, story splitting, ... there are many features available in modern agile methods that make Continuous Delivery possible and improve team focus. Of course, people inevitably will avoid them.

Take Back Agile

I've been conversing with others who have the same sense of Take Back Agile and a few whose sense of departure from non-agile "agile methods" are a bit more pointed.  I think that recognition of Singh's Inevitable Avoidance may become the centerpiece of the movement.

Maybe. We'll See.