(Original Spanish Article is not available anymore)
In Habitissimo, as in any other medium-big sized company, we have many development teams taking care of the different aspects of the business.
In our company, each team is free to choose how they want to work: some teams organize themselves with quite mature Scrum implementations; other teams are entering the Agile World through Kanban, and there are some that even experiment with different methodologies, looking for the perfect one for them.
This fact can be shocking to some, but this way of managing a team is aligned with the way we choose our technologies: our main project is developed using PHP and Symfony, but we have other in-house projects with Python, React, Kotlin…; we like to choose the right technology and methodology for each job.
Today, I’ll tell you about the team I’m currently working for: Marketplace; from a Full-Stack Developer perspective. We manage the team with Scrum:
- They're 2 weeks long and consecutive.
- We work hard trying to fix a single goal for each sprint, aligning it with the current company quarterly goal (we never neglect business - tech relationships).
- We identify them with letters and, when we finish cycling the alphabet, we just start again NON STOP.
- Each alphabet round has some kind of theme associated to it: we like to choose humanized names for the sprint. For example, right now we are using a Food Theme: spanish “Albóndigas” (meatballs) for A, “Bocata de Calamares” (squid sandwich) for B…; but we also tried an Exotic Cities Theme, Flowers Theme… you get the idea :P .
- We are always open to rethink our way of working, so we often try out little changes in our process and we observe if they really work for us or if we should just discard them and try with another one. For example, we started dividing big developments in smaller blocks because we wanted to estimate the time for completion (estimation) better. It's like Caesar said: “Divide and Conquer”!
- In our meetings, all the multidisciplinary team members come together: Developers, Product Owner, User Interface Designers…; but we don’t stop the meeting if someone “crucial” is absent.
- We keep it short: 15 minutes maximum.
- We take out the techie-talk (philosophical technical arguments are important, but they are not needed in this context).
- We focus on asking for help and sharing news that could affect others; and we avoid just reporting to the Product Owner.
-
Disclaimer: this is not an official SCRUM event, but more like a custom event created in Habitissimo Tech Team. It's a daily meeting with a developer from each team that is focused on making visible potential team conflicts and dependencies. It’s like an horizontal meeting, and it foments collaboration.
-
Currently this meeting has taken the form of an asynchronous report: a Slack bot asks us every day if we have anything to inform the rest of the team, and then all the answers are reported in an exclusive channel. We live in the future!
- We are currently migrating from a fixed format of one refinement per Sprint to organic refinements: when the Product and Design teams have an idea ready for development, all the team meet for 15 minutes to analyze it technically. Stand-ups as a way to stretch our legs and improve blood circulation: I totally recommend it.
- We try to meet at the end of the day, as a more distended style meeting.
- It’s the longest meeting, and it’s where we configure the new sprint and where we discuss the pending technical refinements.
- The Product Owner explains the sprint priorities.
- We try to work with a maximum of 2 new epic developments, and they have to be aligned with the Quarterly Goals.
- For one-week sprints, this meeting should take 2 hours. Our sprints last 2 weeks, so we need around 4 hours for this meeting alone.
- We noticed that we are able to decrease this meeting duration if we improve the performance of other Scrum events like for example refinements: let’s all share our ideas and problems as early as possible!
- We developers use the “Scrum Poker” cards to estimate the time to completion of each task. With this system, we do not influence each other and they are pretty cool: we even have a card for “infinite time”!
-
We get together as a team in order to talk about the sprint that is going to be finished next and to try to find any improvement opportunity.
-
Recently we began to focus on writing down an improvement action in each Retrospective and analyzing its execution in the next sprint Retro: a Retrospective is a good group therapy, but we should always commit to improve something in addition to expressing our concerns.
-
Our group dynamics are directed by an amateur Agile Coach, invited from other development team.
-
The Agile Coach writes down the meeting output with the agreed actions, and they even invite us to a calendar event for next week, to remember to execute the actions.
-
Our Retros take between 1 hour and 1:30 hours; we are thinking about reducing it, improving its efficiency.
-
To be honest with you, currently we are not arranging Scrum Reviews.
-
We depend on many different Stakeholders, so it's hard to arrange a meeting with all of them at the same time, in the same place.
-
Right now, we are experimenting with a “Level 10” meeting format in which all the Scrum team and a Business Representative meet. This format helps us to detect actions to execute and to evaluate them in the next meeting. We are focusing on defining our own team KPIs (objectives) and to get feedback about how our developments are affecting the Business really.
-
We are still looking for a way to implement the Scrum Reviews in our routine, because we are concerned that adding more meetings would affect our productivity.
Are all our meetings about problems and needs? No! We have the “Kudos!” too. We’ll talk about it in a future article, but it’s basically a meeting where we can thank all those teammates that make our life easier.
-
Time to completion estimation by points, instead of work hours. The hours estimation seems to us a bit artificial, and it feels more natural to estimate with effort points.
-
We want to be empowered to make our own code deployments, so our Innovations Team is working hard to achieve that. We want to help with this transition too, so as a team we are assuming the deployment rol and the responsibility of fighting production bugs with an Agile mentality.
-
We want to extend the Agile Way of Life to other Company departments! We believe that, as an Integrated Product Team, we’ll never achieve a “high Agile level” if we don’t evangelize about its advantages.
-
We are looking for more people that love to work in an Agile way.
-
Our goal is to have a Designer for each team.
-
The Design Team is beginning to embrace the “Agile World” for their inner processes, so that will help all of us to be more aligned.
-
It’s a bit obvious, but it can be always improved: communication, communication and more communication.
Thanks for reading and see you soon!