Understanding Developer Typology

Understanding Developer Typology
Ahead of the June Leaders in Tech: Baden-Württemberg held on 21st June 2018 we speak with 1&1’s Matthias Wittum, Head of the Source Center and Christian Rehn, Software Developer in 1&1’s Customer Selfcare Solutions about their highly developed frameworks and models which are specially designed to examine developer typology. Their frameworks and models are proven to support developer teams, strengthen communication and optimise design decisions.
Matthias Wittum explains that whilst working with Christian Rehn, they identified how different developers can be when it comes to reaching a design decision and how this has an impact on development teams. We know that developers are unique problem solvers who draw on different approaches, knowledge, cultures, experience and principles to produce software solutions. Developers naturally approach projects uniquely, and the outcome can play to a particular focus or strength. Of course within a development team this can lead to several solutions being found and so the challenge is often finding one team solution or design route.
There are enough personality tests out there, but no tests or frameworks based specifically on developers. We felt that some instruments were needed to enable better production efficiency and to help develop teams according to their orientation and typology, so we started filling the gap. That’s how the Design Types Model for instance, came to fruition. It sets out to define developers’ typology via a relatively straightforward base of questions for each developer to answer. The answers provided help classify their typology and then you can group them accordingly. Using this model makes it easier to gain an impression of whether the tasks, the way of working and the environment are a good fit.
Here are three Models which we have formulated to identify developer typology, aid better case arguments to reach design decisions more quickly and to help optimise development teams:

Design Types Model – sets out to identify why software design is individual and often leads to discussions with colleagues.
Design Cards – great interactive tool using a set of predefined cards used to aid technical discussions by using proven arguments.
Design Matrix – helps you to examine technical problems from all perspectives.

Read more about these interactive Models here.
Ever since the agile movement, technical decisions are increasingly discussed or reviewed within the team. Collective Code Ownership means that everyone is now jointly responsible for the software and as a result, it is important for developers to be able to argue precisely and comprehensively, to be able to put oneself into the motives of your colleagues. With our models, we want to support exactly this and strengthen communication in development teams.
Leaders in Tech
Thanks to those who joined us at our Leaders in Tech: Baden-Württemberg meetup held on 21st June 2018 when Matthias and Christian give a complete overview of the developer typology, as well as the Design Cards and the Design Matrix. As a start, to understand the concepts and the overall context.

Leaders in Tech: Berlin - Scaling an agile organisation

Leaders in Tech Berlin: The Road to Scaling an Agile Organisation

The Road to Scaling an Agile Organisation

Leaders in Tech is a group of senior execs and thought leaders who get together to discuss current tech trends, share knowledge, learn new things and network. We have created thriving local communities in Munich, Stuttgart, Reading, UK, and now we are excited to expand to Berlin.

Our Berlin launch event will be held at VW Digital Labs on 23rd November. Eric Heymann, Vice President Engineering at FlixMobility Tech GmbH (FlixBus), will give an interactive presentation on the journey to a fully independent, agile team.

There are numerous ways to scale a truly agile team. Eric will present his own perspective at the event but here are some considerations that Austin Fraser consultants have encountered recently.
The prevalence of Agile methods in the software industry today is obvious. Most major organisations can tell you about their approaches to implementing the values and principles found in the Agile Manifesto. Published frameworks and methodologies are rapidly maturing, and a wave of associated terminology is part of the modern lexicon. The challenge now is to scale Agile to work in complex settings with larger teams, larger systems, longer timelines, diverse operating environments, and multiple engineering disciplines.

What is scaling?

Many people understand Agile concepts through the illustrations offered by widely adopted methods such as Scrum. These team-focused development processes embody patterns of Agile behaviour and offer concrete implementation examples. If you want to achieve success with Agile methods in large-scale development efforts, you might be tempted to view the challenge as simply a matter of tailoring Scrum to work with larger groups of people. What we are learning from the experiences of major programs undertaken by large businesses is that this view oversimplifies the real work to do.

Below are some key attributes in successfully applying Agile methods. These attributes deserve attention as organisations architect the way their programs will implement Agile processes:

Team size.
Keeping teams small can enable every member of the team to have all the information needed to effectively contribute to the work.
Specialisation of roles.
Limiting the extent of specialisation among team members is something that most Agile proponents strive for. Agile program managers are instead encouraged to move away from a team structure where people focus only on one speciality.
Iteration length.
Iteration length has received much attention among those adopting Agile practices. The challenge of implementing shorter iterations may be one of the biggest challenges in scaling Agile to build larger, more complex software systems.
Synchronised cadence.
Coordinating the contributions of multiple teams to a single product delivery cycle can be hard, no matter what development method you choose. If your teams use different iteration lengths, you will want to look for ways to synchronise the end points of iterations. If teams deliver product features or components (or slices of the architecture) at different times, the cascading effect of rework as integration occurs with each new arrival can lead to a chain of rework-driven cycles that amplify over time. Postponing integration while lagging teams finish their work may lead the early finishing teams to move on to other projects without the benefit of potentially course-correcting feedback from those they’ve just completed.
Release definition.
At scale, most Agile development efforts are structured into a series of releases, each built up from a number of iterations. Typically people set a release to contain four to six iterations, which often fit into a calendar quarter (e.g., four iterations of 3 weeks each, or six iterations of 2 weeks each lead to a 12-week cycle). When scaling Agile methods it is useful to consider synchronising with business cycles (e.g., quarterly reporting requirements or cadence driven by earned value management systems), as budget cycles and other external dependencies may follow these patterns.
Batch size.
In scaling Agile, the long wait for feedback is a bigger problem than the heavy weight of documentation. The priority focus should thus be on working in small batches, prioritised by value, with rapid feedback from the user.
Product owner role.
The product owner role in Scrum is a pivotal element to successful implementation because it provides the development team with a single voice of the business. Even among teams not using Scrum, we are seeing a product owner role – or some variant of it – used to communicate priorities based on value for users.
User role.
Agile development relies on collaboration with the users of the system (or someone who represents the user base) in a way that many other development styles do not. Rather than basing all work on an up-front comprehensive requirements specification, engage the users to help refine the development team’s understanding of what is needed – at a time when that discussion will have the most beneficial effect.

Looking Ahead

While a number of published frameworks are available, each has strengths and weaknesses. The challenge faced by many in the Agile community today is how to scale Agile to succeed in complex settings, with larger teams, larger systems, longer timelines, diverse operating environments, and multiple engineering disciplines.
If you would like to find out more about scaling agile teams, discuss this and other current trends with your peers, and expand your network, then register for the upcoming Leaders in Tech Meetup on Thursday 23rd November: https://www.meetup.com/Leaders-in-Tech-Berlin/events/244144570/