Agile Collaboration in self-organized teams. What is it about and how does it work?
Reading time for this article: 5 minutes
There is hardly anyone at BSH who knows better about agile collaboration in self-organized teams than Şebnem Balaban, who works as Agile and Transformation Coach in our global HR department. In an interview, we asked her to share her experiences with agile collaboration and give tips for colleagues who are interested in learning how to practice it.
Agile collaboration nowadays seems to be on everyone's lips. Where does it come from, and what is it?
Well, it is true that agile mindset and practicing agile frameworks are getting much more recognition in BSH over the years. Some part of it is coming from word of mouth and from success stories that are engaging people. Of course, another factor is the leaders making the adaptability of BSH a priority.
However, as many of us know by now, Agile is not something new, neither in BSH nor in the software and product development scene. The first article about Scrum in the “Harvard Business Review” dates back to 1986 by Taichi Ohno, and Agile Manifesto was put together in 2001.
The roots of agile practices date back to 1950 with Demming Cycle (continuous improvement process) on the one side and on the other side connected with Peter Drucker and his ideas of Modern Management. I also remember some colleagues reflecting back at me how BSH was agile in the '90s and the beginning of the 2000s.
Which working areas practice agile collaboration predominantly at the moment, and what are the reasons for it?
That´s hard to tell from the get-go. When I look at the whole BSH map, the areas where most agile activities take place are the ones with high complexity or some other urgency to do things differently. In these areas, the basic need is to have everybody in the team to bring the best of themselves for creative solutions.
Tell us about the positive experiences you made with agile collaboration in self-organized teams that led to real improvements.
Here it is best to speak of my experience being part of the transformation team in the global IT department. We were a group of six without a manager. An actual self-organization experiment.
From the very beginning, we understood there is no one best way for the transformation ahead. From that point on, we were able to perform because of our common purpose, getting better in our agile coaching mastery and our autonomy to decide what to do. We have run as many parallel experiments as we could, and we learned what works and what does not.
I am proud that many of the experiments we did with the management and the teams are amplified as good practices.
Are there also shortcomings you think would be important to know about?
I would recommend an organization starting an agile journey to be very mindful about why you are practicing agile. If you cannot answer this question, it is not for you. Because you don´t do agile practices when problems are simple, and there is only one best way for the solution. For example, you turn on the tap – water comes out. Turn off the tap – water stops. When cause and effect are super obvious, there is no need for feedback loops. You cannot learn much from turning on and off the tap unless you are trying to develop a better tap.
You should also be mindful of what is on the surface and superficial versus what is the meaning behind it. The things on the surface, what is observable about agile, are some rituals and practices, workshops and post-its, things like that. However, if people miss the real connection with the beliefs and understanding of why these rituals, frameworks, and practices are there, the result would be mimicking agile but not getting the real benefit out of it.
Agile finally boils down to learning supported by a great understanding of complexity, self-organization, and continuous proactive improvements such as transparency, methods of inspection, and adaption. For example, if team members do not understand that experimentation and continuous proactive improvement are needed, retrospectives will be the first rituals to be skipped. It is such a sad thing because every skipped retrospective is a missed opportunity to learn.
Are there typical situations or topics where agile collaboration in self-organized teams is superior to traditional collaboration with pre-defined responsibilities and processes?
This is an interesting question. Because the question implies an assumption that self-organized teams or an agile way of working do not have roles and processes. Many agile frameworks have very lean but separated role structures. For scrum, these are product owner, scrum master, and development team. The essence of any agile framework you pick is the loops of learning. A straightforward example is working in iterations, in cycles of 1. plan, 2. do, 3. check, 4. act. People who really embraced scrum would tell you that it requires a very high level of discipline. I think the biggest difference is that roles and processes in agile collaboration are much leaner.
If I haven´t practiced this kind of collaboration before, what sort of project do you think would be a good one to start with?
My first recommendation would be to put aside the idea that agile is for projects. Agile is about solving adaptive complex problems, products, services, and value streams. Start with people around you bringing transparency over your work, reflecting on who is benefiting from your work, and what are their hopes and wishes. Then start prioritizing and focusing on the topics by priorities. When work is done get feedback from people you serve, reflect on what works and not, take actions to organize better, and do it again. Also, do these steps as a team effort so you can learn collectively.
Where can I learn how to start and what should one consider in the very beginning?
There are a couple of excellent resources, which you can check. A very nice video to watch to understand how an agile team may feel like is Henrik Kniberg’s video of Product Ownership in a Nutshell. An excellent beginner’s book is "Phoenix Project".
What is your number one tip to colleagues who are interested in developing further in the agile area?
Stay curious. Be active about learning more. Be courageous about talking about agility and, you know, challenge yourself and your own beliefs. Seek out a community, and please feel free to reach out.