BrainScrum

I've always disliked production line metaphors in software development (and I hated also the building construction one but only until before I discovered that in reality building construction is much more Agile than people know of). I don't like them because they assume people work in a row with work pushed towards them, usually at high speed, and they must push it, again fast, on to the next person down the conveyor belt.

This way of working doesn't encourage learning, mainly because problems/mistakes/errors are discovered during quality inspection that happens towards the end of the line - exactly when it's too late to make changes.

U-shaped or parallel production lines, like in many Japanese firms, create instead a natural team and make it easier for people to move from one job to another (and help each other). People walk to get work when they need it. Pulling work to them any error can be spotted early by the next person along. And even better they can try to solve it together.

Learning takes place constantly because problems and mistakes themselves provide learning opportunities. You can even stop the line and sort things out rather than letting them throught.

This is a problem I see threatening also us during our daily job: because we do (very)big projects, with lots of people and very fast a tempting, partially unconscious and naturally reassuring tendency towards a production line like:

BAs write stories -> QAs write tests -> Devs write code

might slowly take over.

As a general way of working, if shared by the team and naturally emerged and self-assessed, I found it both practical and reasonable. In fact I think the problem is underneath the surface where the values and principles lie. Entry and exit criterias between the stages of such a story lifecycle are useful to state in a binary way if a story is ready to be played or not (can it be 75% ready? is there something like a Running Tested Feature at the story level? Ready Tested Story anyone? does it really matter or even make sense when there is a team in the real sense of the word?).

If these criterias get in the way of communication and collaboration they slowly become a way to blame others instead of taking action: "it's not my fault, I'm waiting for the BAs to finish this story" or "I don't have anything to do because the QAs are having problems in writing some FIT tests").

Keeping in mind why we work in an Agile way, the core values and principles (not the practices!) that lead us towards this way of behaving we can avoid to fall in that easy, effortless state of mind in which entry & exit criterias are more important than working together. Retrospecting every now and then helps a lot, that's why I like retrospectives!

A friend of mine likes to say: "events are neutral, it’s our mood, our mind status in that particular moment that attaches the judgment to an event", I'd like to paraphrase and say "criterias are neutral, it's our way of using them that affects the team's ability to perform"