What an Agile coach/consultant does, was always covered in Quality assurance remit (without the Lego, and bug-hunt fun days).
Major challenge when talking about quality in software, without sending the audience into deep coma. As with describing your dreams to others, it never seems quite as exciting when put into words.
So why do we need Quality assurance? Because we are all the same in one respect: even when we are sure, we can be 100% wrong.
I focus on interactions (the weakness in humans is the same as code - at points of integration). But keeping on top of this, we can ensure quality in all areas of a project and here are a few ways Quality assurance can help.
We have all heard this before, but these will never happen unless people can feel free to be themselves. Keep momentum on a project, with a group of individuals with complete freedom to express themselves. It's a challenge, and a worthwhile one.
Vital, but should be serving all needs and it is easy to fall into the trap of just celebrating they exist.
Definition of Done
Everyone has a common idea of what sensibly indicates when a Feature is "Done". However, everyone has also subtle variations on what they consider to be "Done". Is it worth dissecting the DoD to a granular level to please everyone? No - keep it pragmatic.
In order to do effective criteria such as the DoD, the user story has to be clear, and it is worth chasing this process down. What helps is thinking beyond a 3-liner user story, and thinking about examples to illustrate meaning more clearly. This gives the developers more direction, a better basis for creating acceptance tests, and a clearer shot of fulfilling expectations.
All quality efforts, at all stages of the project pipeline, should regularly be reviewed. Every process, every way of working has potential for improvement, or perhaps even losing it altogether. Importantly, the team should feel they can be honest.