Latest agile post

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]
(https://en.wikipedia.org/wiki/The_Crowd:_A_Study_of_the_Popular_Mind)”. 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:

allegro.tech agile

Agile is a ubiquitous word in the world of software development. At Allegro, we do not treat it
as a cliche. On the contrary, we dig in, experiment and seek our own ways of doing things. Above all —
we change, develop and adapt to what we see, constantly following our own path. We value the courage
to fail and learn both as a team and as an organization. We eagerly discuss our views and experiences.
On this blog we would like to share our thoughts and engage in a conversation with you, participating
in an international community that supports each other.