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.

Lately I am learning a lot, I admit it!
Some months ago I joined our internal Slack channel #ask-scrum. Together with Léo we create challenging Scrum related questions for the subscribers . All questions are based on the theory contained in the Scrum Guide. Therefore, I am reading the Scrum “Bible” over and over again. :-)

Once we asked “It is possible to add or remove Product Backlog Items from the Sprint Backlog within the Sprint?” The answer is yes! “Yes, the Development Team can renegotiate the scope with the Product Owner.”
If the Development Team wants to renegotiate the scope, a Sprint Goal is needed. Otherwise it is hard to identify what is important and what is not. If the Development Team has a goal, they can add or remove some work to the Sprint, because it is beneficial to the Sprint Goal.
The Sprint Goal describes why the Development Team creates the Product Increment.
Together with stakeholders it is drafted during the Sprint Review, where Scrum Team talk about the next ToDos. It is official defined during the Sprint Planning and serves as the base for planning and every days work. Without the Sprint Goal the Development Team lacks a guidance and can’t reduce/increase the scope within the Sprint in a valuable way. The Sprint Goal is one of the key concepts of Scrum framework.

Does my Scrum Team has a Sprint Goal?

No!
Why? Defining a Sprint Goal is not easy as Scrum itself; “Simple to understand, difficult to master”.
The product which my Scrum Team develops exists for a long time and as we are in the so called “maintenance” phase, we have a lot of small enhancements – apparently unrelated to each other. Additional our clients don't necessarily have a clear vision and roadmap for the product, which makes defining a detailed goal even harder.

My learning

So basically I said “Ok this is fine, we can survive without a Sprint Goal". But I was missing an important point. Actually the Scrum Guide says “...The Sprint Goal can be any other coherence that causes the Development Team to work together rather than on separate initiatives.” This means, it does not matter whether you have a well defined product roadmap or you work on several small unrelated enhancements. The Sprint Goal will always help to work together.

Work together is the success

Does it mean we don’t work together as a Scrum Team? No, of course we do, but it is much harder. Having a common goal simplifies our daily live.

The key of all the story is: “without a Sprint Goal working together and implementing Scrum successfully is challenging”. Let's define one!

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.

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?

The Daily Scrum is to me the most important meeting of the day. The impact of this super short gathering is immense. How many times did we discover that we weren't on the right path, that two people were actually working on the same task, that oh, yeah, it's actually quite cool to talk to each other!

I could write pages and pages of key moments that happened during the “Daily” that saved us from actual (or future) difficult situations.

15 Minutes per Day

The thing is that we spend a lot of time dailying: 2h30 maximum* in a 2 weeks' Sprint, the only longer meeting being the Sprint Planning (4 hours maximum in that configuration). And because it seems fast and easy, we naturally tend to make it quick and dirty, especially because of the misunderstanding regarding the questions we answer there.

That's it from my side

What do I bring to the table? This is the part we usually share: “What did I do yesterday, what will I do today and what are the obstacles along the way?”. This is the part we all know, but this is just the beginning.

Help the team

What could I do to help the team? Meaning it is highly possible that I will do a way more things than “just” programming something.

Developing is important of course, but without deployment, discussions, tests, review, communication, re-tests, refactoring… development is useless.

To help the team, I can pair with a peer, fix the build, remove an impediment, prepare the review, assist the Product Owner, write a useful unit test, test the code of a fellow developer, review some code of my squad, support the Scrum Master, propose some help, etc.

Meet the goal

It is already a way more interesting: it's not only about me anymore, we are a team now, cool!

Ok but where do we go all together? What's the point of moving forward if we don't know where we go? The Sprint Goal, that mix between the Sprint Backlog (living during the Sprint) and the short sentence describing our objectives, keeps us focused and leads us to success.

Me, team, goal

Which brings us to the question to answer at the Daily, the real one from the Scrum Guide:

Heading to a lively Daily

And suddenly it is engaging! It's not only about me but about the whole team and how we plan and execute to achieve the Sprint Goal. Now we talk, now we share challenges and rise to them together. It's not a dead status anymore but a living exchange! We will naturally communicate what we've done, what we plan to do today and the obstacles along the way.

The Daily is about human beings gathered to target a goal. Every member of that trio (me, the team and the goal) resonates with the others. Like with a tripod, if you miss a leg, the ensemble falls. By doing so, the level of energy will rise, the day will be launched and you will look forward to the next one!

*10 days of work for a 2 weeks' Sprint so 10 x 15 minutes maximum per Daily = 150 minutes = 2h30 maximum all combined

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

Das Druids-Team bei Liip wendet deshalb für seine Drupal-Webprojekte das Wellen-Modell an. Wir haben es an unsere Bedürfnisse angepasst und arbeiten mit drei unterschiedlich hohen Wellen:

1. Prototyp
2. Minimum Viable Product (MVP)
3. Overachievement

Für jede Anforderung müssen mindestens die ersten zwei Punkte umgesetzt werden.

Ein Beispiel-Epic könnte so aussehen:

Als Websitebesucher

möchte ich alles über die Hausratversicherung der Versicherung X wissen

um entscheiden zu können, ob ich eine solche Versicherung brauche.

Flexibilität dank Wellen

Der Prototyp wäre in diesem Fall der Drupal-Contenttyp „Versicherungsprodukt“ mit all seinen benötigten Feldern, das MVP der fertig gestylte Contenttyp und das Overachievement könnte sein, dass automatisch Infos von Konkurrenten eingeblendet werden, damit auch wirklich verglichen werden kann (natürlich im Wissen, dass die Versicherung X ein besseres Angebot hat als die Konkurrenz).

Für jede Wellenstufe gibt es eine eigene User-Story, wobei natürlich auch die ersten zwei Stufen in ein und dem selben Sprint durchgeführt werden können, wenn beide Stories ready sind. Innerhalb eines Sprints sind somit Stories für Drupal-Backender und Frontender vorhanden, die parallel bearbeitet werden können, ohne dass eine Rolle auf eine andere warten muss.

In der unten stehenden Beispielgrafik würden während des Sprints 1 vom Epic A 2 Stories entwickelt (Prototyp und MVP), von Epic B und D nur je 1 (Prototyp) und Epic C würde bis zum Overachievement gebracht. Im Sprint 2 könnten dann beispielsweise die Epics B und D mindestens auf MVP-Stufe gebracht werden.

Dank dem Wellen-Modell kann bereits mit der Entwicklung begonnen werden, auch wenn das Visual Design noch nicht komplett fertig ist, da der Prototyp meist nur aus dem Contenttyp besteht. Der Kunde kann somit rasch mit dem Erfassen von Content in Drupal beginnen, da mit dem Prototyp bereits alles dazu vorhanden ist. Natürlich bedingt dann die noch nicht optimale Darstellung des Contents ein gewisses Vorstellungsvermögen, aber das hat sich gemäss meiner Erfahrungen noch nie als Blocker erwiesen.

Very slowly over time things stopped going as smoothly as they used to. The team couldn't finish their sprints and the velocity was going down. The sentence most often heard at the Daily Scrum was: “I don't know what's up with this ticket, person X is working on it” – a sign of “Gärtlidenken” as it is called in Switzerland. Information wasn't flowing as it should, even though we used the ‘Walk the Board' approach to keep Daily Standup meetings short and focused. Other Scrum meetings were long and inefficient and any further growth of the team was entirely out of the question.

This interesting blog entry about the numbers behind Jeff Bezos' two pizza rule for team sizes suggests that the problems the team were facing were possibly due to its size. Communication between all the people involved was complicated and it's impossible to know what's going on everywhere all the time. People focussing solely on the one task they picked is a logical move to push this problem out of sight. Yet, it is counterproductive for self-organising Scrum teams. It decomposes a team back to a group of people which happen to work next to each other on similar tasks rather than working together at achieving a shared goal.

Even though team Lego cannot be considered a very large team, problems were just around the corner. At 10 people, we were probably only beginning to see the problems that a larger team could bring. However, it's always better to act before the horizon's problems arrive at your door.

Just do it

But how does one go about splitting a scrum team that a) works on the same project and touches the same code every day, b) has only one Product Owner and c) likes working together? Creating two separate Scrum teams surely is a bad idea. It would decouple the teams and create too much overhead on the process side. Our setup required a more integrative approach that linked subteams more closely to each other and supported the work done on a single project, with one Product Owner, one client and – in our case – one Scrum Master, essentially a version of the Scrum process to support a multi team structure.

I discovered that LeSS (Large Scale Scrum) provides exactly that: it's a way to scale a one-team Scrum process to multiple teams. By limiting certain meetings to only representatives of subteams and introducing overall retrospective and coordination meetings it provides a lightweight scaling framework for the traditional Scrum process. Too much process overhead is prevented and teams are forced to self organise and make information flow because not everyone can participate in every meeting. Meetings are more effective and efficient, e.g. participants will be more active in meetings because they cannot rely on the rest of the team to do so. Plannings are shorter and retrospectives are more focused. It all sounded like a good approach to solve at least some of my team's problems.

The actual implementation was very simple, “just do it” really. We decided to give ourselves one sprint to figure things out and then start at the beginning of the next sprint with the new setup according to the LeSS framework. We made some alterations to the meeting setup described in LeSS. The team wanted to keep the weekly estimation meeting big because they felt that the value of getting everyone's input outweighed the inefficiency of a large meeting. Planning on the other hand, was done with two representatives of each subteam because the issues have been estimated already and it's just a matter of selecting the right amount. Retrospectives were held separately so that the subteams can improve and grow together as teams. LeSS suggests to have an overall retrospective together with the client and representatives of the subteams to talk about improvements concerning coordination issues. We didn't feel the need yet but are planning on doing that regularly every couple of sprints or as the need arises.

The first official act of each subteam was a small retrospective to talk about their respective working agreements and team names: Team Y and Team Duplo were born! Eventually we even changed the layout of our team working area and moved desks around to support pairing and collaboration within each team.

What we learned

After the first two sprints the change is already quite obvious. The velocity went up and so did the happiness of the team. The Daily Scrums are very fast and effective – and actually about developers sharing relevant information. Hardly ever does one team member not know what the others are doing, it feels like the “shared responsibility” for a sprint is back. There was a lot of positive feedback from my teams e.g. the developers find it much easier to judge if all the stories in the sprint will be finished with small sprints, there is less coordination cost within the subteams of only four people.

Overall, as the Scrum Master, I have the impression that the teams are a lot closer to the self organising Scrum Team ideal than before. There certainly are new challenges to face, like coordination between subteams (in architectural decisions for example), equal division of support work for the project is tricky, sickness and holiday obviously have a much higher impact on the sprints in a small team. During Christmas time and beginning of the new year we even decided to go back to being one team because there simply weren't enough people around for the subteams to work. Because of the small team size (4 developers, one Product Owner and one Scrum Master) a lot of pair programming is done to get around bottlenecks in the “Review” and “Test” lane on the Scrum boards.

The team agreed to treat the implementation of LeSS as an experiment and go back to being one big team if it doesn't work out for us. Nevertheless, I am confident that LeSS was the right choice for my team and the framework will help us to thrive and become even better at agile software development. We'll figure stuff out as we go along, inspect regularly and adapt if necessary.

I tried to make it clearer by rephrasing the words to something more suitable that all of the team members would understand (like ‘I can't take it anymore' instead of Mad and ‘Get stuff off my chest' for Sad for example, see this blog post by Mike Pearce). Although it helped, I still felt that the distinction was not 100% clear to everyone. Frankly, I got tired of having to explain it over and over again.

In a retrospective a few weeks ago when lots of those ‘in between' stickies were placed on the wall we joked about making a new column for them. During that retrospective I noticed that a lot of the time my team was talking about things that came as a surprise to them that had an impact on the sprint or their feeling towards the project and things that they were scared of that could threaten the project or fears they had about the project's current status. So I decided to add more columns reflecting that and came up with ‘Glad, Sad, Surprised, Scared'.

Retrospective vs. Futurespective

Adding a ‘Scared' column opens up the possibility to also talk about fears for the future, which is usually not part of a retrospective but rather a futurespective. However, these fears typically uncover risks and uncertainties relevant to future planning. It also helps me as a Scrum Master to better understand the team's feelings. Few people will talk about what actually scares them on their own. During the exercise I observed that once someone put a sticky in the ‘Scared' column, others followed. Of course most of the stickies covered the same topic. But simply realising that they all share the same fear helped them to see that it's not just their own private problem but that everyone feels that same way and that they actually needed to do something about it.

Surprise!

One can argue that stickies placed in a ‘Surprised' column would also fit in the ‘Glad' or ‘Sad' columns and that's true. And of course, stickies in that column cover a very broad spectrum of topics. But the value of this column is twofold.

Firstly, it helps to uncover things that arise unexpectedly – both in a positive and in a negative way. This way potential impediments can be spotted and dealt with or it can help to find out why a sprint failed (similar to the ‘Expected and Surprised' retrospective).

Secondly, ‘I am surprised that…' often uncovers a richer seam of information than simply ‘Glad' or ‘Sad'. It allows discussion about why it was surprising and how the person feels about it. Software developers tend to primarily add stickies like ‘Sad about the slow server.' or other very technical problems on the board. I felt that the ‘Surprised' column opens up a way to illuminate the other, more personal side of problems which helps the team members to better understand each other and their connection as a team.

Try it out and tell me what you think!

Maybe you are trapped in repetitive rituals and would like to do something about it? Last Wednesday I had been attending the Agile Breakfast in Zurich

titled “Organizing Retrospectives Effectively” with fellow-Liiper Christoph Meier.

Marc Löffler was going to address how we can make our retrospectives

better.

The event was organized by the Expert Committee “Lean, Agile, Scrum” of SwissICT. Many thanks for educating us in such

a splendid way!

Marc started with a slide that said:

Your Retrospective Sucks!

I was suprised – and not quite sure how to deal with what I had

read. Then I had to laugh. It's good not to lose one's sense of humor.

The slide's subtitle read: “…and what you can do about it”.

By the way, Marc's slides are available on slideshare.net if you care

to have a look.

For this blog post I was looking for some images of meetings. I

stumbled on this one: “The Indians giving a talk to Colonel Bouquet”

Source: wikimedia.org

Doesn't that meeting look interesting? Nobody is falling asleep.

Wouldn't we want to have more retrospectives like that? I mean,

we're not fighting wars like the proponents on the image did. But we'd

like to have purpose, and engagement, and …

What can we do?

Marc gave three reasons why retrospectives suck:

• too much and unfocused talking
• repetition
• no effect

As time passes, retrospectives often get less interesting (Marc's

slide):

Source: slideshare.net (slide by Marc Löffler)

We all like to pick the low hanging fruit first. Are we prepared for what comes after that?

Source: dilbert.com

The worst retrospectives are those that show no effect. Nobody looks

forward to such meetings.

Marc was going to cover three elements to address this:

• Purpose (know)
• More Fun (enjoy)
• Systems Thinking (understand)

Purpose

To get the purpose back into the retrospective, Marc wants us to

experiment. Your first reaction to that might be like mine: “Yeah

sure, that's going to ruin it totally. No structure ‘n all. Just

trying stuff!'”

But that wasn't what Marc had in mind. He was talking about

old-fashioned experiments (you know, Newton or Tesla and those

guys…):

An experiment is an orderly procedure carried out with the goal of

verifying, refuting, or establishing the validity of a hypothesis.

So in the 1st retrospective we would start with a hypothesis , for

example:

If we go to work on-site with the client we can have a better common

understanding and therefore we will have less disagreements with the

client.

Time passes and we have the 2nd retrospective where we do a

reality-check: could we verify our hypothesis? Did things turn out

like we thought they would?

No, we had even more disagreements with the client!

What we assumed turned out to be completely wrong.

But that's fine. That's the agile way. We learn. Remember: “Inspect

and adapt”. We refuted the validity Hypothesis Nr. 1. We then form a

new hypothesis. We will verify that one in the 3rd retrospective.

So that's Marc's way to bring back the purpose: through experiments we

approach our issues with methodology and our retrospectives should

become more effective.

We shouldn't be thinking in terms where we already expect the “solution” to work.

More Fun

Now we come to the More Fun element.

There are endless possibilities. Marc presented some pointers to get more fun into

retrospectives:

• Retrospective Cookies

• Change the Location

Source: wikimedia.org

and most importantly (in my opinion):

• Metaphors

To do this we set the stage by choosing a metaphor we'd like to

use. When Marc asked us for ideas, Christoph Meier suggested

to make a Construction Site Retrospective .

When your metaphor-based retrospective starts, you collect terms that

belong to the metaphor. Everyone should try to stick to these terms

when talking events that took place.

So for example, if the hosting provider for you new website was late

with giving you access you would say:

“We couldn't get to the construction site for four days because it was

locked and the owner was on holidays. We are running late now. We

should have completed the basement last week.”

Or if the requirements for a feature were not clear enough:

“The architect said that the wall should be 10 feet and I made it

so. But now the whole building is too wide!”

The benefits of such metaphors are (quoting Marc):

• Thinking outside the box
• New, creative ideas
• “Distance” to real events
• Fun!

Systems Thinking

Last but not least: we should be trying to understand the system we

are dealing with. We need to know which buttons to push. We don't want

to press the wrong buttons! Teams are not endpoints but nodes in a

system.

Assuming someone is sick, the doctor analyzes the given symptoms to

find the cause. If only the symptoms are treated, the patient cannot

get truly healthy. That's why the doctor looks at the whole organism

so he is able to identify the root cause, which might not be directly

related to the observed symptoms.

In our environment, we want to know how the different factors (like

the client, the team's morale, the budget etc.) influence each other.

If we forget to consider important factors, we can probably not solve

the issues at hand very well.

The approach suggested by Marc to understand the “system” is Systems
Thinking.

An example to do this is by using a Causal Loop Diagram:

Source: isixsigma.com

In this case we can see how individual aspects influence other aspects

in a wanted or unwanted fashion by having an increasing or decreasing

effect.

I believe we often focus too much on short-term problems and lose the big picture.

Closing

It was inspiring for me to hear about these options. I would like to

add that Marc has written a book on the subject called

Retrospektiven in der Praxis: Veränderungsprozesse in IT-Unternehmen

effektiv begleiten (in German only). I will hopefully read it soon.

Please contact me or Christoph Meier if you would like to share your

experience, have questions or corrections to make.

On the 26th of June we will be celebrating the grand opening of our

new office in Zurich. There will be an agile session “Agile – to be,

or not to be” in the afternoon where you can even meet me in person.

See the announcement for further details (and to register for sessions).

So long, see you later!

… and thanks to Christoph for helping me with this text.