Taking Inspiration from Others: Transformation at DB Systel Part 2

In the first blog post, René Schneider and Andrea Sturm described the why and how of DB Systel’s transformation journey. Here they dive into how their organisation is now structured and some of the steps taken to achieve this state. It’s not a pattern that can be cut-and-pasted, but I find inspiration and insights in their story that can be applied to any organization. After all, if a traditional legacy organization such as DB Systel can change, surely you can too.

In DB Systel, teams are the core organising structure, consisting of five to nine people, including an Agility Master (AM) and Product Owner (PO). While inspired and informed by traditional agile frameworks, the roles and processes were adapted to our needs. For example, an AM has scrum master accountabilities but is also accountable for facilitating compliance with employer obligations. The small team size enables and encourages strong relationships, decision-making transparency, and the room for diversity needed for innovation. Every team acts like a small business, creating their own business cases against which to create value while meeting revenue, cost, HR, and individual KPIs.

Three team types exist. Delivery teams are responsible for providing services to existing businesses, while account teams are responsible for new business. Combined, these teams also develop customer relationships and focus on creating value. Enterprise teams provide support in areas such as HR and governance.

Transformation: One team at a time

To implement this structure, the transformation process needed to allow every team to have the opportunity and time to embrace new ways of working. This was achieved through three phases, which allowed them to grow in competency and confidence.

The first phase equips teams with the basics of self-organisation and agile methods over three months. The teams develop their first ideas as testable hypotheses such as “how do we want to work agilely?” or “what is our customer value proposition?” Completion of this phase is certified by a group comprising individuals from the transformation team, employees from the organisation, support roles, and the Works Council.

Phase two allows teams to iterate and test their hypotheses over six months, providing an opportunity to test working methods and principles, better understand their business case, and to build team camaraderie and effectiveness.

The final phase allows teams time to continue to develop themselves over a year. They own the business and commercial aspects of their remit, demonstrate resilience in addressing challenges effectively, and prove they can live up to their entrepreneurial and employer obligations.

We found that executives usually need three  to six months longer per phase. Leaders might like to talk about change but need to change as much, if not more, than their teams. Push-button, top-down organisational change simply does not work.

The switch from classic data centre operation to self-organised, agile cloud operation is a good example of how this all came together. Teams began to offer services in the cloud as an alternative to data centres. It quickly became apparent that decisions could be made faster with less coordination and more flexibly because teams owned their own destiny. Services could be offered more cost-effectively as a consequence, and time freed up to acquire additional business. The first cloud teams were born.

This success saw other teams formed over time, gradually taking over existing and new business. The cloud made many activities easier and faster through automation, but these teams extended beyond just the cloud. Now these teams operate in the cloud, with on-premise applications, and with other technology services.

Today we are on the verge of having transformed DB Systel entirely into an agile organisation founded on principles including self-organisation, an agile mindset, and a clear process model. Underpinning this was a constant desire to improve, a critical element we had not foreseen, and an enabler to incrementally dissolve the existing hierarchies.

Goodbye hierarchies

The new structure saw middle management responsibilities increasingly assumed by the teams, making the classic hierarchies superfluous. This dissolution of the hierarchies was not date-driven; rather, it happened organically.

As teams took on the complete management responsibility for their business, many colleagues felt overloaded and forced to juggle priorities. Now, on top of their traditional day job, the teams had to undertake tasks such as choosing and introducing tools and standards, for example.

To address this, support structures were introduced that we called Units and Clusters. These aren’t labels for departments or managers but are structures that work together to support teams without diluting their autonomy. The cost of these lightweight structures was born by the teams through generating additional sales.

The Unit

A Unit’s look creates synergies across nine teams, supporting them in their daily work without drifting back to a world of siloed departments. They are self-organised, agile, continuously improving teams, made up of the AMs and POs of the teams being supported, combined with dedicated Unit AMs and POs.

The challenges they tackle vary based on team maturity. Some might need help in building business, ensuring compliance with employer obligations, or resolving cross-team impediments. A mature team might need support integrating their customers into the development process to remove friction.

Units work “on” the system, not in the operational business, and operate in a servant-leadership mode. This was new to us. It’s about continuously developing the system in which teams operate and the surrounding systems. Aspects we worked on included structure and team diversity, processes, stakeholder management, retrospectives, self-organisation techniques, capacity planning, cooperation models, values, and resilience. These improvements are continuous, regardless of team maturity, facilitated by the Units.

The Cluster

Up to nine Units were further bundled into Clusters that acted together for an overarching customer department or a business line. Clusters also work on the system and consist of the AMs and POs from the Units they support, supported by dedicated Cluster AMs and POs. Clusters work together to advance the organisation’s overall abilities and develop cross-cutting processes.

Clusters deal with company-wide processes such as budget and personnel planning. Here, Units support the teams in planning and consolidating the results at a Cluster level to discuss with management. This efficiently and effectively integrates top-down and bottom-up planning. While this might sound reminiscent of traditional approaches, our planning approaches are usually much more ambitious than the conventional top-down planning given they were better informed through their day-to-day engagements with customers and with their depth of knowledge of their own work and surrounding trends.

Finding our rhythm and aligning interests

How do you ensure self-organising teams act in the interests of the company rather than decide to go off and sell shower heads or build bicycles?! It requires a broad and deep understanding of the corporate strategy, an undertaking that the Units and Clusters help with.

We brought together the AMs and POs from each of the nine Clusters, creating a manageable team to understand and translate the strategy into a framework actionable by teams, while also providing input from the teams themselves. A rhythm was established. The strategy was turned into epics by Clusters every three to six months, then further into features by the Units every two to three months. The epics followed a classic user story format (for whom? what? why?) to define the business rationale, objectives, and acceptance criteria, leaving teams free to decide on the “how” of implementation. The teams themselves then work in sprints of one to four weeks. Each cycle consists of a review, a retrospective, and planning.

Additional roles

Several other roles were created to enable our transformation. Senior Coaches advise teams during the first transformation phase on aspects such as performance and processes. Agile Managers and Agility Instructors pick up after this. The Agile Manager offers a safe space for teams transforming, especially when conflicts with the existing line organisation arise, helping the teams adapt to independent, self-organised work. Agility Instructors teach agile values ​​and methods, support teams with methodology knowledge, and actively give feedback.

Today we have around 80 agility instructors, 40 agile managers, and 15 senior coaches for a company with 5000 employees, all developed from within the company. Yes, it was a complex and costly process, but essential to develop the mindset, methods, and procedures incrementally.

Governance and standards … got better!

We decided to avoid creating separate teams for legal, compliance, and governance obligations to avoid falling into a trap of developing specifications centrally with all of the consequential conflicts and weakened accountabilities.

Instead, we created virtual “Guilds,” responsible for a specific area of ​​governance such as security. Guild members mainly come from delivery teams and invest part of their time in Guild activities. This helped ensure specifications were translated pragmatically so teams could implement them with minimal effort and even with additional benefits. This reduced overheads and the need for coordination mechanisms, while increasing company-wide awareness of governance issues.

Another key to success was that while each team is analogous to a small business, they need to act economically given limited resources. They don’t have the luxury of time to deal with every new topic or desired tool they want, creating an impetus to exchange current best practices with the help of the support structures and to adopt tools already in use. Often teams converged on a single tool for a need, but this is decided by the teams themselves. Ironically, the devolved structure has driven a level of standardisation across the company our enterprise architects could only dream of before!

Upskilling our people

Training and certification have been critical to success, taking several iterations to get right, including optimising what’s mandatory versus optional. A multi-day qualification process for AMs and POs begins with an orientation to teach potential candidates the basics of agile and self-organised work at DB Systel. Two three-day “qualification camps” focus on the practicalities of a team’s lifecycle including self-organising constructs, agile attitudes and methods, stages team development, problem solving, customer focus, and resilience. To qualify, a PO and AM who don’t work together normally show several observers over several hours how they apply the content they have learned, gaining feedback through the process.

A crucial lesson was that AMs and POs have very different learning needs, depending on their personal stage of development and where the team is in the transformation process. Our approach enables us to tailor knowledge based on a specific situation.

Works Councils and transformation

In talking with many other companies, we saw an anti-pattern for transformations: a lack of advocacy from stakeholders, slowing transformations down. To avoid this, we engaged our Works Councils from the very start. We agreed to work together to find solutions for all issues that required codetermination. A strong foundation of trust was critical to achieve this.

We drew up our own Works Council agreements on key decisions such the agile principles, hiring, team formation and dissolution, and role descriptions. Rather than traditional contracts, our contracts continue to develop iteratively with new issues and insights incorporated every three to six months, giving enormous flexibility while protecting the interests of employee representatives.

We hope our own ongoing journey provides you with some insight and inspiration for your own journey.