The Brain-Friendly Approach: “Make it easy, fun and rewarding”
Using an Agile approach to an Agile transformation frequently reminds us to make it “easy, fun and rewarding”. We use it as a guideline on how to think and design the change. And we use it in our daily work. There is no big, easy answer to it, but a lot of small ways to constantly have that approach implemented in the Agile change. We will unfold this more in the “Agile approach” part of the article.
The Brain-Friendly Approach: “The brain reacts positively to clear goals” and “use time to define the wanted behaviour”
In the benefit map, we describe the wanted behaviour on an overall level. But we are much more specific when we use the Agile methods for change. By writing user stories with acceptance criteria and breaking the actual behaviour down into specific tasks in the design of the actual change, we aim at having very clear goals that are easy to train.
The Brain-Friendly Approach: “Make change on demand” and “make change pull instead of push”
Becoming Agile is a large change for all individuals involved. But we can create a pull towards change instead of a push, for instance by using a Kanban board with all behavioural changes of the people involved in the change, and by letting them choose for themselves what they want to focus on changing next in the Agile transformation.
Agile transparency in the Agile transformation
In Agile transformations, we often see that organisations lose their bearings in the change and from time to time feel that the Agile change and behaviour stands still or even goes backwards.
When implementing Agile methods and mindsets, we suggest using an Agile approach. By doing this, we ensure, among many other things, transparency of the specific elements in the change, and we believe it is easier to apply the Brain-Friendly Approach, as described earlier.
To unfold this in more detail, we will go through a concrete example of how to use an Agile approach to an Agile implementation by writing user stories, breaking user stories down into tasks and having stand-up meetings with key stakeholders at fixed intervals.
The example will be about implementing daily stand-ups in a permanent team. The reason for using daily stand-ups as an example is that it is a central ceremony that is easy to understand, but difficult to implement to an extent where the team in effect is self-organised around motivated individuals.
Agile changes formulated as user stories
If we use the structure in a user story, “As <role / person>, I want <what?> so that <why?>” it ensures all the advantages that we normally gain by using user stories to formulate what we want. It is very precise about who needs to do the change, what we want to do and why we want to do it.
Let’s see what a user story with our daily stand-up could look like:
- Headline: “Daily stand-up”.
- Description: “As a Scrum Master, I want to facilitate daily stand-ups, so that team members co-ordinate with each other and issues are identified.”
As with all user stories, formulating the acceptance criteria is essential. They enable us to see when a task is done and make it easier to break the user story down into specific tasks.
Examples of acceptance criteria to our specific “daily stand-up user story” could be:
- “The team talks to each other and follows the structure: What have I done since our last stand-up, what am I going to do until the next stand-up and do I have any issues?”
- “Issues are identified at the stand-up and solved after the meeting.”
- “The team takes responsibility for user stories and tasks on the board.”
We could write it with the team as the role/person, but for now, we will focus on the behaviour of the Scrum Master, and what he/she can do. When we coach and train an Agile transformation while using the Brain-Friendly Approach, it is essential to stress that it is the person(s) who is undergoing the change that writes the user story. It will often be with help from an Agile coach who has actual experience with the concrete Agile behaviour.
This will be one of many user stories in an Agile transformation. To have a good stand-up, we – at the very least – need to have a good refinement process with “Definition of Ready” (DoR) criteria and a good planning session as well as a set of rules to live by in the team. These will have their own user stories (change deliverables) to be delivered in the change effort.
Agile changes as specific tasks
When we write change behaviour as a user story, it is the first step in the Brain-Friendly Approach because we make it specific and easy. But we want to make it even easier and even more fun and rewarding by breaking our user story down into specific tasks. When we do that, we decompose the behaviour and are encouraged to be very operational with the specific behaviour we want to create.
When you write down the tasks of the new behaviour, we encourage you to ask yourself: Is this easy? How can we make this fun? How can we make it rewarding?
Specific tasks for our daily stand-up user story could be:
- Talk with the team about when to have the daily stand-up (so they can commit to the specific time) and invite the team to the daily stand-up
- Write the three questions down and hang them up on the Scrum board (so we remember them)
- Ask the team to inform each other at the stand-up (and not to report to the project manager or the product owner)
- Ask team members to move their own tasks (so they also undertake responsibility for reporting the task)
- As a project manager, move away from the inner circle (so team members don’t report to you)
- Think about your own energy when facilitating the stand-up – have fun
- Place sweets on tasks as rewards when moving to “Done”
And so on. A good stand-up will require more tasks. Experienced Scrum Masters know how many details need to be in place to have a daily stand-up where teams are encouraged to work together and discouraged from reporting to a proxy project manager instead of working together on common goals.
Transparency in the Agile change
By now, we have a user story that is broken down into specific tasks. To make it visible to our new Scum Master, the team and everyone else involved in the change, we will use a Kanban board to create transparency in the change. We will have all user stories and their specific tasks on the board. In the beginning, everything will be in “To Do”. In Agile, this is business as usual.
Because we cannot work on everything at one time, and because we need to train in order to master a specific behaviour, we will start with two to three tasks from our “To Do”. We will only work on tasks in “Doing” and move tasks to “Done” when we can see that the actual change in behaviour has been implemented. Furthermore, by doing this, we can manage WIP (Work in Progress) limits on the Kanban board, ensuring focus on a few things and hereby, maximising the possibilities of experiencing flow. It is also important to let the person(s) involved in the specific change prioritise which tasks to work on and decide when to start a new task.
When you have an overview of the Agile transformation, it also ensures good insights into the status of the overall change and not only the specific behavioural change related to one user story.
Stand up to the Agile change
When we make our progress visible to everyone involved in the change, we exchange information about the elements in our new behaviour that we are working on right now. By meeting with key stakeholders at fixed intervals, we ensure that everyone is on the same page at the same time. There are several stakeholder groups in an Agile transformation that will benefit from knowing: What we are working on right now, what kind of specific challenges we have and how we are handling them.
Zooming back into our “daily stand-up user story”, we suggest that the Agile coach has a stand-up/status meeting with the new Scrum Master and the team once every two weeks to talk about the kind of new behaviour currently being trained. This could be in retrospect to each sprint.
When all tasks are moved from “To Do” to “Done”, we can look at each of our user stories and see if we meet the acceptance criteria of the user story. If we do that, we can move the user story to “To Do” and give high fives or other rewards to the ones involved in the specific change.
Next step Agile
An Agile change is a large behavioural change. In this article, we have only covered a small corner of it. Are you undergoing or thinking about working with Agile methods? Then, an operational next step could be to ask yourself the following questions:
- Do we have a purpose working with agile?
- What kind of benefits are we trying to achieve?
- What kind of behaviour do we want?
- Do we have transparency in our activities
- Is the change in behaviour specific?
- Do we have an agile approach to the change?
- Are we working on making it easy, fun and rewarding?