Some context about ManoMano,
ManoMano is a DIY marketplace. We describe ourselves as a data-driven tech company.
Here is a view of ManoMano Tech department in July 2019:
Those teams are distributed in 3 different offices between Paris, Bordeaux and Barcelona.
- 12 months ago, there were less than 10 feature teams.
- We have now 18 feature teams
- In 12 months, we expect to be around 30 teams.
So, that is hyper growth context!
The challenges we are facing regarding Agility in this context are:
- How do we help people kicking off these new teams to be efficient as soon as possible?
- How do we ensure a global shared Agile mindset (for example about Agile Delivery KPI which can be often discussed)
- How do we enable continuous improvement at scale?
- How do we balance team autonomy and global methodology coherence?
Spoiler: there is no magic solution (or we didn’t find it yet), but here is our agile journey till now.
There were different options possible and we knew that no organization will be perfect.
So, instead of looking for the perfect hierarchy pyramid and agile framework, we set 4 team principles and 3 Agile pillars, which became the foundations for our Agile thinking.
Agile team: people always come first!
- Agility should not be the matter of 1 support team; it should be the matter of all of us
- Agility has to grow within people and organization
- Agile organization must be scalable
- Agile organization must be flexible
With those in mind, we build this Agile Team organization:
- Scrum Master Dev is a partial time role that is open to anyone within the feature team willing to take the role. This is highly important.
That’s why we do not require any specific skills or previous experiences to take the role.
We even have some teams splitting tasks of this Scrum Master Dev role and assign those tasks to different persons within the team.
But, some teams may have difficulties with that role for different reasons:
- No one is motivated to take the role
- People have the motivation but can feel lost
- They do not understand what is exactly this role,
- or it can be a stressed time with high expectations on delivery or there may have been some people leaving the team…
Plus, even if everything seems to go well, our assumption is that there is always room for improvement.
That’s where the Scrum Master Tribe and Agile Coach come in.
- Scrum Master Tribe are full-time person dedicated to a specific tribe. They are responsible to maintain and improve Scrum process and teams efficiencies within their tribe.
They are more experienced people that can mentor the Scrum Master Dev.
By linking this position at the tribe level, we get more flexibility to adapt to changes.
Let’s say there is a new team within a tribe but not yet a Scrum Master Dev, then the Scrum Master Tribe can support this team to take-off.
Plus, by having a look on different teams, they can detect common patterns either for best practices, or risk of failures.
- Then come the Agile Coach. Coaches are responsible to maintain and improve Agile (not only scrum) process and efficiency in the whole organization.
They are not linked to a specific tribe or teams which reinforce our need for flexibility.
They can work on topics more global such as the definition of roadmap, OKR, Leadership Management coaching. And they also work with Scrum Master Tribe within the teams.
They are more experienced people that can mentor the Scrum Master Tribe.
And they act as strong integrator between IT and Product management.
Plus, by setting those two positions of Scrum Master Tribe, and Agile coach around the Scrum Master role, it gives people in ManoMano the opportunity to get a career path inside ManoMano Agility topics. So, that Agility can grow within people and within the organization.
Which Agile methodology?
3 Agile pillars:
- Feedback loop
- Continuous improvement
One key to follow ManoMano Agile teams maturity is autonomy and self-organization.
By default, in ManoMano, we are working on Scrum with 2 weeks iteration. We advice the Scrum framework because rituals and artefacts give a stability and rhythm to the team. We find it an efficient way for new teams to kick-off and focus on learning their functional and technical domain without putting too much energy on the method.
With more and more teams and some of them more mature, we often had a request for a more flexible approach. Kanban was often quoted as a method that teams wanted to try.
And that leads us to Scrumban…
…but we didn’t want to do a pro and cons of scrum vs kanban vs scrumban, others have done it already.
And what works for one team may not fit another team needs.
That is how we came with those 3 Agile pillars.
We don’t care which framework or method a team is using till it follows those 3 pillars.
Teams members commit one to the other to achieve sprint goal. It enables teams to commit to the company level so that roadmap and quarter goal can be achieved successfully.
- Feedback loop
Having feedback from users and customers as soon as possible to ensure the team has the right priorities and is testing a good solution
Having feedback from members of the team, to always enrich the discussion and avoid job silos such as PM is responsible for specifications and dev for coding and QA for testing.
- Continuous improvement
If there is a problem, we should acknowledge it and work on it.
If there is no problem, then there is room to do better.
Without continuous improvement, people will stop learning and soon become bored and either leave the company or (worst) nurrish depressing thoughts.
Commitment enables trust in teams;
which then enables to share and accept constructive feedback;
which then enables to continuously improve.
To conclude, we think that with the Agile team people and those Agile pillars, we have now the ability to scale steadily. It will not be easy but those pillars also apply to the Agile team and organization itself so we will do our best to commit, listen to feedback and improve.
Any comments will be highly appreciated.
One last word: we are recruiting! You can check all our jobs offer online.