News

29th August 2017 | Berlin
Glug Berlin Panel Discussion Part I

For our digital insight event in July, we mixed up the format a little and started the evening off with a panel discussion - sitting developers next to designers from some of the best agencies and startups in Berlin.

We deep dived into best working practises. Hearing some polarized opinions and great discussion between our panellists. We heard from Orderbird’s CTO Thorsten Dittmar, Product Design Lead at Onefootball, Melanie Daveid, Co-founder and Developer at Diesdas.Digital, Harry Keller and Design Manager at Pivotal Labs, Pilar Serna.

We peeled back the curtain to see how different teams approach developer and design relationships. With the discussion focused on how we work and how we communication through team goals and processes.

Below is the overview from the discussion.

Team Goals

Q. How do you keep the goal of the project front and centre so that design and development can keep a 'common good' as their primary function?

Pilar:

Pivotal labs is unique to Berlin, as we have use co-pairing across our disciplines. We pair PM with PM, designer with designer etc. We also co-pair across discipline, which ensures everyone is working towards the same goals. We have ‘balanced teams’, with no more than 6 people in a team. It keeps the process transparent and ensures clear communication.

Thorsten:

When I joined Orderbird as CTO, we destroyed all the teams and instead created feature teams - structuring the team with the best members to create and build a certain feature. Once the feature we start over and create a new team of mixed disciplines. What I would say is mixing teams is intense, so you quickly have to learn how to work together and learn how to communication.

Communication is the most difficult issue between design and development. But, one thing they both have in common is they find it difficult to communication with other key teams outside of their departments, for example with finance teams. We are still focusing on this as a team.

Harry:

When thinking about team goals, it involves different aspects for teams to successfully work together. There is a individual component and a organisation component. For the individual, they have to be curious beyond their own specialisation. This ensures that they not only think about the practicalities and goals outside their own silo, but that they are constantly helping drive the team goals. Organisationally, there have to be processes to bring teams together. These need to focus on facilitating communication and feedback within the teams. To pull this off, you need a strong product owner to drive the team, I find dev and design when left alone get too caught up in the nitty gritty and sometimes forget the wider goal.

Q. It seems that designers are under pressure to design an exceptional and unique experience and developers are under pressure to produce sites with high performance and little to no errors. Designer’s goals add pressure to developers and vice versa.

How can our goals work together instead of causing pressure on each other?

Melanie:

The most important is that everyone does it’s best. At Onefootball, we have one common goal as we have one product, but it is still difficult to get everyone to the same level of engagement and motivation. I encourage people to do their best and go for their craziest idea. It’s easier to break things down into smaller pieces than grow something that is mediocre. You’ll always have time issues, and shortness of resources but it’s how you are selective that is key.

Harry:

The pressure you outlined show working on a product is never perfect - you never have enough time, never fulfil everything you wanted, never make all stakeholders happy.

We work on a smaller scale and on multiple projects at once. So, we don’t tend to go so deep into product details or work as iteratively as Melanie’s team. But we do work in a similar way by assigning people across disciplines onto a product teams, where they need to collaborate so are aware of the different specialities and their goals. There is no fixed process that works for everything, so it’s always about improvising as you go.

Q. Harry, you mentioned that you are improvising your process as you go. As a new studio - how pick which process to replicate from your individual experiences?

Harry:

At Edenspiekermann we introduced agile into the scrum framework. As a certified scrum master I care about the process. I do think, however, that Scrum is too elaborate for smaller projects. It has the right guiding principles for example, not setting a fixed plan, not making decisions when you know very little, bringing in disciples, working at the same time, making sure people can collaboration and share ideas, talk about stories, user stories, acceptance criteria - knowledge in people’s heads from the viewport of different disciplines, bringing that together into one room. Solving something together.

I would be interested in what Thorsten has to say, seeing as he has worked in the space for so many years.

Thorsten:

We have to view the work in context of world importance, as an industry we put too much pressure on ourselves, and this pressure is detrimental to a team and a business. We don’t save lives or work on big problems. It’s a pressure that comes from over promising, we could make projects easier by being more realistic in what we can achieve. It makes the internal teams lives easier, investor’s lives easier and customer’s lives easier.

I was working in the IT industry before agile, and Kent Beck was one of my employees. So I’ve seen agile evolve and transform across the years. I am even the oldest European Agile Manager. One thing I learnt is it’s about control, so in the beginning agile was about establishing control mechanisms for software developments.

I find scrum too general and broach, such that it won't solve your problems. It just solves problems at a strategic and management level. Therefore, it fixes problems at the wrong level. Most real problems are on the ground floor. All these old fashioned agile process - like feature driven development, extreme programming, crystal clear were made to fix problems for real workers not project management.

It’s like you have a high performance engine but it still has slippy wheels.

Pilar:

Our approach at Pivotal comes from extreme programming, but our way of working isn't scrum or agile. We take parts from all of it. An example of a small alteration is in early standups. We talk about what we learned the previous day, not what we did the previous day. It’s a small change that alters how we think and work as a team.

We work in balance team, adapting the comparing teams to meet user tasks. So it could be Project Manager: Project Manager, or Project Manager: Developer. It’s how we combine the disciplines and ensure we have a common goal as opposed to individual discipline goal.

Melanie:

Listening to Pilar makes me feel like our team is running like a bunch of hooligans! :) We do standups in the morning to say hi, but this allows us to go off for the rest of the day to focus. What worries me is these process discussions are always focused on efficiency. Being fast, doing things better, being under pressure. We forget about the humans behind it all. Not everyone fits into a process and it’s wrong that we try to impose them on people.

I call our process mosh pit - it’s not the easiest thing, and its not a process we can define, but we do have guidelines. The most important things is communication. If you dont have this right, then whatever process you have won’t work.

Usually when things don’t work, you can end up doing a lot of pointing, ‘they didnt do this’, ‘they didn't do that’. But at the end of the day, we are on the same side.

Process

Q. How soon should a developer be engaged to sense-check a design? At design brief? Before it goes to the client?

Harry:

I feel the premise of the question is wrong. It separates the two disciplines so creates a us vs them mentality. In our studio we don’t want to put people in boxes of dev or design, we believe that it is a spectrum as you are always doing multiple roles. If I don’t know what to do, then I talk to my colleague, and they to I. I make design decisions and our designers make development decisions - that’s OK.

Q. How does this approach scale?

Most of the people we work with at Diesdas were from Edenspiekermann, so our processes and how we approach things are influenced by our past experience. The project teams we have with 4/5 people is the same as at Edenspiekermann. I do think as the company gets bigger it’s harder to keep the DNA and culture across the separate teams.

Thorsten:

Before Orderbird, I reorganising German agencies inc, DDB and Aperto. With design and software, it’s like algebra and geometry. It’s the same thing, one written in works, and the other drawn with a line. The whole thing is about the central product, from two different perspectives. For some designers find hard to understand - Programmes have more in common with authors than engineering. But their lives are more complicated than an author as they have two audiences, their colleagues and a processor. As design and development are so similar, they should be able to ‘sense check’ throughout the process, but this isn’t the case.

Interestingly, when I worked at xerox we didn’t have this problem at all, as we didn’t have visual design yet. Our team came up with the first window, so everything was completely new so there was no siloes. We all sat together to solve the issue, and everyone was proud of their colleagues for their skill and what they were working on collectively.

Melanie:

I like Thorsten’s approach, and I understand both sides. From a practicality point, it can come to a personality thing though. Some developers don’t want to to looped in, they just want to come in and get their head down and get things done. There are others who are motivated to check in with the design throughout the process. Which can feel like people are stepping on their toes. Then it’s about accepting other people’s opinions.

In the design team we have designers with very good coding skills, sometimes it limits them as they know what could go wrong, so they stop their process a little earlier. In the best case we just ask the engineers - which again comes back to communication.

READ PART TWO HERE

Discover More