Getting the chance to start from scratch designing a new and effective service, together with a team is something I like best in my job as Service Designer at Liip. Immersing myself in customers’ needs, developing great new ideas, making them tangible with prototypes and getting stimulating feedbacks. These parts are definitely the most inspiring and fun of service design projects.

But the delivery can be a really hard landing.

When working on service design projects, we break open existing silos. We align all the different parts involved in the service to create a better and more efficient service experience. For the delivery of the new service, that can also entail a high degree of complexity. In addition to the hard work of developing concrete solutions, we also have to deal with other challenges. For example, changing the habits and behavior of people or clarifying organizational uncertainties. The search for the right decision-makers and sponsors between the different parts of the company and technical restrictions as further examples. After the thrill of the first creative phases, delivery can mean a really hard landing.

Combining service design with agile methods helps facing the challenges of delivering.

Having worked in both Service Designer and Scrum Master roles in recent years, I tried several ways of combining Service Design with Scrum. My goal is to combine the best of the two ways of working to make this hard landing a little softer. Here are 6 learnings that proved to be very helpful:

1. Use epics and user stories to split the service into more “digestible” pieces.

Everyone probably knows the feeling of not seeing the wood for the trees when you’re standing in front of a wall full of sketches and stickies with ideas. Then it’s very helpful to create a list of epics. In the Scrum world, epics are “a large body of work that can be broken down into a number of smaller stories” (see Atlassian). In Service Design, epics can help dividing the entire service into smaller pieces. This reduces complexity, and allows dealing within specific and limited challenges of a single epic, rather than the whole. Also, the ability to clarify one epic gives good clues where to start with this big mountain of work.

2. Use the service blueprint as the master to create the backlog.

In software projects we often use user story maps to create epics and user stories. In service design projects, the service blueprint is a very powerful alternative to do user story mapping. Service blueprints help mapping and defining all aspects of the future service - from the targeted experience to internal processes, systems, people, tools, etc involved. This contains a lot of useful information for user stories e.g.

• The actors involved, eg. the different types of users (as personas), different staff people, systems, tools, etc.
• The required functions, as each step of a service blueprint usually contains a number of functions that will be written in the different user stories.
• The purpose of the function, as you can read from each part of the blueprint what is triggered by this step.

After a first version of the user story backlog is created, you can reassign the user stories to the service blueprint. Mapping all the written stories to the blueprint is also great to determine if some user stories have been forgotten. This helps a lot to have a better overview of what to do and how it affects the service experience in the end.

3. Do technical spikes in an early stage of the project in order to make your service more feasible.

If the service contains digital parts, it’s highly recommended to face the technical crack nuts in the project as soon as possible. Scrum provides us with the so called technical spikes - a great chance to dive deeper into different possibilities of solving technical issues of the new service. Strictly timeboxed, they allow developers to explore different technical solutions and suggest the one that fits best. Furthermore the team can discuss the consequences and adapt the service. In order to still create a great experience but also find a feasible way of delivering it.

4. Estimate the business value of the different aspects of the service.

In Scrum, we use business value poker to prioritize user stories. A business value is a relative comparison of the value of different user stories. It helps to prioritize the delivery and to show where the most time and money needs to be invested. This process is also very healthy (and tough!) for service ideas. Knowing how much value each part of the service brings to the whole service vision is very valuable and allows the team focus on what really matters.

You can also do business value poker in combination with an adaption of the six thinking hats method, e.g. one of the team estimates the business value in the hat of the user, one in the hat of the top manager interested in return on investment, and one in the hat of the staff member interested in delivering a service experience that doesn’t mean additional work.

5. Deliver a “Minimum Viable Service” (MVS) before taking care of the rest.

Once we have the user story backlog rooted in the service blueprint and we know which story brings most value to our service vision, we start step by step to deliver the service. In agile software projects, the team starts by producing the Minimum Viable Product (MVP). Which means, delivering the smallest amount of features necessary in order to create a valuable, reduced product to users. For services, we are doing the same - creating a “Minimum Viable Service” (MVS). This allows the team developing a first basic version of the service in a short time to market. Delivering results in a early stage of the project is not only motivating the team but also allows continuous learning, adapting and evolving of the service.

6. Work in cross functional, self organised and fully empowered teams.

Scrum teams are self organised and include all skills needed. Without having a hierarchy based system. In a service design setting, many different fields of a company are involved and it’s hard to specify decision makers and people responsible. But that’s the key. Including each and every stakeholder of a whole service in the project is never ending and rarely contributing. Therefore dedicate a small and powerful team of experts involved, give them the full competence to decide and to organise themselves but also the responsibility to deliver value.

Scrum provides great ways to deliver complex service projects.

This blogpost highlights a few aspects of how we manage the challenges of delivering a complex service project. By combining service design with scrum - from the the tools and artifacts to the mindset and the way how teams work together.

Yet, also when following all these aspects, delivering a complex service remains a hard piece of work. But definitely an easier one to handle with the structured and well working delivery methods to bring our ideas to life. Step by step - sprint by sprint.

Talking about improving customer satisfaction, companies often describe the fancy new product they are about to design. The one that is meant to boost customer satisfaction and sales rates like a miracle. But: Is the lack of this new product really the source of unhappy customers?

The biggest obstacles for customer friendliness are (internal) processes.

As a Service Designer at Liip, I do a lot of user research in my projects to find out what makes customers unhappy and how we can solve this. And in most of the cases, I encounter difficult, complicated or nontransparent processes as the biggest pain points. Customers feel, that they have to make too much effort to get the problem solved. Often it doesn’t seem to be clear what to do next. Or they are redirected many times and have to tell the same story over and over again.
These problems typically result from (internal) processes that don’t suit the customers' and employees' needs. And in the meantime they seem to have a big impact on customer satisfaction and the way a customer talks about a company.

Internal processes often seem complex and difficult to change.

In my projects, I experience that many people often don’t dare to touch these processes, although they realise something is not working well. Why? Typically, the problems have many different causes. So a variety of processes and systems are affected and they can’t be assigned to just one department or one person’s responsibility. So who should take care of them? Who feels responsible to change something? This threatens to end up expensive and complicated. Sounds a bit like Pandora’s box, right?

But also the cost of doing nothing is high.

People often forget that doing nothing also is expensive and complicated too. Unhappy customers who spread bad word of mouth or don’t buy again can have a big impact on a company’s revenues. Also, handling customer enquiries costs a lot of money, especially when internal processes to handle them are complicated too. And last but not least - the impact of unhappy employees on a company’s performance is not to be underestimated.

Align the customer experience with what happens behind the scenes.

So in order to improve customer satisfaction, it’s time to pay attention to user friendly and efficient services. It’s about aligning the customer experience with what happens behind the scenes - from internal processes to tools and systems.

But how to get there? And how to not get lost in complexity, especially when the service touches many different processes, systems and departments? Service Design provides us a lot of useful answers to these questions.

How to design user friendly and efficient services - 9 steps

1. Have a clear mission:
   At the beginning of every project, I work on creating a clear mission and a common understanding of where to go together with the team - like a lighthouse that helps to keep orientation on the way.
2. Understand the problem in all its aspects before working on the solution:
   In my opinion, the most important part of creating useful new services is to have a clear and overall understanding of where exactly the issues are - from the user’s needs to the company’s goals and problems. And very important: based on data, not assumptions.
3. Start with the user’s needs, not what tools allow you.
4. Focus in Ideation:
   It requires some discipline to not ideate on whatever seems to be cool. But clearly focusing on solving exactly the problems the team encountered is crucial to not get lost in complexity.
5. Prototype ideas already at early stages:
   The clear common understanding of what the idea consists of is extremely valuable.
6. Test continuously:
   The more feedback we get, the better. It helps to discover if we are on the right or wrong way at an early stage.
7. Implement step by step:
   Implementing one idea after the other helps to get things done and not get lost in too many measures we can’t cope with. Improving services is often about continuously implementing a bunch of measures in order to fulfill one big longterm mission. Agile methods as Scrum perfectly support this way of working during implementation.
8. Think big. But start small:
   Sometimes also small changes are promising.
9. Evolve:
   Projects are never done with the GoLive. They just enter a new phase: the one where our work gets really tested by the mass of users. Every new learning helps us to continuously improve the service.

What are your experiences with designing better services and processes? What was hard, what worked well? Let me know by leaving a comment.

More efficiency in machining
Contracts for the more extensive calculators lead directly to a close in the insurance system and thus to a reduction in the workload of Helvetia employees. An automatic credit check is also carried out before the transaction is concluded. Insurance customers can take out insurance around the clock and at the same time the administrative effort has been minimized.

Latest technology
With Angular 4, the latest technologies were used and the product was brought up to date. In order to ensure the high quality during development and also during operation, the implementation of a test automation with Angular 4 took place parallel to the implementation.
The pattern library created by Namics was used as a basis for the components.

With one team to success
To reach the project goal together and agile was the focus of the cooperation. Helvetia and Liip worked in one Scrum team, where company affiliation was less important than the skills of the individuals. We worked together on the project's success. Thus, the first few months resulted in a cooperation lasting over a year. We thank Helvetia for the very pleasant and uncomplicated cooperation!

Calculation of private customer insurance: https://www.helvetia.com/ch/web/de/privatkunden/wohnen-und-eigentum/wohnen/hausratversicherung/praemie-berechnen.html/offer

Trois ans après cette discussion, leur nouvelle plateforme au nom de code “QoQa4” est désormais en ligne après de nombreux sprints, coups de gueule, montées en stress, sans oublier les fondues et choucroutes au Café Romand.
En voyant le chemin parcouru niveau méthodologie agile après plus de 70 sprints, je me suis dis que ça serait intéressant d’interviewer Joann pour avoir son retour d’expérience concret sur l’Agilité et Scrum, quelques années après avoir écrit sa première User Story.

Bienvenue à Joann Dobler, celui qui a introduit Scrum et ses outils assez carrés dans un environnement QoQasien où on pense que les règles sont plutôt faites pour être enfreintes !

Pourquoi toi, Joann, tu as pensé à l'agilité pour QoQa fin 2014 ? Quelles conditions t'ont amené à considérer cette méthodologie ?
En fait, je connaissais déjà l'agilité, et je savais qu’au vu de l'ampleur du projet et donc au temps de sa mise en place, nos priorités business et technologiques allaient évoluer. On devait donc choisir une méthode qui nous permette de nous adapter. De plus, pour une question d’état d’esprit, de partage, et de dynamisme au sein de l'équipe, on devait s’adapter, et donc dynamiser notre façon de travailler.

En résumé : il nous fallait un truc pour mieux nous adapter au business, faire face aux changements de priorités, offrir de la transparence, et amener un réel échange au sein de l’équipe.

Quelle méthodologie de gestion de projet utilisiez-vous avant chez QoQa ?
On utilisait une méthode traditionnelle, genre un agenda par étapes et jalons. Une fois les maquettes graphiques terminées, on débutait avec l’HTML… Pour les petits projets, ça pouvait jouer, mais dès que c’était plus conséquent, on finissait avec des délais jamais tenus, aucune flexibilité, et surtout un gros manque de dynamisme avec les équipes.
Si quelqu’un peut m’assurer un délai d’un gros projet un an à l’avance, je l’invite pour une bouffe afin qu’il m’explique sa technique — no joke !

Pourquoi avoir choisi Liip pour vous accompagner plutôt qu’un coach agile ? Autrement dit, quelle stratégie de montée en compétence recommanderais-tu à quelqu’un qui veut se lancer pour de bon dans Scrum et l’agilité ?
J'avais besoin d'experts dans le domaine pour nous accompagner à l'implémenter.
Je voulais une agence qui a de la bouteille, qui vit agile et qui connaît les avantages et les inconvénients de cette méthode. Je cherchais à ce qu’on se trouve en totale immersion.
Par dessus tout, je voulais bosser avec une agence “no-bullshit”. Du coup j’ai appelé Liip.

Création du backlog QoQa4 de 300+ stories

Comment se sont passées les premières semaines avec Scrum ?
Au début c’était assez excitant, on avait nos post-its, notre board Jira, on faisait nos rétros/reviews et on pouvait se la raconter en interne : “Regardez on arrive avec une méthode révolutionnaire !” Mais c’est seulement après trois mois qu’on a rencontré nos premiers véritables soucis ; c’est une fois que le projet est 100% agile que tu comprends ce que veut dire agile.

Combien de sprints a-t-il fallu pour que tu te rendes compte de l’impact et de la réelle valeur ajoutée de Scrum ?
C’est difficile à dire...je dirais aux alentours de 4 sprints (i.e. 8 semaines) pour la communication et l’échange entre les équipes. Par contre bien plus en terme projet, je dirais environ une dizaine de sprints de deux semaines chacun.
Les premiers mois furent très difficiles car on n’avait pas compris ce que Scrum et l’agilité demandaient, à savoir faire preuve d’une énorme rigueur, et adopter un vrai changement philosophique (vs. “simplement” faire des sprints).
Concrètement, on a du beaucoup plus échanger, se dire les choses de manière transparente. La hiérarchie aussi en prend un coup.

Comment aurais-tu géré ces premières semaines si tu étais resté avec ton ancien modèle de gestion de projet ?
C’est simple, je n’aurais tout simplement plus de job ;)
J’aurais fait un magnifique planning, j’aurais découpé mes tâches, et j’aurais attribué mes tickets. Du coup, peu d’échanges, pas de mise à profit des compétences de tous les membres de l’équipe. Je pense sincèrement que cette méthode nous a permis d’écouter nos utilisateurs, d’analyser leurs vrais besoins, et de s’adapter au fur et à mesure.

Premier meeting d'estimation Scrum

Comment s’est passé l’adoption de l’Agilité/Scrum en interne ?
Au début, c’était super facile car ça paraissait tendance. Mais c’est quand les premiers problèmes surviennent qu’on se rend compte de la difficulté d’intégrer cette méthodologie. Pourquoi ? Car par exemple, lors de nos premières retros/reviews, on a dû se parler en toute transparence ; cela paraît ridicule mais ça change tout.
On n’avait plus de titres mais des rôles à jouer, alors la hiérarchie est rapidement mise de côté au profit de l’échange. On est passés par des périodes difficiles car le projet sur lequel on a démarré est simplement le plus gros de projet de QoQa de ces dix dernières années. Pression, choix à faire, décisions à prendre, implication de plusieurs départements, merci à la méthode qui nous a obligés à rester calme, à partager nos problèmes, et à trouver des solutions ensemble.
Et je dois dire qu’on a eu la GRANDE chance d’être soutenu par la Direction, enfin par la Loutre in Chief qui nous a fait confiance.

Je dois avouer que les débuts furent plus que difficiles, j’avais la sensation de griller du cash en meeting. Le rôle du PO n’est pas simple car on a le budget en tête et un planning que le business attend avec impatience. Alors moi qui suis un impulsif, j’ai vraiment eu la sensation de bosser avec une méthode à la mode. Mais là encore, grâce au soutien, j’y ai cru, j’ai changé ma façon de penser, et aujourd’hui j’en suis heureux. Il faut laisser le temps que tout se mette en place, faire confiance, garder la rigueur, et se faire épauler.

Si tu ne devais citer qu’une valeur ajoutée que Scrum a apporté à QoQa dans son ensemble, qu’est-ce que ça serait ?
La COMMUNICATION !
Sans déc, c’est incroyable les silos que ça a fait péter. Même les gars de la logistique ont adopté des outils de Scrum avec des meetings courts de synchronisation chaque matin

L'équipe cross-fonctionnelle QoQa-Liip — incluant développeurs, POs, et designers

Si tu ne devais citer qu’une valeur ajoutée que Scrum a apporté à toi le PO, qu’est-ce que ça serait ?
Apprendre à couper dans le gras ! Autrement dit savoir mettre des priorités et ne pas partir la tête dans le guidon en se disant que tout est indispensable.

Qu’est-ce que tu penses de la qualité délivrée par un projet en mode agile (i.e. la correspondance entre besoins utilisateurs et le produit développé) comparé à un projet en mode “waterfall” ?
Alors c’est tout simplement différent. Avant c’était moi le pro du web et je savais mieux ce dont l’utilisateur avait besoin. Maintenant, c’est l’utilisateur qui dicte mon métier. On y va étape par étape, on commence par le minimum, on analyse, on implique tous les acteurs. Toutes ces discussions font que tu économies du temps de production car tu testes, tu récoltes des infos du terrain, et seulement après tu construis par dessus. C’est fini la belle époque où on se disait “Je sais une année avant ce qu’il te faudra”.

Est-ce que Scrum a solutionné tous tes problèmes ? Si non, qu’est-ce que ça ne couvre pas ?
J’ai envie de dire OUI — ce que je ne disais pas il y a deux ans — même si on a encore beaucoup à expérimenter. Ce qui est vraiment cool c’est qu’on a un scénario agréable avec un gros projet en interne sur lequel on peut réellement prendre le temps d’itérer, et non juste se contenter de lancer des fonctionnalités l’une à la suite de l’autre.

Combien de sprints avez-vous fait jusqu’à maintenant ?
69 ;)

Rétrospectivement (on est agile après tout), quelles sont les raisons qui font qu’après une soixantaine de sprints vous n’étiez toujours pas en production au printemps dernier ? Et qu’est-ce que tu ferais différemment aujourd’hui avec les connaissances que tu as acquises ?
On aurait dû couper dans le gras. On a fait la pire des erreurs de vouloir tout, tout de suite, et en mieux qu’avant.

Quid de la visibilité ? Mieux ? Moins bonne ? Niveau planning ?
Ce fut mon principal problème quand on a commencé l’intégration de l’agilité, avec tout le monde qui venait me dire “Alors on lance quand ces nouvelles plateformes ?”
J’ai dû geler le business pendant plus de deux ans, donc la question était tout à fait prévisible et je devais pouvoir y répondre. Mais au début, je n’en avais aucune idée avec notre backlog long comme le bras.
Grâce à Liip et leur méthodologie, j’ai pu finalement avoir ma réponse après ce qu’ils appellent une “speed estim”. En gros, on a pris les 300+ User Stories du backlog, et on les a estimé en moins de 3h30. C’était incroyable, j’avais enfin de la visibilité pour moi et les parties prenantes au projet.
Par contre, je me suis pris une grosse claque une fois qu’on a eu la somme totale de Story Points. Si je me fiais au estimation, on en avait pour deux fois plus de temps que notre roadmap initiale sur une année… Mais j’ai fini par comprendre qu’encore une fois je voyais trop gros, et que même si ça faisait mal, il fallait encore plus couper dans le gras.

Le meeting de review Scrum amène de la visibilité sur le travail réalisé, et ce chaque deux semaines

Quid de la communication au management/reporting en interne ? Toujours Gantt ?
C’est quoi un Gantt !!? Ca répond à ta question ?

Sinon, vous avez eu des changements au niveau scope/business en cours de projet ? Comment les as-tu gérés ?
Yes complètement ! Je dirais que quelques mois avant la mise en production, on a dû faire des choix car il fallait bien se lancer un jour. La méthode permet une telle transparence que ces choix furent pris de manière vraiment cool. Je pense qu’on pourrait encore être en train de développer à l’heure qu’il est, et encore pour quelques années au vu de tout ce qu’on veut faire. Mais non, on s’est lancés à l’eau. Comment ? En gérant nos priorités et qui de mieux placé que nos QoQasiens pour nous dire ce qui leur manquent ? Du coup, pas mal de fonctionnalités abandonnées dans une première version, et on a tellement bien fait !

Niveau priorités des parties prenantes dans le projet, comment as-tu géré ça ? Intégration des besoins du chef, des départements ?
Après avoir défini les grandes lignes du scope de la V1 du projet, on a impliqué tous les utilisateurs par département dans les choix, les priorités, le design, et surtout les testing. Les grands axes eux furent validés lors de nos COPIL. La méthode permet une vision très détaillée de l’avancement du projet, ce qui facilite la prise de décision.
Mais c’est important de souligner qu’après environ 6 mois de projet, on était totalement perdus... On sera prêts dans un an, deux an, trois ans… Aucune idée et je peux vous avouer que je faisais pas le malin, et c’est là qu’il faut faire confiance à la méthode, et rassurer les équipes avec un peu de bullshit…
De nouveau : speed estim, couper dans le gras, se faire accompagner, et elle est belle :)

Quid de la rigueur de l’agilité (oui oui l’agilité c’est beaucoup de rigueur malgré le nom !) chez QoQa qui est plutôt freestyle d’habitude ?
C’est ce qu’on n’avait pas compris au départ : il faut de la rigueur sinon c’est mort. Pour moi qui suis un créatif, la rigueur fut difficile à accepter. Mais maintenant je peux le dire, cette rigueur nous rend plus créatif !!! Mais il faut le vivre pour comprendre.

Pause ping-pong, ou comment allier rigueur et freestyle !

Un mot sur les cérémonies Scrum de début de sprint, estim et planning ?
C’est le début d’un projet ou d’une nouvelle itération, alors c’est cool et motivant.
Côté estim, on ne parle plus d’heures de travail, mais de complexité. Ca parait fou mais c’est juste top — ce qui me paraissait irréaliste il y a encore deux ans.

Un mot sur les cérémonies Scrum de fin de sprint, review et rétrospective ?
C’est la fin du projet donc ça dépend du résultat, mais normalement c’est top car il n’y a jamais de surprises. Si surprises, c’est qu’il y a eu une mauvaise communication durant le sprint. C’est un vrai moment d’échanges et de partage. On se dit les choses et on essaie de les améliorer ; c’est dingue mais ça marche ! Au début quand je recevais des post-its rouge, j’avais de la peine à l'accepter... mais aujourd’hui j’adore, on s’améliore sans cesse.

Le meeting de rétrospective Scrum, un élément crucial pour l'amélioration continue

Et le grooming en cours de sprint ? Vous l’utilisez ? Pourquoi ?
Le grooming est essentiel, il peut faire gagner tellement de temps comme on implique l’équipe très tôt dans le processus de création des User Stories. On détaille et on réfléchit ensemble, c’est très créatif. S’il y a un doute, alors la story n’est pas claire et ça nous pousse à être plus précis, et donc éviter les surprises. La boucle est bouclée.

Question finale: Si aujourd’hui tu devais recommencer un projet (pro ou perso d’ailleurs), tu t’y prendrais comment ?
Je débuterai par un Gantt évidemment ;)

Encore un grand merci à Joann d'avoir pris le temps de partager son retour d'expérience.
Chez Liip, ce qu'on retient le plus de cette aventure, c'est que "couper dans le gras" est l'une des clés de la réussite d'un projet.
On se réjouit de continuer à collaborer avec l'équipe des loutres pour échanger sur leurs expérimentations de Scrum.

Why government can[not] build digital services iteratively

I wrote a thesis on the topic, and tried to condense my findings in a 20 minutes’ presentation as a PDF on speakerdeck, and as a Google-Presentation, which includes my speaker notes, too.

(Old graphic, published until 5 January 2018.)

My thesis got accepted, but I will invest some time until the end of 2017 to revise it, before it is going to be published in early 2018. I will add it to this blogpost, when it's ready.

What is your experience with iterating in government?

I am thankful for any feedback on the topic. Please get in contact with me via the following channels:

• @andreasamsler
• andreas.amsler@liip.ch

When I signed up for ALE earlier this year, all I knew about this event was the format. In fact, at Liip we are having an un-conference every year – an intense time of exchanges across our five offices – and I already loved the way it enables freedom and co-creation.

Furthermore, I had been practicing the Scrum Master role for three years, mostly learning by doing, and I felt it was time for me to go « drink from the well ». I needed inspiration, renewed energy, and the least I can say is that I got more than what I was hoping for.

Each of us contributed to create the content

What makes an un-conference work so well (when well organized and facilitated of course) is the « Open Space » format it relies on. In a nutshell:

• The audience literally creates the content. At the beginning of each day, dozens of participants come to the front and pitch their ideas for sessions. Many rooms and spaces are made available in parallel, which allows the creation of a dynamic « programme wall ». Through each the day, every attendee can then pick workshops according to his own interests.
• Everyone is empowered to make use of the « Law of Two Feet », that is: if you ever feel you do not contribute to or learn from the session you’re in, you are free and encouraged to walk out (while minimizing disturbance, that goes without saying) and find another session that you could benefit more to and from.

It all creates a very spontaneous and lively atmosphere. You can really tell that the un-conference concept was invented by people who felt that the best moment in conferences was the coffee breaks. So much happens on-the-spot. And you really have no idea where a day will take you.

There was so much to learn from!

The event was packed with very interesting sessions. Here’s a sample:

FeatureBan with Markus Wissekal

As Scrum Master of a support-oriented team, where operational flow is especially crucial, I knew I had to attend this one. Markus Wissekal, Scrum & Kanban coach, gave us a thorough refresher on the theory of Kanban, with examples from a real-life system, followed by a hands-on game to get a feel of how it works, and most importantly why it works that way. Attendees also got a chance to ask practical questions. Some of them received very strict answers, for example: « Should we keep in a column the tasks that have been postponed by the client? » « No! Everything that can not be delivered is waste, and it pollutes the system. »

Appreciative Agile with Susanne Taylor

Suzanne Taylor works with teams to help them maximize flow and foster collaboration. Her research led her to consider a possible bridge between Appreciative Inquiry and the daily practice of Agility. The core of Appreciative Inquiry is to see value in anything that may happen (including failure), to build upon what already works, and start any discussion upon a « positive bias », that is: suspend disbelief at least until an idea has received enough time to be fully expressed. Isn’t that we all do as Scrum Masters when we facilitate a retrospective? Indeed, if as agile practitioners we do not believe in the possibility of developing and improving the positive things that are already there, how can we expect any success when leading a team in a Continuous Improvement process?

Vipassana with Pia Heinze

Agile practitioners are inherently change agents, and one can ask how you can change your (work) environment if you can not change your own self. That’s one of the reasons why Pia Heinze embarked on a very particular journey to get to know her own mental mechanisms, and change her relationship with her thoughts and emotions. Yes, we are talking about meditation. Ten days of it, cut off from any external stimulus. Even eye contact was to be avoided. Sitting down, eyes closed for essentially 10 days, Pia thought many times she was going crazy. But at the end of the process, she got to touch the notion of equanimity, that is: observe what happens without rushing to categorize it as either positive or negative (what we are trained to do since youth). Pia concludes: « I am even more emotional than before, but I am less reactive. ». She will take the Vipassa once again this year, bringing a friend along for the journey. «The brain? A great bullshit machine!».

A powerful conference that encouraged me to step out of my comfort zone

I also had loads of fun. The feeling of safety established by Silvana, the conference facilitator, was so powerful that there seemed to be no limit in trying things. The craziest was « Powerpoint Karaoke ». Yes, it is exactly what it seems and you can be scared. Unless you feel comfortable enough with the 40 persons who stayed after the day had wrapped for this unlikely session. I had to kick myself a bit to step up but that was a very liberating exercise. I improvised over 10 slides of 20 seconds each of a random deck found on the Internets. I had tears of laughter while watching others do the same.

Even more than the technique of practicing agility, these three days reminded me of the central importance of the relationship you share with your team. I got to experience how strangers become friends, thanks to safety, trust and listening. Those are the foundations. From that point on, it’s a kind of magic.

... By the way, the 2018 edition will take place in Zürich and my colleagues Christoph, Daniel and Leo are amongst the organizing team. Will I see you there?

How to be open to innovation?

You have to be open to new challenges, which is difficult even close to impossible if you are stressed out or under tight deadlines for example. During my first year at Liip (2016), I undertook many projects that had started before I had arrived. As a result, I had little time for planning or strategies, I undertook what was already started. During this first year, everything was new, I was in the turmoil of an event, or in a middle of a project, my whole energy was focused on current tasks.

Before Christmas 2016, my knowledge of the enterprise and the field had exponentially expanded. It allowed me to grasp the necessary bigger picture of my enterprise's needs and challenges. Simultaneously, many projects came to an end, as a result, I was not under tight deadlines. In other words, I was open to new challenges and ideas. I had cognitive capacity to take on new challenges. When Kevin, a colleague I barely knew, approached me, I welcomed his project with an open mind.

Sorry, we have no time to innovate!

An idea that takes 30 minutes to explain but a clear call to action

I do not recall the exact situation of our first actual discussion. We were probably in the open space we call arena. He most probably caught me on my way to the cafeteria.

Note to self: grab people when on their way to the cafeteria, when they are neither in a hurry for a meeting, nor in deep concentration.

Sorry Kevin, the first time you explained I did not understand your idea. It took about 30 minutes of explanation for me to understand that it was about learning, innovation, banking and compliance. It probably did not help that I had no prior knowledge of these fields.

At this point, what Kevin expected was clear ‘come to a workshop'. As I had no urgent deadlines at the time, I accepted. I assumed that I would understand the idea at the some point.

The importance of the team and the setting

At Liip, we have the possibility to undertake innovation projects when we see a business opportunity. Nothing forces us to join or undertake one. I could have decided to perform other tasks that I saw more fitting

Why did I accept to join the workshop? Three important factors simultaneously played a role there:

• Firstly, I had an open mind, I was cognitively open to something new.
• The second thing that convinced me then was Kevin's enthusiasm: he had a vision and he convinced me. I saw potential in this project.
• Thirdly, I felt valued and trusted that my competences were needed. Honestly, this is flattering and energizing. Who is not appealed to have the possibility to make an impact?

Additionnally, I also not only got along, but liked the other colleagues invited to the workshop. In such an innovation process, trust and kindness are necessary. The team is meant to go through uncertainties. Though the vision is clear, the way to reach it is not. The composition of the team is important and this fact should not be underestimated.

Note to self: notice the importance of a vision in the very first step of an innovation project. Someone has to have an idea, and has to be able to share this vision with others to onboard them.

The next steps: the initial workshop

As planned by Kevin, the next step was to organise a workshop, where we would meet and test the idea. I expect it was a vulnerable moment for him. As long as you think something for yourself and plan it in your head, it is all fine. The day you open your mouth, it is for the worse or the better. After this workshop we could have all backed off and turned to other projects. It was a turning point.

To conclude, you guessed already?

It turned out well for Kevin's idea, in the sense that we shared his enthusiasm and we saw business potential in his idea. In other words, the story was just starting. At this very early stage of the innovation process, my ability to be open-minded to something completely new and the fact that we saw business potential in the idea mattered most . The fact that Liip provides an environnement prone to innovation is also highly relevant. As a team, we know, we are supported to dedicate time to investigate new opportunities.

And yes, I take notes to myself about what a leader with a vision is, because I think everybody is someone's leader and someone's follower. It is neither good, nor bad, it is just a role, where you have to play your best part. I am learning good practices to be both.

When I joined Liip in 2010, as one of the first “Romand”, I had the task to expand Liip's activities to west (french speaking) Switzerland, with the great challenge of opening a new office and creating a new team there. New horizons, new persons, an avidity for advancing towards the unknown… the perfect challenge for the entrepreneur-type-of-me :)

After a challenge, follows another

Fast forward a few years later – mid 2015 – the Lausanne office counts 20 Liipers and runs well – mostly without my help anymore. This is surely due to our efforts to bring the company into self-management, added to the fantastic team of Lausanne Liipers that joined me in our everlasting commitment to build the best products for our clients.

Once this challenge was achieved, it felt to me (personally) like the end of a chapter. Moreover, with the arrival of Holacracy as our new governance framework, I was, as a Partner (then “Liip manager”) forced to adapt in that changing organization. I felt something very odd: for the first time since I joined Liip, my motivation diminished.

At the same time, a family dream had come up : getting out of the daily routine, leaving everything else behind to “slow down” and travel the world, just the four of us (our 2 boys, my wife and myself).

At first, realizing such a dream felt totally incompatible with the traditional work-school-life of the typical swiss family that we are… and then we started to think outside that box. And what if… after all?

The need for faith in the unknown

The preparation of our project took about a year, elaborating solutions as we saw the problems pop up, one after another. Finding renters for our apartment, selling our stuff, buying a motorhome, and also… I had to leave Liip, the best company in the world!!

We were confronted by many uncertainties during that path : What countries are we going to visit? Is it sufficiently safe to travel with small children in less developed countries, and for such a long time? Is our planned budget gonna be enough?

No chance to process all our fears at once… we simply had to LET GO. Follow our vision, and analyse and adapt along the way.

Our campervan was our home during one year.

Wait… doesn't that sound like Agile projects?

Those of you familiar to Agile project management will notice some similarities with the initial phases of a typical innovation project :

1. Very early excitement (usually during initial UX Strategy workshops) : putting a vision on paper, thinking big without restrictions
2. Coming back to reality : breaking that all down to actual user stories and tasks and noticing that we will never manage to realize all that we want to do with the planned budget and time our disposal

Yet those are hard truths : budget (usually) remains fixed, as well as the project calendar. So it was for our worldtour travel.

Finally, here we go! On the 1st of April 2016, we left Switzerland. A big leap of faith… towards something that we prepared carefully but can't know in advance all details… just as in a agile project! ;-)

This blog post is the first one of a series on my experience in sabbatical leave. Stay tuned for more!

Your Website is not Responsive

That's usually one of the key indicators for you to think about a website redesign. Did you know that on an average day 80% of internet users use a smartphone to surf the web? That's almost 15% more mobile than desktop usage. Mobile first is thus not just a buzzword, it is a reality that is being confirmed on a statistical basis every day. [1]

Your Website Loads too Slowly

We've all had experiences with slow websites. They're pretty annoying and not fun to use. Actually, 40% of a website's users will leave a page if it takes more than three seconds for it to load? Also, data shows this is bad on a computer but on a mobile device it is even worse. Consider this: Key engagement metrics such as average time on site, pages per visit, or bounce rate already lag behind on smartphone usage. If it now also takes longer to load, you can be almost certain to lose your valuable visits and your conversion rate will take a hit. [2]

You Are Experiencing a High Bounce Rate

That's certainly not a good sign and you should definitely do something about it. Essentially, what it means is that you manage to get people to visit your website and they immediately decide to leave again. That's pretty bad, right? Well, the good news is: if you do collect your data well the internet will also give you some answers about what to improve. It does not necessarily tell you to redo everything but you will have some strong arguments up your sleeve on where to invest your budget next and why. In case you're missing that valuable information, I would strongly advise you to consult with an analytics expert. He will then also know, if a redesign could be an option for you to consider. [3]

You Have Expensive License Costs From a Closed Source Provider

If you do use closed source software, you know what I am talking about: such a model comes attached with expensive license costs. And that's just the cost for you to be able to use the software, development for your system will additionally strain your budget. With open source systems such as Drupal, that's for free – no strings attached. Just like with a closed source system you will also get an incredibly powerful system, enterprise-ready security standards and the help of a community with thousands of developers. It's pretty simple math: add the cost of your closed source system over the years and start investing it in software that will more efficiently generate business value for you.

Your Current Website Setup Is Hard and Expensive to Maintain

It's absolutely normal that your content structure and the requirements towards its digital representation changes over time. As your business advances so will your core digital tools and therefore the requirements to connect their data pools to your business' online representation via clever interfaces. If you spend too little time cultivating and evolving your system this process will even speed up. In such situations, this often results in steep investments towards an old system or it will be getting more difficult to add the right content where, how and when it needs to be there for your online customer. Most definitely, that's just one symptom that is then supplemented by the frustrating experience for your administrators that cultivate your platform – no wonder that content quality will suffer. Does this sound familiar? Then a redesign might be the way out of this vicious cycle.

There are certainly many other influencing factors that might trigger you to think about redesigning your website. In my experience and in almost any case, it boils down to the question of what your online customers are expecting from you as well as from your online business. If you do understand them well this can much more easily be translated in technical and visual requirements. In turn, you get to better understand the ROI and the question of when and if to redesign your website can be answered much more reliably.

If you do find yourself in a position where two or more of the above situations are a match, I would strongly suggest you to bring together your key stakeholders to a roundtable and define a strategy to tackle this situation. It's as simple as that, there is no second chance for the first impression.

[1] storage.googleapis.com/think/docs/twg-how-people-use-their-devices-2016.pdf

[2] thinkwithgoogle.com/articles/mobile-page-speed-load-time.html

[3] thinkwithgoogle.com/interviews/winning-the-zero-moment-of-truth-measure-success.html

Schon nach kurzer Zeit klingelt Ihr Telefon und der Product Owner einer der angeschriebenen Agenturen möchte mehr Informationen.

Ob es denn einen Pitch gebe und dafür bereits Mockups erstellt werden sollten? Ob Sie es sich vorstellen könnten das Projekt agil mit Scrum umzusetzen? Die Agentur habe sich schon einige Gedanken gemacht und würde gerne bei einem ersten Gespräch über den möglichen Scope sprechen. Ausserdem sei es spannend, dass Sie sich bereits Gedanken zum Content gemacht hätten. Ja den werden Sie im Back-End des CMS selbstverständlich problemlos einpflegen können. Für wann denn der GoLive geplant sei?

Sie verstehen nur Bahnhof? Keine Sorge bei Liip können wir uns auch sehr verständlich ausdrücken. Sollten Sie bei unserem ersten Gespräch bereits mit uns fachsimpeln wollen, hilft Ihnen dieses kleine Wörterbuch vielleicht etwas auf die Sprünge:

Das Wörterbuch

Pitch

Aussprache: [pɪtʃ]

Bei einem Pitch handelt es sich um einen Wettbewerb zwischen Agenturen, bei welchem sich diese um ein bestimmtes Projekt bzw. das Entwicklungsetat eines Unternehmens bemühen. In der Regel gehört zu einem Pitch eine Offerte und die Präsentation dieser.

Agile Entwicklung

Aussprache: [ˈaːd͜ʃile ɛntˈvɪklʊŋ]

Im Gegensatz zu vielen klassischen Software-Entwicklungsverfahren konzentriert sich das agile Vorgehen auf die für ein Ziel benötigten wesentlichen Bestandteile. Konkret beschränkt dieser Ansatz festgeschriebene Regeln innerhalb eines Projekts auf ein Minimum und erhöht die Flexibilität. Das bedeutet ebenfalls, es wird wenn immer möglich auf Bürokratie verzichtet und iterativ entwickelt. Ein Ziel soll damit nicht mit einem grossen Wurf sondern mit vielen kleinen Zwischenversionen erreicht werden. So werden auch sich im Laufe eines Projekts verändernde Anforderungen respektiert.

Scrum

Aussprache: [skrʌm]

Scrum ist ein Modell für agiles Vorgehen zum Projekt- und Produktemanagement. Es wird oft im Softwarebereich eingesetzt. Scrum geht davon aus, dass (Software-)Projekte aufgrund ihrer Komplexität im Voraus nicht im Detail planbar sind.

Der für das Projekt ausgearbeitete und priorisierte Projektplan (=Product Backlog) besteht aus einzelnen Funktionsbeschreibungen (=User Stories). Er wird während der gesamten Dauer des Projekts verfeinert und an die aktuellsten Erkenntnisse angepasst. Die Entwicklungsinkremente werden in Scrum “Sprint” genannt, an welchem Abschluss jeweils ein lauffähiges (Teil-)system steht. Liip setzt bei seinen Projekten ausschliesslich auf agile Vorgehensmodelle wie Scrum.

Content

Aussprache: [kənˈtent]

Mit Content sind im Web-Bereich alle Inhalte gemeint: Text, Bild, Ton, Videos und Animationen. Content ist ein integraler Bestandteil des Erlebnisses für den Benutzer einer Website. Das heisst er hat nicht nur informativen und inhaltlichen Charakter, sondern trägt auch dazu bei, wie ein Nutzer mit der Seite interagiert und die Inhalte bei seinem Besuch erfährt (z.B. wie verhält sich ein Link auf der Website?).

Content Management System / CMS

Aussprache: [kənˈtent-mænɪdʒmənt]

Auch: Web Content Management System / Web-CMS

Das Content Management System, zu deutsch Inhaltsverwaltungssystem. Dabei handelt es sich um eine Software, die im Web-Umfeld zum gemeinschaftlichen Erstellen, Berarbeiten und Organisieren von Inhalten dient (Back-End). In der Regel bietet ein CMS auch eine Art Publishing-System, welches die visuelle Ausgabe der Inhalte unterstützt (Front-End). Bekannte Beispiele für CMS im Web-Bereich sind WordPress, Drupal oder Joomla!

Back-End und Front-End

Aussprache: [ˌbækˈend] und [frʌnt end]

Die beiden Begriffe Back-End und Front-End bezeichnen die zwei Ebenen der Informationsdarstellung. Dabei ist in der Regel das Front-End näher am Benutzer, das Back-End näher am System. Im Falle eines Web-CMS werden im Back-End die verschiedenen Inhalte gepflegt und organisiert, so dass diese auf eine intelligente Weise für den Nutzer im Front-End als visuelle und grafisch aufbereitete Version dargestellt werden.

Wireframe

Aussprache: [ˈwaɪə.freɪm]

Ein Wireframe ist ein sehr einfach gehaltener, skizzenartiger Entwurf der visuellen Darstellung einer Webseite. Dabei geht es primär darum, die Anordnung der verschiedenen Elemente und der damit einhergehenden Benutzerführung effizient zu klären. Mit dieser Technik wird zum Beispiel eruiert wie eine Navigation aussehen oder wie die Startseite aufgebaut sein soll. Die visuelle Gestaltung der Website ist nicht Teil des Wireframes. In diesem Zusammenhang spricht man von einem Mock-up.

Mock-up

Aussprache: [ˈmɒk.ʌp]

Mock-ups sind die visuelle Ausgestaltung einzelner Webseiten in einem Grafikprogramm. Diese klären Punkte wie Farben, Schriften, Formen oder Abstände von allen Elementen einer Website und dienen als Grundlage für die Entwicklung des Front-End.

Product Owner

Aussprache: [ˈprɒd.ʌkt ˈəʊ.nər]

Der Product Owner (PO) ist eine von insgesamt sechs Rollen, welche in Scrum auftreten. Seine Aufgabe ist mit derjenigen eines Projektleiters verwandt. Neben der Projekt-Terminierung trägt der PO die Verantwortung für die Konzeption und die Projektkosten. Im weiteren definiert der PO die Richtung der Produktentwicklung mit Hilfe des Product Backlogs (=eine priorisierte Funktionalitätenliste). Der Product Owner nimmt die vom Team gelieferte Leistung hinsichtlich der im voraus definierten Abnahmekriterien ab.

Scope

Aussprache: [skəʊp]

Der Scope steht für den Inhalt bzw. Umfang eines Projektinkrements.

Ihre Begriffe fürs Wörterbuch?

Dies sind sicherlich einige der geläufigsgten Begriffe welche mir im Agentur-Alltag begegnen. Sie denken ein wichtiges Wort fehlt? Das wäre doch ein guter Grund, für eine Version 2 des Wörterbuches für Web-Agenturen 😉

Quellen:

• de.wikipedia.org/wiki/Content-Management-System
• wirtschaftslexikon.gabler.de/Definition/agile-softwareentwicklung.html
• de.wikipedia.org/wiki/Front-End_und_Back-End
• wirtschaftslexikon.gabler.de/Definition/scrum.html
• de.wikipedia.org/wiki/Wireframe
• duden.de/rechtschreibung/Pitch