While it is true to say that people’s attitudes and beliefs are key to implementing an agile project, or Agile in itself, much of the use of the term ‘mindset’ implies a mental model that can be defined and engineered. In this presentation, we will look at how we can measure attitudes within an organization and use multiple small actions to trigger the rapid evolution of organizational culture, so that it can sustain agile developments. Mindset and the alignment-based ideas of some on the Agile movement too often imply creating homogeneous beliefs and values that will lead to full alignment. In practice, this damages resilience and can be dangerous. This presentation will introduce the idea of coherence instead of alignment - the celebration of cognitive and behavioral differences that can align if needed to support the delivery of sustainable solutions.

We all know what is the job of a tester or QA people: she tests... Specifically, she validates changes, she checks non-regression, plus some other things on the side.

But what's her job now that the company is all agile and stuff? It seems no one knows, not to mention that she has been integrated into an agile team. How is it possible to do the same stuff than before but now under the tight deadline of a Sprint? Besides everyone is talking about test automation, so do we really still need a tester?

Why not answer to all these questions by tagging along with an agile tester during a week? During one week, you'll get to see what is the everyday life of an agile tester, what her days are made of, and all the value she's bringing to the team without setting herself as the production environment warden.

In this session you'll see no dogmatism. You'll witness lifelike situations, shared in a humorous tone.

You'll see that the agile tester role is very subtle. Unlike what most people might think, the agile tester has a lot of work to do and most teams would gain a lot to have one!

Mike Cohn advocated writing user stories in a “As a <user> , I want <action> so that <benefit>” template because it put the system requirements in first person, thereby bringing an inherent user perspective to design and helping product owners prioritize effectively. However, the user perspective has so far not captured the user state of mind or mood resulting in terribly designed interfaces and bad user experiences.

Let us look at a couple of user stories to understand this concept.

a. As an entitled-to-support user, I want to enter my broken in-warranty hard disk details so that I can create a support ticket.

b. As a valid user, I want to like my friend’s post so that he gets fake internet karma.

For a development team, these user stories mean fields, buttons, backend, fancy CSS and that is all. But if you look closely, user in story 1 is not just an entitled-to-support user but a ‘frustrated and dejected” user whereas the user in story 2 is a ‘happy’ user.

How about rephrasing the user stories in the experience template

As a <user> , I want <action> so that <benefit> becomes As a <mood> <user> , I want <action> so that <benefit>

Since the purpose of user stories was to initiate and enable team discussions on features and not be the actual task set in stone, I strongly believe that capturing user mood in the story would enable better design discussions and even sharper prioritization.