Agile Work @tech11 - EN Version

100% of our teams use agile methods, be it or . Each team can choose which method they want to work with and is supported by our agile coaches. This ensures optimal efficiency not only within our teams, but also when working with our customers and partners. Our aim is to improve quality, maximise potential and satisfy customers, partners and, most importantly, our colleagues. Read on to find out how we are achieving these goals with our agile working approach and what we have learnt so far.

How does Agility work at tech11?

As a former start-up company, we have already experienced a lot of dynamic adjustments on our way to becoming a scale-up company. And we continue to be exposed to constant structural change. In the beginning, for example, there was only one team. People from all job families worked for one client. Since then, one client project has become nine, and our team has grown enormously.

Our Spotify-style organisational Structure

Basically, we work in self-organising teams based on the model. So we have teams for client projects and our platform, but often times one member works on both. This means that many people are on two teams, not just one. A Business Analyst will work on a customer project as well as being part of our delivery team. A Backend Developer will be part of the backend team as well as working on a customer project.

Our Philosophy: Inspect and Adapt

The idea our bosses follow is called 'Inspect and Adapt'. We like to try out new methods. If it turns out that an idea does not work for us, we stop the test.

"In a constantly growing company, collaboration models and organisational structures have to be constantly adapted." - Matthias Reining, Co-Founder

Why does Agile Work @tech11 work?

The agile way of working has become very popular in software development. Since most of our teams are interdependent, we need an optimal project methodology. For us, this means working in an agile way, using Kanban and Scrum.

A new feature that our backend team is working on may also require development by our frontend team. So before that feature can be completed, both teams need to contribute.

This is where Scrum and Kanban come into play. They provide iterative aspects that allow for dual control of a task. With these boards, we provide the necessary structure for our colleagues so that a ticket can be worked on by several people and departments at the same time.

The fact that a ticket goes through a wide range of reviews and tests means that bugs are caught and fixed at an early stage. This way we can guarantee high quality features.

Our Heros: Agile Coaches

One of the success factors of our agile work are the Agile Coaches, who have a lot of responsibility. They think about the most important issues:

• Are we using the right approaches?
• Are there better methods?
• Does our current meeting structure still make sense?

Our coaches are in constant communication with each other, driving our agile work forward. They are not only responsible for structure and adherence to agile practices, but also for the team building. Each colleague is encouraged and supported to participate in the meetings. This results in satisfied team members and optimal conditions for a successful customer project.

No employee is left behind!

Join Lea and Simon for a Day at Work as Agile Coaches at tech11. ??????????

The Gamechanger: Agile Artefacts

For us, the biggest difference between agile and traditional project management is the agile meeting artefact. Through regular communication, each team member knows what the others are doing and can provide information when needed. This means that bottlenecks caused by holidays or illness can be dealt with in good time.

It should be noted that an excess of meetings should be avoided at all costs. When a project is in the maintenance phase, daily meetings are often no longer necessary and a weekly meeting may be sufficient.

"Communication and collaboration are very important, but you have to find the right balance.” - Franziska P?lsterl , Agile Project Manager

Our personal favourite is the retrospective. Retrospectives take place every 2-4 weeks, depending on the team, and are a review of how the team has worked together over the past few weeks. The focus is not on criticism, but on constructive feedback. This is where our Agile Coaches get involved. Each team member is given the opportunity to comment, for example, on his or her "4Ls".

Liked – Learned – Lacked – Longed (for)

This is followed by identifying next steps in the form of action items. The action items are measures that the team intends to implement from now on. This is also the time to review and discuss the action items from the last retrospective.

The aim is to create a high performing team.

Agile Mindset

Agile working is a mindset that needs to be internalised. Hiring an agile consultancy is not enough. Make mistakes. Learn from them. An agile approach has no real perspective and its potential cannot be fully realised unless everyone in the organisation lives by it.

"We can confidently say that we have been an agile company from hour 0 because we have the right mindset." - Pierre Dubosq, Co-Founder

What does the situation look like in your company?

Is there a one-size-fits-all approach?

We do not believe there is a one-size-fits-all solution, as agile working needs to be adapted to the company or team. We therefore work with all team members to decide which form is best for them. We also conseider combining different principles to find the best fit.

For example, in our Kanban boards we work without work-in-progress limits. This is because our tasks go through various processes, such as reviews, to achieve optimal quality.

Lessons learned

• Adapt the organisational structure to the teams and people. Because everyone is different, one solution will not work for all teams.
• Regularly questioning current working methods and meeting structures is a must.
• Agile working gives you the opportunity to continuously improve, over and over again.
• Don't force agile methods on your teams, but rather involve them in the discovery process. This also creates a greater commitment to the methodology.
• If teams get too big, respond by breaking them up into smaller groups.
• Agile artefacts include all team members, whether remote or on-site. This avoids time-consuming individual meetings.
• Actions should emerge from each retro.
• Every Agile Coach has a different approach, and that is totally fine.
• Coaches must first gain the trust of the teams.
• It is particularly important to have clear communication about how issues will be passed on.
• The Agile Coaches are not watchdogs, but are there to support the teams.
• When allowing the teams to organise themselves, care should be taken to ensure that there is a very fine line between "handing over responsibility" and "overestimating".
• Not every experience curve needs to be taken into account. The cost factor should always be considered.
• Clearly defined structures are important to allow people to develop.

Conclusion

Target achievement may not be 100% pre-programmed, but agile methods reduce errors and increase employee satisfaction. High productivity is good, but employee wellbeing is more important.