Building the Agile Culture
In Taxibeat we love Agile. Building a strong engineering culture centered around agile principles is a core concept in Taxibeat.
We first stepped into the wonderful world of Agile Product Development almost 3 years ago, when Taxibeat had no more than 10 employees. Since then, we have abandoned the old waterfall product development methods, and slowly but steadily move into the much more interesting (and awarding) sphere of Agile principles and methodologies. In this article I will describe some key steps and concepts in trying to create the Agile Culture, which, in my opinion, is the cornerstone of any healthy agile environment — techniques have also their use, but it is the change in perception that will enable an organisation to thrive.
Knowledge is key
The first and most important step towards Agiling our working environment and processes is acquiring the essential knowledge to do this process. We feel the urge to be constantly educated with the current trends that emerge in the Agile world. This is why in Taxibeat the search for knowledge is highly appreciated. Our library is filled with books, many of them about the Agile methodologies. Certain people are already on board with the ongoing education, and study the agile core principles with much attention and focus. We attend conferences and meetups, whenever we are able to, to learn from other people’s experiences and ways. Agile, like software development, is constantly changing and evolving, with new ideas and methodologies being worked out and tested every day. Keeping an eye on current trends is a very good way to ensure that our teams are not left behind. We are early adopters on the field, trying to find out about new things early, and if something works really well, incorporate it into our regimen. In the end, it is all about applied knowledge.
Striving for autonomy
Taking things to the practical part, the company is organised into small teams, generally 5–7 people, that have as much autonomy as they can tolerate. Apart from the autonomy on how to implement given tasks, each team has the ability to choose the agile methodology that suits best for the kind of work it does and also for its needs. Most teams prefer Scrum, as this was the first agile framework that was introduced into the company. Other teams prefer Kanban. Each team discusses the ins and outs of their work with their Scrum master, who in turn provides knowledge to be used. Then the whole team together decides which is the appropriate methodology that is going to be used.
Scrum is the most used Agile framework in Taxibeat. Scrum is lightweight, nimble, and very powerful if done right. It also creates a steady pace, making the whole organisation focus into certain milestones or releases. Every release feels like a small victory, a step towards the larger goal of the company, and this also builds positive energy and strong work ethic. I work with Scrum on most teams, and have to say that I am very amazed by the power that this framework can give if used correctly and with integrity.
At the same time, limiting ourselves to only one framework does not make justice to Agile principles. Kanban is another choice for some teams, especially for teams that have constant work in flow and have repetitive tasks (such as the QA team). Kanban is more powerful than Scrum in certain ways, and I really believe that we just now discover its potential.
The key concept here is that no methodology is better or worse that the other — it really depends on the team itself to choose the framework it wants, based on the team’s individual character, preferences, and type of work that needs to be done. The synchronisation of the different release circles of our teams (especially if the teams are using different methodologies) is a constant struggle, and we work on this as part of building our engineering culture.
Learning from our mistakes : Retrospectives
Retrospectives are at the core of the Taxibeat agile culture. Whatever the result of a sprint, success or failure, it is very crucial that we seize the opportunity to better ourselves and learn both from our victories and from our mistakes. Retrospectives are treated with much respect — the ability to learn and constantly evolve our way of working is one of the most valuable tools we have, and should never be skipped or emitted.
Retrospectives are held in nice, comfortable rooms. Each team has a retrospective backlog, held by the scrum master of the team, where each team member can add an issue that he or she believes is important for the well-being of the team. The scrum master is the owner for this certain retrospective backlog, so she makes sure by discussing with each team member that the backlog is well defined and prioritised. So when the retrospective begins the Scrum master will simply pull the first item from the backlog, which is the subject that had the most impediments in the previous sprint.
I have been in a lot of retrospectives, and my general feeling is that this is the single most important meeting that each member may participate in. During our retrospectives we do not only talk about the flow of work — we talk about everything, really. Anything that can pose an impediment in our way of working — be that synchronisation of teams, not well groomed tasks entering the sprint, lack of test devices, or even a broken chair or a very noisy coffee machine :-) — everything is nailed down, and solutions are suggested. When I first started facilitating retrospectives, I always stayed between the narrow lines of the sprint — what went well, what we should keep doing, what should be dropped etcr. But when I understood the power of feedback, I started really stretching the ways that our working environment could be modified, and tried to cover all possible points that could use some improvement — oftentimes they are the most well hidden.
Retrospectives are one of the most powerful tools because they enforce constant evolution and polishment of our ways of working. It is fascinating to think of how many things have changed since the beginning of this journey almost three years ago — most of these matters arose through retrospectives.
Never ending journey — Search, apply, test and improve
Using Agile in a working environment is not a fixed procedure — it is a living process which is constantly changing and evolving. We learn new things, try them out, and if they work we keep them, otherwise they are discarded as not useful for our purposes. Constant refinement is the key to building this kind of culture. I am a strong believer in that If you want to change something, the first step is to change your mind and your perception on things. This will enable you to look at certain aspects from a different angle, and be able to break free from old habits and work towards new ideas. This is what we strive for, to create an environment that one is really proud of working in.
