Lazycoder

Don’t really like the idea. Developers are expensive and often too logical for their own good. All teams are going to have inefficiencies and waiting around; it’s part of the human condition. Building relationships, trust, and understanding take longer than slinging code.

If you have a culture that encourages constant improvement then there’s no such thing as downtime, anyway. Waiting for a new feature? Go rewrite/refactor an old feature. Anything that’s not actively evolving is dying.

What you describe is in-line with the “swarming” concept in Lean, which I have found to be horrendously inefficient. Eight people looking at a bug doesn’t help anything if only two of them can actually understand and fix it. Everyone doesn’t need to know everything.

Agreed that waiting is a waste, but I feel like too much “swarming” only leads to more waiting & inefficiency. We all hate waterfalls, but you can’t really test and deploy something until it exists.

In the old days, QA would get involved months after coding, which was bad. But that doesn’t mean we should try do do *everything* simultaneously.

Truth is, that first build you ship to QA has the most bugs, probably including a big one that requires a dev to work a long night get a new build out. But, three or four days later, it’s QA doing all the work while the Dev waits for new bugs.

I personally prefer a more “rolling” approach where QA is never more than a week behind Dev. I feel like this helps you dodge the inefficiency of the swarm while still maintaining team unity.

My last Lean/Agile experience wasn’t a great one, though, so I’m probably a little bitter. I do love the “zero technical debt” concept though… definitely encourages refactoring as you go. But man, did we have a lot of arguments about generalization and specialization. In the end, you just can’t expect every team member to be the same. Everyone has a different skill set and role to play, and not all roles can be played simultaneously.

(I’ve also seen the emphasis on Lean cause a team to completely stop designing, but that’s a different gripe altogether…)

So there is a lot of time with everyone that is referred to as “waiting time”.

I am hoping that you are aware of the impossibility of complete testing – which means there are billions of possible tests that we could ideally run on the system we usually work on.

Also, test teams focus should be on test coverage and or quality criteria coverage.

The scripts your QA write can be only to check if the story came alive but there are stories beyond that and life of the system in different and often contradicting ways to the story.

How about using the waiting time to run exploratory testing on the previous build?

This makes at most sense to me because I am focusing on coverage of quality of the system. As you might be aware that quality isn’t just about functionality but a combination of other yyyyy-ability’s ( such as reliability, install-ability, support-ability )

I like the idea of pairing up a dev with a QA but that can be helpful for the dev to learn more about the system when QA is performing Exploratory Testing.

However, if what you have posted works well for you, I am fine with that. The question I am wondering is – we will know we are fine only after making a couple of releases to the customer. Are we willing to take that risk?

Why not minimize risks by maximizing coverage.

Think exploratory testing. Think Session Based Test Management.

We (at Headspring) have found that having a developer who did not implement the story to a developer review (test) of the “completed” story … testing acceptance criteria and looking at the completed feature as if they were the PO. This dramatically helps in quickly finding issues with a story and builds a culture of development pairs delivering higher quality to the developer reviews. This helps getting to “done” with less waste.

The organization is to bureaucratic, like for instance the PO is usually waiting for everyone to finish their tasks so they can see the demo and close the story. It needs streamlining.