Let me tell you a problem I stumbled upon on a recent project. As an Agile Coach I was tasked with rooting out inefficiencies in a tribe of more than 20 people. The problem: agile immaturity, ignoring the team agreements, working on tasks no-one knows about and of course the end results of all problems: delivery speed far from expected. You could call it your textbook agile mess.
After several interviews and weeks spent with the team it became obvious, that the team’s understanding of the scrum processes was not where it should have been (bummer!!!). Based on the experiences collected, coupling it with the team’s input I have distilled down what the main problems are and how important they are. Then the team and me got to work. Missing Definition of Ready and Done? Let's create one! 2 feature teams working on the same micro service? Get the teams aligned and define areas of responsibility! User Stories are too technical? Ok, this is a big one, but using User Story Mapping we could tackle even this one; I can just recommend Jeff Paton’s book "User Story Mapping", it’s entirely worth its money!
Then one even bigger issue came into the picture. People kept complaining about others not using English in the office. It was a whole cacophony of complaints. It was like everyday politics or football, almost everyone had a crystal clear opinion what is going well and what should be done differently. Consensus? None whatsoever.
I kept long hours researching online who is having similar problems and how are these getting solved. What did I gain for the endless searches in endless blogs from the US and from Europe? In the US the topic is quite big and is considered from regulatory perspective, who is entitled to what. Human laws against what the employer is entitled to request from employees. In Europe the topic is rarely discussed, those who touch it mainly say, that yes, it exists, look at what it brings to your team! Solution recommendation? You guessed it, not really.
As any self-respecting agile coach, I went and invited all the members to an overarching retro including all teams to discuss what they want to do. Did I know where the discussion was going? God help no! We started with a warm up - Telephone Game - where you whisper a word or sentence to the guy who stands next to you. It was a good laugh but people were looking at me confusingly.
All right then, let's get to it! The meeting was then split into to 4 parts (on top of the warm up Telephone Game).
At this point, the opposers slowly left the room, the supporters stayed to decide which measures to implement.
“English speaking zone” posters were put on the wall, people started talking more English, then in 2 weeks people were back to “normal” (people using other languages again), like nothing happened.
Only after the overarching team retro and the heated discussions during the upcoming weeks did I realise that the problem was not the language. It is just the obvious epidemic, the easiest way for people to formalise their dislike to their peers and to their behaviour. If it would have been an entirely German speaking team, they would have found something else, like cigarette breaks or smelly breath.
What did I miss then? In the past the team did not have the proper understanding how to work together and went to the way of least resistance, in this case to a soft anarchy. The members have “successfully” built walls and used them as separation lines between people who did not like work together. There was no-one really wanting to build an agile team. As one of the first converted teams in a traditional organisation they were new to agile and everyone followed their personal agenda. Cooperation and team efficiency were considered as utopian concept. The lack of belief in the scrum processes led them to keep doing the same thing as they did in the past, just without the old hierarchies and by using agile expressions.
In case they would have had the understanding of agile team work to tackle problems together, they could have done a retro around it. We are not programmed to be mean to each other, but uncertainty, missing understanding of the structures we work in brings stress out even from the best of us. Relieve this stress, talk it out and keep on enjoying your job. In the end, that's what we all want, right? Happy employees are effective employees and happy employees work at higher efficiency. But you need the baseline for that.
That means that by being in charge for the building of a team, you have to be in charge for establishing the processes. To do it easily, you have to do it as the first thing once your team is set up. Later as we saw from the above example, it will be very hard to reestablish the way of working in the team. If you don’t know how to do it, invest in people who do. Have an experienced scrum master or agile coach and engage people as development team members with agile best practices under their belt. This investment will be your solid base of value delivery, without this any type of architecture or any world-renowned developer will have difficulties to provide you with the expected results. Do not forget, using agile practices is like using an electric screw driver instead of a manual one. If you know how to use it, it leads to great results. But if you start using it wrong, you will create much more damage.