The transition to the Agile way of working is more than a process change. It requires a different way of interaction and behavior and a different mindset. In a large (a little less than 200 people) Agile Implementation endeavor we organized an Agile Mindset session to explain Agile principles and to push the Agile teams away from the comfort of their traditional patterns.
Getting on the Agile track successfully...
In a large Agile transformation assignment 11 teams started to work the Agile way less than 2 months ago. We put them on a 3-weeks iteration track, so they are now in their 3
rd sprint. The teams perform amazingly well: They managed to deliver software all the way into production within the sprint, and retrospectives confirm interaction and team spirit is developing very fast. And we can tell you that was a completely different story in the ‘old’ way of working, which was very traditional, waterfall-like, silo centered and hierarchically controlled.
But is it Agile?
Just at the beginning of the 1-week sprint 0 the team members went through a 1-day Agile Introduction course, in which the Agile manifesto had been discussed for about an hour. During the first two sprints the daily team-coaching emphasized team cooperation, team problem solving and of course software delivery. As mentioned before, the teams did very well, but solutions to problems tended to be more on the ‘right side’ of the manifesto and less efficient than desirable from an Agile point of view.
That is why we decided to expose the teams to an Agile Mindset treat in Sprint 3.
The Agile Mindset session explained
The setup of the Agile Mindset sessions is quite straight forward:
- What is it and why do we do it now
- We give an explanation of the 4 Agile values
- The team gets an assignment to relate team experiences to the 4 values, and
- We have a discussion on how issues should be solved with an Agile Mindset.
We start each session with a short explanation of the session: we want to bring the Agile values to your attention again, because we think it can make your way of working more efficient. And yes, we think it is that important that we disturb you in your sprint ...
We then asked the team to recall the 4 Agile values and talked a bit about the meaning of those. It was interesting to find out that teams are working Agile without being able to recall the Agile values ...
Next, each team member wrote down his/her experiences which they related to the values on a sticky and briefly explained it to the team.
This all took about 30 minutes.
For the second half of the session the facilitator chose the most frequently named issues and discussed it with the team. He challenged the team to explain the solutions they had tried so far and ‘forced’ the team to look for a ‘left side’, Agile mindset alternative. This clearly frustrated the team and made them uneasy. The room was full of resistance, and a merciless stick-to-the-values was requested of the facilitator to move the team out of their comfort zone to experience a new way of thinking.
The most interesting discussion concerned a team that has to deal with a multi-faced customer. They were convinced to be Agile, because they fought this issue with extensive energy on ‘Individuals and interaction’ and ‘Customer collaboration’. Although this was good thinking, it did not solve their issue. They lost valuable time in each (at least the first 3) sprint to get the requirements clear. The team stated to use up to 10 development days in the sprint for this! As next steps they suggested to push the customers to fill in checklists and to improve the documentation. Not especially for the sake of documentation per se, but to force the different business units to interact more, and to document their decisions.
It took a hefty discussion to show the team the ‘Working software’ principle can offer a solution as well: producing working software in the beginning of the sprint, and then demo it to all different business units will speed up the process to get the requirements clear and to define the solution. Yes, this certainly will lead to refactoring or maybe even thrown away code, but that happens in the current situation as well, doesn’t it? And touching software multiple times before it is accepted is not a bad thing, is it?!
One recommended step, to start making the difference
Changing processes is one thing, but changing to an Agile way of working involves changing the mindset as well. In a large Agile Implementation endeavor we decided to organize Agile Mindset sessions for each team. We did this after a couple sprints to give the teams time to build up first and to get used to basic Scrum patterns. The Agile Mindset session is surely a challenging, discomforting experience for the team members, but it is a good way to open them up for a different approach.
