An Agile team in its natural habitat
A picture is worth a thousand words — see for yourself how this unique Agile team learns BASIC from their Product Owner.
A picture is worth a thousand words — see for yourself how this unique Agile team learns BASIC from their Product Owner.
This post was published on April 1st, 2020, and should not be taken too seriously.
How many team leaders do you think there are at Allegro? Earlier this year, about a hundred of us had the chance to meet in person for two days. We tackled company-wide technical challenges, exchanged experiences and discussed the way we and our teams work. We encourage you to read our story since it offers a glimpse at the inner workings of our company and its culture.
This is a post for those seeking to accomplish business goals and ensure stability of the solutions developed while maintaining focus on people. The model of three basic psychological needs that I’m presenting here may be useful for leaders, agile coaches, and scrum masters. I also encourage developers to do some self-reflection. This is the knowledge I’ve gained at the World Conference of Transactional Analysis in Berlin. Transactional Analysis (TA) is a theory of interpersonal relationships developed by Eric Berne which has a practical application in various fields, including organizations.
Last year Agile Testing Days Conference was held between 6th and 8th December in Potsdam, Germany. According to statistics provided by organizers there were around 600 attendants and about 30 speakers in keynotes / workshops. During the whole event around 22 different workshops took place, 9 keynotes and around 30 other speeches / presentations divided into 7 parallel tracks. I had the opportunity to attend the first two days of the conference and in this article I’d like to share with you a short review of the most interesting sessions and my impressions about the event.
In the beginning I would like to stress that this is not yet another article about Minimum Viable Product (MVP) mechanics. For theory and examples of its use in practice, please refer to the great article by Andrzej Winnicki. What made me share my thoughts on MVP is what I consider a prerequisite to start working with this method. Moreover, I also recognised this prerequisite as the biggest obstacle which is stopping many enthusiasts from fully understanding it.
Curiosity drives progress. There are already tens of presentations about Spotify on the Internet but we wanted to see how the work looks like there with our own eyes. Here are some thoughts after our visit to Spotify’s headquarters.
This is a story about how professional approach to coding can save you a lot of troubles. It is a story about passion for coding and how it makes our products great. It is a story about carrying out an IT project by one of Allegro scrum teams as a fine example supported by a set of case studies. Read it to inspire yourself how some of the issues can be dealt with.
Building a Minimum Viable Product (MVP) is a method of developing new products by validating hypotheses using feedback from real users as soon as possible. This is supposed to reduce risk and to ensure a good return on investment. It is most often used together with Agile development methodologies. But there’s no such thing as a free lunch and while it reduces some types of risk, MVP also introduces some risks of its own.
Whether you are forming a new agile team or mixing people in an already existing team you start somewhat afresh. In an existing team the balance and group dynamics changes, in a new team people are experiencing each other for the first time and checking what the boundaries are. I don’t want to get into details of what can possibly happen — it’s best if you dig into works of Bruce Tuckman and his four-stage model or Gustave Le Bon’s “The Crowd”. The former indicated that the team goes through the stages of Forming - Storming - Norming - Performing. I would like to concentrate on the very initial stage of “Forming” the team in the first weeks of it’s existence.
This is a story about a Team working in Scrum that wanted to turn to Kanban and ended up, deliberately, working in something resembling Scrum-ban. Scrum-ban basics can be found in Wikipedia. We did not follow all of them.
Several month ago, we thought about taking part in an interesting experiment. We decided to grab all the equipment we need at work and to go outside the office for one sprint, i.e. for a week. During the planning stage, we listed some assumptions we wanted to test:
We, Scrum Masters at Allegro, undertake actions that facilitate the work of our Developers, Product Owners and the Organization itself. We are working with individuals and teams in a variety of ways to remove impediments, increase their agility, etc. We do not limit ourselves to only following the Scrum Guide as this 16-pager is only a framework — the possibilities of acting as a change agent, facilitator and servant leader seem to be endless.
The aim of this blog post is to summarise an experiment that took place between two scrum teams at the end of 2014 and to share our lessons learned. Have you ever worked in close cooperation with another team? Of course you have. But how close is close? Have you ever wondered what happens when you go one step further than cooperation and you actually mix two teams, stir or even shake? During that time we discovered a lot about team dynamics, sources of inner responsibility that is essential for any team to make commitments and what are the biggest obstacles on the way towards self-organisation. So, without further ado, let the story begin…
According to what we were taught at school, you cannot build a perpetual motion machine as it is against the laws of thermodynamics. There is nothing in the world that can generate energy forever, without any energy source. Anyway, I am not going to teach you physics. Instead, I would like to write about the energy that drives us.
This is the second part of the article about how, in one of the teams at Allegro Group, we combined the Minimum Viable Product (MVP) and Walking Skeleton concepts with the Story Mapping technique to quickly define the scope of the forthcoming project and eventually built a reliable and valuable product in a limited amount of time.
Main purpose of this article is to describe what kind of techniques may be used to build valuable and reliable products with limited time. It is based on the experiences we had, during our work on new logistics platform.