Is it virtuous for a company to let its software engineer invest in the product and the business? In contrast to a hands-on approach, we have chosen to take a central role, self-managing, to cover the phases from gathering requirements to following up with users after deployment.

Empirically, we drew on practices such as extreme programming, DDD, and continuous discovery to gradually break down the boundaries of our jobs and rethink them. Meetings accelerated our thinking, pushing us toward an approach based on experimentation at all levels: our organization, our methods, and our deployed code.

Our developments have taken on more meaning, prioritization has become simpler, and this has enriched the value that we bring to users and, as an extension, to our company.

I invite you to delve into our feedback experience. An opportunity to share what we tested, what we abandoned, and what we loved—in short, our daily routine with several caps. Whether your company is tech-centric or not, daring to take an approach that combines diverse profiles and skills becomes a new source of wealth and a business opportunity.

"Among the many ways of developing, we chose to code together, in software teaming fashion, every day, exclusively thought pairs and mob programming. Does it seem surprising to mix all levels of experience behind the same IDE? Nonetheless, that is what we have been doing for the last four years.

These practices bring many benefits, including improved quality, continuous learning and a shared knowledge of the code base.

You may wonder if this way of working is compatible with your situation, working full-time from home? It may sound counter-intuitive, but full-remote mob programming is a highly efficient way of working, while retaining all the advantages of WFH. On the CTO side, it's a guarantee of productivity, and for a junior developer, there's no better way to get onboarded.

Curious? Intrigued? Come and find out about our experience, where we'll be sharing our difficulties and successes, with a cross-section of perspectives from CTOs, developers, seniors, and juniors."

Team life cycle goes with arrivals of new colleagues with various profiles and experience levels. Although mob and extreme programming refers more to advanced web developers at first, are they really adapted for junior profiles ?
Beyond this first impression, what works and what should be avoided in regard to each team member ? Extreme programming promotes TDD, continuous integration but also peer-programming. In continuation, the mob proposes to code with several people at the same time. When a team practices mob with different experience levels, is it beneficial and under what circumstances ?
I invite you to (re)discover mob and extreme programming throughout my team feedback experience who has been practicing for three years. An occasion to take a step back into our habits and maybe come back with a desire to work together otherwise.